Re: python 3's adoption

[Steven D'Aprano]

On Fri, 29 Jan 2010 07:10:01 +0100, Alf P. Steinbach wrote:

 L = [æ, ø, å]   # This is in SORTED ORDER in Norwegian L

[...]

 L.sort( key = locale.strxfrm )
 L
['å', 'æ', 'ø']
 locale.strcoll( å, æ )
1
 locale.strcoll( æ, ø )
-1
 
 Note that strcoll correctly orders the strings as [æ, ø, å], that
 is, it would have if it could have been used as cmp function to sort (or
 better, to a separate routine named e.g. custom_sort).

This is in Python2.5, so I'm explicitly specifying unicode strings:

 L = [uæ, uø, uå]
 assert sorted(L) == [u'å', u'æ', u'ø']

The default C-locale sorting of L does not equal to L. Now let's change 
to Norwegian locale:

 import locale
 locale.setlocale(locale.LC_ALL, 'nb_NO')
'nb_NO'
 print u''.join(sorted(L, cmp=locale.strcoll))
æøå

So far so good, we've confirmed that in Python 2.5 we can sort in a 
locale-aware form. Now, can we do this with a key function? Thanks to 
Raymond Hettinger's recipe here:

http://code.activestate.com/recipes/576653/


 print u''.join(sorted(L, key=CmpToKey(locale.strcoll)))
æøå


Success!

Let's try it in Python 3.1:

 L = [æ, ø, å]
 assert sorted(L) == ['å', 'æ', 'ø']

 import locale
 locale.setlocale(locale.LC_ALL, 'nb_NO')
'nb_NO'
 ''.join(sorted(L, key=CmpToKey(locale.strcoll)))
'æøå'


The definition of CmpToKey can be found at the URL above. It's not very 
exciting, but here it is:


def CmpToKey(mycmp):
'Convert a cmp= function into a key= function'
class K(object):
def __init__(self, obj, *args):
self.obj = obj
def __lt__(self, other):
return mycmp(self.obj, other.obj) == -1
def __gt__(self, other):
return mycmp(self.obj, other.obj) == 1
def __eq__(self, other):
return mycmp(self.obj, other.obj) == 0
def __le__(self, other):
return mycmp(self.obj, other.obj) != 1  
def __ge__(self, other):
return mycmp(self.obj, other.obj) != -1
def __ne__(self, other):
return mycmp(self.obj, other.obj) != 0
return K


If that's too verbose for you, stick this as a helper function in your 
application:


def CmpToKey(mycmp):
'Convert a cmp= function into a key= function'
class K(object):
def __init__(self, obj, *args):
self.obj = obj
__lt__ = lambda s, o: mycmp(s.obj, o.obj) == -1
__gt__ = lambda s, o: mycmp(s.obj, o.obj) == 1
__eq__ = lambda s, o: mycmp(s.obj, o.obj) == 0
__le__ = lambda s, o: mycmp(s.obj, o.obj) != 1
__ge__ = lambda s, o: mycmp(s.obj, o.obj) != -1
__ne__ = lambda s, o: mycmp(s.obj, o.obj) != 0
return K


[...]
 The above may just be a bug in the 3.x stxfrm. But it illustrates that
 sometimes you have your sort order defined by a comparision function.
 Transforming that into a key can be practically impossible (it can also
 be quite inefficient).

This might be true, but you haven't demonstrated it. With one little 
helper function, you should be able to convert any comparison function 
into a key function, with relatively little overhead.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Duncan Booth]

Steven D'Aprano st...@remove-this-cybersource.com.au wrote:

 If that's too verbose for you, stick this as a helper function in your 
 application:
 
 
 def CmpToKey(mycmp):
 'Convert a cmp= function into a key= function'
 class K(object):
 def __init__(self, obj, *args):
 self.obj = obj
 __lt__ = lambda s, o: mycmp(s.obj, o.obj) == -1
 __gt__ = lambda s, o: mycmp(s.obj, o.obj) == 1
 __eq__ = lambda s, o: mycmp(s.obj, o.obj) == 0
 __le__ = lambda s, o: mycmp(s.obj, o.obj) != 1
 __ge__ = lambda s, o: mycmp(s.obj, o.obj) != -1
 __ne__ = lambda s, o: mycmp(s.obj, o.obj) != 0
 return K
 
 

Shouldn't that be:

def CmpToKey(mycmp):
'Convert a cmp= function into a key= function'
class K(object):
def __init__(self, obj, *args):
self.obj = obj
__lt__ = lambda s, o: mycmp(s.obj, o.obj)  0
__gt__ = lambda s, o: mycmp(s.obj, o.obj)  0
__eq__ = lambda s, o: mycmp(s.obj, o.obj) == 0
__le__ = lambda s, o: mycmp(s.obj, o.obj) = 0
__ge__ = lambda s, o: mycmp(s.obj, o.obj) = 0
__ne__ = lambda s, o: mycmp(s.obj, o.obj) != 0
return K

After all the cmp function needn't return -1,0,1 only negative, 0, 
positive.

And if that's still too verbose for you try:

def CmpToKey(mycmp):
'Convert a cmp= function into a key= function'
class K(object):
def __init__(self, obj, *args):
self.obj = obj
__lt__ = lambda s, o: mycmp(s.obj, o.obj)  0
return K

That works on 3.1 and 2.6 though of course there's no guarantee that a 
future Python version won't use a different comparison operator so only 
use it if you like living dangerously and have problems typing. :^)


-- 
Duncan Booth http://kupuguy.blogspot.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Boddie]

On 29 Jan, 06:56, Terry Reedy tjre...@udel.edu wrote:
 On 1/28/2010 6:47 PM, Paul Boddie wrote:

  What would annoy me if I used Python 3.x would be the apparent lack of
  the __cmp__ method for conveniently defining comparisons between
  instances of my own classes. Having to define all the rich comparison
  methods frequently isn't even as much fun as it sounds.

 You define __eq__, which automatically generates __ne__.

From the Python 3.1 language reference:

There are no implied relationships among the comparison operators.
The truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the
operators will behave as expected.

Maybe Python 3.1 plugs a default method in, anyway.

 You define __lt__, which is all sort and heap need.
 This should be about as easier than __eq__, which is really needed, and
 __cmp__. If you need the other 3, either copy the recipe in the
 Cookbook, or, even faster

 def __ge__(s,o): return o.__lt__(s)
 def __le__(s,o): return s  o or s == o
 def __ge__(s,o): return s  o or s == o

Spot the error in the above. ;-) Of course, this could be defined in a
base class and be inherited everywhere, but the case that made me
raise this issue actually involved instances of a class delegating
comparison/sorting to another object. With __cmp__ this can be done
concisely and only involve the delegation of one method - not so with
the rich comparison protocol.

Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Steven D'Aprano:

On Fri, 29 Jan 2010 07:10:01 +0100, Alf P. Steinbach wrote:


L = [æ, ø, å]   # This is in SORTED ORDER in Norwegian L


[...]


L.sort( key = locale.strxfrm )
L
   ['å', 'æ', 'ø']
locale.strcoll( å, æ )
   1
locale.strcoll( æ, ø )
   -1

Note that strcoll correctly orders the strings as [æ, ø, å], that
is, it would have if it could have been used as cmp function to sort (or
better, to a separate routine named e.g. custom_sort).


This is in Python2.5, so I'm explicitly specifying unicode strings:


L = [uæ, uø, uå]
assert sorted(L) == [u'å', u'æ', u'ø']


The default C-locale sorting of L does not equal to L. Now let's change 
to Norwegian locale:



import locale
locale.setlocale(locale.LC_ALL, 'nb_NO')

'nb_NO'

print u''.join(sorted(L, cmp=locale.strcoll))

æøå

So far so good, we've confirmed that in Python 2.5 we can sort in a 
locale-aware form. Now, can we do this with a key function? Thanks to 
Raymond Hettinger's recipe here:


http://code.activestate.com/recipes/576653/



print u''.join(sorted(L, key=CmpToKey(locale.strcoll)))

æøå


Success!

Let's try it in Python 3.1:


L = [æ, ø, å]
assert sorted(L) == ['å', 'æ', 'ø']

import locale
locale.setlocale(locale.LC_ALL, 'nb_NO')

'nb_NO'



Hm. A bit off-topic, but...

   import locale
   locale.setlocale(locale.LC_ALL, 'nb_NO')
  Traceback (most recent call last):
File stdin, line 1, in module
File C:\Program Files\cpython\python31\lib\locale.py, line 527, in
  return _setlocale(category, locale)
  locale.Error: unsupported locale setting
   _

This on a machine where the Python default locale is Norwegian.



''.join(sorted(L, key=CmpToKey(locale.strcoll)))

'æøå'


The definition of CmpToKey can be found at the URL above. It's not very 
exciting, but here it is:



def CmpToKey(mycmp):
'Convert a cmp= function into a key= function'
class K(object):
def __init__(self, obj, *args):
self.obj = obj
def __lt__(self, other):
return mycmp(self.obj, other.obj) == -1
def __gt__(self, other):
return mycmp(self.obj, other.obj) == 1
def __eq__(self, other):
return mycmp(self.obj, other.obj) == 0
def __le__(self, other):
return mycmp(self.obj, other.obj) != 1  
def __ge__(self, other):

return mycmp(self.obj, other.obj) != -1
def __ne__(self, other):
return mycmp(self.obj, other.obj) != 0
return K


This is pretty smart as a generic solution.

Thanks! :-)

I was thinking more of sticking those comparisions in some custom string class 
or such, which would be rather ugly...


The above does have quite high overhead though!

That is, it's /inefficient/ compared to using a 'cmp' function directly.


If that's too verbose for you, stick this as a helper function in your 
application:



def CmpToKey(mycmp):
'Convert a cmp= function into a key= function'
class K(object):
def __init__(self, obj, *args):
self.obj = obj
__lt__ = lambda s, o: mycmp(s.obj, o.obj) == -1
__gt__ = lambda s, o: mycmp(s.obj, o.obj) == 1
__eq__ = lambda s, o: mycmp(s.obj, o.obj) == 0
__le__ = lambda s, o: mycmp(s.obj, o.obj) != 1
__ge__ = lambda s, o: mycmp(s.obj, o.obj) != -1
__ne__ = lambda s, o: mycmp(s.obj, o.obj) != 0
return K


[...]

The above may just be a bug in the 3.x stxfrm. But it illustrates that
sometimes you have your sort order defined by a comparision function.
Transforming that into a key can be practically impossible (it can also
be quite inefficient).


This might be true, but you haven't demonstrated it.


The can be ... practically impossible was hogwash. I posted late, sorry. The 
quite inefficient holds.



With one little 
helper function, you should be able to convert any comparison function 
into a key function, with relatively little overhead.


I wouldn't call an extra Python method call per comparision relatively little 
overhead.


Note that the same number of comparisions as with a 'cmp' based sort is 
performed.

But with the wrapper every comparision is indirected through a Python method 
call (I think, but not sure, that the creation of those comparision objects does 
not introduce significant overhead, but the calls must).



code
# -*- coding: utf-8 -*-
from __future__ import print_function
from __future__ import unicode_literals
try:
range = xrange
except:
pass


import locale
import sys
import random
import timeit

def CmpToKey( mycmp ):
Convert a cmp= function into a key= function
class K( object ):
def __init__( self, obj, *args ):
self.obj = obj
def __lt__( self, other ):
return mycmp( self.obj, other.obj ) == -1
def __gt__( self, other ):
return mycmp( self.obj, other.obj ) == 1
def __eq__( self, other ):
return mycmp( self.obj, other.obj ) == 0
def __le__( self, 

Re: python 3's adoption

[Paul Rubin]

Jonathan Gardner jgard...@jonathangardner.net writes:
 If you're going to have statements, you're going to need the null
 statement. That's pass.

Why?  Expressions are statements, so you could just say pass (in
quotes, denoting a string literal), or 0, or None, os anything else like
that, instead of having a special statement.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Steven D'Aprano:

On Wed, 27 Jan 2010 18:29:25 +0100, Alf P. Steinbach wrote:


The main problem with the incompatibility is for porting code, not for
writing code from scratch.


Correct. It's a trivial problem, but still a problem.


It's also a problem wrt. learning the language.


This makes no sense. Why is it harder to learn

print(x, y, z)

than this?

print x, y, z


I think it's actually easier to learn just the 3.x form.

But it's more difficult to learn that there are /two different/ syntactic forms, 
depending on which version of Python you're using and in addition depending on 
__future__ declarations!


E.g., picking up some example code from the web, and it does not work...


The first case is like the other functions you have to learn, like len(). 
In fact, many newbies to Python put unneeded parentheses around arguments 
to print simply because they assume it is a function.


I would argue that the new print function is *simpler* to learn. It is 
more consistent with other built-ins, and has fewer magic idioms to 
learn.


Yes, yes, yes, I agree.



Instead of:

print fileObj, x, y, z

you use regular function syntax with a meaningful keyword:

print(x, y, z, file=fileObj)

If you want suppress the newline at the end of each print:

print x, y, z,  # note the final comma

compared to:

print(x, y, z, end='')


Actually I thought the final comma thing was nice. It was like Basic. I think 
the 2.x 'print' must have been modeled on Basic's 'print'.




If you want to change the space between elements, instead of:

sys.stdout.write(str(x) + * + str(y) + * + str(z) + '\n')

you use:

print(x, y, z, sep='*')


If you want to override the behaviour of print in a module, instead of 
having to edit the source code of the module (which might not even be 
available), all you need to do is monkey-patch it:


import module
module.print = myprint


   import builtins
  
   org_print = print
   builtins.print = 666
  
   print( trallala )
  Traceback (most recent call last):
File stdin, line 1, in module
  TypeError: 'int' object is not callable
   org_print( but is that really so smart? )
  but is that really so smart?
   _


Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Luis M . González]

 Please don't post more noise and ad hominem attacks to the group, Steve.

Ad hominem?
Please, operor non utor lingua non notus per vulgaris populus.
Gratias ago vos...

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Gib Bogle]

Luis M. González wrote:

Please don't post more noise and ad hominem attacks to the group, Steve.


Ad hominem?
Please, operor non utor lingua non notus per vulgaris populus.
Gratias ago vos...



ad hominem is lingua notus per vulgaris populus, the vulgar pop of these 
parts, anyway.

--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Mitchell L Model]

I have been working with Python 3 for over a year. I used it in  
writing my book Bioinformatics Programming Using Python (http://oreilly.com/catalog/9780596154509 
). I didn't see any point in teaching an incompatible earlier version  
of a language in transition. In preparing the book and its examples I  
explored a large number of Python modules in some depth and  
encountered most of the differences between the language and libraries  
of Python 2 and Python 3. The change was a bit awkward for a while,  
and there were some surprises, but in the end I have found nothing in  
Python 3 for which I would prefer Python 2's version.


Removal of old-style classes is a big win. Having print as a function  
provides a tremendous amount of flexibility. I use the sep and end  
keywords all the time. There is no reason for print to be a statement,  
and it was an awkward inconsistency in a language that leans towards  
functional styles. Likewise the elimination of cmp, while shocking,  
leads to much simpler comparison arguments to sort, since all the  
function does is return a key; then, sort uses __lt__ (I think) so it  
automatically uses each class's definition of that. The weird objects  
returned from things like sorted, dict.keys/values/items, and so on  
are values that in practice are used primarily in iterations; you can  
always turn the result into a list, though I have to admit that while  
developing and debugging I trip trying to pick out a specific element  
from one of these using indexing (typically [0]); I've learned to  
think of them as generators, even though they aren't. The  
rearrangements and name changes in the libraries are quite helpful. I  
could go on, but basically the language and library changes are on the  
whole large improvements with little, if any, downside.


Conversion of old code is greatly facilitied by the 2to3 tool that  
comes with Python 3. The big issue in moving from 2 to 3 is the  
external libraries and development tools you use. Different IDEs have  
released versions that support Python 3 at different times. (I believe  
Wing was the first.) If you use numpy, for example, or one of the many  
libraries that require it, you are stuck. Possibly some important  
facilities will never be ported to Python 3, but probably most active  
projects will eventually produce a Python 3 version -- for example,  
according to its web page, a Python 3 version  of PIL is on the way. I  
was able to cover all the topics in my book using only Python library  
modules, something I felt would be best for readers -- I used  
libraries such as elementree, sqlite3, and tkinter. The only  
disappointment was that I couldn't include a chapter on BioPython,  
since there is no Python 3 version.


By now, many large facilities support both Python 2 and Python 3. I am  
currently building a complex GUI/Visualization application based on  
the Python 3 version of PyQt4 and Wing IDE and am delighted with all  
of it. It may well be that some very important large 
--

http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Roy Smith]

In article mailman.1545.1264694607.28905.python-l...@python.org,
 Mitchell L Model mlm...@comcast.net wrote:

 I use the sep and end keywords all the time.

What are 'sep' and 'end'?  I'm looking in 
http://docs.python.org/3.1/genindex-all.html and don't see those mentioned 
at all.  Am I just looking in the wrong place?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Roy Smith:

In article mailman.1545.1264694607.28905.python-l...@python.org,
 Mitchell L Model mlm...@comcast.net wrote:


I use the sep and end keywords all the time.


What are 'sep' and 'end'?  I'm looking in 
http://docs.python.org/3.1/genindex-all.html and don't see those mentioned 
at all.  Am I just looking in the wrong place?


   print( print.__doc__ )
  print(value, ..., sep=' ', end='\n', file=sys.stdout)

  Prints the values to a stream, or to sys.stdout by default.
  Optional keyword arguments:
  file: a file-like object (stream); defaults to the current sys.stdout.
  sep:  string inserted between values, default a space.
  end:  string appended after the last value, default a newline.
   _


Cheers  hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Lie Ryan]

On 01/28/10 19:37, Paul Rubin wrote:
 Jonathan Gardner jgard...@jonathangardner.net writes:
 If you're going to have statements, you're going to need the null
 statement. That's pass.
 
 Why?  Expressions are statements, so you could just say pass (in
 quotes, denoting a string literal), or 0, or None, os anything else like
 that, instead of having a special statement.

or, if the null statement pass is removed, you could define:
pass = None
or
pass = object() # sentinel

and have essentially the same thing.

hmm... on second thought, not special-casing pass means doing a
LOAD_GLOBAL or LOAD_CONST for operation that is supposed to be doing
nothing.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Lie Ryan]

On 01/28/10 20:12, Alf P. Steinbach wrote:
 * Steven D'Aprano:
 On Wed, 27 Jan 2010 18:29:25 +0100, Alf P. Steinbach wrote:
 Instead of:

 print fileObj, x, y, z

 you use regular function syntax with a meaningful keyword:

 print(x, y, z, file=fileObj)

 If you want suppress the newline at the end of each print:

 print x, y, z,  # note the final comma

 compared to:

 print(x, y, z, end='')
 
 Actually I thought the final comma thing was nice. It was like Basic. I
 think the 2.x 'print' must have been modeled on Basic's 'print'.

if that was true, then python missed the final semicolon

 If you want to change the space between elements, instead of:

 sys.stdout.write(str(x) + * + str(y) + * + str(z) + '\n')

 you use:

 print(x, y, z, sep='*')


 If you want to override the behaviour of print in a module, instead of
 having to edit the source code of the module (which might not even be
 available), all you need to do is monkey-patch it:

 import module
 module.print = myprint
 
import builtins
   
org_print = print
builtins.print = 666
   
print( trallala )
   Traceback (most recent call last):
 File stdin, line 1, in module
   TypeError: 'int' object is not callable
org_print( but is that really so smart? )
   but is that really so smart?
_

Monkey patching follows (or should follow) the same rule as class
inheritance overriding: the overrider's input domain must be a superset
of the overriden's input domain and the overrider's output range must be
a subset of the overriden's output range. 666 object (int) is not even
remotely compatible with function object.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Lie Ryan:

On 01/28/10 20:12, Alf P. Steinbach wrote:

   import builtins
  
   org_print = print
   builtins.print = 666
  
   print( trallala )
  Traceback (most recent call last):
File stdin, line 1, in module
  TypeError: 'int' object is not callable
   org_print( but is that really so smart? )
  but is that really so smart?
   _


Monkey patching follows (or should follow) the same rule as class
inheritance overriding: the overrider's input domain must be a superset
of the overriden's input domain and the overrider's output range must be
a subset of the overriden's output range. 666 object (int) is not even
remotely compatible with function object.


Yes, that's my point.

A 'print' replacement should ideally provide all the guarantees on behavior that 
 standard 'print' does.


And with that it's not so easy to put in a /correct/ replacement of 'print'; in 
particular, it has to honor the 'file' keyword argument.


Thus the 3.x design makes it easy to replace 'print' incorrectly.

I'd rather still had 'print' as keyword... ;-)


Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Terry Reedy]

On 1/28/2010 3:37 AM, Paul Rubin wrote:

Jonathan Gardnerjgard...@jonathangardner.net  writes:

If you're going to have statements, you're going to need the null
statement. That's pass.


Why?  Expressions are statements, so you could just say pass (in
quotes, denoting a string literal), or 0, or None, os anything else like
that, instead of having a special statement.


As Python is currently compiled, you are right, pass is not needed.
A string becomes the doc attribute, and becomes local var 0, but 0 is 
just ignored. I actually expected a load_const but that is now optimized 
away. I am not sure this was always true. Perhaps 'pass' is easier than 
'0' for mewcomers reading the tutorial, but I have no data.


 def f(): ''

 def g(): pass

 def h(): 0

 from dis import dis
 dis(f)
  1   0 LOAD_CONST   1 (None)
  3 RETURN_VALUE
 dis(g)
  1   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE
 dis(h)
  1   0 LOAD_CONST   0 (None)
  3 RETURN_VALUE
 f.__doc__
''
 g.__doc__


Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Terry Reedy]

On 1/28/2010 11:03 AM, Mitchell L Model wrote:

I have been working with Python 3 for over a year. I used it in writing
my book Bioinformatics Programming Using Python
(http://oreilly.com/catalog/9780596154509). I didn't see any point in
teaching an incompatible earlier version of a language in transition. In
preparing the book and its examples I explored a large number of Python
modules in some depth and encountered most of the differences between
the language and libraries of Python 2 and Python 3. The change was a
bit awkward for a while, and there were some surprises, but in the end I
have found nothing in Python 3 for which I would prefer Python 2's version.

Removal of old-style classes is a big win. Having print as a function
provides a tremendous amount of flexibility. I use the sep and end
keywords all the time. There is no reason for print to be a statement,
and it was an awkward inconsistency in a language that leans towards
functional styles. Likewise the elimination of cmp, while shocking,
leads to much simpler comparison arguments to sort, since all the
function does is return a key; then, sort uses __lt__ (I think) so it
automatically uses each class's definition of that. The weird objects
returned from things like sorted, dict.keys/values/items, and so on are
values that in practice are used primarily in iterations; you can always
turn the result into a list, though I have to admit that while
developing and debugging I trip trying to pick out a specific element
from one of these using indexing (typically [0]); I've learned to think
of them as generators, even though they aren't. The rearrangements and
name changes in the libraries are quite helpful. I could go on, but
basically the language and library changes are on the whole large
improvements with little, if any, downside.


I agree completely.


Conversion of old code is greatly facilitied by the 2to3 tool that comes
with Python 3. The big issue in moving from 2 to 3 is the external
libraries and development tools you use. Different IDEs have released
versions that support Python 3 at different times. (I believe Wing was
the first.) If you use numpy, for example, or one of the many libraries
that require it, you are stuck. Possibly some important facilities will
never be ported to Python 3, but probably most active projects will
eventually produce a Python 3 version -- for example, according to its
web page, a Python 3 version of PIL is on the way. I was able to cover
all the topics in my book using only Python library modules, something I
felt would be best for readers -- I used libraries such as elementree,
sqlite3, and tkinter. The only disappointment was that I couldn't
include a chapter on BioPython, since there is no Python 3 version.

By now, many large facilities support both Python 2 and Python 3. I am
currently building a complex GUI/Visualization application based on the
Python 3 version of PyQt4 and Wing IDE and am delighted with all of it.
It may well be that some very important large


Something got clipped ;-)

Anyway, thank you for the report.

Terry Jan Reedy


--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Fencer]

On 2010-01-28 17:03, Mitchell L Model wrote:

I have been working with Python 3 for over a year. I used it in writing
my book Bioinformatics Programming Using Python
(http://oreilly.com/catalog/9780596154509).


That book sounds very interesting, even though I am more interested in 
the bioinformatic parts, I already know some python. I'll show my boss 
the link, thanks!


- Fencer
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Mitchell L Model]

On Jan 28, 2010, at 12:00 PM, python-list-requ...@python.org wrote:


From: Roy Smith r...@panix.com
Date: January 28, 2010 11:09:58 AM EST
To: python-list@python.org
Subject: Re: python 3's adoption


In article mailman.1545.1264694607.28905.python-l...@python.org,
Mitchell L Model mlm...@comcast.net wrote:


I use the sep and end keywords all the time.


What are 'sep' and 'end'?  I'm looking in
http://docs.python.org/3.1/genindex-all.html and don't see those  
mentioned

at all.  Am I just looking in the wrong place?



Sorry -- I wasn't clear. They are keyword arguments to the print  
function.


--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Mitchell L Model]

On Jan 28, 2010, at 1:40 PM, Terry Reedy tjre...@udel.edu wrote

...



On 1/28/2010 11:03 AM, Mitchell L Model wrote:

I have been working with Python 3 for over a year. ...


I agree completely.


Such sweet words to read!



Conversion of old code is greatly facilitied by the 2to3 tool that  
comes

with Python 3. The big issue in moving from 2 to 3 is the external
libraries and development tools you use. Different IDEs have released
versions that support Python 3 at different times. (I believe Wing  
was
the first.) If you use numpy, for example, or one of the many  
libraries
that require it, you are stuck. Possibly some important facilities  
will

never be ported to Python 3, but probably most active projects will
eventually produce a Python 3 version -- for example, according to  
its
web page, a Python 3 version of PIL is on the way. I was able to  
cover
all the topics in my book using only Python library modules,  
something I
felt would be best for readers -- I used libraries such as  
elementree,

sqlite3, and tkinter. The only disappointment was that I couldn't
include a chapter on BioPython, since there is no Python 3 version.

By now, many large facilities support both Python 2 and Python 3. I  
am
currently building a complex GUI/Visualization application based on  
the
Python 3 version of PyQt4 and Wing IDE and am delighted with all of  
it.

It may well be that some very important large


Something got clipped ;-)


Thanks for noticing. Actually, I had abandoned that sentence and went  
back and
added more to the prior paragraph. Just never went back and deleted  
the false start.




Anyway, thank you for the report.



Glad to contribute; gladder to be appreciated.
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Thu, 28 Jan 2010 13:20:02 -0500, Terry Reedy wrote:

 On 1/28/2010 3:37 AM, Paul Rubin wrote:
 Jonathan Gardnerjgard...@jonathangardner.net  writes:
 If you're going to have statements, you're going to need the null
 statement. That's pass.

 Why?  Expressions are statements, so you could just say pass (in
 quotes, denoting a string literal), or 0, or None, os anything else
 like that, instead of having a special statement.
 
 As Python is currently compiled, you are right, pass is not needed. A
 string becomes the doc attribute, and becomes local var 0, but 0 is just
 ignored. I actually expected a load_const but that is now optimized
 away. I am not sure this was always true. Perhaps 'pass' is easier than
 '0' for mewcomers reading the tutorial, but I have no data.


As I said earlier, a dedicated statement `pass` indicates the intent of 
the author better than some arbitrary constant.

if flag:
0
else:
do_something()


could be a mistake, perhaps the programmer intended to write x = 0, but 
there is no ambiguity with the pass statement. I would hope that 
PyChecker and the equivalent would flag the use of bare constants in code 
and give a warning.

In any case, while such a idiom works in code, it plays havoc with the 
interactive interpreter:

 while 1:
...pass
... 
'pass'
'pass'
'pass'
'pass'
'pass'

Traceback (most recent call last):
  File stdin, line 2, in module
KeyboardInterrupt


I have trimmed the output for convenience -- in reality, it fills my 
terminal's output buffer faster than I can hit ctrl-C. Using a constant 
as a proxy for the pass statement would get obnoxious really fast.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Boddie]

On 27 Jan, 13:26, Xah Lee xah...@gmail.com wrote:

 So, for practical reasons, i think a “key” parameter is fine. But
 chopping off “cmp” is damaging. When your data structure is complex,
 its order is not embedded in some “key”. Taking out “cmp” makes it
 impossible to sort your data structure.

What would annoy me if I used Python 3.x would be the apparent lack of
the __cmp__ method for conveniently defining comparisons between
instances of my own classes. Having to define all the rich comparison
methods frequently isn't even as much fun as it sounds.

Paul
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Thu, 28 Jan 2010 18:37:56 +0100, Alf P. Steinbach wrote:

 * Lie Ryan:
 On 01/28/10 20:12, Alf P. Steinbach wrote:
import builtins
   
org_print = print
builtins.print = 666
   
print( trallala )
   Traceback (most recent call last):
 File stdin, line 1, in module
   TypeError: 'int' object is not callable
org_print( but is that really so smart? )
   but is that really so smart?
_
 
 Monkey patching follows (or should follow) the same rule as class
 inheritance overriding: the overrider's input domain must be a superset
 of the overriden's input domain and the overrider's output range must
 be a subset of the overriden's output range. 666 object (int) is not
 even remotely compatible with function object.
 
 Yes, that's my point.
 
 A 'print' replacement should ideally provide all the guarantees on
 behavior that standard 'print' does.
 
 And with that it's not so easy to put in a /correct/ replacement of
 'print'; in particular, it has to honor the 'file' keyword argument.

Oh come on, that's easy. This is Python we're talking about. Any object 
with a write() method is valid.


 class MyIO:
... def __init__(self):
... self.buffer = []
... def write(self, *args):
... self.buffer.extend(args)
...
 io = MyIO()
 print(Say goodnight Gracie, Goodnight Gracie!, file=io)
 io.buffer
['Say goodnight Gracie', ' ', 'Goodnight Gracie!', '\n']


In many cases, probably most, you won't be writing your own full-blown 
print replacement, but merely decorating the existing function. How easy 
is that? Trivial. Here's how to shut down a noisy module that prints too 
much:

 def make_quieter(func):
... def inner(*args, **kwargs):
... out = kwargs.get('file')
... if out in (None, sys.stdout):
... pass
... else:
... func(*args, **kwargs)
... return inner
...
 print = make_quieter(print)
 print(spam spam spam)
 print(spam spam spam, file=io)
 io.buffer
['Say goodnight Gracie', ' ', 'Goodnight Gracie!', '\n', 'spam spam 
spam', '\n']

(except of course you would monkey-patch the module).

Because print is a built-in, getting the original version back is even 
easier:

 del print
 print(spam spam spam)
'spam spam spam'


 
 Thus the 3.x design makes it easy to replace 'print' incorrectly.

This is Python -- the compiler won't stop you from shooting yourself in 
the foot.

 len = 666
 len(hello world)
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: 'int' object is not callable


 I'd rather still had 'print' as keyword... ;-)

We've shown many benefits of print as a function. Can you give any 
benefits of it being a statement, other than backward compatibility for 
those who learned it from Python 2.x?

If you were designing your own language from scratch, so that backwards 
compatibility wasn't an issue, why would you make print a statement?



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Wed, 27 Jan 2010 23:50:55 -0800, Jonathan Gardner wrote:

 I agree on assert. I don't like running a program in test mode and
 then running it in production mode with different code. I would rather
 test what I am going to actually run. assert should be a function, and
 support for removing assert statements should be eliminated.

But then it wouldn't be an assert, it would be a test, and tests are best 
written explicitly.

The whole point of assertions (outside of test code) is that they should 
ALWAYS pass. Since they should always pass, they're safe to optimize 
away, if the user explicitly runs Python with the optimize runtime 
switch. This is under the end-user's control, not the application writer. 
If you don't trust optimized code, don't use it.

Assertions should be treated as this will never happen code, and are 
only there to catch coding errors and logic mistakes. If you expect that 
a test could fail, it shouldn't be written as an assert but as an 
explicit test.

 I simply don't use assert statements at all.

Outside of explicit test code (e.g. unit tests or equivalent), asserts 
should be rare. If you never use them at all, it probably means you're 
either not programming defensively enough, or you're needlessly writing 
explicit tests to cover situations that can't happen. assert exists to 
cover the middle ground between those two extremes.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Steven D'Aprano st...@remove-this-cybersource.com.au writes:
 If you were designing your own language from scratch, so that backwards 
 compatibility wasn't an issue, why would you make print a statement?

As another real estate analogy, my apartment has some problems with its
plumbing, plus an ugly spot on the kitchen wall that could use a coat of
paint to fix.  The plumbing problem is fairly serious (they keep
shutting off the water in the building when it acts up) but the kitchen
spot is a minor annoyance that is mostly hidden by the refrigerator
anyway.  Fixing either of those things would be a hassle: I'd have to
cover all my stuff with plastic and stay out of the apartment for a day
or so while the maintenance guys hacked on things, and I'd expect some
of my stuff to get damaged inadvertently no matter how careful everyone
was.

It's worth dealing with the repair hassles to get the plumbing fixed,
and if I'm going to have to deal with that disruption anyway, then sure,
I'd like them to paint the kitchen spot at the same time.  But if they
say they want me to cover up all my stuff and leave so they can JUST fix
the kitchen spot, and then do the same thing a second time so they can
fix the plumbing at some unspecified date in the future, then I'd rather
just live with the kitchen spot the way it is.  Yes it's a cosmetic
blemish, but it's not causing any real problems, and I'd rather not
deal with the hassle and risk of fixing it if there's no other benefit.

In Python terms, the print statement is the spot on the wall, while the
plumbing is something like the GIL and the legacy codebase that would
break in a hundred ways if Python had real parallelism and a tracing
garbage collector and a native-code compiler and the various language
changes it would take to make all that stuff really fly rather than just
limp along.  If they are going to make everyone deal with the disruption
of migrating to an incompatible version, they should do it once rather
than twice.

In short, there's a mythical Python 4 that only exists in my
imagination, but it already interests me a lot more than Python 3.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[mdj]

On Jan 29, 9:47 am, Paul Boddie p...@boddie.org.uk wrote:
 On 27 Jan, 13:26, Xah Lee xah...@gmail.com wrote:



  So, for practical reasons, i think a “key” parameter is fine. But
  chopping off “cmp” is damaging. When your data structure is complex,
  its order is not embedded in some “key”. Taking out “cmp” makes it
  impossible to sort your data structure.

 What would annoy me if I used Python 3.x would be the apparent lack of
 the __cmp__ method for conveniently defining comparisons between
 instances of my own classes. Having to define all the rich comparison
 methods frequently isn't even as much fun as it sounds.

OT, but you can always define the other operators in terms of a cmp
and mix it in, restoring the original behaviour. Unfortunately it
won't restore the original performance until someone comes to their
senses and restores __cmp__

Matt
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Thu, 28 Jan 2010 17:38:23 -0800, mdj wrote:

 On Jan 29, 9:47 am, Paul Boddie p...@boddie.org.uk wrote:
 On 27 Jan, 13:26, Xah Lee xah...@gmail.com wrote:



  So, for practical reasons, i think a “key” parameter is fine. But
  chopping off “cmp” is damaging. When your data structure is complex,
  its order is not embedded in some “key”. Taking out “cmp” makes it
  impossible to sort your data structure.

 What would annoy me if I used Python 3.x would be the apparent lack of
 the __cmp__ method for conveniently defining comparisons between
 instances of my own classes. Having to define all the rich comparison
 methods frequently isn't even as much fun as it sounds.
 
 OT, but you can always define the other operators in terms of a cmp and
 mix it in, restoring the original behaviour. Unfortunately it won't
 restore the original performance until someone comes to their senses and
 restores __cmp__

Comes to their senses?

There's nothing you can do with __cmp__ that you can't do better with 
rich comparisons, and plenty that rich comparisons can do that __cmp__ is 
utterly incapable of dealing with. __cmp__ is crippled since it can only 
be used for defining classes where the operators  etc return flags. It 
can't be used if you want to implement some other behaviour for the 
operators. E.g. here's a silly example:

 class Silly(object):
... def __init__(self):
... self.link = None
... def __gt__(self, other):
... self.link = other
...
 x = Silly()
 x  Silly()
 x.link
__main__.X object at 0xb7cda74c


More importantly, __cmp__ is only suitable for classes that implement 
total ordering. If you have a data type that does not have total 
ordering, for example sets, you can't implement it using __cmp__.

E.g.:

 s = set([1, 2, 3, 4])
 t = set([3, 4, 5, 6])
 s  t
False
 s  t
False
 s == t
False
 cmp(s, t)
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: cannot compare sets using cmp()


Sets have partial ordering, and __cmp__ is simply not up to the job of 
dealing with it.

Having two mechanisms for implementing comparisons is unnecessary. It 
adds complications to the language that we are better off without. The 
only advantage of the obsolete __cmp__ is that lazy programmers only need 
to write one method instead of six. This is an advantage, I accept that 
(hey, I'm a lazy programmer too, that's why I use Python!) but it's not a 
big advantage. If you really care about it you can create a mixin class, 
a decorator, or a metaclass to simplify creation of the methods. For 
example, a quick and dirty decorator:


 def make_comparisons(cls):
... cls.__gt__ = lambda self, other: self.__cmp__(other) == 1
... cls.__ge__ = lambda self, other: self.__cmp__(other) = 0
... cls.__eq__ = lambda self, other: self.__cmp__(other) == 0
... cls.__ne__ = lambda self, other: self.__cmp__(other) != 0
... cls.__le__ = lambda self, other: self.__cmp__(other) = 0
... cls.__lt__ = lambda self, other: self.__cmp__(other) == -1
... return cls
...
 @make_comparisons
... class BiggerThanEverything(object):
... def __cmp__(self, other):
... return 1
...
 x = BiggerThanEverything()
 x  1000
True
 x  0
False


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Roy Smith]

In article 03720b25$0$1309$c3e8...@news.astraweb.com,
 Steven D'Aprano st...@remove-this-cybersource.com.au wrote:

 In any case, while such a idiom works in code, it plays havoc with the 
 interactive interpreter:
 
  while 1:
 ...pass
 ... 
 'pass'
 'pass'
 'pass'
 'pass'
 'pass'

It's not particularly useful without the quotes either :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Roy Smith]

In article hjsd34$pv...@news.eternal-september.org,
 Alf P. Steinbach al...@start.no wrote:

 * Roy Smith:
  In article mailman.1545.1264694607.28905.python-l...@python.org,
   Mitchell L Model mlm...@comcast.net wrote:
  
  I use the sep and end keywords all the time.
  
  What are 'sep' and 'end'?  I'm looking in 
  http://docs.python.org/3.1/genindex-all.html and don't see those mentioned 
  at all.  Am I just looking in the wrong place?
 
 print( print.__doc__ )
print(value, ..., sep=' ', end='\n', file=sys.stdout)
 
Prints the values to a stream, or to sys.stdout by default.
Optional keyword arguments:
file: a file-like object (stream); defaults to the current sys.stdout.
sep:  string inserted between values, default a space.
end:  string appended after the last value, default a newline.
 _

I'm inclined to call it a docs bug that these keywords are not in the HTML 
index.  Yes?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

Roy Smith wrote:
 In article 03720b25$0$1309$c3e8...@news.astraweb.com,
  Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
 
 In any case, while such a idiom works in code, it plays havoc with the 
 interactive interpreter:

 while 1:
 ...pass
 ... 
 'pass'
 'pass'
 'pass'
 'pass'
 'pass'
 
 It's not particularly useful without the quotes either :-)

Perhaps not. but at least it keeps its misery to itself.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

Steven D'Aprano wrote:
 On Thu, 28 Jan 2010 17:38:23 -0800, mdj wrote:
 
 On Jan 29, 9:47 am, Paul Boddie p...@boddie.org.uk wrote:
 On 27 Jan, 13:26, Xah Lee xah...@gmail.com wrote:



 So, for practical reasons, i think a “key” parameter is fine. But
 chopping off “cmp” is damaging. When your data structure is complex,
 its order is not embedded in some “key”. Taking out “cmp” makes it
 impossible to sort your data structure.
 What would annoy me if I used Python 3.x would be the apparent lack of
 the __cmp__ method for conveniently defining comparisons between
 instances of my own classes. Having to define all the rich comparison
 methods frequently isn't even as much fun as it sounds.
 OT, but you can always define the other operators in terms of a cmp and
 mix it in, restoring the original behaviour. Unfortunately it won't
 restore the original performance until someone comes to their senses and
 restores __cmp__
 
 Comes to their senses?
 
 There's nothing you can do with __cmp__ that you can't do better with 
 rich comparisons, and plenty that rich comparisons can do that __cmp__ is 
 utterly incapable of dealing with. __cmp__ is crippled since it can only 
 be used for defining classes where the operators  etc return flags. It 
 can't be used if you want to implement some other behaviour for the 
 operators. E.g. here's a silly example:
 
 class Silly(object):
 ... def __init__(self):
 ... self.link = None
 ... def __gt__(self, other):
 ... self.link = other
 ...
 x = Silly()
 x  Silly()
 x.link
 __main__.X object at 0xb7cda74c
 
 
 More importantly, __cmp__ is only suitable for classes that implement 
 total ordering. If you have a data type that does not have total 
 ordering, for example sets, you can't implement it using __cmp__.
 
 E.g.:
 
 s = set([1, 2, 3, 4])
 t = set([3, 4, 5, 6])
 s  t
 False
 s  t
 False
 s == t
 False
 cmp(s, t)
 Traceback (most recent call last):
   File stdin, line 1, in module
 TypeError: cannot compare sets using cmp()
 
 
 Sets have partial ordering, and __cmp__ is simply not up to the job of 
 dealing with it.
 
 Having two mechanisms for implementing comparisons is unnecessary. It 
 adds complications to the language that we are better off without. The 
 only advantage of the obsolete __cmp__ is that lazy programmers only need 
 to write one method instead of six. This is an advantage, I accept that 
 (hey, I'm a lazy programmer too, that's why I use Python!) but it's not a 
 big advantage. If you really care about it you can create a mixin class, 
 a decorator, or a metaclass to simplify creation of the methods. For 
 example, a quick and dirty decorator:
 
 
 def make_comparisons(cls):
 ... cls.__gt__ = lambda self, other: self.__cmp__(other) == 1
 ... cls.__ge__ = lambda self, other: self.__cmp__(other) = 0
 ... cls.__eq__ = lambda self, other: self.__cmp__(other) == 0
 ... cls.__ne__ = lambda self, other: self.__cmp__(other) != 0
 ... cls.__le__ = lambda self, other: self.__cmp__(other) = 0
 ... cls.__lt__ = lambda self, other: self.__cmp__(other) == -1
 ... return cls
 ...
 @make_comparisons
 ... class BiggerThanEverything(object):
 ... def __cmp__(self, other):
 ... return 1
 ...
 x = BiggerThanEverything()
 x  1000
 True
 x  0
 False
 
 
While I am fully aware that premature optimization, etc., but I cannot
resist an appeal to efficiency if it finally kills off this idea that
they took 'cmp()' away is a bad thing.

Passing a cmp= argument to sort provides the interpreter with a function
that will be called each time any pair of items have to be compared. The
key= argument, however, specifies a transformation from [x0, x1, ...,
xN] to [(key(x0), x0), (key(x1), x1), ..., (key(xN), xN)] (which calls
the key function precisely once per sortable item).

From a C routine like sort() [in CPython, anyway] calling out from C to
a Python function to make a low-level decision like is A less than B?
turns out to be disastrous for execution efficiency (unlike the built-in
default comparison, which can be called directly from C in CPython).

If your data structures have a few hundred items in them it isn't going
to make a huge difference. If they have a few million thenit is already
starting to affect performance ;-)

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[mdj]

On Jan 29, 12:21 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:

 Comes to their senses?

 There's nothing you can do with __cmp__ that you can't do better with
 rich comparisons, and plenty that rich comparisons can do that __cmp__ is
 utterly incapable of dealing with. __cmp__ is crippled since it can only
 be used for defining classes where the operators  etc return flags. It
 can't be used if you want to implement some other behaviour for the
 operators. E.g. here's a silly example:

[example snipped]

Okay, but I think that overloading to change the semantic meaning of
operators is another issue, and one that there's a great deal of
difference of opinion on. Personally, I find arbitrarily redefining
operators with well understood semantics to mean something totally
different to be poor style, and those who disagree would find my style
poor :-)

 Having two mechanisms for implementing comparisons is unnecessary. It
 adds complications to the language that we are better off without. The
 only advantage of the obsolete __cmp__ is that lazy programmers only need
 to write one method instead of six. This is an advantage, I accept that
 (hey, I'm a lazy programmer too, that's why I use Python!) but it's not a
 big advantage. If you really care about it you can create a mixin class,
 a decorator, or a metaclass to simplify creation of the methods. For
 example, a quick and dirty decorator:

I agree it's unnecessary, but deleting a time tested idiom in the name
of consistency seems excessive to me. Is there not a compromise? For
those of us who prefer limiting operator overloads to semantically
compatible cases the extra flexibility is seldom necessary, and the
price extracted in terms of inconvenience is therefore quite high. You
can (as I mentioned and you demonstrated) work around the problem, but
I'd hate to see 50 different implementations of a common idiom wasting
brain space in future projects.

Matt

(Note I remove the crosspost to comp.lang.lisp where I saw this - one
of the reasons I love lisp is that discussions like this become
totally unnecessary)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[alex23]

Roy Smith r...@panix.com wrote:
 I'm inclined to call it a docs bug that these keywords are not in the HTML
 index.  Yes?

No. The indices don't list the named parameters for any other built-
in, so why would they for print()?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Thu, 28 Jan 2010 21:26:43 -0500, Roy Smith wrote:

 In article 03720b25$0$1309$c3e8...@news.astraweb.com,
  Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
 
 In any case, while such a idiom works in code, it plays havoc with the
 interactive interpreter:
 
  while 1:
 ...pass
 ...
 'pass'
 'pass'
 'pass'
 'pass'
 'pass'
 
 It's not particularly useful without the quotes either :-)



Of course while 1: pass is useless, but it doesn't fill the terminal 
with thousands of lines of pass. The point I was making is that the 
statement pass does nothing, while in the interactive interpreter a 
string or other object prints to the screen.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Terry Reedy]

On 1/28/2010 6:47 PM, Paul Boddie wrote:

On 27 Jan, 13:26, Xah Leexah...@gmail.com  wrote:


So, for practical reasons, i think a “key” parameter is fine. But
chopping off “cmp” is damaging. When your data structure is complex,
its order is not embedded in some “key”. Taking out “cmp” makes it
impossible to sort your data structure.


What would annoy me if I used Python 3.x would be the apparent lack of
the __cmp__ method for conveniently defining comparisons between
instances of my own classes. Having to define all the rich comparison
methods frequently isn't even as much fun as it sounds.


You define __eq__, which automatically generates __ne__.
You define __lt__, which is all sort and heap need.
This should be about as easier than __eq__, which is really needed, and 
__cmp__. If you need the other 3, either copy the recipe in the 
Cookbook, or, even faster


def __ge__(s,o): return o.__lt__(s)
def __le__(s,o): return s  o or s == o
def __ge__(s,o): return s  o or s == o

All done.

Terry Jan Reedy




--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Steve Holden:



While I am fully aware that premature optimization, etc., but I cannot
resist an appeal to efficiency if it finally kills off this idea that
they took 'cmp()' away is a bad thing.

Passing a cmp= argument to sort provides the interpreter with a function
that will be called each time any pair of items have to be compared. The
key= argument, however, specifies a transformation from [x0, x1, ...,
xN] to [(key(x0), x0), (key(x1), x1), ..., (key(xN), xN)] (which calls
the key function precisely once per sortable item).


From a C routine like sort() [in CPython, anyway] calling out from C to

a Python function to make a low-level decision like is A less than B?
turns out to be disastrous for execution efficiency (unlike the built-in
default comparison, which can be called directly from C in CPython).

If your data structures have a few hundred items in them it isn't going
to make a huge difference. If they have a few million thenit is already
starting to affect performance ;-)


It's not either/or, it's do programmers still need the cmp functionality?

Consider that *correctness* is a bit more important than efficiency, and that 
sorting strings is quite common...


Possibly you can show me the way forward towards sorting these strings (shown 
below) correctly for a Norwegian locale. Possibly you can't. But one thing is 
for sure, if there was a cmp functionality it would not be a problem.



example
  Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] 
on win32

  Type help, copyright, credits or license for more information.
   L = [æ, ø, å]   # This is in SORTED ORDER in Norwegian
   L
  ['æ', 'ø', 'å']
   L.sort()
   L
  ['å', 'æ', 'ø']
  
   import locale
   locale.getdefaultlocale()
  ('nb_NO', 'cp1252')
   locale.setlocale( locale.LC_ALL )  # Just checking...
  'C'
   locale.setlocale( locale.LC_ALL,  )  # Setting default locale, Norwgian.
  'Norwegian (Bokmål)_Norway.1252'
   locale.strxfrm( æøå )
  'æøå'
   L.sort( key = locale.strxfrm )
   L
  ['å', 'æ', 'ø']
   locale.strcoll( å, æ )
  1
   locale.strcoll( æ, ø )
  -1
  
/example


Note that strcoll correctly orders the strings as [æ, ø, å], that is, it 
would have if it could have been used as cmp function to sort (or better, to a 
separate routine named e.g. custom_sort).


And strcoll can be so used in 2.x:


example
C:\Documents and Settings\Alf\test py2
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on 
win32

Type help, copyright, credits or license for more information.
 def show( list ):
... print [ + , .join( list ) + ]
...
 L = [uæ, uø, uå]
 show( L )
[æ, ø, å]
 L.sort()
 show( L )
[å, æ, ø]
 import locale
 locale.setlocale( locale.LC_ALL,  )
'Norwegian (Bokm\xe5l)_Norway.1252'
 L.sort( cmp = locale.strcoll )
 show( L )
[æ, ø, å]
 L
[u'\xe6', u'\xf8', u'\xe5']
 _
/example


The above may just be a bug in the 3.x stxfrm. But it illustrates that sometimes 
you have your sort order defined by a comparision function. Transforming that 
into a key can be practically impossible (it can also be quite inefficient).



Cheers  hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Tue, 26 Jan 2010 23:37:00 -0800, Paul Rubin wrote:

 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 Sorry, I meant consistent with the rest of Python, which mostly uses
 functions/methods and only rarely statements (e.g. del and import).
 
 yield, assert, if/else, return, etc.  If we're after that kind of
 consistency, why not get rid of all those statements too?  They have
 already partly done it with yield, and they ended up introducing a new
 separate if/else expression syntax as an alternative to the statement.

Without becoming a purely functional language, you won't get rid of all 
statements. In my opinion, outside of such purely functional languages 
and unconventional languages like Forth, statements play a valuable role 
in that they are controlling syntax. For example:

for, while, if, try, break, yield, return

are all used for flow control, and should remain as statements. But print 
is not -- it's a function disguised as a statement. print, after all, is 
just sugar for stdout.write, which is fine as far as it goes, but when 
you want to do something slightly different from what the sugar does, it 
becomes terribly inconvenient.

A consequence of print being a statement is that my modules are often 
filled with functions and methods called print_. Suppose I want to 
print the type of each argument as well as it's value. I would like to do 
this:


def decorator(pr):
def inner(*args, **kwargs):
 args = [(type(a), a) for a in args]
 pr(*args, **kwargs)
return inner

print = decorator(print)


and then use print as normal, but of course I can't. So instead I do 
something like this:


def print_(*args, **kwargs):
args = [(type(a), a) for a in args]
kw = {'file': sys.stdout, 'sep': ' ', 'end': '\n'}
kw.update(kwargs)
if len(kw) != 3:
raise TypeError('invalid keyword argument')
file = kw['file']
sep = kw['sep']
end = kw['end']
for arg in args:
print file, (str(arg) + sep),  # Don't forget the comma.
print file, end,  # Another comma.


And then, I have to remember to call print_ instead of print.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 Without becoming a purely functional language, you won't get rid of all 
 statements. 

Why not?  GCC lets you use any statement in an expression:

#include stdio.h

main()
{
  int i, x, p=0;
  x = ({ for (i=1; i=10; i++) p += i; p;});
  printf (x=%d\n, x);
}

and C is certainly not a purely functional language.

 for, while, if, try, break, yield, return
 are all used for flow control, and should remain as statements. 

What about assert, import, and pass?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Daniel Fetchinson]

 * Print is now a function. Great, much improvement.

 Actually not, IMHO. All it does is is to provide incompatibility.


What incompatibility are you exactly talking about?

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.
 print( 'hello' )
hello
 print 'hello'
hello


Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

Paul Rubin wrote:
 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 Without becoming a purely functional language, you won't get rid of all 
 statements. 
 
 Why not?  GCC lets you use any statement in an expression:
 
 #include stdio.h
 
 main()
 {
   int i, x, p=0;
   x = ({ for (i=1; i=10; i++) p += i; p;});
   printf (x=%d\n, x);
 }
 
 and C is certainly not a purely functional language.
 
 for, while, if, try, break, yield, return
 are all used for flow control, and should remain as statements. 
 
 What about assert, import, and pass?

Remember that Guido stated (I think in the original FAQ entry for why
assignments don't produce results, but I could be wrong) that he
explicitly wanted Python to be a statement-based language.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Xah Lee]

Someone is badmouthing me, and it has been doing so over the years. I
feel obliged to post a off topic relpy. See:

• DreamHost.com and A Incidence of Harassment
  http://xahlee.org/Periodic_dosage_dir/t2/harassment.html

• Why Can't You Be Normal?
  http://xahlee.org/Netiquette_dir/why_cant_you_be_normal.html

 Xah

On Jan 26, 7:12 pm, Alf P. Steinbach al...@start.no wrote:
 * John Bokma:

  Alf P. Steinbach al...@start.no writes:

  Please don't post more noise and ad hominem attacks to the group,
  Steve.

  Funny that you talk about noise while replying yourself to noise. Xah
  Lee is just a pathetic spammer. He's not going to reply in this
  thread. He just shits out his stuff in as many groups as possible to
  promote his website.

 Sorry, I didn't know.

 Thanks for the heads-up.

 Cheers,

 - Alf

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Xah Lee]

On Jan 26, 3:47 pm, Xah Lee xah...@gmail.com wrote:

 * 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)

See also:

“Iterators: Signs of Weakness in Object-Oriented Languages” (1992) By
Henry G Baker. http://home.pipeline.com/~hbaker1/Iterator.html

Xah wrote:
 * 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)

Steven D'Aprano wrote:
 I did too, when I first heard cmp was to be dumped. But I changed my mind
 and now agree with the decision to drop cmp. Custom sorts are nearly
 always much better written with key rather than cmp: key adds an O(N)
 overheard to the sorting, while cmp makes sorting O(N**2). In other
 words, key is *much* faster, and generally easier to write as well.

The reason cmp is a order slower is due to Python lang's limitation
and compiler implementation limitation.

• Sorting in Python and Perl
  http://xahlee.org/perl-python/sort_list.html

the python lang, by the very nature of being a dynamic lang, makes it
hard for compiler analize and optimize a sort function call with cmp
argument that is equivalent to a key.

So, for practical reasons, i think a “key” parameter is fine. But
chopping off “cmp” is damaging. When your data structure is complex,
its order is not embedded in some “key”. Taking out “cmp” makes it
impossible to sort your data structure.

in the essay, i also gave a few examples of data structures where you
need a general means to specify the ordering function in order to
sort. Without a cmp, you'll need to munge your data by some decorate-
sort-dedecorate technique.

From another perspective, often it is considered a good principle of
design that the lang be a bit flexible to let programers do what they
want, instead of force them into one way. Python, being a loosely
typed lang, with so-called “duck typing”, in contrast to Java or OCaml
in different ways, certainly is more on the lose extreme of the lang
spectrum with respect to code construction. So, i don't see how python
3 people made the decision to removed cmp. (am pretty sure, at least
part of the reason, is a ill attitude towards functional programing
and lambda, lead by Guido.)

 There may be a handful of rare applications where there is no obvious way
 to convert a cmp function to a key, but they are vanishingly rare. I
 think, if you search the archives, Paul Rubin may have come up with one
 example. There are a number of recipes for easily converting cmp sorts to
 key sorts.

You say that it is rare. You are probably right. Though, that may just
be caused by the language itself and consequently the type of people
who uses it. If Python's lambda is not limited, and the python
community doesn't look down on lambda, it is likely cmp will used
more. The more your data structure becomes complex, the more cmp will
be needed.

 I think, in my perfect world, list.sort() and sorted() should continue
 being key based, while the standard library contained (perhaps in the
 functools module?) a sort function that contains all the bells and
 whistles. You want cmp, it's there, and you can pay the extra cost if you
 need it. You want to sort multiple lists by the contents of one? One
 import away. But keep the general sort() function lean and super-fast.

btw, is something like cmp still available in some module for sort?

  Xah
∑ http://xahlee.org/

☄
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Daniel Fetchinson:

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.



What incompatibility are you exactly talking about?

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.

print( 'hello' )

hello

print 'hello'

hello

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?


I gather that your example is about code that technically executes fine with 
both versions and produces the same result, i.e. that there is a subset with the 
same syntax and semantics.


But 'print' calls that technically execute fine with both versions may and will 
in general produce different results.


I.e. not just the syntax but also the semantics have changed:


 import sys
 sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'

 print( 2+2 =, 2+2 )
('2+2 =', 4)
 _


 import sys
 sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'

 print( 2+2 =, 2+2 )
2+2 = 4
 _



Cheers  hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Daniel Fetchinson]

 * Print is now a function. Great, much improvement.
 Actually not, IMHO. All it does is is to provide incompatibility.


 What incompatibility are you exactly talking about?

 Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
 [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
 Type help, copyright, credits or license for more information.
 print( 'hello' )
 hello
 print 'hello'
 hello

 Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

 I gather that your example is about code that technically executes fine with
 both versions and produces the same result, i.e. that there is a subset with
 the
 same syntax and semantics.

 But 'print' calls that technically execute fine with both versions may and
 will
 in general produce different results.

 I.e. not just the syntax but also the semantics have changed:


   import sys
   sys.version
 '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
  
   print( 2+2 =, 2+2 )
 ('2+2 =', 4)
   _


   import sys
   sys.version
 '3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
  
   print( 2+2 =, 2+2 )
 2+2 = 4
   _

True. However, as someone else pointed out in a neighbouring thread you can do

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.
 from __future__ import print_function
 print( 2+2 =, 2+2 )
2+2 = 4


which gives 100% compatibility as far as print is concerned between 2.6 and 3.x.

So again, what sort of an incompatibility are you talking about
concerning 'print' between 2.6 and 3.x?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Daniel Fetchinson:

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.


What incompatibility are you exactly talking about?

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.

print( 'hello' )

hello

print 'hello'

hello

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

I gather that your example is about code that technically executes fine with
both versions and produces the same result, i.e. that there is a subset with
the
same syntax and semantics.

But 'print' calls that technically execute fine with both versions may and
will
in general produce different results.

I.e. not just the syntax but also the semantics have changed:


  import sys
  sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
 
  print( 2+2 =, 2+2 )
('2+2 =', 4)
  _


  import sys
  sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
 
  print( 2+2 =, 2+2 )
2+2 = 4
  _


True. However, as someone else pointed out in a neighbouring thread you can do

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.

from __future__ import print_function
print( 2+2 =, 2+2 )

2+2 = 4

which gives 100% compatibility as far as print is concerned between 2.6 and 3.x.


That makes the code behave with 3.x syntax and semantics regarding print. I.e. 
it chooses one language. It doesn't make them compatible: if they were, then you 
wouldn't have to choose.


For example, it doesn't fix up 2.x code that prints tuples: incompatible, it 
will still execute but no longer do what it was supposed to do.


But lest you focus down on that rare case, consider 2.x code that contains

  print 2+2, 2

All such statements need to be fixed up in a 2-3 transition. Adding __future__ 
just makes the code invalid, it doesn't give you any shred of compatibility for 
this. A code rewrite can be partially automated like 2to3 but the 
incompatibility needlessly introduces an additional set of things that Can Go 
Wrong(TM), and with Murphy present, as He always is, well.




So again, what sort of an incompatibility are you talking about
concerning 'print' between 2.6 and 3.x?


Syntax and semantics. They're different.


Cheers  hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Stefan Behnel]

Xah Lee, 27.01.2010 00:47:
 Any comment on this?

No, sorry. Not worth bothering.

Stefan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Grant Edwards]

On 2010-01-27, Alf P. Steinbach al...@start.no wrote:

 I'm responding to the original message by Xah Lee, which is
 not carried by my Usenet provider.

A Usenet provider that doesn't carry messages from Xah Lee.

So... many... jokes.

-- 
Grant


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Daniel Fetchinson]

 * Print is now a function. Great, much improvement.
 Actually not, IMHO. All it does is is to provide incompatibility.

 What incompatibility are you exactly talking about?

 Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
 [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
 Type help, copyright, credits or license for more information.
 print( 'hello' )
 hello
 print 'hello'
 hello

 Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?
 I gather that your example is about code that technically executes fine
 with
 both versions and produces the same result, i.e. that there is a subset
 with
 the
 same syntax and semantics.

 But 'print' calls that technically execute fine with both versions may
 and
 will
 in general produce different results.

 I.e. not just the syntax but also the semantics have changed:


   import sys
   sys.version
 '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
  
   print( 2+2 =, 2+2 )
 ('2+2 =', 4)
   _


   import sys
   sys.version
 '3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
  
   print( 2+2 =, 2+2 )
 2+2 = 4
   _

 True. However, as someone else pointed out in a neighbouring thread you
 can do

 Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
 [GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
 Type help, copyright, credits or license for more information.
 from __future__ import print_function
 print( 2+2 =, 2+2 )
 2+2 = 4

 which gives 100% compatibility as far as print is concerned between 2.6
 and 3.x.

 That makes the code behave with 3.x syntax and semantics regarding print.
 I.e. it chooses one language.

 It doesn't make them compatible:

Of course it makes them compatible. I'm not saying any print-related
code in python 2.6 is valid python 3 code, but that it is *possible*
to write print-related code in python 2.6 that is also valid in python
3.

 if they were, then you wouldn't have to choose.

It seems to me you are arguing with the statement Any print-related
python 2.6 code is valid python 3 code. Nobody is making this
statement. Let me repeat, what you should be arguing with is It is
possible to write print-related python 2.6 code that is also valid
python 3 code. Perhaps I didn't make myself clear before, but at
least now I hope it's clear what I mean.

Cheers,
Daniel

 For example, it doesn't fix up 2.x code that prints tuples: incompatible, it
 will still execute but no longer do what it was supposed to do.

 But lest you focus down on that rare case, consider 2.x code that contains

print 2+2, 2

 All such statements need to be fixed up in a 2-3 transition. Adding
 __future__
 just makes the code invalid, it doesn't give you any shred of compatibility
 for
 this. A code rewrite can be partially automated like 2to3 but the
 incompatibility needlessly introduces an additional set of things that Can
 Go
 Wrong(TM), and with Murphy present, as He always is, well.


 So again, what sort of an incompatibility are you talking about
 concerning 'print' between 2.6 and 3.x?

 Syntax and semantics. They're different.


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Daniel Fetchinson:

* Print is now a function. Great, much improvement.

Actually not, IMHO. All it does is is to provide incompatibility.

What incompatibility are you exactly talking about?

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.

print( 'hello' )

hello

print 'hello'

hello

Yes, this is with python 2.6.2 which is in the 2.x line of releases. So?

I gather that your example is about code that technically executes fine
with
both versions and produces the same result, i.e. that there is a subset
with
the
same syntax and semantics.

But 'print' calls that technically execute fine with both versions may
and
will
in general produce different results.

I.e. not just the syntax but also the semantics have changed:


  import sys
  sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
 
  print( 2+2 =, 2+2 )
('2+2 =', 4)
  _


  import sys
  sys.version
'3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)]'
 
  print( 2+2 =, 2+2 )
2+2 = 4
  _

True. However, as someone else pointed out in a neighbouring thread you
can do

Python 2.6.2 (r262:71600, Aug 21 2009, 12:23:57)
[GCC 4.4.1 20090818 (Red Hat 4.4.1-6)] on linux2
Type help, copyright, credits or license for more information.

from __future__ import print_function
print( 2+2 =, 2+2 )

2+2 = 4

which gives 100% compatibility as far as print is concerned between 2.6
and 3.x.

That makes the code behave with 3.x syntax and semantics regarding print.
I.e. it chooses one language.

It doesn't make them compatible:


Of course it makes them compatible. I'm not saying any print-related
code in python 2.6 is valid python 3 code, but that it is *possible*
to write print-related code in python 2.6 that is also valid in python
3.


if they were, then you wouldn't have to choose.


It seems to me you are arguing with the statement Any print-related
python 2.6 code is valid python 3 code. Nobody is making this
statement. Let me repeat, what you should be arguing with is It is
possible to write print-related python 2.6 code that is also valid
python 3 code. Perhaps I didn't make myself clear before, but at
least now I hope it's clear what I mean.


Perhaps we're in violent agreement. :-)

However, the root node of this subthread was my statement about the needless 
incompatibility introduced by changing print in 3.x, whether that statement was 
correct or reasonable / whatever.


The main problem with the incompatibility is for porting code, not for writing 
code from scratch. It's also a problem wrt. learning the language. And I see no 
good reason for it: print can't really do more, or less, or more conveniently 
(rather, one has to write a bit more now for same effect).



Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

Alf P. Steinbach wrote:
[...]
 The main problem with the incompatibility is for porting code, not for
 writing code from scratch. It's also a problem wrt. learning the
 language. And I see no good reason for it: print can't really do more,
 or less, or more conveniently (rather, one has to write a bit more now
 for same effect).

Of course it can do more: it allows you to layer your own print
functionality into the system much more easily than you could with the
print statement.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Steve Holden:

Alf P. Steinbach wrote:
[...]

The main problem with the incompatibility is for porting code, not for
writing code from scratch. It's also a problem wrt. learning the
language. And I see no good reason for it: print can't really do more,
or less, or more conveniently (rather, one has to write a bit more now
for same effect).


Of course it can do more: it allows you to layer your own print
functionality into the system much more easily than you could with the
print statement.


Yeah, point. Very minor though. :-)


Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Grant Edwards]

On 2010-01-27, Alf P. Steinbach al...@start.no wrote:
 * Steve Holden:
 Alf P. Steinbach wrote:
 [...]
 The main problem with the incompatibility is for porting code, not for
 writing code from scratch. It's also a problem wrt. learning the
 language. And I see no good reason for it: print can't really do more,
 or less, or more conveniently (rather, one has to write a bit more now
 for same effect).
 
 Of course it can do more: it allows you to layer your own print
 functionality into the system much more easily than you could with the
 print statement.

 Yeah, point. Very minor though. :-)

I don't think it's minor at all.  Being able to globally
redefine the behavior of print for all modules is a big win
when you want to import a module that's too chatty about what
it's doing.  The right way for modules to chatter about
internals is using the logging module, but not everybody
follows that convention.

-- 
Grant Edwards   grante Yow! Four thousand
  at   different MAGNATES, MOGULS
   visi.com NABOBS are romping in my
   gothic solarium!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Adam Tauno Williams]

On Wed, 2010-01-27 at 18:52 +0100, Alf P. Steinbach wrote:
 * Steve Holden:
  Alf P. Steinbach wrote:
  [...]
  The main problem with the incompatibility is for porting code, not for
  writing code from scratch. It's also a problem wrt. learning the
  language. And I see no good reason for it: print can't really do more,
  or less, or more conveniently (rather, one has to write a bit more now
  for same effect).
  Of course it can do more: it allows you to layer your own print
  functionality into the system much more easily than you could with the
  print statement.
 Yeah, point. Very minor though. :-)

So you get to determine that?

I'd call the whole print thing (a) a legitimate change to increase
consistency and (b) a fairly minor porting nuisance since application
code [as in big-chunks-o-code] almost never contains print statements.
I know at least two shops that have scripts they run on all Python code,
prior to it entering production, to ensure there are no print
statements.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Adam Tauno Williams:

On Wed, 2010-01-27 at 18:52 +0100, Alf P. Steinbach wrote:

* Steve Holden:

Alf P. Steinbach wrote:
[...]

The main problem with the incompatibility is for porting code, not for
writing code from scratch. It's also a problem wrt. learning the
language. And I see no good reason for it: print can't really do more,
or less, or more conveniently (rather, one has to write a bit more now
for same effect).

Of course it can do more: it allows you to layer your own print
functionality into the system much more easily than you could with the
print statement.

Yeah, point. Very minor though. :-)


So you get to determine that?


I'm sorry, I don't find that question meaningful.



I'd call the whole print thing (a) a legitimate change to increase
consistency and (b) a fairly minor porting nuisance since application
code [as in big-chunks-o-code] almost never contains print statements.
I know at least two shops that have scripts they run on all Python code,
prior to it entering production, to ensure there are no print
statements.



Considering that in your opinion application code [as in big-chunks-o-code] 
almost never contains print statements, is the point about being able to 
replace print, as you see it, more than a minor point?



Cheers  sorry for not grokking your question,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[John Bokma]

Xah Lee xah...@gmail.com writes:

 Someone is badmouthing me, and it has been doing so over the years. I
 feel obliged to post a off topic relpy. See:

 • DreamHost.com and A Incidence of Harassment
   http://xahlee.org/Periodic_dosage_dir/t2/harassment.html

Dreamhost is not the only ISP that has agreed with me in the past
regarding your spamming. And yes, it's spamming if you copy paste an
article from your web site with the link to that site and cross post it
to as many groups as your Usenet provider allows for. Thank goodness
that GG has a limit on how many groups you can spam at a time.

Post to on-topic groups only, really on-topic groups, not as many as you
can select. And participate like you know do, and nobody will complain
about /how/ you post. And if you cross-post /set a follow-up-to/.

That's netiquette.

-- 
John Bokma   j3b

Hacking  Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl  Python Development
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Jonathan Gardner]

On Jan 27, 9:38 am, Luis M. González luis...@gmail.com wrote:
  Please don't post more noise and ad hominem attacks to the group, Steve.

 Ad hominem?
 Please, operor non utor lingua non notus per vulgaris populus.
 Gratias ago vos...

My rough, machine-assisted translation:

Don't try to use language that the people don't know. Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Jonathan Gardner]

On Jan 26, 10:12 pm, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:

 I did too, when I first heard cmp was to be dumped. But I changed my mind
 and now agree with the decision to drop cmp. Custom sorts are nearly
 always much better written with key rather than cmp: key adds an O(N)
 overheard to the sorting, while cmp makes sorting O(N**2). In other
 words, key is *much* faster, and generally easier to write as well.


Imagine what sort() could do if all the keys were platform-native
types. In other words, if you could bypass the Python compare because
all the keys were native int, char, char*, or float. You can't do that
with cmp either.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 always much better written with key rather than cmp: key adds an O(N) 
 overheard to the sorting, while cmp makes sorting O(N**2). 

Whaa ..   No I don't think so.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Jonathan Gardner]

On Jan 27, 12:36 am, Paul Rubin no.em...@nospam.invalid wrote:
 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
  Without becoming a purely functional language, you won't get rid of all
  statements.

 Why not?  GCC lets you use any statement in an expression:

     #include stdio.h

     main()
     {
       int i, x, p=0;
       x = ({ for (i=1; i=10; i++) p += i; p;});
       printf (x=%d\n, x);
     }

 and C is certainly not a purely functional language.

  for, while, if, try, break, yield, return
  are all used for flow control, and should remain as statements.

 What about assert, import, and pass?

I think you missed the point about what a functional language is and
is not.

Let me see if I can help clear up that confusion a bit.

In a functional language, you don't use statements. For instance, when
you declare a new function, you call the function-declaring-function
with parameters describing the parameters and body of that function.

In such a language, flow control is very, very strange for those not
familiar with it. For instance, how can you call an if function that
only evaluates one or the other branches? In such a case, you're not
making a function call, at least not as you know it. What you're doing
is calling a special kind of function that doesn't evaluate its
parameters until later, if at all.

With the above paradigm, you have to start thinking about the
programming task in a completely different light. Rather than
organizing your code into a sequence of evaluated statements, you
organize it into one giant function that will evaluate its parameters
and return some result. This is a difficult paradigm for programmers
to grasp, and is one reason why Lisp and other functional languages
aren't know for being newbie-friendly.

Whether or not a statement can be used as an expression is really
orthogonal to this conversation.

If yield, break, and continue were functions, then you could
call them from within another function and have the call-ee yield,
break, or continue. For instance:

 def do_something():
 break()

 while 1:
 do_something()
 # The next line is never reached
 do_something_else()

This could be useful for some situations, but it is really, really
confusing and so it's not allowed. Such a function would have to rely
on some type of magic so that it is correctly identified as a yield,
break, or continue, and not a typical function call.

import is another case. It does something very special. It assigns
to values in the namespace of the code from which it was called. No
function can do that, at least not without some weird magic. It's
better to leave it as a statement and teach new users that it is very,
very special, than to redefine how functions work with the call-ees
namespace, or make it a common task to muck with such things.

If while, for, try, if, def, and class were functions,
they would have to be written like so:

 if(expr, if-true-expr, if-false-expr)

Note, however, that you can't execute if-true of if-false until AFTER
the if() function is called. That means either we re-define what it
means to call a function, or we have some notation that means Don't
execute this yet. Either way, it's really, really confusing.

Also, note that statements allow you to combine many statements into
one. Python's rule is that you can't pass statements to a function,
only expression, so you'd have to re-define how that works to allow
some function that would combine multiple statements together.

In the end, print is a great candidate for a function, while the
others are most definitely not. Adding any of them as functions would
mean other, fundamental aspects of Python would have to be re-defined
as well.

I hope this clears up Steve's point about functional languages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Jonathan Gardner]

On Jan 27, 3:54 pm, Paul Rubin no.em...@nospam.invalid wrote:
 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
  always much better written with key rather than cmp: key adds an O(N)
  overheard to the sorting, while cmp makes sorting O(N**2).

 Whaa ..   No I don't think so.

You're referring to the O(N**2) bit, right? I am sure he knew it was O
(N*log(N)), which is still worse than O(N) for key.

If he didn't, well, Python has some fundamental flaws in its basic
sort algorithm.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Jonathan Gardner jgard...@jonathangardner.net writes:
 What about assert, import, and pass?
...
 For instance, how can you call an if function ...
 If yield, break, and continue were functions, ...
 import ... does something very special. It assigns
 to values in the namespace of the code from which it was called.
 In the end, print is a great candidate for a function, 

Reasonable point about import.  If, yield, break, and continue
are irrelevant if one accepts the flow control argument, although there
is already expression syntax for if and yield.  What about assert
and pass?

 Also, note that statements allow you to combine many statements into
 one. Python's rule is that you can't pass statements to a function,

But if we're going around introducing changes that break things, why not
get rid of that silly restriction?

I don't mind that 3.x is breaking stuff for the sake of improving
things.  That's the whole idea of 3.x, after all.  What bugs me is that
the improvements are mostly quite superficial, and the breakage seems
often gratuitous.  I'd rather see much more drastic changes and
correspondingly much larger improvements.

Right now I rent an apartment in a city where real estate values have
dropped a couple percent in the past few years.  So in principle, I
could move to a 2% bigger apartment while paying the same rent, or move
to a similarly sized apartment while paying 2% less.  Either of those is
objectively an improvement, but am I going to do it?  Hell no--moving
even down the same street is way too big a hassle to even consider doing
it for such a tiny gain.  But if the 2% were replaced by 3x or 5x, the
proposition would be a heck of a lot more attractive, even if I had to
move a larger distance.  That's sort of the way I feel about switching
from Python 2.x to 3.x.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Jonathan Gardner jgard...@jonathangardner.net writes:
 You're referring to the O(N**2) bit, right? I am sure he knew it was O
 (N*log(N)), which is still worse than O(N) for key.

It's O(n log n) for both key and cmp.  key is usually more convenient
and usually gives a constant-factor speedup (DSU pattern), but it uses
more memory and there are some types of orderings that it can't handle
without a bunch of contortion.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Carl Banks]

On Jan 27, 4:16 pm, Jonathan Gardner jgard...@jonathangardner.net
wrote:
 On Jan 27, 3:54 pm, Paul Rubin no.em...@nospam.invalid wrote:

  Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
   always much better written with key rather than cmp: key adds an O(N)
   overheard to the sorting, while cmp makes sorting O(N**2).

  Whaa ..   No I don't think so.

 You're referring to the O(N**2) bit, right? I am sure he knew it was O
 (N*log(N)), which is still worse than O(N) for key.

 If he didn't, well, Python has some fundamental flaws in its basic
 sort algorithm.

Quicksort is O(N**2) worst case, perhaps that's what he meant.  I'm
not sure about timsort but since it's based on quicksort I'd guess it
is O(N**2) or worse, worst case, as well.

Typical case of a sort is still O(N*log(N)) whether using key or cmp.
People recommended against cmp not because of overall algorithmic time
considerations, but because of the number of function calls.  cmp
function was called a minimum of N-1 times and typically around N*log2
(N) times, whereas key was called exactly N times.  Since the overhead
of a Python function call was very large compared to the built-in cmp
operation, it usually outweighed the algorithmic time considerations.


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Wed, 27 Jan 2010 18:29:25 +0100, Alf P. Steinbach wrote:

 The main problem with the incompatibility is for porting code, not for
 writing code from scratch.

Correct. It's a trivial problem, but still a problem.

 It's also a problem wrt. learning the language.

This makes no sense. Why is it harder to learn

print(x, y, z)

than this?

print x, y, z

The first case is like the other functions you have to learn, like len(). 
In fact, many newbies to Python put unneeded parentheses around arguments 
to print simply because they assume it is a function.

I would argue that the new print function is *simpler* to learn. It is 
more consistent with other built-ins, and has fewer magic idioms to 
learn. Instead of:

print fileObj, x, y, z

you use regular function syntax with a meaningful keyword:

print(x, y, z, file=fileObj)

If you want suppress the newline at the end of each print:

print x, y, z,  # note the final comma

compared to:

print(x, y, z, end='')

If you want to change the space between elements, instead of:

sys.stdout.write(str(x) + * + str(y) + * + str(z) + '\n')

you use:

print(x, y, z, sep='*')


If you want to override the behaviour of print in a module, instead of 
having to edit the source code of the module (which might not even be 
available), all you need to do is monkey-patch it:

import module
module.print = myprint





-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Wed, 27 Jan 2010 00:36:52 -0800, Paul Rubin wrote:

 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 Without becoming a purely functional language, you won't get rid of all
 statements.
 
 Why not?  GCC lets you use any statement in an expression:

I stand corrected. Whether it is a good idea or not is another story.



 for, while, if, try, break, yield, return are all used for flow
 control, and should remain as statements.
 
 What about assert, import, and pass?

Both assert and pass are special and need to be treated specially by the 
compiler. Arguably we could replace pass with None, but pass makes the 
intent more obvious. 

Although assert could be a function, it is treated specially by the 
compiler and so making it a statement emphases that it is special.

The regular form of import could easily be a function returning the 
module object. After all, that's exactly what __import__ is! But using 
__import__ for anything but the simplest cases is quite awkward, hence we 
have syntactic sugar in the form of the import statement.

You also missed del as another statement-based command.

All the current statements have good strong reasons for being statements. 
print on the other hand lacks a strong reason for being a statement, and 
the only good argument against changing is to avoid an incompatible 
change. But since it is not a gratuitous incompatible change, the long 
term benefit out-weighs the short-term pain, in my opinion.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Wed, 27 Jan 2010 16:16:59 -0800, Jonathan Gardner wrote:

 On Jan 27, 3:54 pm, Paul Rubin no.em...@nospam.invalid wrote:
 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
  always much better written with key rather than cmp: key adds an O(N)
  overheard to the sorting, while cmp makes sorting O(N**2).

 Whaa ..   No I don't think so.
 
 You're referring to the O(N**2) bit, right? I am sure he knew it was O
 (N*log(N)), which is still worse than O(N) for key.
 
 If he didn't, well, Python has some fundamental flaws in its basic sort
 algorithm.


I may have the details wrong, but the performance of sort with cmp is 
very poor.

sort with key calls the key function once for each element in the list, 
which is O(N), and then sorts O(N*log N), giving a total of O(N*log N).

sort with cmp has to compare the comparison function multiple times for 
each element. I *thought* it ended up calling it N times each, giving 
O(N**2), but I may be delusional. Whatever it is though, it's quite slow. 
Here's my test code (for Python 2.5):



from timeit import Timer
from string import letters
from random import shuffle

def mycmp(s, t):
return cmp(s.upper(), t.upper())

def randstr():
L = list(letters)
shuffle(L)
return ''.join(L)

setup = from __main__ import mycmp, data

N = 300
data = [randstr() for _ in xrange(N)]
t1 = Timer(d = data[:]; d.sort(), setup)  # raw sort
t2 = Timer(d = data[:]; d.sort(cmp=mycmp), setup)
t3 = Timer(d = data[:]; d.sort(key=str.upper), setup)

for t in (t1, t2, t3):
print min(t.repeat(number=500))

N *= 10 # Do it again with bigger N.
data = [randstr() for _ in xrange(N)]
for t in (t1, t2, t3):
print min(t.repeat(number=500))



And here are the results on my PC:

# N = 300
0.0631489753723
2.36756515503
0.226485967636

# N = 3000
1.03457903862
35.3092911243
2.77242517471



This doesn't support my claim of O(N**2), but it does demonstrate that 
sort with cmp should be avoided if at all possible.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Wed, 27 Jan 2010 16:44:18 -0800, Carl Banks wrote:

 You're referring to the O(N**2) bit, right? I am sure he knew it was O
 (N*log(N)), which is still worse than O(N) for key.

 If he didn't, well, Python has some fundamental flaws in its basic sort
 algorithm.
 
 Quicksort is O(N**2) worst case, perhaps that's what he meant.

No, apparently I was delusional.


 I'm not
 sure about timsort but since it's based on quicksort I'd guess it is
 O(N**2) or worse, worst case, as well.

timsort is actually a mergesort, not a quicksort.

You may like to read this:

http://svn.python.org/projects/python/trunk/Objects/listsort.txt


 Typical case of a sort is still O(N*log(N)) whether using key or cmp.
 People recommended against cmp not because of overall algorithmic time
 considerations, but because of the number of function calls.  cmp
 function was called a minimum of N-1 times and typically around N*log2
 (N) times, whereas key was called exactly N times.  Since the overhead
 of a Python function call was very large compared to the built-in cmp
 operation, it usually outweighed the algorithmic time considerations.

Yes, that sounds more like it. Thanks for the corrections.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[David Cournapeau]

On Thu, Jan 28, 2010 at 9:25 AM, Paul Rubin no.em...@nospam.invalid wrote:

 I don't mind that 3.x is breaking stuff for the sake of improving
 things.  That's the whole idea of 3.x, after all.  What bugs me is that
 the improvements are mostly quite superficial, and the breakage seems
 often gratuitous.  I'd rather see much more drastic changes and
 correspondingly much larger improvements.

At the risk of saying something trivial, that depends on what you
consider superficial or not.  It totally depends on your usage. I know
I would have taken something to improve python packaging (dropping
distutils, stable ABI across the whole 3.x range) over any feature in
py3k.

That's why your real estate comparison is not adequate IMHO - what is
2 % for you is maybe 30 % for someone else, and my own 30 % for
packaging may be 1 % for most people who don't care about C extensions
at all.

David.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Gib Bogle]

Steven D'Aprano wrote:

On Wed, 27 Jan 2010 02:28:00 +0100, Alf P. Steinbach wrote:


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


The aphorism needs fixing: If it ain't broke, don't fix it.
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Jonathan Gardner]

On Jan 27, 4:25 pm, Paul Rubin no.em...@nospam.invalid wrote:
  What about assert and pass?


If you're going to have statements, you're going to need the null
statement. That's pass. It could be renamed null_statement but
pass is a better description. None and pass are cousins of
sorts, since None is the null expression and pass the null
statement.

I agree on assert. I don't like running a program in test mode and
then running it in production mode with different code. I would rather
test what I am going to actually run. assert should be a function,
and support for removing assert statements should be eliminated. I
simply don't use assert statements at all.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[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.
* 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)
* 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)
* Integers by default is long. Great!
* Much more integrated unicode support, rewrite of most its text
or string semantics. Fantastic. Finally.

Am looking because i wonder if i should switch to python 3 for my own
few scripts, and rewrite my Python Tutorial for version 3. Am also
interested to know how python 3 is received by the computing industry.
Apparantly, a little search on the web indicates that vast majority of
python base have not switched, as expected, for many good reasons.
Vast majority of major python modules and tools have not switched.
Most linux distro have not switched, i don't find any large
corporation having adopted Python 3 (Google, Yahoo, Facebook,
NASA,... ). (sources: Source, Source) Basically, such a incompatible
change with trivial, ideological improvements, is too costy to switch.

I wonder, if by 2015, will most large corporate users have switched to
python 3. I give it a maybe. In today's Proliferation of Computing
Languages, such a major antic by Guido can just hurt itself. What is
he thinking? He of course thought himself as a god of lang designer,
who sincerely wants to push towards perfection, all future-looking.
Unfortunately, the tens of other major language designers all think
similarly.

perm archive of this post with possible updates here:
http://xahlee.org/comp/python3.html

Any comment on this?

  Xah
? http://xahlee.org/

Hello Xah,

I have no figures to base this on (just what I have read on the web), 
but although the vast majority of comanies with big Python investments 
are probably waiting for the 'critical mass' to use Python3 regularly 
(oil-tanker effect), I would like to think that smaller operations are 
experimenting with it more-and-more.


I think that for beginners who have dived into Python in the last 6-12 
months (like me), it doesn't make sense to start with an older version. 
I do not want to learn 'old' syntax and functions of a language, only to 
have to learn the new versions when most developers upgrade to 3 - I 
might as well learn the new syntax now and be ahead-of-the-game ;-) . I 
know my choice of related packages (web-framework, ORM, 
templating-engine) is very limited at present, but there are enough 
branches and beta-versions around to help me with my learning-curve, and 
I figure there will be some full-production-releases around by the time 
I am 'fluent' with Python (12-18 months?).


Currently I am using Python 3.1 and CherryPy (3.20 rc1) every day, and 
have had no serious problems (yet).


I would be interested to hear how other people are using Python 3, and 
with what compatible packages.


Regards,
Alan Harris-Reid
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

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.




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




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


Well, perhaps floating point, but...



* Much more integrated unicode support, rewrite of most its text
or string semantics. Fantastic. Finally.


I'm not sure if the Unicode support is fantastic. I have the impression that 
there are still some edges to iron out and corners to smooth, + bugs to kill. 
But it's Very Good.



[snip]

Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[alex23]

Alf P. Steinbach al...@start.no wrote:
 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.
[...]
 Probably there must have been some rationale, but to put it bluntly removing 
 the
 comparator is more like moronic than pythonic.

So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 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]
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steve Holden]

[Off-list]
alex23 wrote:
 Alf P. Steinbach al...@start.no wrote:
 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.
 [...]
 Probably there must have been some rationale, but to put it bluntly removing 
 the
 comparator is more like moronic than pythonic.
 
 So in both cases, you haven't put any effort into researching why
 these decisions were made, but you're happy to jump to conclusions
 about the intelligence of the implementer(s) while regularly trotting
 out complaints of ad hominem attacks against yourself.
 
 The saddest part of all is you seem to consider yourself some kind of
 educator.

snort/ ;-)

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010  http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* alex23:

Alf P. Steinbach al...@start.no wrote:

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.

[...]

Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic.


So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.


Hi alex23.

Ad hominem attacks like you try above, just reflect on the one doing it.

Adding in some obviously false assertions just makes you look even worse.

And posting anonymously, well, that article's got it all.

Such attacks constitute noise and, except for how they reflect on you, only 
noise.


Cheers  hth.,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* Steve Holden:

[Off-list]
alex23 wrote:

Alf P. Steinbach al...@start.no wrote:

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.

[...]

Probably there must have been some rationale, but to put it bluntly removing the
comparator is more like moronic than pythonic.

So in both cases, you haven't put any effort into researching why
these decisions were made, but you're happy to jump to conclusions
about the intelligence of the implementer(s) while regularly trotting
out complaints of ad hominem attacks against yourself.

The saddest part of all is you seem to consider yourself some kind of
educator.


snort/ ;-)


Please don't post more noise and ad hominem attacks to the group, Steve.


- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[John Bokma]

Alf P. Steinbach al...@start.no writes:

 Please don't post more noise and ad hominem attacks to the group,
 Steve.

Funny that you talk about noise while replying yourself to noise. Xah
Lee is just a pathetic spammer. He's not going to reply in this
thread. He just shits out his stuff in as many groups as possible to
promote his website.

-- 
John Bokma   j3b

Hacking  Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl  Python Development
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Alf P. Steinbach]

* John Bokma:

Alf P. Steinbach al...@start.no writes:


Please don't post more noise and ad hominem attacks to the group,
Steve.


Funny that you talk about noise while replying yourself to noise. Xah
Lee is just a pathetic spammer. He's not going to reply in this
thread. He just shits out his stuff in as many groups as possible to
promote his website.


Sorry, I didn't know.

Thanks for the heads-up.


Cheers,

- Alf
--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[John Bokma]

Alf P. Steinbach al...@start.no writes:

 * John Bokma:
 Alf P. Steinbach al...@start.no writes:

 Please don't post more noise and ad hominem attacks to the group,
 Steve.

 Funny that you talk about noise while replying yourself to noise. Xah
 Lee is just a pathetic spammer. He's not going to reply in this
 thread. He just shits out his stuff in as many groups as possible to
 promote his website.

 Sorry, I didn't know.

 Thanks for the heads-up.

My apologies for the harsh tone of my reply. I am more than tired of how
Xah Lee spams weekly, and shouldn't have assumed you were aware of that.

-- 
John Bokma   j3b

Hacking  Hiking in Mexico -  http://johnbokma.com/
http://castleamber.com/ - Perl  Python Development
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Terry Reedy]

On 1/26/2010 6:47 PM, 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.


Something we agree on. For simple scripts, it is a bit of a nuisance, 
but it eliminates kludgy special-case syntax for options, which are now 
normal keyword arguments.



 * 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)


Something we disagree on. I consider the shift from list or iterator 
orientation a major advance. If you ever want to iterate a 10 million 
item dict or map or filter a 100 million item sequence, you might then 
see the point.



 * 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)


It is completely gone. Cmp was kludgy. Sort paid no attention to the 
tri-state return but only paid attention to the less-than branch. Which 
means a) that it was redundant with the less than method and that the 
effort to split == from  was completely wasted. It is difficult to find 
use cases where cmp= is superior to key=



 * Integers by default is long. Great!
 * Much more integrated unicode support, rewrite of most its text
or string semantics. Fantastic. Finally.


What is missing now on Windows is better support from the OS, at least 
with XP. I have not tried 3.1 on Win7 yet (and never touched Vista).


Am looking because i wonder if i should switch to python 3 for my own
few scripts, and rewrite my Python Tutorial for version 3.


I am writing my book on algorithms using 3.1 because of the above and 
other improvements (consistent / and elimination of old classes, for 
instance).


 Am also

interested to know how python 3 is received by the computing industry.
Apparantly, a little search on the web indicates that vast majority of
python base have not switched,


Some people have panicked prematurely.

Guido never expected that working old apps would all be switched. There 
is probably code still being run with 1.5 from 15 years ago. And there 
will be 2.7 code running at least that far in the future.


Even before 3.0 was out, he also never expected major uptake until 3.2, 
which is a year away. 3.0 was, well, a .0 release with a couple of .0 
problems. 3.1 is pretty solid and modules are appearing for it.



as expected, for many good reasons.
Vast majority of major python modules and tools have not switched.


A few have, more will in the next year or after 3.2 is released, some 
never will. The most important one, in my opinion, is numpy, since some 
module authors who *want* to do a 3.x version are waiting on that.



Most linux distro have not switched,


Have any switched to 2.6 yet, as the default? Some do have 3.1 version 
available.


 i don't find any large

corporation having adopted Python 3 (Google, Yahoo, Facebook,
NASA,... ). (sources: Source, Source) Basically, such a incompatible
change with trivial, ideological improvements, is too costy to switch.


The major reduction of redundancy by the overdue removal of obsolete 
features makes it a much nicer language to learn than, say, 2.6. It is 
much closer to the simplicity of 1.4, which is what I started with.


Terry Jan Reedy


--
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 print as a function is more consistent and more convenient than print as 
 a statement. 

Convenience is subjective, but the 3.x 'print' behavior is definitely
inconsistent (i.e. different from 2.x).  The change makes a lot of my
code silently produce wrong results, too.  I often print tuples to show
what a program is doing:

print (timestamp, 'transmogrified', blob)

which in 2.x prints a parenthesized tuple that I can later read back in
with eval.  That line of code still prints a message, but in a different
format, instead of throwing an error.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Steven D'Aprano]

On Tue, 26 Jan 2010 22:23:11 -0800, Paul Rubin wrote:

 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 print as a function is more consistent and more convenient than print
 as a statement.
 
 Convenience is subjective, but the 3.x 'print' behavior is definitely
 inconsistent (i.e. different from 2.x). 


Sorry, I meant consistent with the rest of Python, which mostly uses 
functions/methods and only rarely statements (e.g. del and import).


 The change makes a lot of my
 code silently produce wrong results, too.  I often print tuples to show
 what a program is doing:
 
 print (timestamp, 'transmogrified', blob)
 
 which in 2.x prints a parenthesized tuple that I can later read back in
 with eval.  That line of code still prints a message, but in a different
 format, instead of throwing an error.


I don't pretend that the transition between statement and function syntax 
will be anything but inconvenient, but I believe the end result will be 
worth it.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Stephen Hansen]

On Tue, Jan 26, 2010 at 10:23 PM, Paul Rubin no.em...@nospam.invalidwrote:

 Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
  print as a function is more consistent and more convenient than print as
  a statement.

 Convenience is subjective, but the 3.x 'print' behavior is definitely
 inconsistent (i.e. different from 2.x).


This is a strange definition of consistent in my mind.

To me, consistent means that it matches the patterns and idioms of the rest
of the language at that point in time, not that it implies anything about
backwards-compatibility.

print as a statement was always inconsistent with the rest of the Python
language; the rules of how it behaved had to be defined in a unique way
(e.g., the behavior of trailing commas, the  syntax to redirect what you
print to). Everything about the statement was inconsistent.

Yes, 3.0 changing the print statement to a function made it inconsistent
with previous versions, but at the same time it made it MORE consistent with
the rest of the language and Python code.

If we are defining consistent as backwards-compatible, we have a
problem. Python3 is about fixing -language- inconsistencies, and allowing
for backwards incompatibility when that meant the language itself was more
consistent.



  The change makes a lot of my
 code silently produce wrong results, too.  I often print tuples to show
 what a program is doing:

print (timestamp, 'transmogrified', blob)

 which in 2.x prints a parenthesized tuple that I can later read back in
 with eval.  That line of code still prints a message, but in a different
 format, instead of throwing an error.


That seems like bad code. If one needs to print out what a program is doing,
use the logging module.

Maybe its just me, but in my experience-- real professional code never uses
print unless it was a small script with a very narrowly focused purpose.
Changing that focus to use Python3's print function vs a statement isn't
really all that hard.

And the language is more consistent.

--S
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[Paul Rubin]

Steven D'Aprano ste...@remove.this.cybersource.com.au writes:
 Sorry, I meant consistent with the rest of Python, which mostly uses 
 functions/methods and only rarely statements (e.g. del and import).

yield, assert, if/else, return, etc.  If we're after that kind of
consistency, why not get rid of all those statements too?  They have
already partly done it with yield, and they ended up introducing a new
separate if/else expression syntax as an alternative to the statement.

 I don't pretend that the transition between statement and function syntax 
 will be anything but inconvenient, but I believe the end result will be 
 worth it.

This just seems like a gratuitous change with very little benefit.  
Changing a bunch of list functions to instead return iterators is
a much deeper change that will cause larger amounts of breakage, but
it has quite a lot of benefits, so there's a stronger case for it.
-- 
http://mail.python.org/mailman/listinfo/python-list