Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case Against Python 3

learnpythonthehardway.org

Post reply on HN
Print view View original

211–220 of 281 posts

Re: The Case Against Python 3

#211

Post by kqr »

joatmon-snoo wrote: post #199
kqr wrote: post #185

Earlier quoted context omitted.

> his point about the concatenation of unicode and bytearrays certainly seems a valid point This is one of those subjects where I feel like being a non-English programmer has given me surprisingly valuable experience. The operation of concatenating a text value (string) and binary data (byte array) simply does not make sense, for two reasons. What do you expect the result to be? 1. Binary data with the text appended.…

That's a pretty fair point, and I completely agree that the Python 2 result is pretty ridiculous. In zed's defense, it still does seem like a rather daunting error for a beginner programmer - although like you, I have no good viable alternative to suggest.

Encoding and decoding binary data is hard for a beginner in general, and I'd argue it's good to avoid it for the first few lessons. Unless the beginner has a CS education in which case by all means explain how encoding is taking text and translating it to bits.

Re: The Case Against Python 3

#212

Post by lisper »

pdonis wrote: post #205
joatmon-snoo wrote: post #203

Earlier quoted context omitted.

Nope! (TIL) http://stackoverflow.com/questions/5516044/system-where-1-by... I think in the context of the original answer there's also the problem that char types aren't necessarily 8 bits wide, e.g. wchar etc.

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

EDIT: Downvotes? Seriously?

Re: The Case Against Python 3

#213

Post by pwdisswordfish »

AstralStorm wrote: post #180
Falkon1313 wrote: post #165

A lot of people seem to be confused by his Turing completeness argument. I think it's misleading and the phrase 'Turing complete' is a red herring. My guess is that what he was getting at was that other languages use 'compiler-mode' switches for compatibility-breaking upgrades so that you can use older code with newer code. For example, you can write a program in the latest dialect of Free Pascal that includes a unit…

There was no way to keep the compatibility given the string change anyway, as the literal is changed. Port to Python 3 is almost never a rewrite.

    from __future__ import unicode_literals, print_function, division, absolute_import

Re: The Case Against Python 3

#215

Post by majewsky »

kbenson wrote: post #197
flukus wrote: post #188

Earlier quoted context omitted.

What's replacing C? I can see languages like go/rust/crystal replacing C++ for application development, but what's producing stable binaries that other languages can consume in the same way the do C ones?

Rust can produce C compatible libraries. Go apparently can too. I suspect a little googling would show me that Nim and D can as well. I'm sure there are at least a few more.

Go can use C libraries, but AFAIK it cannot be compiled into a shared library to be used by a C program. Go needs control of the program flow to orchestrate its runtime (esp. the GC).

Nim can definitely produce C-compatible libraries, seeing how it compiles to C itself.

Re: The Case Against Python 3

#216

Post by pdonis »

lisper wrote: post #212
pdonis wrote: post #205

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…

> 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 represented in the hardware. Python 3 got rid of the distinction between int and long for the same reason. The only reason the "bytes" object exists at all is to represent binary data, for example data that gets read from/written to files, network sockets, and other I/O, and AFAIK bytes in such data are always defined to be 8-bit chunks of data. (If you really insist on having Python representations of hardware data chunks, there's the ctypes module.)

Re: The Case Against Python 3

#217

Post by flukus »

kbenson wrote: post #197
flukus wrote: post #188

Earlier quoted context omitted.

What's replacing C? I can see languages like go/rust/crystal replacing C++ for application development, but what's producing stable binaries that other languages can consume in the same way the do C ones?

Rust can produce C compatible libraries. Go apparently can too. I suspect a little googling would show me that Nim and D can as well. I'm sure there are at least a few more.

I didn't know rust could, I just checked it out. I didn't realize rust was that low level.

Re: The Case Against Python 3

#218

Post by lisper »

pdonis wrote: post #216
lisper wrote: post #212

Earlier quoted context omitted.

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…

> 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 >255 as fixed-width binary data and you don't have wide bytes, then you have to choose an endianness convention. If you have wide bytes then you can be endianness-agnostic.

> AFAIK bytes in such data are always defined to be 8-bit chunks of data

This is usually true, but not always. For example, UTF-16 and UTF-32 data is specified as 16-bit and 32-bit bytes. This is why you need a BOM.

> there's the ctypes module

Yes, this is why I said it's not a serious problem.

Re: The Case Against Python 3

#219

Post by upofadown »

>There is a high probability that Python 3 is such a failure it will kill Python.

This seems unlikely. Python 2 is a very popular language. There is currently more than one implementation. So no matter how weird the Python 3 thing gets, Python 2 should be available in some form.

Python 3 is actually helping Python 2 here. It attracts those who want to do cool new language things, leaving Python 2 as a stable target.

Re: The Case Against Python 3

#220

Post by geezerjay »

haikuginger wrote: post #9
ayrx wrote: 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.

I also can't run Python 2 by passing it into a C compiler. Man, I should publish a paper on this- they thought C was Turing-complete, but I proved them wrong!

Considering how C has been targeted for all sorts of nonsense, I suspect that your argument would be somehow used as irrefutable proof that C is outdated and deprecated.

At least that's the conclusion that is repeatedly forced upon C, no matter what the argument is.

Post reply on HN