Ask HN: What do you want to see in Python? | Hacker News Reader

Ask HN: What do you want to see in Python?

32 pointspyeu29 comments

Howdy HackerNews!

I'm interested in HackerNews feedback and feature requests for Python. I am posing this question to the garrulous HN crowd, so I'm excited about it, and I'm sure this will be interesting!

Please include in your replies the following bullets: - HEADLINE: 1-line description of the request

- DESCRIPTION: A lengthier description of the feature. Bonus points for constructive criticism ;-)

We're super interested in your feedback!

Thanks, HN!

View on HN

Real threads.

For better or for worse, Python is the language of deep learning. We're going through all sorts of contortions to make it scale to large datasets, and the biggest problem is that Python is single-threaded for practical purposes.

I know all about the GIL and how difficult it is, but as a user, I don't care about any of that. The moment a similarly usable language comes along that does have working threads, I'll use it. I hope that language is also Python.

C++ is the language of deep learning. Python is the scripting language on top of it.

Real threads don't scale outside a single machine easily and it's adding allot of hazards that should be abstracted away. We don't want a dataset interface that makes a developer worry about race conditions. The pythonic way is to use one of those "contortions" because they are actually useful production-grade abstractions that let you scale beyond a single machine. Dask ( https://dask.pydata.org/en/latest/ ) is superior to threads for handling large datasets IMHO.

And if you're wanting something primitive then use cooperative threads like gevent, asyncio, or twisted.

Cython has “with nogil:” not sure if appropriate.

Unfortunately, Julia doesn't have a good multi-threading story as of yet. But `Base.@threads` works pretty in many cases, so perhap looking to that and the Knet.jl package?

why can't you use multiprocessing?

Copy on write for large datasets = bad.

- More explanation/docs of the concepts & structures in asyncio

- Some descriptions & examples of the constructs in the asyncio module, and what kind of problems you'd use each construct for would go a long way. IMO the API docs are too detailed to be able to learn from vs reference[0]. Perhaps a HOWTO is the kind of level I'd be looking for[1]. Or maybe this already exists but I'm using bad search terms.

[0] https://docs.python.org/3/library/asyncio.html [1] https://docs.python.org/3/howto/index.html

Another LTS release would be cool. Toward the end of 2011[1], it was announced that python 2.7 that would be supported until 2020[2]. With 8 years of support, this effectively made 2.7 into an LTS release. It would help 2->3 migration efforts if there was a python 3.x LTS release.

[1] https://www.python.org/dev/peps/pep-0404/ [2] http://legacy.python.org/dev/peps/pep-0373/#update

Isn't 3.x essentially LTS (team has decided on at least 12-2021) just without that name applied to it, just like you're saying about 2.7?

Sorry, I'm just a little confused.

From what I can see, they are doing 5 years for each 3.x point release[1].

> By default, the end-of-life is scheduled 5 years after the first release. It can be adjusted by the release manager of each branch. Versions older than 2.7 have reached end-of-life.

3.3 and lower and already considered end-of-life. 3.4 will be end-of-life next year.

I'm not sure if 5 years is a reasonable length to be considered LTS, but it seems like it should be long enough for most people.

[1]: https://devguide.python.org/#status-of-python-branches

My main pain points with python currently are distribution and GUI. PyInstaller is working fairly well at the former, but is by no means perfect. For GUI, there are a lot of options, but they all come with suboptimal trade-offs (licensing, non-native look, dated look, etc).

The recent features that have been added have been amazing, though. The new Windows installer, type hinting, asyncio, and f-strings have all made my life easier.

I definitely agree - I've always felt frustrated by the quality of GUI toolkits in Python. Pyglet and Kivy seem like the best I could see (PyQt is licensed), but everything in the 'gallery' seemed sort of simplistic or

On a similar note, it would be really helpful if library maintainers (e.g. PyGame) would express somewhere that they're looking for a designer to help make their website easier to use. I'd offer my (very basic) help, but I'm worried about offending someone if I ask to redo their website. This isn't necessarily porting to a 'minimalist' or 'modern' theme, but simple things like emphasizing the intended UX, increasing readibility, organizing in a helpful way (e.g., a gallery should be split by type of application so that a business doesn't have to trawl through a bunch of games wondering if they can use this for their application).

I'm keeping an eye on the BeeWare project[1]. They seem to be doing interesting work in both of those spaces as well as mobile development. They also do a very good job of helping new contributors[2].

[1]: https://pybee.org/

[2]: https://pybee.org/contributing/how/first-time/

I'd like to see van Rossum drop his anti-functional sentiment, but at the same time I suppose there are much better languages for that.

Actual anonymous functions. Not just lambda expressions.

Subjective but makes for unreadable code.

1. Type safety!

Run time type hint checks in the standard library, small performance impact allowed.

2. Compilation/optimisation using your hints

Like cython but using python's own type hints so you can give the compiler type information without leaving valid python.

As a python aficionado, I am really concerned that Python might eventually become the new Perl. Golang has pretty much replaced python for most of infra level projects.

1. Python needs to get JIT support (interfaces to dynamically JIT), beyond PyPy.

2. Type Safety. Type hinting is a good start. I love the direction projects like mypy is going. Allow programmers to mention types for functions which can be then JITed.

Packaging still seems cumbersome to me although to be fair I don't think any language/community has sorted this yet.

PIP, Anaconda, environments, ... too many concepts for a newbie. And too tedious for the experienced.

Python has just about everything it can have without breaking compatibility. Also believe 3.7 is in feature freeze.

The remaining hurdle appears to be performance. Perhaps bundling cython or pypi is doable?

Successful Gilectomy so we can use shared-memory multi-threading!

Curly braces, non-significant whitespace, sigils...

Oh wait, we already have that. It's called Perl! :-D

Remove the GIL

gilectomy might not be coming around soon, I guess.

Brackets, ffs.

    from __future__ import braces

Reply on news.ycombinator.com