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

91–100 of 113 posts

Re: Python 2 vs. Python 3: A retrospective

#91

Post by masklinn »

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)

Er... they are methods not functions. Tell me how does the C++ way namespace methods within an object?

Re: Python 2 vs. Python 3: A retrospective

#92

Post by masklinn »

xymostech wrote: post #59
mhenr18 wrote: post #41

Earlier quoted context omitted.

There's no need to make it not be valid. C++ uses begin() and end() for obtaining iterators to containers, but nothing's stopping you from using those method names for your own purposes. It's just that if you want to use a few new language niceties like range-based for loops then you'll need to conform to that convention.

In C++ it's fairly common to be calling begin() and end() on containers, where in Python it's not common to call next(), you let the for loop handle it. It's reasonable to rename a function to something ugly when you're never going to be seeing it.

> where in Python it's not common to call next()

In fact it should never happen, that's what the `iter` and `next` builtins are for. The only use case for calling __next__ by hand is iffy as hell, it's overloading it while inheriting from an iterator.

Re: Python 2 vs. Python 3: A retrospective

#94

Post by smnrchrds »

krakensden wrote: post #55
lmm wrote: post #47

Earlier quoted context omitted.

It's a big, ambitious update. The biggest difference is forcing users to distinguish between strings and byte sequences; essentially programs now have to be encoding-aware (at least if they use any of the standard library functions). Which is a Good Thing, but can require a ton of work for existing codebases.

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 work together, all because of the whole string/unicode seperation and the fact that things work automagically as long as you're just using ASCII.

Re: Python 2 vs. Python 3: A retrospective

#95

Post by michielvoo »

Question for the professional Python developers: do you (on a daily/weekly/monthly) basis switch between projects in Python 2 and Python 3? Is that hard to do (e.g. do you have to constantly and consciously remind yourself of syntax/semantic differences), or does your mind sort of automatically adjust to the new/old patterns?

Re: Python 2 vs. Python 3: A retrospective

#96

Post by _random_ »

"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 “oh but you want a free-form dynamically typed language here so you can do all of your quick, flexible stuff, and people that aren’t really programmers can do this stuff”, but you know one of the big lessons of a big project is you don’t want people that aren’t really programmers programming, you’ll suffer for it!"

Re: Python 2 vs. Python 3: A retrospective

#98

Post by mercurial »

pmelendez wrote: post #25

This is my problem with Python: "Rename func_name —> __name__, etc Rename .next() —> .__next__()" Too many ugly renames, too few alternatives of doing things. To be honest the only attractive thing to me is all the libraries that they support but I don't find the language itself interesting.

> too few alternatives of doing things

That's what you want for maintainability. I'm not interested in maintaining a codebase where every programmer have their own idea of how something should be done. Of course, you have code reviews for this kind of thing. Except when the code is already written. And when it is not, arguing over minor points is an unnecessary timesink.

Re: Python 2 vs. Python 3: A retrospective

#99

Post by syllogism »

steveklabnik wrote: post #56
spamizbad wrote: post #36

Earlier quoted context omitted.

The Python ecosystem is far too diversified to get knocked down by one language. Python has a wealth of production-quality libraries across a ton of domains (Web, scientific computing, data science, NLP, parsing, scripting/automating, etc). Go is a non-entity in most of these domains and isn't even a top-20 programming language on Github (source: http://sogrady-media.redmonk.com/sogrady/files/2013/07/progr... ) Pytho…

The scientific Python community will never leave 2.5 -> 2.7, though...

NLP will definitely be on Python3 sooner rather than later. unicode strings is a really killer feature for us.

Re: Python 2 vs. Python 3: A retrospective

#100

Post by chilldream »

yeukhon wrote: post #8

The one thing I wish they could change in the future is forcing list and dictionary iterable same syntax: instead of writing for index, element in enumerate(some_list) for key, value in my_dict.items() they should unify and make items and enumerate default behavior. i.e. for index, element in my_list: for key, value in my_dict: I really don't see the benefit of not doing this as default behavior. I always find if I n…

If you're proposing that I can write either `[x for x in X]` for iterating without indices and `[i,x for x in X]` (or `[i,x for i,x in X]` then you introduce ambiguity (what if it's a list of 2-tuples?). If you mean that I always have to write `[i,x` etc even if I don't need the indices then that introduces a lot of noise for the distant minority case.

Dictionaries also have the same ambiguity problem (tuples can be dictionary keys). The noise problem is a bit more justified, but the entire construct is less needed since `D[k]` is less clunky and error-prone than `L.index`.

Post reply on HN