4 ms·

The earlier versions of 3.x (3.0, 3.1, etc) yes they sucked. But then again you didn't have to switch immediately. But it was kinda "expected" that these first

The earlier versions of 3.x (3.0, 3.1, etc) yes they sucked. But then again you didn't have to switch immediately. But it was kinda "expected" that these first versions were a bit unstable. Now people are using that as an excuse to say "Python 3 is bad?" No, sorry. I'm happy they went from ASCII to Unicode. (hey, people didn't want to use 'setdefaultencoding' for pure BS reasons, so, yeah, you got it coming!)

dagw 5y ago
The main problem wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. In an alternate universe where the python core developers had coordinated with a handful of the most popular libraries and announced 3.0 with at least usable beta versions of those libraries being available then I imagine the reception being very different.
- raverbashing 5y ago
  > wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. Well, that counts to me as a version fault as well (especially since things like venv were green to say the least), but yes, a coordination would have been helpful. Though it's a bit of a chicken/egg problem.
- zerkten 5y ago
  There wasn't an expectation that libraries would work nor was there an expectation that the transition should be quick. That's from listening to conversations at PyCon 2008 and 2009. Back then I got the feeling that this would result in a bumpy ride later on, but accepted it because I was new to Python. It has similarities to how packaging was treated historically. I think this precipitated a number of other problems which meant that by Python 3.3 and 3.4 inertia had set in. There appeared to be a bit of a panic that code wasn't being brought over from Python 2. This resulted in flipflopping on a recommended approach which I would argue was an unnecessary problem. There should have been a deeper assessment of the situation. It was was only in this timeframe that differentiated features started appearing for CPython 3. My experience from the PyCons when CPython 3 was in the early versions was that attention went to possible alternative runtimes. There was a lot of energy going into PyPy, Unladen Swallow, and the like while language features for regular devs were limited. It's only later that a coherent strategy started to form around porting libraries, providing clear and unchanging guidance on migration to Python 3, and big projects committed to migrating. I'm missing a few things, but this combination started to build real momentum. The backend runtime stuff and the limitations of CPython still existed, but Cython and other tools helped ML usage of Python grow. I don't think people who weren't Python fans would have predicted that given the performance constraints.
whoknowswhat11 5y ago
But the intentionally seemed to screw folks who needed ASCII - and hey - a lot of web protocols were ASCII at the time. Sure, do the unicode thing. But if someone needs to deal with ASCII they need to deal with it. And python 3 was pathetic here. Some folks wrote some very clear posts about this I wish I could find as they explain it a lot better than I ever could.
- raverbashing 5y ago
  > But if someone needs to deal with ASCII they need to deal with it. Of course. Also byte strings were not there yet IIRC in those earlier versions. But you could deal with it. .decode/.encode to ASCII never stopped working But beats annoying the rest of the world that needed to deal with non ASCII strings.

dagw 5y ago

The main problem wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. In an alternate universe where the python core developers had coordinated with a handful of the most popular libraries and announced 3.0 with at least usable beta versions of those libraries being available then I imagine the reception being very different.

raverbashing 5y ago
> wasn't that 3.0 and 3.1 'sucked' or where unstable, it was that basically no libraries worked. Well, that counts to me as a version fault as well (especially since things like venv were green to say the least), but yes, a coordination would have been helpful. Though it's a bit of a chicken/egg problem.
zerkten 5y ago
There wasn't an expectation that libraries would work nor was there an expectation that the transition should be quick. That's from listening to conversations at PyCon 2008 and 2009. Back then I got the feeling that this would result in a bumpy ride later on, but accepted it because I was new to Python. It has similarities to how packaging was treated historically. I think this precipitated a number of other problems which meant that by Python 3.3 and 3.4 inertia had set in. There appeared to be a bit of a panic that code wasn't being brought over from Python 2. This resulted in flipflopping on a recommended approach which I would argue was an unnecessary problem. There should have been a deeper assessment of the situation. It was was only in this timeframe that differentiated features started appearing for CPython 3. My experience from the PyCons when CPython 3 was in the early versions was that attention went to possible alternative runtimes. There was a lot of energy going into PyPy, Unladen Swallow, and the like while language features for regular devs were limited. It's only later that a coherent strategy started to form around porting libraries, providing clear and unchanging guidance on migration to Python 3, and big projects committed to migrating. I'm missing a few things, but this combination started to build real momentum. The backend runtime stuff and the limitations of CPython still existed, but Cython and other tools helped ML usage of Python grow. I don't think people who weren't Python fans would have predicted that given the performance constraints.

whoknowswhat11 5y ago

But the intentionally seemed to screw folks who needed ASCII - and hey - a lot of web protocols were ASCII at the time. Sure, do the unicode thing. But if someone needs to deal with ASCII they need to deal with it. And python 3 was pathetic here. Some folks wrote some very clear posts about this I wish I could find as they explain it a lot better than I ever could.

raverbashing 5y ago
> But if someone needs to deal with ASCII they need to deal with it. Of course. Also byte strings were not there yet IIRC in those earlier versions. But you could deal with it. .decode/.encode to ASCII never stopped working But beats annoying the rest of the world that needed to deal with non ASCII strings.