Quoting [EMAIL PROTECTED]:
>
> Guido> Over lunch with Alex Martelli, he proposed that a subclass of
> Guido> dict with this behavior (but implemented in C) would be a good
> Guido> addition to the language.
>
> Instead, why not define setdefault() the way it should have been done in th
Done :)
I summarized my point of view and I'm waiting for comments :)
Pierre
Aahz a écrit :
> On Thu, Sep 29, 2005, Pierre Barbier de Reuille wrote:
>
>>Ok, so I took a closer look at the documentation and tried a few things
>>to understand better what you said
Ok, so I took a closer look at the documentation and tried a few things
to understand better what you said and I have some remark ...
Phillip J. Eby a ecrit :
> At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
>
>> Regularly, you see questions about augmented assignme
Phillip J. Eby a écrit :
> At 05:40 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
>
>> Rather than closing this as invalid, it would be wiser to update the
>> documentation before ! Nothing corresponds to the current behavior.
>
>
> I got my infor
a performance issue that
will easily be fixed by using "extend" method for lists and
corresponding methods for other objects.
My opinion is, redefining the augmented assignment is a problem given
the assignment semantic, and perhaps we should get rid of it.
Pierre
--
Pierre Barbie
Josiah Carlson a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
>
> 0.5
>
> So, subtracting that .5 seconds from all the cases gives us...
>
> 0.343 seconds for .find's comparison
> 0.313 seconds for .index's exception handling when an e
Shane Hathaway a écrit :
> Eric Nieuwland wrote:
>
>> Pierre Barbier de Reuille wrote:
>>
>>> Or you want to have some "partition" method which accept regular
>>> expressions:
>>>
>>> head, sep, tail = some_str.partition(re.c
sep, tail = some_str.partition(re.compile(sep+'.'*offset))
>
> --eric
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/pie
Josiah Carlson a écrit :
> Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
>
>>Well, I want to come back on a point that wasn't discussed. I only found
>>one positive comment here :
>>http://mail.python.org/pipermail/python-dev/2005-August/055775.html
hod
QStringList::split) and, in that case, the separator would be the actual
matched separator string.
Pierre
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34
for-loop cannot be used with iterator-for-blocks.
The main problem with this syntax is the use of the blocks for things
that are not loops (like the synchronize object)! And they are, indeed,
quite common ! (or they will be :) ).
Pierre
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs
you need to break from many loops, enclose them
into a function and return from it !
Pierre
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la
error if
used with an iterator-for-block. But as blocks require an
iterator-for-blocks they will allow iterator-for-loops too !
Cheers,
Pierre
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII,
Nick Coghlan a écrit :
Pierre Barbier de Reuille wrote:
One main reason is a common error could be (using the synchronised
iterator introduced in the PEP):
for l in synchronised(mylock):
do_something()
It will compile, run, never raise any error but the lock will be
acquired and never
n, never raise any error but the lock will be
acquired and never released !
Then, I think there is no use case of a generator with __error__ in the
for-loop as it is now. So, IMO, it is error-prone and useless to have
two different syntaxes for such things.
Pierre
--
Pierre Barbier de Reuille
IN
value': " 123 256,", 0: " 123", 1:" 256"},
'logic': {'_value': 'and'},
3: {'_value': " 123 289", 1: " 123", 2:" 289"} }
Pierre
Regards.
Chris.
_______________
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/pierre.barbier%40cirad.fr
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ
17 matches
Mail list logo
