Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Steven D'Aprano]

On Sat, 05 Apr 2014 00:02:58 -0500, Mark H Harris wrote:

>     Having said that, I do believe that the migration to C python3 has
> been too conservative. 

Why? Is it a race? Does Python 2.x turn into PHP at midnight?

Some people think the move to Python 3 has been too radical and too fast 
for them. Are they wrong?


> Nobody wants to maintain a fork, not really.

There will be no serious fork of Python 2.7.

Oh, I dare say that when the core developers finally announce Python 2.7 
is end-of-lifed, probably in another five or so years, there will be a 
flurry of cheap talk about forking Python, and maybe even a few 
"Python2.8" projects on Github. But nobody will use them, and they will 
fade away into obscurity. I can't see *anyone* with the necessary  
resources taking on the job and gathering enough community support for a 
successful fork.

With perhaps one exception. Twisted has apparently said they cannot 
migrate to 3.x. They might, I suppose, take up maintenance of Python 2.7. 
But I doubt it. I expect that when push comes to shove in 4 or 5 years 
time, they'll find a way to migrate.

Python 2.7 will continue to get paid-for support from RedHat until 2024, 
and I expect that there will be companies like Activestate that will 
offer extended support for Python 2.7 for a few years too. But that's it.


> I don't think its something anyone should be afraid of.

Nobody is *afraid* of a fork. But forks do split the community, and 
introduce FUD (Fear, Uncertainty, Doubt), except for the rare occasions 
like the XFree86 to X.Org fork where the entire community moved almost 
overnight to the fork. That was a HUGE vote of no confidence to the 
original maintainer, and (so I'm told) deservedly so.

Nothing like that is plausible with Python. There simply isn't anywhere 
near that level of dissatisfaction with the way the language is being 
managed, mild grumbling from a few people aside. Most importantly, the 
core devs have been *very* responsive to people's complaints.


> Somebody should
> put a date on C python 3.4+ migration and cut off support for 2.7.x/

2045-04-01. If you're not migrated to Python 3.4 by then, no cake for you.

A date will be set when the time is right, but rushing to set a date now 
when we don't know the state of the language in five years time is just 
silly. It is expected to be five years from now, but if there is a flurry 
of migration activity it may be brought forward, and if five years is not 
long enough it may be delayed. *May* be delayed. 

It's fine if people don't migrate to 3.4. Waiting until 3.5 or even 3.6 
is perfectly acceptable too. Leaving it to 3.7 (expected about 5 years 
from now) is probably okay too. The longer you wait to migrate, the 
easier it will be: migrate when the benefit of migrating exceeds the cost.

(I'm talking about application-level projects here. Libraries and 
frameworks are somewhat different.)

Each point release of 3.x has added not just new features to entice 
users, but new features (and sometimes old features) to aid in porting. 
For example, some things that had been dropped, like the callable() built-
in, were re-added in 3.2. 3.3 re-added the u'' syntax solely to aid in 
porting from 2.x. There is a lot of discussion going on to make it easier 
to deal with mixed bytes and ASCII text, which is a very important use-
case which by accident was suited well to the Python 2.x byte-string 
model, but not well suited to the Python 3.x unicode-text versus bytes 
model. You should expect that to come into production in 3.5.


> Its
> just an opinion. If 'Twisted' isn't ready for 3.x, well, they need to
> get ready. 


Are you volunteering to do the work for them?


> That's also just an opinion.

Ah, but is it an *informed* opinion? Do you know why Twisted say they 
cannot migrate to 3.x?




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/