[SciPy-User] Naming Ideas
Thu Sep 6 06:58:52 CDT 2012
On Thu, Sep 6, 2012 at 7:42 AM, Brennan Williams
> 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
More information about the SciPy-User