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

New features you can't use unless you are in Python 3

asmeurer.com

Post reply on HN
Print view View original

121–130 of 264 posts

Re: New features you can't use unless you are in Python 3

#121

Post by chc »

problems wrote: post #72
chc wrote: post #67

Earlier quoted context omitted.

> It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen. Ruby released the source-incompatible Ruby 1.9 just months before Python 3. IIRC most versions of Swift have been source-incompatible with each other. Even a language as buttoned-down as C++ has made source-incompatible changes[1]. I have no idea where people got t…

Go ahead and look at those breaking changes, then compare with Python 2 to 3's breaking changes. It's a difference of a few minor things versus a whole swath of changes to the handling of strings in the language, heck, a python 2 print statement isn't compatible with python 3. These are much more significant breaking changes which make porting code much harder than any of the other examples you've given. For the most…

I don't use Swift or C++ much, but I have several years of experience in both Ruby and Python. The changes in Python might be a bit bigger, but the changes in Python 3 and Ruby 1.9 seem of roughly the same magnitude to me. Text encoding is now a problem you need to think about, some methods were removed, other methods were added, the output of some methods changed (e.g. the output of Array.to_s, the result of indexing a string), a few syntactic constructs changed (e.g. character literals used to return numbers, now return strings), and all C-based libraries broke in Ruby 1.9. In both cases, more than 99% of your code will probably be the same (unless your program is mostly print statements, I guess). What's more, Python took more pains than Ruby to ease the upgrade process, with stuff like __future__ imports, 2to3, and the six library. IIRC the Ruby team just changed stuff and said, "OK, update your code accordingly and we promise not to do this to you again for a long time."

It seems to me like the primary difference that made the Python upgrade worse is that the authors of the big libraries in Ruby were enthusiastic about moving to Ruby 1.9, so that it was possible to start porting most Ruby apps very soon after 1.9 released, while a few big Python library authors dragged their feet on even getting started. This was a very real problem, but it was essentially a cultural problem of the library landscape being very different, not a matter of the language itself being drastically different.

Re: New features you can't use unless you are in Python 3

#122

Post by jwilk »

NuSkooler wrote: post #35

How old is Python 3 now? I've always used Python for a "miscellaneous task" language, and still do... and even I find "...because you refuse to upgrade" a bit insulting. If I used it for something serious, even more so. The way 2.x -> 3.x was handled is/was/will is an absolute disaster. Upgrading simple scripts is a non-issue. Larger projects seem to always be a horrible pain.

Python 3.0 was released on 2008-12-03.

It actually become usable somewhere around 3.2/3.3, released in 2011/2012.

Re: New features you can't use unless you are in Python 3

#123

Post by JupiterMoon »

giardini wrote: post #52
JupiterMoon wrote: post #47

Open page. Nothing works. Enable their scripts. First slide shows but nothing works - except the link to the pdf version. Why not give a link to the pdf version in a element?

Works for me! when I hit or right-arrow it goes to the next slide, for previous slide.

Tried all of these - as well as space :(

Re: New features you can't use unless you are in Python 3

#124

Post by [deleted] »

deathanatos wrote: post #96
seanp2k2 wrote: post #49

Earlier quoted context omitted.

Just from __past__ import print_statement I really hope someone makes this work. I literally laughed and thought that it was a troll the first time I saw the future print import and that being used as a compelling reason that I should switch to Py3.

I don't think print() is what I'd call "compelling", but I for one am quite glad to see this go: print "Text", For those not familiar with Python 2's syntax: that trailing comma is significant. And it's pure syntax; it's not the creation of a tuple either…

[deleted]

Re: New features you can't use unless you are in Python 3

#125

Post by david-cako »

pheldagryph wrote: post #59
Fej wrote: post #20

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

There's lot more Stack Overflow answers for 2.x than 3.x, which is helpful for going fast. I'm not using 3.x for personal projects, yet.

I cannot imagine any cases where a general python 2 answer isn't applicable to python 3, with at most a minor change.

In my experience, the most you are doing is shifting around imports (urllib, for instance), declaring classes slightly differently, handling string encoding differently, or printing, format-ing, and raising exceptions slightly differently (and in a more sensible syntax for all, imo).

On the contrary, there are new modules that you are missing out on and you will regularly run into "it's in the stdlib" answers that are not applicable to you.

Re: New features you can't use unless you are in Python 3

#126

Post by jwilk »

problems wrote: post #13
xutopia wrote: post #4

I'm impressed how much Python seems stuck on older versions. What went wrong?

It was source-level incompatible with older code so it couldn't be used as a smooth transition like... almost any other language upgrade I've ever seen. Breaking code like this was a big mistake in my opinion - it resulted in many people sticking on the old version for code and library compatibility. There are still libraries which don't work on Python 3, though now fairly few of them. In addition to that, the unicod…

"hex" and "base64" are still available via the codecs module:

  >>> import codecs
  >>> codecs.encode(b'eggs', 'hex')
  b'65676773'
  >>> codecs.encode(b'eggs', 'base64')
  b'ZWdncw==\n'

Re: New features you can't use unless you are in Python 3

#127

Post by dom0 »

vapemaster wrote: post #19
rjgonza wrote: post #5

Earlier quoted context omitted.

Python 3 came about with a split in the community.

what is the split that has to do with 2vs3? Really it just seems like some devs are still griping about fairly minor backwards compatibility issues. the whole print vs print() is obviously a straw man. but the major one, strings, unicode, and bytes, changes for the good in py3. the fact that people have to go back and "un-hack" their code is time, effort, and more commits but it's for the best. i think the real split…

So, you see, I know a bit about writing efficient code. I have held a firm belief, and still do, that if you're doing heavy lifting in CPython, you're doing it wrong, and better parallelism will not significantly help you.

Re: New features you can't use unless you are in Python 3

#129

Post by dragonwriter »

Animats wrote: post #104
dlbucci wrote: post #66

I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).

Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic ov…

> Overloading operators for cute purposes is usually a misfeature

Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used.

> There was a fad for this in the early C++ days.

Yeah, like overloading the bitwise shift operators as stream insertion/extraction operators.

> Python's classic overload problem comes from using "+" for concatenate. For built-in vectors, "+" is concatenate

Python doesn't have built-in vectors, it has lists.

> but for NumPy arrays, it's addition.

Not sure I see a problem. For numbers, it's an addition. For simple ordered collections, it's concatenation. For matrix-like collections, it's memberwise addition.

> You can use "+" between a NumPy array and a built-in vector. Does it add, or concatenate?

To the extent that's a problem, it's a problem with implicit coercion more than operator overloading.

Re: New features you can't use unless you are in Python 3

#130

Post by dom0 »

jtchang wrote: post #62

Just wondering but what should you do if you decide to go with Python 3 and find a library you want to use that isn't compatible and you are short on time?

Nowadays it's more likely that a Python 2 user wants to use a library and finds it doesn't work on Python 2, because the developers never targeted nor tested on 2.
Post reply on HN