Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.11

docs.python.org

Post reply on HN
Print view View original

151–156 of 156 posts

Re: Python 3.11

#151

Post by mbreese »

wutbrodo wrote: post #148
mbreese wrote: post #44

Earlier quoted context omitted.

It's pretty common to have kept `/usr/bin/python` as Python2. This is the most conservative option and won't break anything that's already running. Anyone who is using Python currently will have already installed Python 3 (or knows how to do this), and is probably using `#!/usr/bin/env python3`. As an OS vendor with many (many...) systems in the wild, you don't want to switch Python versions on people unexpectedly. E…

Oh, sure, it's definitely not a good idea to change what the unqualified python binary refers to. But I interpreted "refusing to ship an up-to-date global python interpreter with macOS" as meaning that Python3 isn't shipped at all, with the binary name "python3"). Is that the case? If so, I still don't understand the reasoning.

I don’t think anything in macOS (the base OS) requires Python, does it? If not, then, I don’t see why Apple would want to ship any Python with the OS. Let people install the Python version they want and then the users will have to maintain it.

Re: Python 3.11

#152

Post by eink-reader-32 »

EmilStenstrom wrote: post #54
eink-reader-32 wrote: post #50

I noticed on https://www.python.org/downloads/ I only see up to python 3.9. Where is 3.10 and 3.11 downloads? whats the best way to install python?

3.10 will be released tomorrow. 3.11 is still very much work in progress and is expected to drop in 2022.

Thanks this is what I was looking for. Don't know why i was down-voted for asking

Re: Python 3.11

#153

Post by throwaway81523 »

pletnes wrote: post #130
throwaway81523 wrote: post #111

Earlier quoted context omitted.

It would sure be great if they made it easier to break to the debugger in case of an unhandled exception, like (setq debug-on-error t) in Emacs Lisp.

This can be done in some IDEs. Although it can get confusimg if you’re working in an app framework that does some sort of catch-all exception handling.

Yeah it seems to me that regular Python should be able to do it though.

Re: Python 3.11

#154

Post by lacker »

isoprophlex wrote: post #61
lacker wrote: post #55

Earlier quoted context omitted.

It's still a mess, honestly. They tried to standardize on venv but since it doesn't deal well with Python libraries that depend on non-Python components, conda is still better for many purposes.

Can you give a specific example? I've had nothing but pain with conda in mixed linux/mac/win environment at work, and actively worked to get it deprecated. We're on plain venvs now, with the occasional setup.py Curious if I missed some useful case for it. - very slow dependency resolvers - using conda in docker is annoying - the worst thing: inconsistencies in downloading binaries and other resources between win/mac/…

Here's an example, let's say you're developing GPU code that needs to work with different CUDA versions on different machines. Look at the `cupy` install instructions for example:

https://docs.cupy.dev/en/stable/install.html

With conda this installation tends to just work, conda will also install the non-python cudatoolkit for you. With pip you have to either make all your python developers set up their c++ environment the same way as well, to install from source, or set a fixed cuda version that all users have to be on.

Now `cupy` is just one python library that has non-python dependencies. If your project has several dependencies like this, where conda is a one line install and pip means you have to mess around with your c++ environment, conda is probably the right choice for you.

All of the pain you mention with conda is totally correct, though, it's just a question of which sort of pain happens to be worse for the packages you are going to use.

Re: Python 3.11

#155

Post by wutbrodo »

mbreese wrote: post #151
wutbrodo wrote: post #148

Earlier quoted context omitted.

Oh, sure, it's definitely not a good idea to change what the unqualified python binary refers to. But I interpreted "refusing to ship an up-to-date global python interpreter with macOS" as meaning that Python3 isn't shipped at all, with the binary name "python3"). Is that the case? If so, I still don't understand the reasoning.

I don’t think anything in macOS (the base OS) requires Python, does it? If not, then, I don’t see why Apple would want to ship any Python with the OS. Let people install the Python version they want and then the users will have to maintain it.

The comment I asked rhe question of said:

> the problem is apple. they are (understandably) refusing to ship an up-to-date global python interpreter with macOS

Ie the claim is that it's causing a problem for users. I don't have an opinion about this point, but it is the premise of my question.

Re: Python 3.11

#156

Post by mrlonglong »

gypsyharlot wrote: post #71

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 recently wrote a python script to handle serial communication and uploading of a bare metal binary to my RPi3, this saves me so much time debugging now that I don't need to swap SD cards continually. Excellent tool.
Post reply on HN