[Python-ideas] A tuple of various Python suggestions
brett at python.org
Fri Apr 8 18:20:17 EDT 2016
On Fri, 8 Apr 2016 at 14:16 Keith Curtis <keithcu at gmail.com> wrote:
> Hi all,
> I just discovered this alias and I thought I'd post a few ideas. I
> wouldn't call myself a Python master yet, but it's an amazing language
> and my biggest wish is that it was more widely used in the industry.
> Here are a few suggestions:
> 1. Decrease the bug count. I recently noticed that there are about
> 5,400 active bugs in http://bugs.python.org/. That surprised me
> because I almost never see anyone complain about bugs in Python
> (compared to the number who complain about bugs in LibreOffice,
> graphics drivers, Gnome / KDE, etc.)
> There are a lot of people on this list, and if the brainpower can be
> applied to practical, known, existing problems, it is a great way to
> improve Python while also considering more exotic ideas. I can also
> suggest making a pretty graph of the bug count and putting it on the
> front page of python.org for greater visibility.
That bug count is misleading because it includes not only legitimate bugs
but also enhancement proposals.
> 2. Python is somewhat popular on servers, and there is a lot of
> potential for more. WordPress is easy to use and powerful, but lots of
> Codebases like Whoosh full-text search
> (https://bitbucket.org/mchaput/whoosh/wiki/Home) are important, but
> have minimal dev resources as most people are using Lucene /
> ElasticSearch. The common choice is between 1.3M lines of Java:
> https://www.openhub.net/p/elasticsearch, containing 1100 todos and
> 1000 references to "deprecated", or 41K lines of Python written mostly
> by one person.
> Hadoop is another big Java project (1.9M lines), and there is even an
> ecosystem around it. Python interoperates with Hadoop, but it should
> be possible to build a radically simpler framework that provides the
> same functionality using Python-native functionality and without all
> the baggage. Hadoop has several interesting sister projects: a
> distributed database, scalable machine learning, a high-level data
> flow language, a coordination service, etc. I'm sure you'd build
> something smaller, cleaner, faster in many cases, more reliable, etc.
> 3. It was a sad mistake that Google picked Java over Python for
> Android. However, there is now a great program called Kivy which
> allows people to write apps for IOS or Android with one codebase, but
> it could also use more resources, as for example it doesn't fully
> support Python 3.x yet.
> There are 10s of thousands of bugs in the popular Python libraries and
> I would fix those before proposing more language changes.
> 4. I enjoy reading about the Python performance improvements, but it
> is mostly a perception problem with all the existing workarounds.
> think Python would be fast enough. Lots of people write Node because
> it's compiled and "fast". I suggest taking some of the effort working
> on performance, and spend it on evangelizing to other programmers that
> Python / Cython / PyPy, etc. are already good enough! There are a lot
> of programmers out there who would be happier if they could work in
Two things. One, there is actually a good amount of performance work
potentially landing in Python 3.6. Two, we have been saying Python is fast
enough for most things for decades at this point, so this is an old issue
that's never going away.
> 5. It would be great to get Python in the web browsers as an
> LibreOffice ships with a Python interpreter, why can't Firefox and
> Webkit? ;-) Obviously there are interoperability issues, but it would
> server-oriented article, but it gives a flavor:
> http://notes.ericjiang.com/posts/751) This might sound like a crazy
> idea, but the engineering problems aren't that hard.
Once https://github.com/WebAssembly lands in the browser then it won't be
as much of an issue. There are also various transpilers of Python to
so this has been tried before. :)
> 6. In a few cases, there are two many codebases providing the same
> functionality, and none of them are really doing the job. For example,
> the de-facto MySQL Python interop library
> (https://pypi.python.org/pypi/MySQL-python) only supports Python 2.x
> and appears to be abandoned. There are several other libraries out
> there with different features, performance, compatibility, etc. and
> it's kind of a minefield for what should be a basic scenario. It takes
> leadership to jump in and figure out how to fix it and make one
> codebase good enough that the others can switch over.
> 7. Focus more on evolving the libraries rather than the language. I've
> recently discovered Toolz, which has a more complete set of functional
> language methods. I think some of them should be included in the
> official versions. A lot of people don't think Python is good enough
> for functional programming and this would help. These new routines add
> complexity, but a newbie doesn't need to write in a functional way, so
> it obeys the "only pay for what you use" rule.
> There are a number of under-staffed libraries and frameworks. I see
> people complain about the YAML parsing library being unmaintained, the
> default HTTP functionality being difficult and limiting, poor SOAP
> support, etc. There are a million ways to improve the Python ecosystem
> without making any language changes. You don't have a big rich company
> who can pay for thousands of full-time developers working on
> libraries, but the bug reports are a great way to prioritize.
> 8. I've yet to find a nice simple free IDE with debugging for Python.
> I use Atom, but it has primitive debugging. I tried PyCharm but it's
> very complicated (and not free, and Java). I use Jupyter sometimes
> also but I'd prefer a rich client app with watch windows, etc.
> 9. It would be interesting to re-imagine the spreadsheet with a more
> native Python interface. Pandas and matplotlib are great, but it would
> be cool to have it in LibreOffice Calc that supports drag and drop,
> copy and paste, can read and write ODS, etc. (Also, LibreOffice Base
> is basically unmaintained. I think if 10 Python programmers passionate
> about databases and GUIs showed up, it could re-invigorate this dead
> 10. Being simple to learn and powerful is very hard. Fortunately, you
> can break compatibility every 10 years. My only suggestion is to get
> rid of the __self__ somehow ;-)
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas