[Python-Dev] multiprocessing vs. distributed processing
(Sorry for the double send...) 2009/1/16 James Mills : > I've noticed over the past few weeks lots of questions > asked about multi-processing (including myself). Funny, I was going to blog about this, but not just for Python. > For those of you new to multi-processing, perhaps this > thread may help you. Some things I want to start off > with to point out are: > > "multiprocessing will not always help you get things done faster." Of course. There are some programs that are I/O or memory bandwidth bound. So if one of those bottlenecks is common to the cores you use, you can't benefit from their use. > "be aware of I/O bound applications vs. CPU bound" Exactly. We read a lot about fold...@home, s...@home, they can be distributed, as it is more or less "take a chunk, process it somewhere and when you're finish tell me if there something interesting in it". Not a lot of communications between the nodes. Then, there are other applications that process a lot of data, they must read data from memory, make one computation, read other data, compute a little bit (finite difference schemes), and here we are memory bandwidth bound, not CPU bound. > "multiple CPUs (cores) can compute multiple concurrent expressions - > not read 2 files concurrently" Let's say that this is true for the usual computers. Clusters can make concurrent reads, as long as there is the correct architecture behind. Of course, if you only have one hard disk, you are limited. > "in some cases, you may be after distributed processing rather than > multi or parallel processing" Of course. Clusters can be expensive, their interconnections even more. So if your application is made of independent blocks that can run on small nodes, without much I/Os, you can try distributed computing. If you need big nodes with high-speed interconnections, you will have to use parallel processing. This is just what my thoughts on the sucjet are, but I think I'm not far from the truth. Of course, if I'm proved wrong, I'll be glad to hear why. Matthieu -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] issue 4927: Inconsistent unicode repr for fileobject
I would appreciate if some of you could chip in your opinion of this issue. http://bugs.python.org/issue4927 Cheers, Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r68547 - in python/trunk/Lib/test: test_datetime.py test_os.py
On Thu, Jan 15, 2009 at 10:40 PM, Kristján Valur Jónsson wrote: > Right. I've fixed the remainder, things should quiet down now. > K Thank you! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing vs. distributed processing
James Mills wrote: > I've noticed over the past few weeks lots of questions > asked about multi-processing (including myself). While these are fair points, did you perhaps mean to send this to python-list rather than python-dev? Cheers, Nick. > > For those of you new to multi-processing, perhaps this > thread may help you. Some things I want to start off > with to point out are: > > "multiprocessing will not always help you get things done faster." > > "be aware of I/O bound applications vs. CPU bound" > > "multiple CPUs (cores) can compute multiple concurrent expressions - > not read 2 files concurrently" > > "in some cases, you may be after distributed processing rather than > multi or parallel processing" > > cheers > James > > -- > -- "Problems are solved by method" > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] py3k: TypeError: object.__init__() takes no parameters
I've noticed with latest python 3.1 checkout (68631) if I have this
object hierarchy with a default __init__ in the superclass to be used
by the subclasses which don't necessarily need an __init__ it blows up
with a TypeError.
class Field(object):
def __init__(self, data):
"""Default init for the subclasses"""
print("init class=%r, self=%r" % (self.__class__.__name__, self))
super(Field, self).__init__(data)
self.data = self.orig = data
class IntegerField(Field):
def __init__(self, data):
"""Overridden init"""
super(IntegerField, self).__init__(data)
self.data = int(data)
class StringField(Field):
pass
f1 = StringField('abc')
f2 = IntegerField('10')
print("f1=%r" % f1.data)
print("f2=%r" % f2.data)
print(type(f1))
print(type(f2))
It blows up with
init class='StringField', self=<__main__.StringField object at 0xb7d47b4c>
Traceback (most recent call last):
File "subclass-super-problem-py3k.py", line 17, in
f1 = StringField('abc')
File "subclass-super-problem-py3k.py", line 5, in __init__
super(Field, self).__init__(data)
TypeError: object.__init__() takes no parameters
The exact same code runs under py 2.5 just fine.
I can't think of anything to write in Field.__init__ to tell whether
super is about to run __init__ on object.
The problem can be fixed (inelegantly IMHO) like this
class BaseField(object):
def __init__(self, data):
"""Default init for the subclasses"""
self.data = self.orig = data
class Field(BaseField):
def __init__(self, data):
"""Another Default init for the subclasses"""
super(Field, self).__init__(data)
class IntegerField(Field):
def __init__(self, data):
"""Overridden init"""
super(IntegerField, self).__init__(data)
self.data = int(data)
class StringField(Field):
pass
f1 = StringField('abc')
f2 = IntegerField('10')
print("f1=%r" % f1.data)
print("f2=%r" % f2.data)
print(type(f1))
print(type(f2))
Is this a bug or a feature? Is there a better work-around?
--
Nick Craig-Wood -- http://www.craig-wood.com/nick
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
Nick Craig-Wood wrote:
I've noticed with latest python 3.1 checkout (68631) if I have this
object hierarchy with a default __init__ in the superclass to be used
by the subclasses which don't necessarily need an __init__ it blows up
with a TypeError.
class Field(object):
object is default baseclass, hence not needed
def __init__(self, data):
"""Default init for the subclasses"""
print("init class=%r, self=%r" % (self.__class__.__name__, self))
super(Field, self).__init__(data)
This line is the problem: remove it and I believe all is fine.
Since object()s are immutable, its init cannot do anything as far as I
know. Deleting this is effectively what you did below.
Actually, I am puzzled why object even has __init__. Perhaps to avoid
hasattr(ob,'__init__') check Doc implies that is it possible for a
class to not have one.
"
object.__init__(self[, ...])
Called when the instance is created. The arguments are those passed to
the class constructor expression. If a base class has an __init__()
method, the derived class’s __init__() method, if any, must explicitly
call it to ensure proper initialization of the base class part of the
instance; for example: BaseClass.__init__(self, [args...]). As a special
constraint on constructors, no value may be returned; doing so will
cause a TypeError to be raised at runtime.
"
But in 3.0, *all* classes will inherit object.__init__.
From super() doc...
"There are two typical use cases for “super”. In a class hierarchy with
single inheritance, “super” can be used to refer to parent classes
without naming them explicitly, thus making the code more maintainable."
I wonder about this claim. This use of super() does not eliminate the
need to pass legal args, so you have to know what actually is called, so
why not name it?
self.data = self.orig = data
class IntegerField(Field):
def __init__(self, data):
"""Overridden init"""
?? This over-rides and is not over-ridden.
super(IntegerField, self).__init__(data)
self.data = int(data)
class StringField(Field):
pass
f1 = StringField('abc')
f2 = IntegerField('10')
print("f1=%r" % f1.data)
print("f2=%r" % f2.data)
print(type(f1))
print(type(f2))
It blows up with
init class='StringField', self=<__main__.StringField object at 0xb7d47b4c>
Traceback (most recent call last):
File "subclass-super-problem-py3k.py", line 17, in
f1 = StringField('abc')
File "subclass-super-problem-py3k.py", line 5, in __init__
super(Field, self).__init__(data)
TypeError: object.__init__() takes no parameters
The exact same code runs under py 2.5 just fine.
Perhaps 2.5's object.__init__ just swallowed all args, thus hiding bogus
calls.
I can't think of anything to write in Field.__init__ to tell whether
super is about to run __init__ on object.
I do not understand. You know it is going to run the .__init__ of its
one and only base class, which here is object.
The problem can be fixed (inelegantly IMHO) like this
class BaseField(object):
def __init__(self, data):
"""Default init for the subclasses"""
self.data = self.orig = data
class Field(BaseField):
def __init__(self, data):
"""Another Default init for the subclasses"""
super(Field, self).__init__(data)
These two inits together are the original without bad call to
object.__init__. No need to do this.
class IntegerField(Field):
def __init__(self, data):
"""Overridden init"""
super(IntegerField, self).__init__(data)
self.data = int(data)
class StringField(Field):
pass
f1 = StringField('abc')
f2 = IntegerField('10')
print("f1=%r" % f1.data)
print("f2=%r" % f2.data)
print(type(f1))
print(type(f2))
Is this a bug or a feature? Is there a better work-around?
Eliminate bad call.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
Terry Reedy wrote:
> Nick Craig-Wood wrote:
> > I've noticed with latest python 3.1 checkout (68631) if I have this
> > object hierarchy with a default __init__ in the superclass to be used
> > by the subclasses which don't necessarily need an __init__ it blows up
> > with a TypeError.
> >
> > class Field(object):
>
> object is default baseclass, hence not needed
Agreed, but I wanted the code to run with py < 3 also!
> > def __init__(self, data):
> > """Default init for the subclasses"""
> > print("init class=%r, self=%r" % (self.__class__.__name__, self))
> > super(Field, self).__init__(data)
>
> This line is the problem: remove it and I believe all is fine.
> Since object()s are immutable, its init cannot do anything as far as I
> know. Deleting this is effectively what you did below.
Yes you are absolutely right - that super is never needed. I don't
know what I was thinking of! Without that the problem disappears.
[snip]
> Perhaps 2.5's object.__init__ just swallowed all args, thus hiding bogus
> calls.
Yes it did which is the fundamental difference in behaviour between
py2 and py3 as far as I can see.
[snip]
> Eliminate bad call.
Check!
(Bashes head against wall!)
Thanks
Nick
--
Nick Craig-Wood -- http://www.craig-wood.com/nick
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
On Fri, Jan 16, 2009 at 2:12 PM, Terry Reedy wrote: > > I do not understand. You know it is going to run the .__init__ of its one > and only base class, which here is object. Because this class might be used as base of another class. Take this trivial example code (in py2.6): class A(object): def __init__(self, a): #super(A, self).__init__(a) self.a = a print "A" class B(object): def __init__(self, a): #super(B, self).__init__(a) self.b = a print "B" class C(A, B): def __init__(self, a): super(C, self).__init__(a) self.c = a print "C", dir(self) C(1) Running the last line shows that A's constructor got called, but not B's constructor. The only way to make sure all __init__s are called in this example is by doing class A(object): def __init__(self, a): super(A, self).__init__(a) self.a = a print "A" class B(object): def __init__(self, a): #super(B, self).__init__(a) self.b = a print "B" class C(A, B): def __init__(self, a): super(C, self).__init__(a) self.c = a print "C", dir(self) C(1) which is really ugly (as in, why is B's call to super.__init__ commented but not A's, if A and B are otherwise identical?) I'm not sure, but I think the proper behavior for object.__init__ should be ignoring all args. -- - Alexandre ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (01/09/09 - 01/16/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2313 open (+40) / 14473 closed (+24) / 16786 total (+64) Open issues with patches: 796 Average duration of open issues: 699 days. Median duration of open issues: 4 days. Open Issues Breakdown open 2289 (+40) pending24 ( +0) Issues Created Or Reopened (65) ___ thread_nt.c update 01/12/09 CLOSED http://bugs.python.org/issue3582reopened loewis patch, patch Can't Locate File with No Capital in Name01/09/09 CLOSED http://bugs.python.org/issue4900created markpennock inconsistent API docs for tp_iter01/09/09 CLOSED http://bugs.python.org/issue4901created garcia failed to build ctypes in Python2.6.1 (even with gcc)01/09/09 CLOSED http://bugs.python.org/issue4902created akineko binascii.crc32() - document signed vs unsigned results 01/11/09 http://bugs.python.org/issue4903reopened gregory.p.smith Typo for PickingError in pickle.py 01/10/09 CLOSED http://bugs.python.org/issue4904created erickt Use INVALID_FILE_ATTRIBUTES instead of magic numbers 01/10/09 http://bugs.python.org/issue4905created eckhardt patch os.listdir fails on debug build (windows)01/10/09 CLOSED http://bugs.python.org/issue4906created ocean-city patch, needs review ast.literal_eval does not properly handled complex numbers 01/10/09 CLOSED http://bugs.python.org/issue4907created aronacher patch, patch adding a get_metadata in distutils 01/10/09 http://bugs.python.org/issue4908created tarek patch incorrect renaming in imports01/10/09 CLOSED http://bugs.python.org/issue4909created loewis patch Remove uses of nb_long slot, and rename to nb_reserved. 01/10/09 http://bugs.python.org/issue4910created marketdickinson patch Windows installer Quad processor issues 01/10/09 CLOSED http://bugs.python.org/issue4911created zhar2 Invalid syntax in ctypes/util.py 01/10/09 CLOSED http://bugs.python.org/issue4912created pitrou wave.py: add writesamples() and readsamples()01/11/09 http://bugs.python.org/issue4913created alex_python_org patch trunc(x) erroneously documented as built-in 01/11/09 http://bugs.python.org/issue4914created MLModel Port sysmodule.c to MS Windows CE01/11/09 CLOSED http://bugs.python.org/issue4915created eckhardt patch test_io is broken on UCS401/11/09 CLOSED http://bugs.python.org/issue4916created benjamin.peterson patch PyBytes_Format documented but doesn't exist in C/API 01/12/09 CLOSED http://bugs.python.org/issue4917created omorvant Windows installer created with Python 2.5 does
Re: [Python-Dev] issue 4927: Inconsistent unicode repr for fileobject
Done. Rejected, with argumentation. On Fri, Jan 16, 2009 at 1:14 AM, Kristján Valur Jónsson wrote: > I would appreciate if some of you could chip in your opinion of this issue. > > http://bugs.python.org/issue4927 -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
On Fri, 16 Jan 2009 at 16:53, Nick Craig-Wood wrote: [snip] Perhaps 2.5's object.__init__ just swallowed all args, thus hiding bogus calls. Yes it did which is the fundamental difference in behaviour between py2 and py3 as far as I can see. Actually, between py<=2.5 and py>=2.6. --RDM ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
Alexandre Passos wrote: On Fri, Jan 16, 2009 at 2:12 PM, Terry Reedy wrote: I do not understand. You know it is going to run the .__init__ of its one and only base class, which here is object. Because this class might be used as base of another class. Take this trivial example code (in py2.6): class A(object): def __init__(self, a): #super(A, self).__init__(a) self.a = a print "A" class B(object): def __init__(self, a): #super(B, self).__init__(a) self.b = a print "B" class C(A, B): def __init__(self, a): super(C, self).__init__(a) self.c = a print "C", dir(self) C(1) Running the last line shows that A's constructor got called, but not B's constructor. Same in 3.0 with print ()s The only way to make sure all __init__s are called in this example is by doing class A(object): def __init__(self, a): super(A, self).__init__(a) self.a = a print "A" class B(object): def __init__(self, a): #super(B, self).__init__(a) self.b = a print "B" class C(A, B): def __init__(self, a): super(C, self).__init__(a) self.c = a print "C", dir(self) C(1) which is really ugly (as in, why is B's call to super.__init__ commented but not A's, if A and B are otherwise identical?) Especially since the commenting would have to be reversed should the definition of C change to reverse the inheritance order. Should one write "class D(B,A) .." or "class D(B,C..)", nothing would work. I'm not sure, but I think the proper behavior for object.__init__ should be ignoring all args. Given "The second use case is to support cooperative multiple inheritence in a dynamic execution environment. ... Good design dictates that this method have the same calling signature in every case (because the order of parent calls is determined at runtime and because that order adapts to changes in the class hierarchy)." the change makes object unsuitable as a multiple inheritance base. I think as a practical matter it is anyway since practical cases have other methods that object does not have that need exist in the pyramid base. This must be why there have not been squawks about the change in 2.6. So I wonder whether the proper change might have been to remove object.__init__. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecate PyNumber_Long?
Now that all uses of nb_long and __long__ have disappeared from the 3.x codebase, would it make sense to mark PyNumber_Long as deprecated in the c-api documentation, and convert all existing uses (I count a grand total of 3 uses in the py3k branch!) to PyNumber_Int? (The two functions behave identically: PyNumber_Int is a macro that's #defined to expand to PyNumber_Long.) Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate PyNumber_Long?
On Fri, Jan 16, 2009 at 13:34, Mark Dickinson wrote: > Now that all uses of nb_long and __long__ have disappeared from > the 3.x codebase, would it make sense to mark PyNumber_Long > as deprecated in the c-api documentation, and convert all existing > uses (I count a grand total of 3 uses in the py3k branch!) to > PyNumber_Int? > > (The two functions behave identically: PyNumber_Int is a macro > that's #defined to expand to PyNumber_Long.) Assuming we have been moving the C API usage to PyInt and not PyLong, then yes it makes sense. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
Terry Reedy wrote: > Given > "The second use case is to support cooperative multiple inheritence in > a dynamic execution environment. ... Good design dictates that this > method have the same calling signature in every case (because the order > of parent calls is determined at runtime and because that order adapts > to changes in the class hierarchy)." > the change makes object unsuitable as a multiple inheritance base. > > I think as a practical matter it is anyway since practical cases have > other methods that object does not have that need exist in the pyramid > base. This must be why there have not been squawks about the change in > 2.6. I think that sums up the reasoning fairly well - the (IMO, reasonable) expectation is that a CMI hierarchy will look something like: object | CMIBase | While the signatures of __new__ and __init__ will remain the same for all classes in the CMI hierarchy, CMIBase will assume the only class after it in the MRO is object, with signatures for __new__ and __init__ that accept no additional arguments beyond the class and instance respectively. Note that CMIBase serves another purpose in such a hierarchy: isinstance(obj, CMIBase) becomes a concise check to see if an object is a member of the hierarchy or not. > So I wonder whether the proper change might have been to remove > object.__init__. That would have broken too much code, since a lot of immutable types rely on it (they only override __new__ and leave __init__ alone). For more info, see Guido's checkin changing the behaviour and the associated tracker issue: http://svn.python.org/view?rev=54539&view=rev http://bugs.python.org/issue1683368 Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k: TypeError: object.__init__() takes no parameters
Nick Coghlan wrote: Terry Reedy wrote: So I wonder whether the proper change might have been to remove object.__init__. That would have broken too much code, since a lot of immutable types rely on it (they only override __new__ and leave __init__ alone). In what way do they depend on the equivalent of "def f(): pass"? If, during the object creation process, "if hasattr(newob, '__init__'):" were added after calling cls.__new__ and before calling newob.__init__, what dependency would be left? To repeat a previous comment, the doc sentence beginning "If a base class has an __init__() method," implies that it is intended to be possible for classes to not have an __init__ method. Should the doc be changed. Is this just a holdover from pre-object-class days? For more info, see Guido's checkin changing the behaviour and the associated tracker issue: http://svn.python.org/view?rev=54539&view=rev http://bugs.python.org/issue1683368 Ah yes. In that thread I complained that >>> object.__init__.__doc__ 'x.__init__(...) initializes x; see x.__class__.__doc__ for signature' unchanged in 3.0) is uninformative. Why cannot object.__init__.__doc__ tell the truth? "object.__init__(self) takes no other args and does nothing" The signature of a class as a callable is *not* the signature of its __init__ method! In particular >>> object.__class__.__doc__ "type(object) -> the object's type\ntype(name, bases, dict) -> a new type" (also unchanged in 3.0) is irrelevant and uninformative as to whether object.__init__ accepts (as it used to) or rejects (as it now does) args other than 'self'. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems with unicode_literals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been playing with 'from __future__ import unicode_literals' just
to see how unicode unclean some of my code was. Almost everything was
fairly easy to fix but I found two interesting situations. One seems
fairly shallow and might arguably be fixable in Python 2.6 (but
probably not :). The other clearly can't be addressed in Python 2.6,
but the question is whether it should be changed for Python 2.7.
Here's some sample code:
- -snip snip-
from __future__ import unicode_literals
def foo(a=None, b=None):
print a, b
# This is a TypeError
foo(**{'a': 1, 'b': 2})
foo(**dict(a=1, b=2))
from optparse import OptionParser
parser = OptionParser()
# This also raises a TypeError
parser.add_option('-f', '--foo')
- -snip snip-
The add_option() failure is a one-line fix.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSXFFmnEjvBPtnXfVAQKx0QP/Un7RG++ugtgywBHXd+pWTD2V7QC1JDqP
rpIkwqocicMZiNBbg0NS5/TSGHa0CyaQphDmBBeNFr7jFb4rxdUESyLmBNNIz7dV
/PEBZxJp5ZjTGCIylEJoXHMSN102wqe/n6QAAGqV5ce7e3Fhr8b7kU2m7cMT6yDQ
/1b4riH/H0Y=
=dp0u
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with unicode_literals
Is the issue that in foo(**{'a': 1, 'b': 1}) the 'a' and 'b' are
unicode and not acceptable as keyword arguments? I agree that should
be fixed, though I'm not sure it'll be easy.
I'm not sure you're saying that the optparse case shouldn't be fixed
in 2.6. or the foo(**{...}) shouldn't be fixed in 2.6, though I think
the latter.
On Fri, Jan 16, 2009 at 6:42 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I've been playing with 'from __future__ import unicode_literals' just to see
> how unicode unclean some of my code was. Almost everything was fairly easy
> to fix but I found two interesting situations. One seems fairly shallow and
> might arguably be fixable in Python 2.6 (but probably not :). The other
> clearly can't be addressed in Python 2.6, but the question is whether it
> should be changed for Python 2.7.
>
> Here's some sample code:
>
> - -snip snip-
> from __future__ import unicode_literals
>
> def foo(a=None, b=None):
>print a, b
>
> # This is a TypeError
> foo(**{'a': 1, 'b': 2})
>
> foo(**dict(a=1, b=2))
>
> from optparse import OptionParser
>
> parser = OptionParser()
>
> # This also raises a TypeError
> parser.add_option('-f', '--foo')
> - -snip snip-
>
> The add_option() failure is a one-line fix.
>
> - -Barry
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (Darwin)
>
> iQCVAwUBSXFFmnEjvBPtnXfVAQKx0QP/Un7RG++ugtgywBHXd+pWTD2V7QC1JDqP
> rpIkwqocicMZiNBbg0NS5/TSGHa0CyaQphDmBBeNFr7jFb4rxdUESyLmBNNIz7dV
> /PEBZxJp5ZjTGCIylEJoXHMSN102wqe/n6QAAGqV5ce7e3Fhr8b7kU2m7cMT6yDQ
> /1b4riH/H0Y=
> =dp0u
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with unicode_literals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 16, 2009, at 10:26 PM, Guido van Rossum wrote:
Is the issue that in foo(**{'a': 1, 'b': 1}) the 'a' and 'b' are
unicode and not acceptable as keyword arguments? I agree that should
be fixed, though I'm not sure it'll be easy.
I'm not sure you're saying that the optparse case shouldn't be fixed
in 2.6. or the foo(**{...}) shouldn't be fixed in 2.6, though I think
the latter.
Yep, sorry, it's been a long week. ;)
The optparse one could easily be fixed for 2.6, if we agree it should
be fixed. This untested patch should do it I think:
Index: Lib/optparse.py
===
- --- Lib/optparse.py (revision 68465)
+++ Lib/optparse.py (working copy)
@@ -994,7 +994,7 @@
"""add_option(Option)
add_option(opt_str, ..., kwarg=val, ...)
"""
- -if type(args[0]) is types.StringType:
+if type(args[0]) in types.StringTypes:
option = self.option_class(*args, **kwargs)
elif len(args) == 1 and not kwargs:
option = args[0]
Should this be fixed, or wait for 2.7?
The fact that 'a' and 'b' are unicodes and not accepted as keyword
arguments is probably the tougher problem. I haven't yet looked at
what it might take to fix. Is it worth fixing in 2.6 or is this a
wait-for-2.7 thing?
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSXFUWHEjvBPtnXfVAQK0cgQAt5CqfAYmDCCaN7XkplrYg1mr2B6SBj5Q
oPGxuYaQAu5k4iEcicl27JFElbzzAqMtJ/bpRPVajQlagZt8s7o+dbn/dhHvIBpQ
u2nPUAtBcfoqvfMvoaCmA9xixI/N4z1dAJjkifwG9n2Dh/PhDzc6KuFFXthh6Euy
KnguC64McvE=
=U2B+
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with unicode_literals
On Fri, Jan 16, 2009 at 9:45 PM, Barry Warsaw wrote:
>
> The optparse one could easily be fixed for 2.6, if we agree it should be
> fixed. This untested patch should do it I think:
>
> Index: Lib/optparse.py
> ===
> - --- Lib/optparse.py (revision 68465)
> +++ Lib/optparse.py (working copy)
> @@ -994,7 +994,7 @@
> """add_option(Option)
>add_option(opt_str, ..., kwarg=val, ...)
> """
> - -if type(args[0]) is types.StringType:
> +if type(args[0]) in types.StringTypes:
> option = self.option_class(*args, **kwargs)
> elif len(args) == 1 and not kwargs:
> option = args[0]
It'd probably be better to replace that whole line with
isinstance(args[0], basestring).
>
> The fact that 'a' and 'b' are unicodes and not accepted as keyword arguments
> is probably the tougher problem. I haven't yet looked at what it might take
> to fix. Is it worth fixing in 2.6 or is this a wait-for-2.7 thing?
Actually, this looks like a one line fix, too:
--- Python/ceval.c (revision 68625)
+++ Python/ceval.c (working copy)
@@ -2932,7 +2932,8 @@
PyObject *keyword = kws[2*i];
PyObject *value = kws[2*i + 1];
int j;
- if (keyword == NULL || !PyString_Check(keyword)) {
+ if (keyword == NULL || !(PyString_Check(keyword) ||
+PyUnicode_Check(keyword))) {
PyErr_Format(PyExc_TypeError,
"%.200s() keywords must be strings",
PyString_AsString(co->co_name));
But I agree with Guido when he says this should be a 2.7 feature.
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
