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

271–280 of 281 posts

Re: The Case Against Python 3

#271

Post by barbs »

nailer wrote: post #225

[Re-posting as a top level comment as I don't want to give the comment I'm replying to any more attention.] >> 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. 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…

> This is nonsense obviously, 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.

> This is very, very obvious.

Um...what? That in itself is nonsense.

The reason he brought up Turing completeness is to make it seem like Python 3 breaks some fundamental programming 'law' that all programming languages should adhere to, in order to further his point.

Sure, maybe the Python 3 VM should run Python 2 code, but he doesn't need to puff up his argument like this. It just makes him look uneducated.

Re: The Case Against Python 3

#272

Post by pdonis »

lisper wrote: post #268
pdonis wrote: post #267

Earlier quoted context omitted.

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

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

More precisely, hardware at the time that "the natural unit of data" was becoming a standardized convention was built to operate on units of 8 bits at a time. As you say, the 8-bit convention is mainly for historical reasons, and hardware today can handle larger chunk sizes.

> Python exposes 8-bit florbs, but not other sizes of florbs

To the extent it exposes florbs at all, yes. But that does not mean you are stuck with 8-bit operations in Python in all cases. For example, operations on Python floats use the IEEE standard data chunks, which, as you note, are not 8-bit. Operations on Python integers are not restricted to using 8-bit CPU instructions; they will use whatever register sizes the hardware allows (more precisely, the hardware the Python interpreter was compiled for--if you run a 32-bit Python interpreter on a 64-bit machine, you won't be using 64-bit register operations). It is true that the programmer has no control over the data chunk sizes that Python uses; they are hard-coded into the interpreter.

> Common Lisp has arbitrarily sized florbs.

Can you give an example of how this capability in CL is used?

Re: The Case Against Python 3

#273

Post by lispm »

pdonis wrote: post #272
lisper wrote: post #268

Earlier quoted context omitted.

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

> 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. More precisely, hardware at the time that "the natural unit of data" was becoming a standardized convention was built to operate on units of 8 bits at a time. As you say, the 8-bit convention is mainly for historical reasons, and hardware today can handle larger chunk sizes.…

> Can you give an example of how this capability in CL is used?

Common Lisp for example can extract/set a byte given its width and its position:

    CL-USER 145 > (write (ldb (byte 11 2) #b1100101011010110) :base 2)
    1010110101
(byte 11 2) is a specifier for this: 11 = width, 2 = position.

Historically this comes form a DEC PDP-10 instruction 'load byte'.

Re: The Case Against Python 3

#274

Post by lisper »

pdonis wrote: post #272
lisper wrote: post #268

Earlier quoted context omitted.

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

> 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. More precisely, hardware at the time that "the natural unit of data" was becoming a standardized convention was built to operate on units of 8 bits at a time. As you say, the 8-bit convention is mainly for historical reasons, and hardware today can handle larger chunk sizes.…

The best example I can think of is implementing certain cryptographic algorithms, particularly symmetric ciphers and cryptographically secure hash functions, which are often defined in terms of 32 and 64-bit chunks and mod 2^32 and mod 2^64 arithmetic.

Why not just use C? Because the C language spec has "features" that allow a C compiler optimize away parts of your code that you really don't want optimized away in crypto code. For example, if you do this:

    int secret_key[SIZE];
    ...
    for (int i=0; i
A C compiler is allowed to get rid of that code if it can prove that it doesn't contribute to the final result (the "as-if" rule). Forcing a C compiler to not do such things is generally very tricky.

Re: The Case Against Python 3

#275

Post by asah »

This is so filled with #fakenews it's perhaps easier to pick out the one useful criticism, which is having to learn 3 string formatting styles, which is indeed a pain. For commercial work it seems wise to stdize on one in a given project/organization.

As for the rest, I'll pile on: - python3 is eight years old, not decades, and this matters: Perl4 => 5 was a similarly long transition and for similar reasons. - python3 is obviously Turing complete. Moreover, I'm not sure its lack of whatever the author thinks TC means, actually matters in the question of whether python3 is worth choosing to learn or build systems. - very few languages can be used "side by side" with each other, and I want aware that this was a common use case. If you have python2 code, there are various ways to invoke it without porting, eg subprocess, web service, etc. Obviously, there's various costs eg performance, system mgmt, debugging, etc. - high probability of failure? Strange but I see the exact opposite, with more and more projects more supporting ONLY python3 ie the tide is turning. Anyway, this is scaremongering and #fakenews so YMMV.

Re: The Case Against Python 3

#276

Post by IndianAstronaut »

TylerE wrote: post #69
IndianAstronaut wrote: post #23

Earlier quoted context omitted.

I think Python is amazing to get small stuff ip and running and quick scripts, but it quickly becomes a nightmare as the project scales up.

Why would you say that? The main Python project I work on is 271k LOC... no problems here.

The lack of type checking makes it much harder to coordinate right inputs and outputs. Doable, but makes the overhead much harder than when you do have it.

Re: The Case Against Python 3

#277

Post by RandomInteger4 »

dagw wrote: post #209
RandomInteger4 wrote: post #145

Earlier quoted context omitted.

I feel like I'm the only one who learned Python from the official site's tutorial page: https://docs.python.org/3/tutorial/index.html I found it really helpful.

Did you learn programming from that tutorial or just python? What's good about Learn Python the Hard Way is that it first and foremost teaches programming, with python largely being an implementation detail.

Ah, I see. No, I learned programming eons ago with a "Logic of Programming" course at my local community college where the book in question made heavy reference to mainframe programming and came with a stencil for flowcharts. There was no actual coding involved when learning the concepts, just tediously produced flowcharts and ample use of a sketch pad / eraser. Kids these days would be better off learning in a similar fashion.

Re: The Case Against Python 3

#279

Post by kazinator »

lisper wrote: post #274
pdonis wrote: post #272

Earlier quoted context omitted.

> 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. More precisely, hardware at the time that "the natural unit of data" was becoming a standardized convention was built to operate on units of 8 bits at a time. As you say, the 8-bit convention is mainly for historical reasons, and hardware today can handle larger chunk sizes.…

The best example I can think of is implementing certain cryptographic algorithms, particularly symmetric ciphers and cryptographically secure hash functions, which are often defined in terms of 32 and 64-bit chunks and mod 2^32 and mod 2^64 arithmetic. Why not just use C? Because the C language spec has "features" that allow a C compiler optimize away parts of your code that you really don't want optimized away in cr…

Not really. Just put the clearing function into another translation unit.

    clear_memory(secret_key, sizeof secret_key);
(And don't enable any wacky whole program link-time optimizations. Those violate ISO C by continuing semantic analysis into translation phase 8. ISO C makes it clear that tokens are "syntactically and semantically analyzed" in phase 7, as translation unit. Then in phase 8, only references are resolved to link. Doing any semantic analysis to optimize things at link time violates the conceptual model thereby given. GCC has support for this but it has to be explicitly enabled; moreover, there is more to using link-time optiizations than just passing options.)

The current translation unit must really call clear_memory and really pass it the pointer to the secret_key, whose contents have to be settled. The writes performed by clear_memory really have to take place, because the caller depends on it; clear_memory has no idea that the object is dead (having no next use) in the calling translation unit.

The main problem is not getting the clearing not to be elided, but with stray copies of the data being elsewhere. The C programmer doesn't have visibility and control over all the storage areas where a datum may end up. If secret_key is really cleared, is that enough?

Re: The Case Against Python 3

#280

Post by suzuki »

saurik wrote: post #229
MereInterest wrote: post #123

Earlier quoted context omitted.

The most visible changes, such as print being a function, are the easiest and most trivial to adapt to. They clean up the language, and can be automatically converted from one to the other. This can be pulled into python 2 with "from __future__" imports. The harder part is the string handling. In Python 2, you have one class, string, which is performing two different jobs. It is acting both as a holder for text, and…

> In Python 2, you have one class, string, which is performing two different jobs. What? Have you used Python 2? No: in Python 2, you have two classes; one is called "str" and represents a sequence of bytes, and one is called "unicode" and represents text. The former is used while interacting with network protocols and files, and the latter is what you use internally in your program: at the boundaries you use .decode…

I totally agree with you.

> ... one is called "str" and represents a sequence of bytes ... The former is used while interacting with network protocols and files ... Python 3 actually got this wrong for years ...

Actually some Japanese have suffered from this wrong design of Python 3. If you read Japanese, please see http://www.oki-osk.jp/esc/python/upload-cgi/v2.html#3

Post reply on HN