On Lists and Iterables

[Xen]

Neal McBurnett schreef op 16-12-2017 18:16:

> Though, as John Lenton notes, there are excellent reasons for most of
> the changes in Python 3

By the way, all of these "excellent reasons" are disputed.

And citing "authorative sources" does not make them any less disputed, 
or any more "proven".

The fact is and remains that this is a selling out to the gains of the 
material world, ie. more efficiency.

Apart from the apparently very broken implementation of unicode, I think 
most of the changes (apart from new language features) come down to 
efficiency of execution.

I'm not sure, using a broad sweep here.

But for instance:

- print x
+ print(x)

Is not mandated by anything. You go from script syntax to compiled 
language syntax. This agrees with the notion that they wanted more 
efficiency at the cost of developer pleasance.

We see an evolution from a script language to a compiled language here. 
That is not mandated by ANYTHING other than the choice to sacrifice 
readability for performance.

That's what they have done. They have sacrificed the attractiveness of 
their language for more cpu cycle output.

That is what Python 3 represents.

>    Why Python 3 exists https://snarky.ca/why-python-3-exists/

He only takes about unicode.

Which is a deficient and extremely poor solution to the problem that is 
apparently arguably worse than the situation that existed before, at 
least for lowlevel programmers who have to write protocols and such 
things.

So the argument "because unicode" really needs to be qualified with "how 
good is your solution actually?"

But that's the only argument he makes, and they've just failed at their 
task.

It simply means that Python 3 is a failure with respect to the task 
they've set themselves, even if the original intent (to solve the 
unicode mess) was good.

It's possible to fail at what you do you know.

If I try to climb a tree it doesn't mean I succeed.

If I try to paint a house but the walls end up in all the wrong colours 
and then I say "Here, I'm done" that doesn't mean that I have succeeded.

 From the perspective of anyone that needs to format or convert strings 
that are not composed of unicode code points, the whole system is a 
failure.

> For more on the rationale for changes related to iterators see
> http://portingguide.readthedocs.io/en/latest/iterators.html

That entire rationale is only explained with one word "memory 
consumption".

So now you are changing the design of your _grammar_ just so that the 
resulting code will use less memory.

That is the job of the compiler, not the developer.

You are exposing language internals because this way the compiler 
(interpreter) doesn't need to do any work, and the developer now 
directly has to work with intermediate objects like I said, it's more 
work for the developer, but in *some* cases will lead his application to 
use a little less memory,

even though these are discardable objects in that case and the memory 
will be reclaimed anyway.

So even though it's the programmer's job to ensure the objects get 
garbage collected,

by scoping them properly,

you NOW make it his job to perform meaningless optimizations that for 
90% of code will not matter a thing,

AND you make that an essential element of language "design" (nondesign) 
that everyone suffers from.

And you call THIS good?

It's a freaking hack to consume less memory.

Like what the hell is going on here.

Virtually no one benefits from this.

Python has excellent scoping. All those objects are released quickly 
enough.

This is even more dumb than I thought.

You are really insulting my intelligence here you know.

If these temporary objects get discarded anyway, then what's the deal?

We have 8GB of RAM.

The compiler/interpreter can easily optimize this as well internally.

And what do they do:

    "Alternatively, you can keep the higher-order function call,
    and wrap the result in list. However, many people will find
    the resulting code less readable:"

Ah, now we get to it! They have changed the result of map and filter to 
an iterable, so the original code is now much more ugly:

    "powered = list(map(power_function, numbers))"

    "less readable"

Yeah, you just did that!!!

For your no-benefit language corruption in order to save a bit of memory 
that gets instantly garbage collected.

I am just perplexed. This is really face-palm.

The extra step to convert to list can only be less efficient unless the 
interpreter optimizes that away, which I doubt.

This is plain dumb and plain ignorent.

So you all bought the rap that this would be beneficial but you didn't 
even look into it yourself.

Meanwhile Python 3.4 can be excessively slower than 2.7. SO WHERE'S THE 
GAIN?

https://www.raspberrypi.org/forums/viewtopic.php?t=183829

I have never heard of a dumber decision in any programming language than 
this.