Live data from Hacker News

The Case Against Python 3

learnpythonthehardway.org

261–270 of 281 posts

Re: The Case Against Python 3

#261
post #119

After careful statistical analysis I concluded that there is a 9.56% chance Zed is trolling experienced programmers. Disregarding the trolling about "Turing Completeness", there are some points he raises that are interesting. On some (most thing) items there, the train has left the station. But some are good to listen to: Better error messages. Rust has been making progress there so maybe a good place for inspiration…

> Wouldn't be nice to have requests in the main library? Yes, but changes are still made to it, it might not be updated for a long time then. As they say modules go to the standard library to die.

In fact, the plan is for there to be no further new features to requests: http://docs.python-requests.org/en/master/dev/todo/#feature-...

Re: The Case Against Python 3

#262

As someone who has been extremely critical of the Python 3 debacle, even I think this is overdone. Yes, the transition was totally botched, and 8 years in, Python 3 still has less production usage than Python 3. But by now, at least, enough libraries have been ported or replaced that you can actually use Python 3. This was not true three years ago. Porting remains painful. I ported a medium-sized web backend system a…

Could you share any links that show "There have been explicit attempts to apply pain to Python 2.7 users"?

I don't think you are lying, but it seems extraordinary to me, so I'm interested in seeing some context and I'm not sure how to find it.

Re: The Case Against Python 3

#264

This has to be the ne plus ultra of Python scaremongering. It describes some sort of bizzaro world of a doomed language which it populates with Machiavellian Python maintainers, brainwashed developers, and a small group of heroic holdouts who see resisting Python 3 as a moral imperative. Apparently having too many string formatting options is a moral issue (three, to be specific). As someone who writes a _lot_ of Pyt…

One of the nicest things about the Python community is the lack of drama.

Re: The Case Against Python 3

#265
post #72
post #2

> Currently you cannot run Python 2 inside the Python 3 virtual machine. Since I cannot, that means Python 3 is not Turing Complete and should not be used by anyone. I stopped there.

Yea I skimmed the rest. This makes me ashamed that I even bought the guys book (Learn Python the Hard Way). His attitude is what is going to kill python, not python 3. I moved from Perl 5 to Python 3 hoping to flee the internal dev fighting and attitudes, yet here I am again. I'll say this, at Pycon 2016 I attended some dev sprints/hackathons with the python 3 developers. Python 2 is no where on their radar, its dead…

> His attitude is what is going to kill python

No. The rest of the community is much better. In fact, his behavior is an aberration.

Re: The Case Against Python 3

#266
post #119

After careful statistical analysis I concluded that there is a 9.56% chance Zed is trolling experienced programmers. Disregarding the trolling about "Turing Completeness", there are some points he raises that are interesting. On some (most thing) items there, the train has left the station. But some are good to listen to: Better error messages. Rust has been making progress there so maybe a good place for inspiration…

> Wouldn't be nice to have requests in the main library? Yes, but changes are still made to it, it might not be updated for a long time then. As they say modules go to the standard library to die. In fact, the plan is for there to be no further new features to requests: http://docs.python-requests.org/en/master/dev/todo/#feature-...

Oh interesting! Thanks for pointing that out.

I think requests module is one of the nice assets in Python, having it in the standard library would be a good move.

Re: The Case Against Python 3

#267
post #260
post #255

Earlier quoted context omitted.

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

> Python 3 doesn't put any size limit on integers 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 instan…

> Variable-length bytes is a feature that Python does not have.

That wasn't my point. My point was that, as far as integer objects are concerned, there is no concept of "byte" at all, not even a fixed length "byte" of 8 bits. There is no concept of "chunk of data operated on as a single unit by the hardware", and there is no concept of "unit of data of the underlying storage for this object". There are just objects representing integers of any value you like.

The only kind of object in Python for which a concept of "byte" in your sense exists at all (if we leave out modules like the ctypes module) is the byte string (str in Python 2, bytes in Python 3). For those objects, you are correct that "byte" is always 8 bits in Python, and there is no way to vary it. But that has nothing to do with the underlying hardware; it is just the data model that Python has chosen for binary data.

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

Only if these things are exposed to you at all. In Python, you don't have to worry about this for integer objects because you don't see the underlying storage at all; things like what endianness is used to store integers > 255 are implementation details of the interpreter. Frankly, I find that to be a good thing: if I wanted to worry about stuff like that, I'd be programming in C, not Python. But of course different people will have different needs and preferences.

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

I understand that you prefer to use this terminology; but my point in that particular comment was that it is not the terminology that is used in the Unicode documentation, which is the closest thing we have to an "official" terminology for Unicode. As is shown by what I quoted, that documentation clearly uses the term "byte" to mean 8 bits; it refers to UTF-16 and UTF-32 as encodings that use 2 or 4 "bytes" to encode a code point. It does not use the term "byte" to refer to 16 or 32 bit chunks of data. So it seems misleading, or at least potentially misleading, to use the term "byte" to refer to anything other than 8 bits when talking about Unicode encodings, since the Unicode documentation does not give the term "byte" that meaning.

Re: The Case Against Python 3

#268
post #267
post #260

Earlier quoted context omitted.

> Python 3 doesn't put any size limit on integers 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 instan…

> Variable-length bytes is a feature that Python does not have. That wasn't my point. My point was that, as far as integer objects are concerned, there is no concept of "byte" at all, not even a fixed length "byte" of 8 bits. There is no concept of "chunk of data operated on as a single unit by the hardware", and there is no concept of "unit of data of the underlying storage for this object". There are just objects r…

I think we're mostly in violent agreement here.

Let me try to re-state the point I was trying to make: the only reason there is anything special about 8 bits as a unit of data is because hardware is built to operate on units of 8 bits at a time. Whether you call these things "bytes" or "words" doesn't matter. You can call them florbs for all I care.

The fact that florbs are 8-bits wide is mainly for historical reasons. There is no particular reason to make the magic number be 8 (except that it's a power of 2), and indeed there have been historical examples of hardware with florbs of other sizes. The Intel 4004 had 4-bit florbs. The PDP-8 had 12-bit florbs.

Modern hardware is built to natively handle florbs of multiple sizes, typically 8, 16, 32 and 64 bits, but sometimes other sizes as well (e.g. 80 bits for extended precision floats, or 128 for SSE5 instructions). Because of this, many algorithms are designed to operate on binary data in these sizes, and because of that it can be helpful to have binary data in these sizes exposed in your programming language. Python exposes 8-bit florbs, but not other sizes of florbs. Common Lisp has arbitrarily sized florbs. If you're doing certain things (like crypto) having access to florbs larger than 8 bits can be useful. That's all.

Re: The Case Against Python 3

#269
post #10

Earlier quoted context omitted.

Yes, the author doesn't know what he's talking about. But people talking about Turing completeness in a real programming language (usually in the form of "x is Turing complete, therefore you couldn't ask for more") almost always haven't got a clue.

I just point them towards Unlambda. Turing completeness in three characters (plus one for output) http://www.madore.org/~david/programs/unlambda/#what_is

Unlambda as a language may be a joke (the funny kind), but learning it is incredibly enlightening, and makes you understand some fundamental concepts of computer science.

As such, I think it represents one of the most enlightening esoteric languages out there together with Brainfuck.

Re: The Case Against Python 3

#270

Earlier quoted context omitted.

All stable versions of the big ML frameworks are still 2.7.

Even if your statement was true (it's not)[1][2][3][4], how would that be a sign that Python is dying? [1] http://www.deeplearning.net/software/theano/install.html [2] https://www.tensorflow.org/versions/r0.11/get_started/os_set... [3] https://keras.io/#you-have-just-found-keras [4] https://lasagne.readthedocs.io/en/latest/user/installation.h...

I think the author's point was not that python3 is dying. His point was that it deserved death, that 2.7 is flourishing, while 3 is failing to thrive, and reasons for this were postulated.
Post reply on HN