[SciPy-User] Naming Ideas
Thu Sep 6 07:06:23 CDT 2012
What about SciPy backwards:
Ypics (or yPicS)
We could even pronounce it "epics" because having such a broad collection of packages would in some sense be "epic".
On Sep 6, 2012, at 6:58 AM, email@example.com wrote:
> On Thu, Sep 6, 2012 at 7:42 AM, Brennan Williams
> <firstname.lastname@example.org> wrote:
>> On 6/09/2012 10:41 p.m., Thomas Kluyver wrote:
>>> On 6 September 2012 01:58, Benjamin Root <email@example.com> wrote:
>>>> I am against deprecation because it serves an important purpose/niche.
>>>> However, I can imagine spinning pylab off as a new project that serves its
>>>> current purpose, but allows it to grow outside its current scope.
>>> This sounds reasonable. For instance, I've previously wanted to expand
>>> pylab to include bits from pandas, to make it more competitive with R.
>>> But the details of what goes in are a debate for another day, so let's
>>> not discuss that now.
>>> If we go down this route, I suggest that pylab should not include any
>>> code itself, so that we don't end up with pylab-the-package. Rather,
>>> it should just provide a namespace to access functions and classes
>>> from other projects.
>>> To summarise, the top 3 names so far, with the advantages and drawbacks of each:
>>> - Pylab: For: our community already has the major use of the name, and
>>> it's used in a vaguely similar sense, so we get a running start.
>>> Against: Confusion with existing meaning of pylab, getting pylab.org
>>> domain (no response yet from the owner)
>>> - Scipy: For: our community already has the main use, and it's
>>> probably even closer to the intended meaning (as in the scipy
>>> conferences and scipy-central). Against: confusion with
>>> - Unipy: For: No direct confusion with existing names. Against: We'd
>>> have to build up name recognition from scratch, for a community and
>>> set of projects that are not new. Similarity to Unipay might hinder
>>> I suggest that, if we can get hold of the pylab.org domain, we go for
>>> that - it strikes a balance between the existing name recognition and
>>> the difficulty of repurposing a name.
>>> SciPy-User mailing list
>> I don't think the Unipy vs Unipay searchability issue is that valid. The
>> question is whether Unipy encompasses the intended meaning and for me it
>> doesn't. Does it mean unify? Does it mean unicode? Obviously not the
>> latter, probably more the former.
>> I do agree with Thomas' comment about SciPy being closest to the
>> intended meaning. I understand that there are issues with the
>> scipy-the-family vs scipy-the-package etc type issues. However if you
>> mentally step a few years into the future I think everyone might be
>> comfortable with scipy being a "scipy related suite".
>> I prefer scipy to pylab but my comment above about a "scipy related
>> suite" would be equally applicable to a "pylab related suite". Possibly
>> one issue with pylab is, as one previous poster noted, it implies a
>> matlab clone approach. How much truth is in that I don't know as I've
>> never used Matlab and Matlab compatibility has never been of interest to me.
> That's also what I'm thinking with pylab: matlab imitation and no namespaces.
> I hope whatever we are talking about will be more. (a numerical
> kitchen sink in **Python**.)
>> SciPy-User mailing list
> SciPy-User mailing list
More information about the SciPy-User