On Mon, Apr 7, 2014 at 9:38 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > Hi, > > 2014-04-07 3:41 GMT+02:00 Nathaniel Smith <n...@pobox.com>: >> So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: >> http://legacy.python.org/dev/peps/pep-0465/ > > I'm not convinced yet that there is enough usage of Python in > mathematical world to modify the Python language to add a new > operator. Python is used for a lot of different use cases, in a lot of > domains. I'm not sure that it's a good thing to modify the *language* > for a specific domain. But you can do a lot without modify the > language :-) > > I'm a little bit surprised by the "Count of Python source files on > Github matching given search terms" table, it's very different from > these statistics: > http://python3wos.appspot.com/ > > Where are six, pytz, mock, webob, etc. in your table? (all modules > which come before "numpy" in the "Python 3 Wall of Superpowers")
They'd be down in bottom half, with ~30-50k total. (You can check easily by running the search yourself :-).) PyPI downloads are not a great proxy for usage, for a number of reasons. The way to get really big on PyPI downloads is to be depended on by a lot of projects get deployed often :-). This is very different from being used directly in lots of different files. Consider also that probably a majority of numpy users get numpy (and python, etc.) by using one of the many specialized scientific python distributions that different companies and people maintain: http://www.scipy.org/install.html#scientific-python-distributions and also that using pip to install scientific packages basically never works, so no-one uses the pip -r requirements.txt system for deployment... >> But isn't it weird to add an operator with no stdlib uses? > > I agree that it sounds weird :-) Maybe we should start by putting some > parts of numpy/scipy/sage/pylab/panda into the stdlib? (I'm not sure > that the new statistics module is such beginning.) There are many reasons why this is not a great idea in the short term -- including the problem mentioned a few sentences after the one you quoted, which is that @ seems to be a precondition to getting consensus on a numeric array duck type, which in turn would be a precondition to putting an array type into the stdlib ;-). So while putting numpy into the stdlib is probably a bad idea regardless, even if we wanted to do it there's a chicken-and-egg problem. > -- > > It would be nice to support A × B too, because it's much more > readable. You can configure a keyword to write arbitrary characters. > For example, on Linux you can write × using "Compose x x" if you > configured the Compose key. Or sometimes, you can replace "@" with "×" > using your favorite text editor (copy-paste from another script, from > a webpage, or something else). Sounds like a pretty major violation of TOOWTDI... -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
