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

131–140 of 264 posts

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

#131

Post by dom0 »

mattnewton wrote: post #18
matthewmacleod wrote: post #14

Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.

My guess is it could also have to do with the communities. Anecdotally, the limited sample of ruby-istas I have interacted with tend to have more tolerance of churn for improvement's sake whereas the people attracted to python are more interested in stability because they are focused on some other need that the code is mearly an ends to.

And/or because many Python projects have completely insufficient testing which means that any change that might break anything anywhere can go undetected.

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

#132

Post by ubernostrum »

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.

Leaving out third-party open-source projects I contribute to, and projects I've been involved with as part of my work (both open and private), and just focusing on code from my own personal Python packages:

By count of lines, 0.04% of Python code I've published exists only to deal with 2 vs. 3 issues. Of that code, 34% consists of importing and applying a decorator from Django that handles setting up either __str__() or __unicode__() on a Django model as appropriate. Tellingly, there are exactly two lines I could find that aren't that decorator and which deal with a str/unicode issue.

And that's in code which doesn't just run on Python 3, it supports 2 and 3 in the same codebase.

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

#133

Post by dom0 »

dozzie wrote: post #68
arximboldi wrote: post #22

Earlier quoted context omitted.

This is covered in the link. Just put a * without a name, as in def foo(*, x=None, y="") (Edit) The specific slide: http://www.asmeurer.com/python3-presentation/slides.html#16

Oh my, it looks atrocious. Almost every time I see something introduced in Python 3 I have an impression that current Python envies Perl its baroque semantics, except that Perl usually tries to guess what the programmer meant, while with Python the relationship is reversed: the programmer needs to guess what the language wants. Python's main selling point was simplicity of syntax and semantics that preserved its high…

Python 2 is a vastly more complex language compared to Python 3. Just try to name the basic classes of types that exist in Python 2.

Hint: Cannot be counted on two hands.

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

#134

Post by dom0 »

problems wrote: post #33
maxerickson wrote: post #26

Earlier quoted context omitted.

`hex` and `fromhex` were added to the bytes type in Python 3.5. And while it isn't trivial, it is easy enough to just deal with bytes in 3.x.

Nice, do they have similar for base64 too?

    import base64

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

#135

Post by dom0 »

jwilk wrote: post #126
problems wrote: post #13

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

Though I agree that it was an annoying change. hex/fromhex have helped there, though a 3.4 codebase retains stupid helpers like bin_to_hex.

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

#136

Post by dragonwriter »

matthewmacleod wrote: post #14

Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.

Ruby 1.8 to 1.9 was a similar mess for a shorter period of time, and not because it was handled better, but because there was less diverse entrenched code and subcommunities to deal with: when Rails and popular Rails libraries worked, most of the community could move; Python had a whole lot more that had to be addressed, the curse of it's broader success.

(Also, being already expression-oriented, Ruby didn't have to deal with running into problems where a core feature was a statement that couldn't be used in contexts limited to expressions; fixing that is inherently painful.)

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

#137

Post by coldtea »

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…

>It seems to be best to restrict the math operators to math.

Ken Iverson would probably disagree.

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

#138

Post by jacquesm »

dragonwriter wrote: post #129
Animats wrote: post #104

Earlier quoted context omitted.

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

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

The fact that it requires context other than the language spec is where the problem resides. The cognitive overhead of reading code is high enough without having to alias common operators.

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

#139

Post by eyelidlessness »

loeg wrote: post #112
asdfgadsfgasfdg wrote: post #97

Earlier quoted context omitted.

If you work with international users full unicode support is very compelling.

Why do your users care about symbols internal to your code?

They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.

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

#140

Post by JupiterMoon »

loeg wrote: post #112
asdfgadsfgasfdg wrote: post #97

Earlier quoted context omitted.

If you work with international users full unicode support is very compelling.

Why do your users care about symbols internal to your code?

True. It is a nice thing for scientific code though. Often in a field α etc etc have a known meaning by convention and being able to write them as α rather than alpha can really make longer formulas more readable.
Post reply on HN