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

211–220 of 264 posts

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

#211

Post by est »

KerrickStaley wrote: post #106

One big thing that's missing from this list is the __traceback__ on exceptions, which pretty much does what you think it does. In Python 2, there's no way to access the traceback for an exception once you've left the `except:` block. This matters when you're using things like gevent; if one of your gevent greenlets throws an exception and you inspect the .exception attribute on it, you'll be able to get the exception…

> there's no way to access the traceback for an exception once you've left the `except:` block

Also in 2.4 if you assign a variable to a local inside a traceback it might leak memory.

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

#212

Post by comex »

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…

It’s awful, especially since you can’t omit the space at the end. But the replacement,

    print(“Text”, end=“”)
is verbose. Not too verbose, but considering how often I write prints as temporary throwaway code, every little bit hurts…

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

#213

Post by catdog »

pishpash wrote: post #100
mixmastamyk wrote: post #55

Earlier quoted context omitted.

Consistency and keyword args are useful.

"11. There should be one-- and preferably only one --obvious way to do it." from the Zen of Python. Somebody intentionally misread it as, "There should be only one way to do it." They obviously made a grave mistake. Same with many 2->3 changes.

Also from the Zen of Python: "Special cases aren't special enough to break the rules", the old print statement contains a lot of special syntax not found anywhere else in the language. Also "Readability counts", it's really obvious what print("foo", file=sys.stderr, end="") does instead of deciphering a construct like print >>sys.stderr, "foo", . Moreover you can pass a print function around, perform partial application, etc., a statement does not give you that.

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

#214

Post by est »

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

And it's totally portable to Python 2.

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

#215

Post by rsj_hn »

catdog wrote: post #209
rsj_hn wrote: post #76

Earlier quoted context omitted.

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codeb…

> but at least the java community doesn't force developers to rewrite their source code when a new JVM comes out. Java contains a lot of ugly legacy bullshit because of that.

Yes. If you're not prepared for cruft, then you are going to be rewriting things all the time.

Joel Spolsky talks about this desire for artistic purity over useful backwards compatible cruft in a couple of nice essays:

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

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

#217

Post by Sir_Cmpwn »

baq wrote: post #146
lottin wrote: post #145

Earlier quoted context omitted.

How many format strings does Python have already?

https://pyformat.info/ should know, ask it

This link does not mention f-strings, the feature in question.

The answer is there are 3 ways to format a string: %, .format, and f-strings.

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

#218

Post by VyseofArcadia »

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…

You probably despise a lot of popular Haskell libraries.

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

#219

Post by daurnimator »

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…

Lua uses '..' as the concatenation operator.

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

#220

Post by Animats »

jrs95 wrote: post #174
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.

There are a lot of people who refuse to upgrade. I have to use 2.7 at work for pretty much no reason at all, and I'm sure I'm not the only one.

You're not. von Rossum has to maintain Python 2.7 as part of his day job.

Things I still have in Python 2.7:

- Code that runs on low-end shared hosting. There's a Python 3, but it's 3.2, the least-compatible version. No "six", and "u'xyz' isn't allowed.

- ROS, the Robot Operating System. Python 3 support is coming, but it's not really here yet.

I converted over the dedicated servers and some IoT stuff a year ago.

The types stuff probably should have been called Python 4, not Python 3.6. Those are major language changes. The optional-types-that-are-not-checked thing seems a bad idea. I can see having checked types; that allows some important optimizations. When you know something is a machine type, such as an int or float, you don't have to box it. But the feature of type declarations without checking is a foot gun.

Post reply on HN