Live data from Hacker News

Python 3.11

docs.python.org

131–140 of 156 posts

Re: Python 3.11

#131
post #101

Earlier quoted context omitted.

It's probably the most voiced complaint these days, unless core devs are deaf, I bet ten solid dollars they're gonna address that soon.

It’s been like this for over a decade. I wouldn’t hold my breath. By comparison, I’m pretty sure the Ruby community adopted bundler over a decade ago.

Maybe they were busy on other things. Py3k, async. Now these are settled I don't see what other defect needs to be worked on

Re: Python 3.11

#132
post #7

Earlier quoted context omitted.

No such problems on Linux, which is free and open-source. I think 'open-source' is the key.

I think you mean you don't have such problems on Linux, there are plenty of people who trip over the fact that the default python on RHEL https://www.ibm.com/support/pages/work-around-frustrating-py... https://unix.stackexchange.com/questions/468620/how-to-chang...

You are comparing apples and oranges, obviously. Perhaps some people are just unconsciously too enamored with apples.

OP's problem was not configuring default Python version as in your second link. Your first link is about some IBM stuff, and IBM is proprietary, so no comments there.

Neither was OP's problem about setting up Python on an old version of the Mac OS.

In any case, on old RHEL, you can just do something like this: https://www.2daygeek.com/install-python-3-on-centos-6/

Installing Python on Linux is much easier than you're trying to say.

For the the love of apples.

Re: Python 3.11

#133

Python is deceptive. They lure you in with its simplicity, and then one day you want to deploy your software and you realize that it's more complicated than any other programming language ever conceived of.

I don't know; I've just written something in .net/c# and it's pretty bloddy difficult to deploy.

.net/C# was one of the easiest to deploy in my experience. Just build a self-contained executable and you're done.

Re: Python 3.11

#134

Python is deceptive. They lure you in with its simplicity, and then one day you want to deploy your software and you realize that it's more complicated than any other programming language ever conceived of.

This is a solved problem. The community provides a handy system overview[^1] that should be good enough for most cases. [^1]: https://xkcd.com/1987/

Didn’t even need to open the link to know what it was, thanks for the laugh!

Re: Python 3.11

#135
post #132

Earlier quoted context omitted.

I think you mean you don't have such problems on Linux, there are plenty of people who trip over the fact that the default python on RHEL https://www.ibm.com/support/pages/work-around-frustrating-py... https://unix.stackexchange.com/questions/468620/how-to-chang...

You are comparing apples and oranges, obviously. Perhaps some people are just unconsciously too enamored with apples. OP's problem was not configuring default Python version as in your second link. Your first link is about some IBM stuff, and IBM is proprietary, so no comments there. Neither was OP's problem about setting up Python on an old version of the Mac OS. In any case, on old RHEL, you can just do something l…

Configuring the default python, also referred to as installing a new Python, is exactly what OP was doing.

The process in the supplied link, which is the same as the process you weirdly called IBM proprietary even though it has nothing to do with IBM, is essentially the same as the process on MacOS. Realize that the OS python is not what you want, enable a non-default package repository with a few shell commands, install Python.

Prejudice about anything to do with Apple aside, glad to see we agree that RHEL and MacOS have similar install processes.

Re: Python 3.11

#136
post #76
post #74

Earlier quoted context omitted.

Because of dependency management, or?

Because of having to know what WSGI and ASGI are and picking the right one. Then pick which implementation of the above you want to use. Then configuring it correctly for your app. And finally make it play nicely with nginx/apache/whatever. If on the other hand you're trying to deploy a desktop app, that is an entirely different kettle of 'fun'.

> Because of having to know what WSGI and ASGI are and picking the right one. Then pick which implementation of the above you want to use. Then configuring it correctly for your app. And finally make it play nicely with nginx/apache/whatever.

None if the Python in I deploy has to deal with any of that, all of which applies in a very narrow particular application domain. Even if it was a source of valid criticism, it would only be of using Python for that specific use, not generally.

Re: Python 3.11

#137

> When printing tracebacks, the interpreter will now point to the exact expression that caused the error instead of just the line. For example: Traceback (most recent call last): File "distance.py", line 11, in print(manhattan_distance(p1, p2)) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "distance.py", line 6, in manhattan_distance return abs(point_1.x - point_2.x) + abs(point_1.y - point_2.y) ^^^^^^^^^ AttributeError: 'NoneType…

Well if you like this, you are going to love 3.10 due for tomortow, because it's packed with a lot of error message improvements. Everybody talks about the pattern matching, but I'm excited about this. I'm going to upgrade ASAP just so for it.

Oh wow, I completely missed this in the release notes, probably due to not carefully reading them since earlier versions. This is amazing!

Re: Python 3.11

#138

Earlier quoted context omitted.

Care to elaborate on what is bad? How bad are they compared to other languages? (Assuming you are always accepting some tradeoffs when moving from one eco system to another)

It's painfully archaic compared to languages that have all this sorted out. Pip is a recipe for disaster, indicated by the huge amount of churn in the Python packaging sphere. It's constantly the worst part of my day whenever I pick a Python project up. Conflicting dependencies, non-deterministic installs, etc. I used to cope with this crap fest until I tried Elixir and experienced the beauty of modern package manage…

> non-deterministic installs

Things continue to improve. For example, Pip's resolver has been deterministic since around November 2020. Bringing something minimal into Python that provides deterministic builds (e.g. pip-tools) would help packaging a lot.

Re: Python 3.11

#139
post #42

Earlier quoted context omitted.

4 hours? Yeesh. Here's how to do it in 5-10 minutes. Use pyenv to install any python version and pyenv-virtualenv to manage virutal environments. https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv-virtualenv

For me, pyenv on Mac is about 15 minute compile time with a bunch of environment variables required to make sure tkinter works properly.

Use miniconda. It's much better.

Re: Python 3.11

#140
post #122

Earlier quoted context omitted.

Please enough of this. Trying spending 2 minutes googling it. Hint: pyenv

If you spend 2 minutes googling it (or even just reading HN comments here), you'll get various people recommending venv, pyenv, poetry, conda, pyflow and probably a whole bunch of deprecated stuff, where it's totally unclear to outsiders which one to use.

Fwiw if you are an outsider, having gone through this exact issue myself recently start with venv: https://docs.python.org/3/library/venv.html

It is a standard library module and serves as the base functionality, most the other things you list are third party tools that build on the venv concept in various ways.

Once you grok venv, you will be in a position to understand if those tools can provide value to your particular situation.

Post reply on HN