Live data from Hacker News

Python 3: Ten years later

archive.fosdem.org

21–30 of 93 posts

Re: Python 3: Ten years later

#21
post #18

As an outsider who only uses Python when I need a specific tool that's only available through pip: it's still one of my biggest nightmares. Every single time I need to install something with pip on MacOS there is this hour-long struggle with figuring out how to get the correct version of Python (2.7 vs 3) working with the correct version of pip working with the correct version of the library itself. I don't know, I g…

Create a virtualenv and install the version you need of Pip there

Or use Anaconda, which is your own Python "Disneyland" but it is hard to interface with external infrastructure

Re: Python 3: Ten years later

#22
post #18

As an outsider who only uses Python when I need a specific tool that's only available through pip: it's still one of my biggest nightmares. Every single time I need to install something with pip on MacOS there is this hour-long struggle with figuring out how to get the correct version of Python (2.7 vs 3) working with the correct version of pip working with the correct version of the library itself. I don't know, I g…

with homebrewed python, i use 'pip2' or 'pip3' and haven't had an issue (or better yet, a virtualenv with the appropriate interpreter). don't use apple's default python. hope that helps!

Re: Python 3: Ten years later

#23
post #3

I wish they spent the effort on making Python 2 faster and removing GIL instead.

Why? I teach Python and c++ to A level students. They pick up the basics in a few weeks. C++ is pretty easy. We push our students through the c++ institute exam with few issues. Choose the right tool for the job. If you need speed, choose c

C++ is pretty easy!? Wow, that's an opinion you often don't hear. :-)

Re: Python 3: Ten years later

#24
post #13
post #6

Earlier quoted context omitted.

...or you could just use the unicode type in Python 2; like: all of my Python 2 software handled languages in other character sets correctly (and yes: this was stress tested often as I have had many many users from China and the Middle East). There was absolutely nothing wrong with Python 2 and Unicode, and if anything Python 3 just made a bunch of stuff impossible to do correctly (in particular encodings for filenam…

You have to be kidding. I don't even need to elaborate, people who actually used Python 2 know what I'm talking about.

You're suggesting the parent is lying about having used Python 2 and/or having felt that way?

Re: Python 3: Ten years later

#25
No, IMO. Don't get me wrong, Python 3 is a better language than Python 2. I just don't think it's that much better that it was worth breaking backwards compatibility and stalling the language for several years.

Python 3 did enough to break everyone's existing code, but nowhere near enough to make that worthwhile.

It's common for other language communities to consider the Python 2/3 transition as an example of "what not to do".

Re: Python 3: Ten years later

#26
I think Python 3 primarily showed that breaking backwards incompatibility across an entire ecosystem is worse than one could have predicted. Even today Python 2 is far from dead.

On the other hand the core development team "outsourced" many of the issues that people actually want to have solved to the community like packaging and distribution.

Python's biggest downfall is a highly academic approach with slow release cycles which makes large feature development hard and detached from the real world. Python 3's unicode model is completely outdated but was supposed to be the big feature of the version. While that was happening however the rest of the world started moving over to UTF-8. There was no feedback loop that could have enabled Python to be UTF-8 based. It was released and then decisions were locked in.

Similar things happened in asyncio. New versions of it only land with every major version of the language which meant that a lot of asyncio only became really useful with 3.6 and 3.7 which was years after it was initially created.

I have very high hopes that the new leadership of the language will be able to tackle some of these problems. Python 3 is way less backwards incompatible to 2.7 now than it was 10 years ago. The two versions moved closer to each other and today it's pretty easy to support both from a single codebase. With faster iteration we might have been able to cut this time short by 5 years or more

Re: Python 3: Ten years later

#27
post #18

As an outsider who only uses Python when I need a specific tool that's only available through pip: it's still one of my biggest nightmares. Every single time I need to install something with pip on MacOS there is this hour-long struggle with figuring out how to get the correct version of Python (2.7 vs 3) working with the correct version of pip working with the correct version of the library itself. I don't know, I g…

I use Ubuntu and it's the exact same thing for me, so I don't think it's MacOS-specific. To be honest, the whole versioning quagmire is the main reason why I don't use Python as one of my main languages, but just as an outsider like you. I like the language but I hate wasting my time with that kind of thing. Say what you will about Java, but you can just slap a jar file into a folder and it will work with the latest version, with zero drama.

Re: Python 3: Ten years later

#28
post #13

Earlier quoted context omitted.

You have to be kidding. I don't even need to elaborate, people who actually used Python 2 know what I'm talking about.

You're suggesting the parent is lying about having used Python 2 and/or having felt that way?

It's completely impossible to have used Python 2 and not having felt miserable under a pile of UnicodeDecodeErrors.

Re: Python 3: Ten years later

#29
post #3

I wish they spent the effort on making Python 2 faster and removing GIL instead.

Why? I teach Python and c++ to A level students. They pick up the basics in a few weeks. C++ is pretty easy. We push our students through the c++ institute exam with few issues. Choose the right tool for the job. If you need speed, choose c

agree with choose the right tool, and don't write it yourself. a beginner in c will struggle to beat python + numpy for speed, no matter how "fast" c is
Post reply on HN