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

221–230 of 264 posts

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

#221

Post by [deleted] »

iak8god wrote: post #85
chestervonwinch wrote: post #32

Earlier quoted context omitted.

Yes. My reason is that I simply don't really care that much. It's the default on all my systems, so why bother putting in the effort to use something that doesn't appear to offer much advantage to me personally? I use python for my personal research, so my particularly situation affords me this laziness. edit: I don't mean this as a knock on py3. All I'm saying is that my situation and uses for python allow me to be…

I'm in similar situation wrt what I use python for, and suffered from the same apathy until quite recently. Man, it was really easy to switch, and completely worth it just for the little things (like UTF-8 as default encoding for strings). It's really painless, but if you want to ease into it, I recommend using __future__ in your py2 stuff for now just to get you into a py3 state of mind: https://docs.python.org/2/li…

[deleted]

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

#222

Post by Animats »

iak8god wrote: post #85
chestervonwinch wrote: post #32

Earlier quoted context omitted.

Yes. My reason is that I simply don't really care that much. It's the default on all my systems, so why bother putting in the effort to use something that doesn't appear to offer much advantage to me personally? I use python for my personal research, so my particularly situation affords me this laziness. edit: I don't mean this as a knock on py3. All I'm saying is that my situation and uses for python allow me to be…

I'm in similar situation wrt what I use python for, and suffered from the same apathy until quite recently. Man, it was really easy to switch, and completely worth it just for the little things (like UTF-8 as default encoding for strings). It's really painless, but if you want to ease into it, I recommend using __future__ in your py2 stuff for now just to get you into a py3 state of mind: https://docs.python.org/2/li…

UTF-8 isn't CPython's default encoding for strings. The internal encodings are ASCII, UTF-16, or UTF-32, depending on the widest character in the string.

I would have made UTF-8 the internal representation, and generated an array of subscript indices only when someone random-accessed a string. If the string is being processed sequentially, as with

    for c in s :
        ...
you don't need an index array. You don't need them for list comprehensions or regular expressions. One could even have opaque string indices, returned by search methods, which don't require an index array unless forcibly converted to an integer. Some special cases, such as "s[-1]", don't really need an index array either.

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

#223

Post by lwf »

Animats wrote: post #220
jrs95 wrote: post #174

Earlier quoted context omitted.

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…

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

*van Rossum

I wouldn't say that's an accurate statement of what Guido does every day :)

(nb: I work at Dropbox, and have worked with Guido at Dropbox.)

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

#224

Post by deathanatos »

Sir_Cmpwn wrote: post #217
baq wrote: post #146

Earlier quoted context omitted.

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.

.format() and format string literals essentially share the same syntax, so I don't really think it's fair to bracket them out separately.

You could sort of pull a retcon and say that .format() is the dynamic form of f'' literals.

Having used the equivalent feature in JavaScript, this stuff is super handy. It also makes "printf" a lot nicer:

  print('I have {count} {color} {object}'.format(count=count, color=color, object=object))
  print('I have {} {} {}'.format(count, color, object))
  print(f'I have {count} {color} {object}')
% had real issues, so I'm quite glad .format() came along.

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

#225

Post by deathanatos »

sprash wrote: post #201
Fej wrote: post #20

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

Yes. Following reasons: * I work a lot with low level data and I prefer strings to be an array of bytes. The forced unicode support is stupid for all my use cases. Also Unicode in 3.x support is rather flawed: http://www.cmlenz.net/archives/2008/07/the-truth-about-unico... * Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases. Ev…

> The forced unicode support is stupid for all my use cases.

bytes and bytearray are still there … if you don't want to work with unicode data in a proper Unicode type, you don't have to. But it doesn't follow that the rest of us that do want a good type for text shouldn't be able to have a good type / tooling for that.

(If you mean that functions that take text require text as input now, well, yeah.)

> Also Unicode in 3.x support is rather flawed

The entirety of "Internal Representation" is out of date, and no longer correct. For just about every other section, I believe libraries readily exist in PyPI to solve those problems. I do agree that it would be nice to have some of that closer to the standard library.

> I have to convert a lot of clear text data formats

I find it strange that you work with text formats, but you dislike having a proper text type? Even if you data were mostly or all ASCII, Python's text handling would still be mostly transparent, just silently doing the right thing if non-ASCII ever were encountered.

> I think printing something is absolutely substantial and it is justified for "print" be a statement.

I'm going to disagree. Python 2's print statements special syntax just adds cognitive load to reading, and to newcomers encountering such syntax, that just doesn't need to be there. Further, the trailing comma for "no EOL" is too subtle from a readability perspective.

> Major APIs now return iterators or views instead of simple lists. This is rarely justified introduces unnecessary complication in many cases.

The old APIs forced materialization of an iterable to a list, and there are plenty of circumstances where this just isn't required. This results in higher memory usage, for that list. The list() also makes it explicit where such materialization happen.

You can always get a list from an API/function that uses generators. You can't go the other way.

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

#226

Post by kstrauser »

jwilk wrote: post #122
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.

Wow! I hadn't thought about it, but Python 3 is older now (almost 9) than Python 2 (released on 2000-10-16) was when Python 3 came out.

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

#227

Post by assafmo »

I'm not touching python like it was fire since it threw YouHaveAMissingTabSomewhereException at me 6 years ago.

And it always pisses me off to see a python source code all lower case. Someone would think upper case letters cost money and underscores are a must like a lemon in a corona.

Am I the only one?

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

#228

Post by Animats »

lwf wrote: post #223
Animats wrote: post #220

Earlier quoted context omitted.

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…

> You're not. von Rossum has to maintain Python 2.7 as part of his day job. *van Rossum I wouldn't say that's an accurate statement of what Guido does every day :) (nb: I work at Dropbox, and have worked with Guido at Dropbox.)

That's from Quora.[1] Dropbox apparently has a lot of Python 2.7 code that hasn't been ported.

[1] https://www.quora.com/What-version-of-Python-does-Dropbox-us...

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

#229

Post by Animats »

daurnimator wrote: post #219
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…

Lua uses '..' as the concatenation operator.

Now that's a good idea.

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

#230

Post by coldtea »

nayuki wrote: post #186
iak8god wrote: post #164

Earlier quoted context omitted.

Can you expand on "mypy is a much better type system than Java"? I'd love it if that were true.

mypy can help you ensure that a variable is never None, whereas it's still tedious to manually check for null in Java.

Seems trivial, if Python which is so dynamic could get it, to give it to Java with a similar static checker.

Haven't checked, but I find it absolutely possible that there's one (or more).

Post reply on HN