[SciPy-User] Naming Ideas

Josh Lawrence josh.k.lawrence@gmail....
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".

--Josh

On Sep 6, 2012, at 6:58 AM, josef.pktd@gmail.com wrote:

> On Thu, Sep 6, 2012 at 7:42 AM, Brennan Williams
> <brennan.williams@visualreservoir.com> wrote:
>> On 6/09/2012 10:41 p.m., Thomas Kluyver wrote:
>>> On 6 September 2012 01:58, Benjamin Root <ben.root@ou.edu> 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
>>> scipy-the-package.
>>> - 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
>>> searchability.
>>> 
>>> 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.
>>> 
>>> Thomas
>>> _______________________________________________
>>> SciPy-User mailing list
>>> SciPy-User@scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-user
>>> 
>> 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**.)
> 
> Josef
> 
> 
>> 
>> Brennan
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User@scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user
> _______________________________________________
> SciPy-User mailing list
> SciPy-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user



More information about the SciPy-User mailing list