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

Python 3: Ten years later

archive.fosdem.org

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Python 3: Ten years later

#41

Post by singularity2001 »

mehrdadn wrote: post #20
iagooar wrote: 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 don't have a Mac and maybe you've already tried this, but just in case, you can always do python2 -m pip install ... or python3 -m pip install ... to make sure it's running within that particular Python installation. You can use the --user flag to install to your user directory as well, if the system level is annoying.

why is it that the pip command can't handle what it's supposed to do, instead you have to resort to `python3 -m pip install`?

Hell, it even breaks itself:

pip install --upgrade pip # => pip unusable

https://github.com/pypa/pip/issues/5447

https://github.com/pypa/pip/issues/5221

etc

Re: Python 3: Ten years later

#42

Post by randomsearch »

Nope.

But it survived, which is the important thing. I thought 3 would kill Python, but it has survived and that is a very good thing.

Anecdotally, non-nerds fins python easier to read than other popular languages. It’s become the go-to language for a bunch of domains that reach outside core nerding (data analysis, education, DSL like stuff) and I predict Python will therefore be widely used in 2050, and probably be popular aged 100.

Re: Python 3: Ten years later

#43

Post by klipt »

Joeboy wrote: post #31
Santosh83 wrote: post #23

Earlier quoted context omitted.

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

As in "pretty easy to introduce catastrophic errors with".

If you use the right features of C++17 errors are easier to avoid than ever.

The problem is that this elegant subset of C++ is hidden inside ... the rest of C++.

I guess that's the counter example to Python's 2/3 breaking change. C++ just keeps adding new features while retaining all the old ones for backwards compatibility, even if they're awkward in context of the new language.

Re: Python 3: Ten years later

#44

Post by bespoken »

Python almost became my main language, but I moved to another language when I saw it was stuck at 2.7. Another reason was the lambda's only allowing 1 line instead of the flexible closures in so many other languages. And my expectations for future improvements were very low as the core maintainer looked quite stubborn to me.

Re: Python 3: Ten years later

#45

Post by rurban »

avian wrote: post #40
the_mitsuhiko wrote: post #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…

> 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. I’m not sure what you mean. Are you suggesting that Python use UTF-8 encoded strings internally instead of decoded Unicode codepoints like it does currently? I’ve worked on Perl that uses that approach and it’s an absolute nightma…

The python nightmare is purely performance due to its use of the UCS-2 or 4 encoding (wchar_t without surrogate pairs). UTF-8 was ruled out for its inability for direct indexing, but this proved wrong. 4x longer string buffers trash the cache much more than the needed CPU cycles for utf-8 decoding.

perl's problem is that they didn't make room for the original encoding, it's only latin-1 or utf-8 from everything else. so the context needs to store it, like IO, process. and for performance they silently loose the utf-8 flag for 128—255 codepoints.

but all this is still better than the libc/POSIX design failure to use ENV vars, where the encoding is global, not localized. every single string API needs to do a getenv, and its interpretation is action at a distance.

Re: Python 3: Ten years later

#46

Post by Sir_Substance »

Michaelanjello wrote: post #12

There are still idiots on Github using Python 2 for new projects. These are usually academics who don't actually share any love for technology. Their code will never be used by anyone.

>Their code will never be used by anyone.

Critical FORTRAN libraries are still the center of certain types of analysis, and they're often used by _everyone_ in the field.

The reason for that stems from two issues:

1. Making accurate simulation libraries for things like weather formation, magnetic field formation or hydraulic fracturing requires crazy in depth knowledge of the systems you are modelling, and takes years of implementing and hypothesis testing to ensure they are accurate enough for academic use.

2. Academics are not software developers, they don't get paid for the software they write, they get paid for papers. They get no reward for rewriting those crazy indepth libraries every decade in the new language de-jour.

This is a perfect example of why the python2 to python3 hard-cutoff transition was a terrible idea. "Just update your software" is something you can say to professional software developers with a straight face. You can't say it to academics, or mechatronics engineers, or real estate agents, or photographers, or _anyone else_ who has a job that benefits from a little bit of software but is mostly about delivering something other than software.

Well, you can, but they're going to ignore you.

Re: Python 3: Ten years later

#47

Post by mrweasel »

the_mitsuhiko wrote: post #35
mrweasel wrote: post #32

Earlier quoted context omitted.

We where able to delete so much code when we switched to Python 3. When you integrate with especially Windows system converting unknown text was tricky at best. It’s not that Python 2 couldn’t do it, but the corner cases and error handling was a pain. Trying to guess encoding at runtime was pretty error prone, with Python 3 it just works. Python 3 was a rocky transision, but I never understood the negativity and I’ll…

I think this is largely a second system result. If you want correct unicode handling it's not harder in 2.x than in 3.x. The main reason unicode support was more complex in 2.x for the most part is that many APIs supported working with Bytes and on 3.x that burden is pushed to the API consumer. > Trying to guess encoding at runtime was pretty error prone, with Python 3 it just works. You should not guess on 2.x eithe…

>on 3.x that burden is pushed to the API consumer

So for most people it's better. The same goes for the guessing encoding part. Sure, you really shouldn't, but sometimes you had to and then you end up with chardet all over the place. Python 3 may do the exact same behind the scenes. The thing is that the Python core developer are much more talented than I am, so now I get to not think to much about it and just build on their work. From the "regular end-user developer" it's better.

Re: Python 3: Ten years later

#48

Post by pacifika »

upofadown wrote: post #34
Michaelanjello wrote: post #12

There are still idiots on Github using Python 2 for new projects. These are usually academics who don't actually share any love for technology. Their code will never be used by anyone.

There has been a pledge by the largest group of Python developers not to mess around with Python 2. So if you want your code to be able to just run forever without any concern for all the new and exciting language ideas being loaded into Python 3 then Python 2 is the logical choice.

As long as you don’t need to connect to sites using https

Re: Python 3: Ten years later

#49

Post by avian »

rurban wrote: post #45
avian wrote: post #40

Earlier quoted context omitted.

> 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. I’m not sure what you mean. Are you suggesting that Python use UTF-8 encoded strings internally instead of decoded Unicode codepoints like it does currently? I’ve worked on Perl that uses that approach and it’s an absolute nightma…

The python nightmare is purely performance due to its use of the UCS-2 or 4 encoding (wchar_t without surrogate pairs). UTF-8 was ruled out for its inability for direct indexing, but this proved wrong. 4x longer string buffers trash the cache much more than the needed CPU cycles for utf-8 decoding. perl's problem is that they didn't make room for the original encoding, it's only latin-1 or utf-8 from everything else.…

> it's only latin-1 or utf-8

There’s no other way, is it? You basically have to have the complete string library re-implemented for each supported multi-byte encoding.

Re: Python 3: Ten years later

#50

Post by mehrdadn »

singularity2001 wrote: post #41
mehrdadn wrote: post #20

Earlier quoted context omitted.

I don't have a Mac and maybe you've already tried this, but just in case, you can always do python2 -m pip install ... or python3 -m pip install ... to make sure it's running within that particular Python installation. You can use the --user flag to install to your user directory as well, if the system level is annoying.

why is it that the pip command can't handle what it's supposed to do, instead you have to resort to `python3 -m pip install`? Hell, it even breaks itself: pip install --upgrade pip # => pip unusable https://github.com/pypa/pip/issues/5447 https://github.com/pypa/pip/issues/5221 etc

Well pip is only one command, so it can't simultaneously work for both Python 2 and Python 3. And if you happen to have another installation of Python or pip in your path (e.g. at the user-level) but not have the other one there, then they'd affect different installations entirely. When you run it via Python you know it's affecting exactly the same installation.

Upgrading pip itself is kind of a special case I think. You don't want to upgrade stuff managed by a system package manager using pip; their work will conflict with each other. This includes pip itself. I think this is kind of a mess and I don't know of a great way to deal with it other than just remembering not to upgrading system packages using pip (yes this includes pip itself, and means you should avoid trying to upgrade via --user if it's installed on the system). On Windows where I am it's ironically less annoying since there's no system-level package manager to worry about... go figure.

Post reply on HN