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

81–90 of 392 posts

Re: Why I'm Making Python 2.8

#81

Post by js8 »

wfunction wrote: post #69
xrisk wrote: post #63

Earlier quoted context omitted.

So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no... I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.

> So you _hate_ Python 3 because of two changes in syntactic sugar? First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple). That means Python 2.7 helped me catch more bugs . Think about that! Second,…

Regarding tuple unpacking, instead of writing, say:

    def foo((birthname,surname)):
        ...
you can write in Python 3:

    def foo(name):
        birthname, surname = name
        ...
It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.)

Edit: If you have problem with this in lambda expression, just create a named inner function. It's a feature/shortcoming (depends on POV) of Python that you cannot bind variables in an expression. I hope you understand that they couldn't keep the feature in lambdas if they didn't keep it in proper functions.

I am sure if you think about other things, there are good reasons to do it the way Python 3 does it, usually there is a hidden case where things need to be disambiguated (like your list() examples).

Re: Why I'm Making Python 2.8

#83

Post by ubernostrum »

wfunction wrote: post #62
js8 wrote: post #37

Earlier quoted context omitted.

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…

> Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard. Really? So even if no one ever uses it, it still renders the old one obsolete?!

You should be aware that trying to badger people with strict adherence to an arbitrarily-chosen definition of a term as a way to avoid countering their arguments does not make you look intelligent, does not make you look well-qualified to argue the topic, and does not make you look like you're winning the argument. Resorting to technical haranguing about the definition of a term typically, in fact, gives the appearance of someone who does not have an argument to make and is searching for any way to try to salvage a declaration of victory.

Just so you know.

Re: Why I'm Making Python 2.8

#84

Post by wfunction »

js8 wrote: post #81
wfunction wrote: post #69

Earlier quoted context omitted.

> So you _hate_ Python 3 because of two changes in syntactic sugar? First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple). That means Python 2.7 helped me catch more bugs . Think about that! Second,…

Regarding tuple unpacking, instead of writing, say: def foo((birthname,surname)): ... you can write in Python 3: def foo(name): birthname, surname = name ... It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.) Edit: If you have problem with this in lambda expression, just create a named inner…

I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas. That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine.

Re: Why I'm Making Python 2.8

#85

Post by the_mitsuhiko »

masklinn wrote: post #53
sirclueless wrote: post #44

Earlier quoted context omitted.

> the text model of Python 2 is a giant mess and makes it very hard to correctly deal with non-ascii text for any non-trivial software There are counter-arguments to this. Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice [1][2]. Reasons include: You can do byte -> byte conversions with codecs that are no…

> Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice. Armin Ronacher works in a very specific context of having to deal with byte/text interfaces in pretty much all his projects, and while I can see where he comes from I work at a different level and at the level at which I work the P2 model is a giant pain…

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

Re: Why I'm Making Python 2.8

#86

Post by Tehnix »

singularity2001 wrote: post #47
toggafgnadx wrote: post #9

The worst thing about open source is that people can do stupid stuff with your software. If you're going to create this abomination, at least do us all a favour and DON'T call it Python. Call it Retardython or something. I don't want to imagine people coming into the official support channels and claiming they are using "Python 2.8", then other people lecturing them about what that software really is, etc. Sounds lik…

"DON'T call it Python" They shouldn't have called it 'Python' 3 in the first place when it's practically backwards incompatible

Hence the major version number bump...

Re: Why I'm Making Python 2.8

#87

Post by andy_ppp »

I think the problem for me is that they did these changes and made a big song and dance about Python 3. If they had have called Python 3.0 v2.9 instead everyone would have been clear they had to migrate.

PHP has been successfully deprecating features for decades now and cleaned up their code base; they have never had a schism in the way Python has so you can argue all you want about legacy, or people preferring 2.7. The reason this happend (and is still happening) are human not technical.

Re: Why I'm Making Python 2.8

#88

Post by sandGorgon »

masklinn wrote: post #60
jsmeaton wrote: post #56

Earlier quoted context omitted.

Literally the first time I've heard of python-future. How is it that you claim it supercedes six?

> Literally the first time I've heard of python-future. So? > How is it that you claim it supercedes six? Its `future` library goes further than Six and it provides CLI tools to convert both Python 2 and Python 3 code to 2/3 code.

this is pretty cool!

the unicode part is not very seamless though even in python-future

Post reply on HN