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 dictionary to
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
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, and the answer is simply: don't make
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=raothl=en#88bb8a26750dd8c6
Basically, should staticmethods be made
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 called
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
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
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 about
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
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
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 object
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 understanding
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 example, the
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
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 feature
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 it provides by
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 answer the question myself
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
[EMAIL PROTECTED] wrote:
import re2
buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping'
regex='^((?Pverse(?Pnumber\d+) (?Pactivity[^,]+))(, )?)*$'
pat2=re2.compile(regex)
x=pat2.extract(buf)
x
{'verse': [{'number': '12', 'activity': 'drummers
drumming'}, {'number': '11', 'activity':
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='^((?Pverse(?Pnumber\d+) (?Pactivity[^,]+))(, )?)*$'
pat2=re2.compile(regex)
x=pat2.extract(buf)
If one wanted to match the API
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*
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 if
23 matches
Mail list logo
