(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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.p
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubsc
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, perhap
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 i
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 basec
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.
> >
> > c
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):
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
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/)
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
___
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
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 ident
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 p
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
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 e
-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
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
-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 yo
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/optpars
20 matches
Mail list logo
