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

Why I'm Making Python 2.8

naftaliharris.com

Post reply on HN
Print view View original

371–380 of 392 posts

Re: Why I'm Making Python 2.8

#371

Post by true_religion »

yladiz wrote: post #309
dismantlethesun wrote: post #243

Earlier quoted context omitted.

I don't know about that. It forked a Python compiler, and is fully interoperable with 100% of Python 2 code, and much of Python 3 code. It's even compatible with Python C extensions. Why isn't it a valid Python compiler? To me, the whole morass about trying to end-of-life Python 2 is a bit silly. People have gotten emotional about the situation. On one side, people like Zed Shaw are calling the Python maintainers 'ev…

There are some fair points, but unlike C or other languages that have "old" versions, most of the newer versions are compatible with this old code (as in, if you have some C89 code, you can compile it in the newest C compiler. Same with Fortran). This isn't the case with Python 3 (there are breaking changes), and I think it's fair that the Python core developers who, besides Guido, probably work on this for free deci…

They transitioned with a lot of community support and did sooner the course of years. It wasn't easy to support 2/3 out of the box. For a normal company, staying on 2 is like keeping technical debt and we all know how companies loathe to allow weeks for major refactoring when the gains aren't immediately visible. My company switched to using puppy and eschewing c extensions before we supported python 3.

Re: Why I'm Making Python 2.8

#372

Post by guitarbill »

int_19h wrote: post #293
guitarbill wrote: post #171

Earlier quoted context omitted.

> So the built in csv module needs to support a reasonable behavior. Which it does not. It could be argued that the csv module's behaviour is reasonable, and NumPy's isn't. (I'm not 100% sure about all the details of this issue) Hopefully, NumPy will change it's behaviour to match Python 3, but if not you could still use the NumPy CSV routines like `loadtxt` or `genfromtxt` [0]. So then this becomes a documentation c…

> It could be argued that the csv module's behaviour is reasonable I don't see how silently printing a binary literal, if that is indeed what it does, is reasonable. Simply put, b"foo" is not meaningful CSV. What it should do is 1) raise an exception by default, informing the user that they need to be supplying strings and not bytes, and 2) provide an explicit switch to treat binary data as pass-thru, which would be…

The docs say that "[a] row must be an iterable of strings or numbers" [0]. So I guess an exception could be raised. However, the docs do tell a lie; non-strings are accepted and get converted to strings. You can pass any object in which has a string representation - including a byte array. It actually wouldn't be too hard to introduce a check for a bytes field, https://hg.python.org/cpython/file/3.6/Modules/_csv.c#l1227

    + if (PyBytes_Check(field)) {
    +     append_ok = FALSE;
    +     Py_DECREF(field);
    +     PyErr_SetString(PyExc_TypeError, "Field is bytes");
    + }
    else {
This would then raise a TypeError.

I don't think this is the right solution. It seems weird to have a special case because people aren't watching what they're putting in. Garbage in, garbage out, consenting adults and all that.

[0] https://docs.python.org/3/library/csv.html

Re: Why I'm Making Python 2.8

#373

Post by guitarbill »

coldtea wrote: post #198
duckmysick wrote: post #160

Earlier quoted context omitted.

> it's mostly blackmail ("port or else you wont run on 3, and we'll stop the 2.x line"). Would you also call the RHEL life cycle a blackmail? I'm using version 5 now and the normal support ends in March 2017. My options now are "port or pay extra for extended life cycle or else my RHEL will be without security fixes". And like Python, major RHEL versions break backwards compatibility.

> Would you also call the RHEL life cycle a blackmail? The RHEL life cycle is based on real business needs (and a real business need to balance between newer releases/features and stable environments). Not on some decree from above that "you should use this new thing".

Yes, and that's why you pay for it. Yet here is somebody complaining about that.

If you e.g. can't be bothered to do continuous integration or automated testing, then you might consider RHEL with it's life cycle to be an acceptable alternative. Which is fine. Just be ready to pay for that service.

Similarly, if you wanted continued Python 2 support, you could have donated time or money towards that goal. I would be surprised if anybody complaining did that. There's just not that much business value in dragging legacy Python further along.

Re: Why I'm Making Python 2.8

#374

Post by orf »

coldtea wrote: post #365
orf wrote: post #214

Earlier quoted context omitted.

Oh, but you're expressing your thoughts and desires perfectly well though. You want someone else (not you, of course) to maintain Python 2 for you for the princely sum of of £0.00, so that you don't have to do any work on upgrading to Python 3. And when the time finally comes around that those people, who have been maintaining Python 2 for many many years (for free), want to focus their efforts on an easier to mainta…

> Oh, but you're expressing your thoughts and desires perfectly well though. You want someone else (not you, of course) to maintain Python 2 for you for the princely sum of of £0.00, so that you don't have to do any work on upgrading to Python 3. That's how it works with programming language communities. Not everybody is directly involved in maintaining the language, but the whole community has a stake (and a say) in…

> That's how it works with programming language communities

Not always, python has a BDFL rather than a steering committee. But nonetheless it's the people who actually maintain the language who drive it forward.

> but the whole community has a stake (and a say) in the future of the language.

Comments like "the core team are repressing me by not updating 2.7" and random people making half-baked 2.8 releases don't help the future of the language.

Look, it's simple. Core team doesn't want to update Python 2.x anymore for a large number of good reasons. For some people (including you I assume) this isn't the decision you wanted.

But this decision was made years ago. Either move to a different language, update to Python 3 (again, you've had years of warning) or pay for a supported 2.7 version. Or just carry on using 2.7, it's supported until 2020.

Bitching about non-existent repression on hacker news archives squat.

Re: Why I'm Making Python 2.8

#375

Post by jchassoul »

thewhitetulip wrote: post #131

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.

Unwillingness to refactor and people bad habits, mostly bad habits like print 'this stuff out'... simple bad habits humans we have that a lot.

Re: Why I'm Making Python 2.8

#376

Post by coldtea »

orf wrote: post #374
coldtea wrote: post #365

Earlier quoted context omitted.

> Oh, but you're expressing your thoughts and desires perfectly well though. You want someone else (not you, of course) to maintain Python 2 for you for the princely sum of of £0.00, so that you don't have to do any work on upgrading to Python 3. That's how it works with programming language communities. Not everybody is directly involved in maintaining the language, but the whole community has a stake (and a say) in…

> That's how it works with programming language communities Not always, python has a BDFL rather than a steering committee. But nonetheless it's the people who actually maintain the language who drive it forward. > but the whole community has a stake (and a say) in the future of the language. Comments like "the core team are repressing me by not updating 2.7" and random people making half-baked 2.8 releases don't hel…

>But this decision was made years ago.

So? For one, almost everybody I've read, even if they are OK with Python 3, say that that decision wasn't the best course the core team could have been taken.

Now, given that the decision has already been taken and followed through for 6+ years, should they now stick with it and see it through? It depends. There's no reason some of us should not just say "no" to that.

There's always this: http://www.lifehack.org/articles/communication/how-the-sunk-...

>Either move to a different language, update to Python 3 (again, you've had years of warning) or pay for a supported 2.7 version. Or just carry on using 2.7, it's supported until 2020.

Or you know, we can do all/either of those things, and still criticize Python 3 and try to get them to change course.

Re: Why I'm Making Python 2.8

#377

Post by coldtea »

mrob wrote: post #218
coldtea wrote: post #196

Earlier quoted context omitted.

> Or how it is inhibiting or preventing the expression or awareness of your thoughts or desires. How's that difficult to parse? It is stomping on the desire to keep my 2.x userbase AND receive updates for the language.

It would not prevent you from receiving updates, it would prevent you from receiving updates for free . You may of course pay somebody to update 2.7 for you. The Python Software Foundation never promised they would continue maintaining any release indefinitely, and it's unreasonable to expect them to do so. But in fact they are continuing to fix critical bugs even in 2.7, so they are being generous. Nobody is being b…

>and it's unreasonable to expect them to do so

No, but it's reasonable to expect them to hear the concerns of the largest use base of Python, which is 2.x users - even if they decide not to follow them in the end.

Except if they just do it "for fun" and "for the sake of it" and could not care less for adoption or the community in general.

Re: Why I'm Making Python 2.8

#378

Post by Sir_Cmpwn »

ianamartin wrote: post #363
Sir_Cmpwn wrote: post #261

Earlier quoted context omitted.

with open('some latin-1 file', 'rb) as f: text = f.read().decode('latin-1') with open('some utf8 file', 'wb') as f: f.write(text.encode('utf-8')) Python 3's string encoding support is super good. I've said it before and I'll say it again: if you use bytes as a string you are Doing It Wrong. If you use bytes as a string you are Doing It Wrong. If you use bytes as a string you are Doing It Wrong.

Allow me to rephrase. I do that operation on a file I get from an API. I know for a fact that the encoding I'm receiving is latin-1. I run exactly that operation on the file that you wrote out in code. When I try to read that file back in as UTF-8, I get encoding errors. That does not make for "super good." That makes me want to scream. I do not have this problem when I use Python 2.7.x

You're definitely making a mistake somewhere, because I just tested it for myself and it worked perfectly fine. I made a latin-1 file, applied the above code with it, and got a correct utf-8 file out. Are you reading the final file back as latin-1? You have to read it as utf-8 of course.

Re: Why I'm Making Python 2.8

#379

Post by yoz-y »

jprzybyl wrote: post #274
yoz-y wrote: post #20

I 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.

Obsolete is a funny word to use. In this case, it would mean that Python 2 is in good working order, but is no longer wanted. That's bound for a flame war, because: - There is a community that wants it (largely enterprise). - The Python team does not want it. A less controversial word is deprecated - the Python team is discouraging use of Python 2, but not prohibiting it's use or development. That's fair, and if you…

Obsolete was a wrong word to use, I admit that. But from an integrator's perspective supporting both versions is a mess. The problem is that the interpreter has the same name (python), the libraries export the same symbols (well, same names, different signatures for extra fun) etc.

Like you said, Python team sees the 3.x series as the successor AND as a replacement for Python 2.x. They were never meant to exist one beside the other (or, there was no thought put into this before the release).

From my perspective, giving people the choice between 2 or 3 will only give us problems down the road, which is why I vehemently discourage it.

Re: Why I'm Making Python 2.8

#380

Post by wfunction »

int_19h wrote: post #341
wfunction wrote: post #325

Earlier quoted context omitted.

Notice in said languages they added lazy APIs. They did not remove eager APIs. Python already had imap, ifilter, izip, etc... I already said this and I'll repeat: I would've been just fine if they made those easier to use (e.g. no import). There was no need to change the behavior of existing APIs.

There were generally no map/filter/fold APIs in those languages, eager or lazy. In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). The new APIs are more straightforward to use. The reason to change the behavior of an existing API is because the default (i.e. most obvious) API should also be th…

> There were generally no map/filter/fold APIs in those languages, eager or lazy.

Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence.

> In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them).

This is going on a tangent but LINQ still has hoops to jump through. You have to say "using System.Linq;" at the top if you want to use the new syntax. That's like saying "from itertools import *" and then using imap, which you could've always done.

Post reply on HN