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

Python 2 vs. Python 3: A retrospective

dropbox.com

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#101

Post by chilldream »

pmelendez wrote: post #40
sillysaurus2 wrote: post #33

Earlier quoted context omitted.

__ is basically a namespace for official language extensions. How would you suggest they do it? Prevent "next()" from being a valid method name?

That has been addressed in some many other ways by several languages that goes from the C++ way where you actually have namespaces to the C way where you don't worry about it and pick another name. From all of them I find this the most odd way to address it, specially when python was supposed to improve legibility by design (at least for me those underscores are very distracting)

The underscores are distracting on purpose; any method surrounded by double underscores is one that you're virtually never supposed to explicitly call (there's a builtin `next(foo)` in Python 3, for instance)

Re: Python 2 vs. Python 3: A retrospective

#102

Post by chilldream »

nron wrote: post #50
jzwinck wrote: post #46

Earlier quoted context omitted.

As someone who learned Python when 3.2 came out, I completely agree with you. I have only really used Python 2.7! Because too much shit is broken (NumPy, hello). Because Python 3 has been the default on basically no system ever (OK, maybe this is changing right now, slowly). As Guido says, it's been five years and it will take another five. This whole experiment has been a huge misstep for Python, an absolutely massi…

On the other hand, my experience has been very different: I learned Python when 3.2 was current as well, using Lutz' "Learning Python", which takes the approach of "teach Python 3, and explain how 2 is different whenever necessary". I've followed suit and taken the approach of writing Python 3 code first, and to make it work on 2.7 only when I need to, which I found fairly easy to do, though it can make the code a bi…

My story is similar, and I learned Python 3.2 for Numpy.

Re: Python 2 vs. Python 3: A retrospective

#104

Post by LBarret »

_random_ wrote: post #96

"People positively hate incompatible changes – especially bad for dynamic languages", "Never again this way – the future is static analysis and annotations". Wouldn't it be better to pick a better-suited language then? John Carmack put it nice way: "One of the lessons that we took away from Doom 3 was that script interpreters are bad, from a performance, debugging, development standpoint. It’s kind of that argument “…

Epic might disagree, the UnrealEngine is heavily scriptable. This was one of its major selling points in the last generation.

I have a huge respect for Carmack but some other people prooved him wrong in the past. His opinions are often taken as gospel but more discreet people (like Sweeney) may have different and a s worthy points of view.

Re: Python 2 vs. Python 3: A retrospective

#105

Post by gcr »

yeukhon wrote: post #17
asperous wrote: post #14

Earlier quoted context omitted.

Explicit is better than implicit. I think you think for is magical and could be modified like this, but really for just iterates over something. It's enumerate and items that are the magic. Enumerate zips a range onto a list, the ``index,element`` unpacks the zip. Items returns a list of (key,value) tuples and the key,value unpacks that. You couldn't modify the iterators because it would effect EVERYTHING. sum([1,1,1…

I never said it would be easy to implement or whether it would be actually possible. My complain is that what we are doing right now isn't convenient and is counter-intuitive. I don't write programming language so I wouldn't know how difficult it would be to change the grammar and the semantic of for. Being simple vs explicit is a political debate. I prefer if Python has simpler magical syntax.

The reason why Python works the way it does is specifically to keep the magical syntax as simple as possible.

Consider the following:

    menu = [("Apples", 5),
            ("Cream Pie", 2),
            ("Tea and scones", 3)]
    for food, price in menu:
        print "To buy %s, please pay %d dollars" % (food,price)
Right now, it works unambiguously -- just the way you'd expect. The above prints:

    To buy Apples, please pay 5 dollars.
    To buy Cream Pie, please pay 2 dollars.
    To buy Tea and scones, please pay 3 dollars.
What if we implemented your rule? Would the intprereter print the above, or would it say this?

    To buy 0, please pay ("Apples", 5) dollars.
    To buy 1, please pay ("Cream Pie", 2) dollars.
    To buy 2, please pay ("Tea and scones", 3) dollars.
What if you wanted to print the first one? If your syntax were implemented, the programmer would have to write something awful like

    for index, (food, price) in menu:
or even

    for food, price in destructuring_without_index(menu):
which puts us in full circle again!

The reason why most of us don't like your idea is because it introduces ambiguity and doesn't even remove the trade-off. No matter how you implement it, there's going to be a trade-off.

The zen of python, by Tim Peters:

    Explicit is better than implicit.
    Special cases aren't special enough to break the rules.
    In the face of ambiguity, refuse the temptation to guess.

Re: Python 2 vs. Python 3: A retrospective

#106

Post by gcr »

smnrchrds wrote: post #94
krakensden wrote: post #55

Earlier quoted context omitted.

It's not that ambitious- none of the changes are particularly compelling, none of them scream "update now". It does, on the other hand, break backwards compatibility. Which is why hardly anyone updated.

Maybe not in the world of ASCII, but the new Unicode system scream seems pretty loud to me. When I decided to use pelican for a non-English blog, I thought it would be piece of cake; just changing the theme and plugging a calendar converter and I would be done with it. In reality, I had to fork pelican and the calendar library (which was not well-maintained) and bang my head to the wall for three days to make them wo…

Does this get easier or harder in python 3?

I like the explicit separation that Racket has between "here is a buffer of binary data" and "here is a sequence of Unicode characters," and (looking on the outside without working with it), I'm glad that Python 3 began to adopt some of that.

Re: Python 2 vs. Python 3: A retrospective

#108

Post by rspeer »

gcr wrote: post #106
smnrchrds wrote: post #94

Earlier quoted context omitted.

Maybe not in the world of ASCII, but the new Unicode system scream seems pretty loud to me. When I decided to use pelican for a non-English blog, I thought it would be piece of cake; just changing the theme and plugging a calendar converter and I would be done with it. In reality, I had to fork pelican and the calendar library (which was not well-maintained) and bang my head to the wall for three days to make them wo…

Does this get easier or harder in python 3? I like the explicit separation that Racket has between "here is a buffer of binary data" and "here is a sequence of Unicode characters," and (looking on the outside without working with it), I'm glad that Python 3 began to adopt some of that.

smnrchrds's case of fixing someone else's ASCII assumption gets easier, because the code probably would not have been written that way.

In Python 2, it's really easy to write code that confuses bytes and characters, which introduces bugs and crashes when non-ASCII characters show up.

In Python 3, they made it easier to work with Unicode, because it's the default for everything, and much harder to confuse bytes and characters, because of that separation between the data types.

Re: Python 2 vs. Python 3: A retrospective

#109

Post by csense »

andyl wrote: post #42

It seems like I've been reading about the difficulties of Python V2 -> V3 for awhile. Why is that? Is this Python upgrade unusually difficult/ambitious? Or is the Python community just very reluctant to jump on new things?

Network effects.

When Python 3 started out, it had almost no libraries. So most projects at the top of the software stack couldn't use Python 3 because all the libraries they needed only worked with Python 2.

Below the top, to this day any individual library that wants to switch to 3 basically has to maintain separate forks for 2 and 3, because a lot of downstream users still use 2 because not all libraries are 3-compatible yet.

I think the Python developers are crazy for not using the proven __future__ import mechanism to allow new features to be introduced gradually and have new code interoperating with old code.

Re: Python 2 vs. Python 3: A retrospective

#110

Post by yeukhon »

ghshephard wrote: post #38
yeukhon wrote: post #30

Earlier quoted context omitted.

Whoever downvoted me have some weird negativity here. It doesn't against ethos of Python. There is a Zens of Python, I don't know Ethos of Python. http://www.python.org/dev/peps/pep-0020/ Beautiful is better than ugly. Writing .items() or surrounding enumerate() does not make your code look prettier, does it? Explicit is better than implicit. In fact, my proposal is more explicit than the implicit of for key in my_di…

I almost never use enumerate in python - 90%+ of the time it's the values I'm interested in - an exception might be if I'm trying to print a numbered list - and it's just handy to have the index instead of incrementing a counter. In your scenario, though, to find the location of a specific item in a list: >>> b=['one','two','three','four','two'] >>> b.count("two") 2 >>> b.index("two") 1 >>> b.index("two",2) 4

Try building binary search with .index()
Post reply on HN