python 3's adoption

[MRAB]

Alf P. Steinbach wrote:
> I'm responding to the original message by Xah Lee, which is not carried 
> by my Usenet provider.
> 
> * Alan Harris-Reid:
>> Xah Lee wrote:
>>> Some thoughts about Python 3 Adoption.
>>>
>>> Xah Lee, 2010-01-26
>>>
>>> Some notes of Wikipedia readings related to Python.
>>>
>>> Unladen Swallow, a new project from Google. It is a new python
>>> compiler with the goal of 5 times faster than the de facto standand
>>> implementation CPython. Also note Stackless Python, which is already
>>> been used in some major commercial projects.
>>>
>>> Was looking into what's new in Python 3. See: 
>>> http://docs.python.org/dev/3.0/whatsnew/3.0.html.
>>> >From a quick reading, i don't really like it. Here's some highlights:
>>>
>>>     * Print is now a function. Great, much improvement.
> 
> Actually not, IMHO. All it does is is to provide incompatibility. They 
> forgot Ronald Reagan's old maxim: if it don't need fixin', don't fix it.
> 
It was an inconsistency in the language.

BTW, the usual form of the maxim is: if it ain't broke, don't fix it.
> 
>>>     * Many functions that return lists now returns “Views” or
>>> “Iterators” Instead. A fucking fuck all fucked up shit. A extraneous
>>> “oop engineering” complication. (See: Lambda in Python 3000)
> 
> On the contrary, this is a great improvement. It makes no sense to have 
> to write more code and less readable code for the common efficient case. 
> And the default, the way that takes 0.5 seconds less to do, does have a 
> great influence on what people choose, even in elections (Obama's latest 
> "opt out" proposal is an example that this principle is recognized even 
> by the President of the United States). When you want an explicit 
> collection such as a 'list', introducing some overhead for presumably a 
> good reason, it's as easy as e.g. 'list(range(42))'.
> 
> 
>>>     * The cmp() function used in sort is basically gone, users are now
>>> supposed to use the “key” parameter instead. This is a flying-face-
>>> fuck to computer science. This would be the most serious fuckup in
>>> python 3. (See: Sorting in Python and Perl)
> 
> I agree. :-)
> 
> Probably there must have been some rationale, but to put it bluntly 
> removing the comparator is more like moronic than pythonic. If the 
> rationale was efficiency, then a rational solution could be to provide 
> two sort methods, like 'sort' using direct comparisions and 
> 'custom_sort' using a specified comparator. Come to think of it, that 
> door is still open, except for the language spec freeze.
> 
> It's possible to work around the removal of 'cmp' in various kludgy 
> ways, but you shouldn't have to "work around" a library sort routine.
> 
Why two sort methods? It would be simpler just to retain the 'cmp'
argument, like it is in Python 2.6, but deprecated.
> 
>>>     * Integers by default is long. Great!
> 
> Yes, totally agree.
> 
> Nothing confuses the newbie or the now-and-then programmer so much as 
> limited range integers.
> 
Limited range? That hasn't been the case with 'int' for long time!
(It's automatically promoted to long.)


[snip]