Steven Bethard wrote:
> On 4/17/06, Russell E. Owen <[EMAIL PROTECTED]> wrote:
>> At some point folks were discussing use cases of "make" where it was
>> important to preserve the order in which items were added to the
>> namespace.
>>
>> I'd like to suggest adding an implementation of an ordered d
Guido van Rossum wrote:
> There's no need to change Python so that people coming from other
> languages won't make silly mistakes, is there?
Is that really a mistake... Yes, it's a mistake since staticmethod is a
descriptor, but isn't it in a sense an implementation detail,
particularly for a n
Armin Rigo wrote:
> Hi Nicolas,
>
> On Thu, Mar 02, 2006 at 01:55:03AM -0500, Nicolas Fleury wrote:
>> (...) A use case is not hard to
>> imagine, especially a private static method called only to build a class
>> attribute.
>
> Uh. I do this all the time
Guido van Rossum wrote:
> In which context did you find a need for defining a static method and
> calling it inside the class definition? I'm guessing that what you're
> playing dubious scoping games.
I'm not. I almost never use staticmethod actually. I find them not
very pythonic, in my humble
Steven Bethard wrote:
> My only (mild) concern is that if staticmethod is going to get a
> __call__, I think classmethod should probably get one too. Inside a
> class this doesn't make much sense:
I agree, make sense or not, if "@staticmethod def foo()" and a simple
"def foo(self)" can all be ca
Hi,
I've posted this question on comp.lang.python, but nobody seems to
conclude it is a bad idea, so I post it here.
http://groups.google.com/group/comp.lang.python/browse_frm/thread/6082dae1deef9161/88bb8a26750dd8c6?lnk=raot&hl=en#88bb8a26750dd8c6
Basically, should staticmethods be made callabl
Raymond Hettinger wrote:
> I propose that in Py3.0, the "and" and "or" operators be simplified to
> always return a Boolean value instead of returning the last evaluated
> argument.
Please no. I find things like:
def __cmp__(self, other):
return (cmp(self.a, other.a) or
Hi,
I would like to know what is the status of PEP 328? Can absolute_import
be expected in 2.5? Any help needed? I'll be interested.
Also, the content of the PEP doesn't seem to be up-to-date with the
status quo, since it is mentioned support in 2.4 for "from __future__
import absolute_impor
Fred L. Drake, Jr. wrote:
> On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote:
> > These names should be changed to __beginwith__ and __endwith__. The
> > current names are too vague, not obviously paired with each other, not
> > obviously tied to the with-statement, and provide no hint
Raymond Hettinger wrote:
> Several thoughts:
As I told you in a private dicussion, you have convinced me about copy.
About clear, however, I feel I have to defend my colleagues and
myself, who almost all wasted time once (but only once) searching how to
clear a list. Improving the docs (like
Raymond Hettinger wrote:
> [Shane Holloway]
>
>>I would agree generic clearing is a lark in terms of programming
>>feature. However, I have been asked how to clear a list more than a
>>handful of times.
>
> list.clear() does not solve the root problem. The question is
> symptomatic of not unde
Raymond Hettinger wrote:
> Use copy.copy() for generic copying -- it works across a wide range of
> objects. Alternatively, use the constructor as generic way to make
> duplicates:
>
>dup = set(s)
>dup = list(l)
>dup = dict(d)
>dup = tuple(t) # note, the duplicate is original
Barry Warsaw wrote:
> I've been looking at the API for sets.Set and built-in set objects in
> Python 2.4.1 and I think I have found some minor inconsistencies.
This comment reminds me another small inconsistency/annoyance.
Should copy and clear functions be added to lists, to be more consistent
Guido van Rossum wrote:
> Why are you so excited about having until indented? You didn't give
> any examples with multiple occurrences. A single occurrence works just
> fine unindented, as PEP 315 has already shown.
FWIW, I must say I disagree (about "works just fine"). I find PEP 315
counter-in
Nick Coghlan wrote:
> With PEP 344, this could simply be:
>
>try:
>parser.parseFile(file)
>exeption Exception, exception:
>raise type(exception)("Error at line %s in file %s" % (x,y))
>
> Introspectively,
> Nick.
>
It doesn't work (unless I misundertand you). For exampl
Sorry if this message is not a direct reply to Ka-Ping
Yee message on PEP344, I'm in vacation in China and
there's a thing I must say that could make sense in
PEP344.
I do a lot of exception re-raising at work; I use that
technique to add content to exception messages while
keeping the original s
Guido van Rossum wrote:
>>Maybe generators are not the way to go, but could be
>>supported natively by providing a __block__ function, very similarly to
>>sequences providing an __iter__ function for for-loops?
>
> Sorry, I have no idea what you are proposing here.
I was suggesting that the featu
Paul Moore wrote:
> On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> 2. Manual protocol implementations are _significantly_ easier to write
>
> Hmm, I've not tried so I'll have to take your word for this. But I
> don't imagine writing manual implementations much - one of the key
> features
Guido van Rossum wrote:
> [Skip Montanaro]
>>Guido> How many try/finally statements have you written inside a loop?
>>Guido> In my experience this is extrmely rare. I found no
>>Guido> occurrences in the standard library.
>
>>How'd we start talking about try/finally?
>
> Because i
Guido van Rossum wrote:
[Nicolas Fleury]
scoped EXPR as VAR:
BLOCK
Definitely not. In too many languages, a "scope" is a new namespace,
and that's exactly what a block (by whichever name) is *not*.
Humm... what about "context"?
context EXPR as VAR:
BLOCK
I may a
Guido van Rossum wrote:
A variation on this with somewhat different semantics swaps the keywords:
in EXPR for VAR:
BLOCK
If you don't need the variable, you can leave the "for VAR" part out:
in EXPR:
BLOCK
Too cute? :-)
I don't think it reads well. I would prefer something
Josiah Carlson wrote:
Nicolas Fleury <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
import re2
buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping'
regex='^((?P(?P\d+) (?P[^,]+))(, )?)*$'
pat2=re2.compile(regex)
x=pat2.extract(buf)
If one wanted to matc
[EMAIL PROTECTED] wrote:
import re2
buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping'
regex='^((?P(?P\d+) (?P[^,]+))(, )?)*$'
pat2=re2.compile(regex)
x=pat2.extract(buf)
x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity': 'pipers
piping'}, {'n
Nick Coghlan wrote:
Guido van Rossum wrote:
No, no, no! NO! Never catch a general exception like that and replace
it with one of your own. That can cause hours of debugging pain later
on when the type error is deep down in the bowels of the += operation
(or perhaps deep down inside something *it* i
Reinhold Birkenfeld wrote:
"""
He proposes that
[x in list if x > 0]
(which is currently undefined) be exactly equal to:
[x for x in list if x > 0]
"""
What about that?
But [x in list] means already something.
Supporting [x in list if condition] will complicate the parser and will
be error-prone i
Raymond Hettinger wrote:
I felt the same way when reading it. Also, it seemed to embody the
political outlook that optimization is sinful. The document could be
much more positive, fact based, and informative. Also, the wording
seems somewhat outdated.
A draft for a new entry is included below.
26 matches
Mail list logo
