I never knew that despite Python 3 is called the future by PSF and has been around for a ling time, people still want to stick to Python 2. I mean it isn't the 2013 that libs aren't ported, most famous ones generally are ported. Don't know what the problem is.
Why I'm Making Python 2.8
131–140 of 392 posts
Re: Why I'm Making Python 2.8
#132Earlier quoted context omitted.
Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files. Yes, the built in csv module really does that in Python 3.
Yes, the built in csv module really does that in Python 3. If you pass it bytes, yes, it does. If you pass it strings, no, it doesn't. If what you pass to the built-in CSV writer is not a string, the CSV writer will call str() to get a string representation it can write out. The string representation of a bytes object includes the 'b' prefix. Meanwhile, you discovered your bug: you were treating bytes as text, which…
I had this problem.
It doesn't "blow up". If it blew up and retired, I would have seen the problem. The problem, like several python 2/3 incompatibilities, is that Python 3 merrily did something different, without telling anyone, until eventually we track down what has changed. I spent quite a while on this very bug myself, and it, along with others, persuaded me to switch to a different language (serious I know, but I was just getting annoyed with python's general loose dynamic nature, in combination with the python 2/3 changes.)
Re: Why I'm Making Python 2.8
#133Earlier quoted context omitted.
Companies with Python code are probably better off keeping their working, tested code than switching to an incompatible interpreter and set of libraries which among other things will print "b'Hello',b'World'" into their mission critical CSV files. Yes, the built in csv module really does that in Python 3.
But people that have that csv issue have deeper lurker encoding issues they're probably not aware of. Sure, don't change the stuff that works and cause yourself unnecessary pain, but don't blame python 3 for your misencoded data.
Oh we are perfectly well aware of our encoding issues. In NumPy, one of the most important libraries in Python 2 or 3, strings always take one byte per character. And it's not going to change. So the built in csv module needs to support a reasonable behavior. Which it does not.
If a company tries Python 3 and discovers basic things like CSV produce utter gibberish, they would do well to opt out. And they do--in droves.
My data is not misencoded, you see. It's just misunderstood.
Re: Why I'm Making Python 2.8
#134Earlier quoted context omitted.
What makes something obsolete in your eyes then? Just because some people want A to replace B, that makes B obsolete? For reference, Oxford dictionaries define (..."define"? are multiple dictionaries involved here?) "obsolete" as: 1. no longer produced or used; out of date. Clearly Python 2.7 is in widespread use, and version 2.7.12 came out just a few months ago, so it's neither "no longer produced" nor "no longer u…
Python 2.7 is outdated by Python 3.5. The fact that there is a bugfix release doesn't change that. I mean look at other things. You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards. Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied i…
> You can still program in C 89 or FORTRAN 77 or COBOL 74 (and no doubt there is somebody still supporting compilers and runtimes for those), but they are all obsolete standards.
The situation with C89 and Fortran 77 is completely different than what you see today with Python 2 vs Python 3. For 99.9999% of C89 and Fortran 77 code you can build the old code with new C and Fortran compilers and use it from today's standards. You can take a piece of code written 30 years ago, recompile it and it usually works.
Re: Why I'm Making Python 2.8
#135I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
> "Please, do not put obsolete software on life support."
The vast majority of current development out there is in python 2.x. A small minority use Python 3.x. How on earth does this make Python 2.x obsolete?
This is like saying Perl 5 is obsolete, just because Perl 6 is out and completely ignore the realities of the real world use of the products.
Re: Why I'm Making Python 2.8
#136Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. Python 3 I think people and businesses with python 2 code would be better off moving their code bases to python 3 instead of doing things like this.
> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. S…
That seems kinda petty. Surely you can work around that. If they really were killer features that many devs used I doubt they'd have been deprecated and removed in python 3. I do agree that though I wish lambdas could be more useful instead of one liners.
Re: Why I'm Making Python 2.8
#137Earlier quoted context omitted.
Are the other standards inclusive or repressive?
Are you implying Python3 is repressive?
> Are you implying Python3 is repressive?
I am not GP but I think the xkcd is relevant. OP is delusional if they think "Python" 2.8 is even python. It is not.
From what I've read so far, it is a fork of Python 2.7. There is nothing wrong with that. What is wrong is calling it Python.
Re: Why I'm Making Python 2.8
#138Earlier quoted context omitted.
> Benefits? I meant I don't see any benefits for me , not benefits for other people. I assumed that was clear; sorry if it wasn't. > Unicode. Yeah, but some people have still been living without the changes, and it's hardly enough of a reason on its own (for me anyway) when there's other things I hate about the language. > Async. It's a nice feature, yeah. I can live without it, as people have for many years. Maybe i…
Well, things change, especially in tech. For better or worse, but most of the time for the better. You should read some changelogs of past python 3 releases. 3.6, for example, has ordered dicts by default. Which is quite convenient when you need to write test testing a small dict with two items for example. I like driving an old muscle car, most of m look beautiful and bring me everywhere i want. But damn, those new…
Pretty sure they say NOT to rely on the ordered nature of the new dicts. So definitely not something you want to put in your tests.
Re: Why I'm Making Python 2.8
#139Earlier quoted context omitted.
> Also note that Armin has repeatedly praised Rust's text model, which is much more similar to P3's than P2's (except with static types and no messy legacy). That is incorrect. Rust's text model has (almost) free (and copyless) transmutes from bytes to strings. Python does not. The text model of rust is much closer to Python 2 than 3 in many ways.
> That is incorrect. […] The text model of rust is much closer to Python 2 than 3 in many ways. Rust's text model strictly separates proper strings and bytestrings, defaults to proper strings and requires that strings be properly formed (so much so that it has additional completely separated platform-dependent types for dealing with OS-originated "stuff"). The one "difference" (which is more in the realm of implement…
Rust having strings that are utf-8 is a guarantee and as such allows uou to do very efficient operations on them. Puthon gives you a vagie guarantee that it gives you O(1) access to something like a glyph.
These are very different and incompatible text models.
At no point is Python's text model fast or overly useful.
Re: Why I'm Making Python 2.8
#140> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…
>What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you.
I call BS (to counter your "bollocks").
Whether the "writing was on the wall" or not, doesn't change the fact that people had to actively port their old code if they wanted it to run on 3.
Sometimes that code could run into the tens of thousands (or even millions for large companies) of lines.
And why would they do it (and at a great cost and time effort)? For the marginal improvements Python 3 brings?
The "writing has been on the wall" is not an excuse, it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). And most people didn't (and shouldn't) fall for that.