251–260 of 264 posts
Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.
This shouldn't be downvoted, it's a legit question. I hear some people really really prefer `print as statement`, but I've never seem them in real life.
Earlier quoted context omitted.
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 fo…
I agree. Go does something similar (using UTF-8). The Go creators _invented_ UTF-8, so I trust them. :)
Indexing a string in Python 3 returns glyphs (which are strings), not bytes. Not graphemes; if you index through a Python 3 string with emoji that have skin color modifications, you'll get the emoji glyph and the skin color modifier as separate items.
Python 3 also has a type "bytes", which can't quite decide whether it's a string type or an array of integers. Print a "bytes" type, and it's printed as a string, with a 'b" in front of it, not as an array of integers. But an element of a "bytes" array is an int, not a bytes type. This is for backwards compatibility; it's roughly compatible with legacy "str" from Python 2.
Rust struggles with this. Rust tries to prevent you from getting a invalid UTF-8 string. The solution used involves re-checking for UTF-8 validity a lot, or bypassing it with unsafe code. This gets messy.
Earlier quoted context omitted.
I agree. Go does something similar (using UTF-8). The Go creators _invented_ UTF-8, so I trust them. :)
Go uses UTF-8 internally, but you index a Go string by bytes, not glyphs or graphemes. The "index" function on strings in Go returns an integer, not an opaque index object or a slice. You can create a slice of a UTF-8 string which is misaligned and not valid UTF-8. Indexing a string in Python 3 returns glyphs (which are strings), not bytes. Not graphemes; if you index through a Python 3 string with emoji that have sk…
You only need to check once, at the boundary of when you're converting from something that may or may not be UTF-8 to a UTF-8 string.
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.
I used to think like you, but when i started actually using Python 3 it all was a lot less worse than i've expected it to be from reading Hacker News comments. YMMV, but converting existing code for me usually didn't amount to more than adding parentheses around print statements. The proper support for unicode alone was enough of a reason to upgrade for me.
I've upgraded projects, but this "you refuse to upgrade" business bothers me. There is a reason people haven't: The way Python handled all of this is horrid.
It's often easier to just move to another language.
Earlier quoted context omitted.
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,…
Earlier quoted context omitted.
They don't, they care about `str` being unicode and developers not having to do additional work to support unicode strings.
Strings can be unicode in Python2, you start a unicode string with u". Python2 has full unicode support. While Python3 supports only unicode strings.
Is there any reason to require extra work to support unicode strings?
Earlier quoted context omitted.
As an independent contractor maintaining large Python 2 codebases, your comments really hit home for me. I only have a portion of my time each month to maintain and develop features for them. If the Python 2 floodgate ever breaks, I am more likely to rewrite the system in a statically typed language. Even today, I am tempted. I know that a sibling mentions the ridiculousness of the situation, but a forced depreciatio…
This. I don't think people realize that there are fixed costs that are born in making these kinds of migrations so that migrating to Java from python is not 100x more work than migrating from python 2 to python 3. There is no such thing as a small breaking change to a runtime. Maybe one way of thinking about it is to take a hard drive full of data and randomly flip a few bits. Then ask what the effort is to find and…
I'm sorry to be the one to break this to you friend, but you must be suffering from the Java shop version of Stockholm Syndrome.
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…
Earlier quoted context omitted.
And the other 96% of us can move on, no need to act like you're the majority. Py 2.6 is already EOL for almost five years.
>no need to act like you're the majority Is he making that assumption, or are you?
Earlier quoted context omitted.
Strings can be unicode in Python2, you start a unicode string with u". Python2 has full unicode support. While Python3 supports only unicode strings.
I was thinking through my response to this, and realized that I would just be repeating what I already said. Is there any reason to require extra work to support unicode strings?