251–260 of 281 posts
This article was written in the mental state of hate. The author may well reread it, and remove all the hate. He can have the opinion that Python3 is not suited for teaching where Python2 is, but his arguments are in fact just opinions. Another problem in the tone: no respect for his readers. "if *I* struggle to use Python's strings then you don't have a chance."
I didn't know Zed Shaw was that stupid. Or is he just trolling?
The argument is bad but the headline has a point: the value of a language is the quality of its libraries and the community that maintains it. Python 3 seems like a mistake; it fractured the community and sent people away. (to golang, to scala, probably even to ruby). If I were a library maintainer on py2 I would have felt betrayed by py3. Suddenly print is a function? 'yield from' won't be available on the py2 branc…
>C++ is an example of the serious negative consequences of language change. From the outside looking in (as a non-C++ developer), for me the bigger problem is honestly that they left in the warts rather than just paving around them. Those who have followed C++ for its entire life cycle have probably been able to mostly keep up with what language features were mistakes and what the best way to do things is, but I can'…
I mean this is an age-old argument but MS comes down very strongly on the other side because, like... what if nobody is working on that C# 3.0 code anymore but you need it for whatever reason? Well, I guess you're out of luck in the world where they just break ArrayList.
Earlier quoted context omitted.
If you're looking for a new tutorial for beginners, I really liked "Dive Into Python 3" ( http://www.diveintopython3.net/ ) and have had some success giving that link to new coders.
If Zed's understanding is correct, that would be a waste of time: The outcome would be that you learned a dead language.
Earlier quoted context omitted.
> a chunk of data that can be operated on as a single unit by the hardware I didn't realize that this concept was referred to by the term "byte". But this clarifies how you are using that term. Given that usage, I'm not sure why 8-bit bytes are an issue at all for a language like Python that is supposed to be hardware-agnostic; the whole point is that programs should not care about how the data is physically represen…
> I didn't realize that this concept was referred to by the term "byte". It is common to see "byte" used to mean 8-bit-byte, and also to see the term used for wider units of binary data. If you want to be unambiguous, the word "octet" is commonly employed to mean 8-bit byte. > a language like Python that is supposed to be hardware-agnostic That is exactly why you want wide bytes. If you want to represent an integer >…
But Python 3 doesn't represent integers that way, because Python 3 doesn't put any size limit on integers. There's no way to represent integers of potentially unbounded size as fixed-width binary data.
This is one of the things I meant by "hardware agnostic"--I didn't mean "able to represent the different register sizes of different hardware"; I meant "having a representation that doesn't have any concept of register size at all".
(Python 2 does have a separate int type, which IIRC is either 32 or 64 bits wide depending on the platform. AFAIK this is just a wrapper around the underlying C int, so it isn't affected by any 8-bit byte restriction.)
> UTF-16 and UTF-32 data is specified as 16-bit and 32-bit bytes. This is why you need a BOM.
Um, no. UTF-16 and UTF-32 data is specified as 16-bit and 32-bit code points. You need a Byte Order Mark (BOM) to specify in which order the 8-bit bytes that make up a 16-bit or 32-bit code point appear.
From the Unicode FAQ[0]:
"Q: What is a UTF?
"A: A Unicode transformation format (UTF) is an algorithmic mapping from every Unicode code point (except surrogate code points) to a unique byte sequence. The ISO/IEC 10646 standard uses the term “UCS transformation format” for UTF; the two terms are merely synonyms for the same concept."
Further down, under the table listing the UTFs and their properties:
"In the table indicates that the byte order is determined by a byte order mark"
And in the answer to the next question after that:
"UTF-16 and UTF-32 use code units that are two and four bytes long respectively."
Earlier quoted context omitted.
Ok, I should have been a bit more specific: aren't all bytes on machines that Python can realistically run on 8 bits wide?
No. All modern machines can address 8-bit-wide bytes for historical reasons, but they can also address wider bytes. 32 and 64 bit bytes are common. We call them "words" instead of "bytes", but they're really the same thing: a chunk of data that can be operated on as a single unit by the hardware). And having that capability exposed as a software abstraction can be extremely useful, particularly in applications like c…
I upvoted you to compensate. :-)
Earlier quoted context omitted.
I attended a few newbie classes at pycon2016. A few of them suggested Learn Python The Hard Way, to which I pointed out how the author states to never try installing python 3 on the first page.
The author should essentially be banned from community and his book no longer recommended after that lest someone believes him. You're essentially giving up great features like async keyword and proper encoding handling getting nothing in return. The few libraries that are still Python 2 only should be ignored.
Earlier quoted context omitted.
> The author is - quite obviously - staying the Python 3 VM should run Python 2 code, in the same way the JVM and CLR run other languages. There is no "CPython VM": no version of Python guarantees bytecode compatibility between versions. The bytecode is just an optimisation. For a Python interpreter to support both Python 2 and Python 3, it would need to have have some source level way of telling the two apart. Bytec…
> > That the Python 3 VM doesn't run Python 2 code - and that the Python maintainers apparently say it can't - means the Python 3 VM isn't Turing complete. > No it doesn't. You do realise the next four words in the post you're replying to is: > > This is nonsense obviously ? And then a reason why the claim is being made? To continue your CPU analogy (I actually read your post), it's like Intel saying x64 can't run x8…
> but it's a way of pointing out that the claim that the Python 3 VM can't be made to run Python 2 code is also nonsense.
And that's why I wrote:
> For a Python interpreter to support both Python 2 and Python 3, it would need to have have some source level way of telling the two apart.
[And now I have no way to double check what you wrote originally because you overwrote your original comment.]
Earlier quoted context omitted.
This is what the author doesn't get- the fact that Python 2 makes no distinction between bytes-like objects and string-like objects is a bug , not a feature . He finds his code so awful to migrate because he has built it on a contrary assumption.
Definitely disagree. I am a literal genius, wrote compilers, learned a dozen programming languages for fun, but prefer to do hard things. Yes p2 handling of coding is broken, but p3 is much worse. Making a theoretical argument about a pragmatic problem is a category mistake. And it's not even the core of Zed's expressed concern, which is the arrogant and abusive manipulation of the user community in service of the in…
I like what you said about self-obsessed project. It's clear that you have a very well reasoned position, not just opinion. What you say makes irrefutable sense.
Earlier quoted context omitted.
> I didn't realize that this concept was referred to by the term "byte". It is common to see "byte" used to mean 8-bit-byte, and also to see the term used for wider units of binary data. If you want to be unambiguous, the word "octet" is commonly employed to mean 8-bit byte. > a language like Python that is supposed to be hardware-agnostic That is exactly why you want wide bytes. If you want to represent an integer >…
> If you want to represent an integer >255 as fixed-width binary data But Python 3 doesn't represent integers that way, because Python 3 doesn't put any size limit on integers. There's no way to represent integers of potentially unbounded size as fixed-width binary data. This is one of the things I meant by "hardware agnostic"--I didn't mean "able to represent the different register sizes of different hardware"; I me…
Yes, obviously. Variable-length bytes is a feature that Python does not have. (AFAIK the only language that has variable-length bytes is Common Lisp.)
> There's no way to represent integers of potentially unbounded size as fixed-width binary data.
Yes, obviously. To be excruciatingly precise I should have said: if you want to represent a binary data type with N instances where N>255 (e.g. an integer in a range from 0 to N where N>255, or from -N to N where N>127) then you either need bytes wider than 8 bits, or you need to worry about endianness.
> UTF-16 and UTF-32 data is specified as 16-bit and 32-bit code points.
No. Unicode characters are specified as code points, which are just numbers with no specific representation. UTF-16 and UTF-32 are encodings of unicode which use 16-bit-wide and 32-bit-wide bytes respectively to encode those code points. It is only when you serialize those encodings to octets that you need a BOM. When UTF-16 and UTF-32 are used internally to one machine you don't need a BOM.
There are also, as I pointed out before, many algorithms (particularly in cryptography) that are specifically designed to operate on fixed-width binary data wider than 8 bits.