Alex Martelli schrieb:
Adam Atlas [EMAIL PROTECTED] wrote:
Hasn't this been discussed many many times before? I think Guido has
been favourable to the idea of allowing :=, but that was a long time
ago, and I don't think anything ever came of it.
Personally, if anything, I'd like to see
Hasn't this been discussed many many times before? I think Guido has
been favourable to the idea of allowing :=, but that was a long time
ago, and I don't think anything ever came of it.
Personally, if anything, I'd like to see more use of the 'as' keyword
as in Python 2.5's new 'with' statement.
Adam Atlas [EMAIL PROTECTED] wrote:
Hasn't this been discussed many many times before? I think Guido has
been favourable to the idea of allowing :=, but that was a long time
ago, and I don't think anything ever came of it.
Personally, if anything, I'd like to see more use of the 'as'
Alex Martelli wrote:
As others have mentioned, your particular instance is probably
evidence that you need to restructure your code a little bit, but I
do agree that x = y; if x: ... is a common enough idiom that it
warrants a shortcut. And reusing as, I think, is nice and readable,
and it's
On Apr 7, 9:55 pm, Paul McGuire [EMAIL PROTECTED] wrote:
seriesAndEpnum = Combine( OneOrMore( ~Literal(-) +
Word(alphas) ).setParseAction( capitalizeAll ),
joinString= ).setResultsName(series) + \
Word(nums).setResultsName(episodeNum)
should
On Apr 5, 2:51 pm, [EMAIL PROTECTED] wrote:
I would like to gauge interest in the following proposal:
Problem:
Assignment statements cannot be used as expressions.
Performing a list of mutually exclusive checks that require data
processing can cause excessive tabification. For example,
Dustan [EMAIL PROTECTED] wrote:
class Wrapper(object):
def __init__(self, obj):
self.obj = obj
def getit(self):
return self.obj
def setit(self, obj):
self.obj = obj
return obj
Yeah, that's substantialy the same
On Apr 8, 10:56 am, [EMAIL PROTECTED] (Alex Martelli) wrote:
Dustan [EMAIL PROTECTED] wrote:
class Wrapper(object):
def __init__(self, obj):
self.obj = obj
def getit(self):
return self.obj
def setit(self, obj):
self.obj =
On Apr 5, 4:08 pm, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
I love event-based parsers so I have no problem with that
approach in general.
You might find a pyparsing version of this to be to your liking. It
is possible in the parser events (or parse actions as pyparsing
calls them) to
Gabriel Genellina [EMAIL PROTECTED] wrote:
You have to build the handlers list, containing (regex, handler) items;
the unknown case might be a match-all expression at the end.
Well, after playing a bit with decorators I got this:
snip
That's a nice class, and more maintainable with the
On Thu, 2007-04-05 at 12:51 -0700, [EMAIL PROTECTED] wrote:
I would like to gauge interest in the following proposal:
Problem:
Assignment statements cannot be used as expressions.
Performing a list of mutually exclusive checks that require data
processing can cause excessive
[EMAIL PROTECTED] wrote:
Performing a list of mutually exclusive checks that require data
processing can cause excessive tabification. For example, consider
the following python snipet...
temp = my_re1.match(exp)
if temp:
# do something with temp
else:
temp = my_re2.match(exp)
Carsten Haese [EMAIL PROTECTED] wrote:
If that's your only justification for this proposal, that's almost
certainly not enough to convince anybody of its necessity. Your code
example should be rewritten as a loop:
match_actions = [(my_re1, action1),
(my_re2, action2),
On Apr 5, 4:22 pm, Duncan Booth [EMAIL PROTECTED] wrote:
Can you come up with a real example where this happens and which cannot be
easily rewritten to provide better, clearer code without the indentation?
I'll admit to having occasionally had code not entirely dissimilar to this
when first
[EMAIL PROTECTED]:
else:
my_match = capper_re.match(f):
if my_match:
capper = capper_re.match(f).group(1)
if capper == 'JJ' or capper == 'JeffreyJacobs':
capper = 'Jeffrey C. Jacobs'
On Apr 5, 6:01 pm, Neil Hodgson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:
else:
my_match = capper_re.match(f):
if my_match:
capper = capper_re.match(f).group(1)
if capper == 'JJ' or capper == 'JeffreyJacobs':
[EMAIL PROTECTED] wrote:
On Apr 5, 4:22 pm, Duncan Booth [EMAIL PROTECTED] wrote:
Can you come up with a real example where this happens and which cannot be
easily rewritten to provide better, clearer code without the indentation?
I'll admit to having occasionally had code not entirely
Steven Bethard wrote:
[EMAIL PROTECTED] wrote:
On Apr 5, 4:22 pm, Duncan Booth [EMAIL PROTECTED] wrote:
Can you come up with a real example where this happens and which
cannot be
easily rewritten to provide better, clearer code without the
indentation?
I'll admit to having occasionally
[EMAIL PROTECTED] a écrit :
I would like to gauge interest in the following proposal:
Problem:
Assignment statements cannot be used as expressions.
This is by design.
Performing a list of mutually exclusive checks that require data
processing can cause excessive tabification. For
Duncan Booth a écrit :
[EMAIL PROTECTED] wrote:
Performing a list of mutually exclusive checks that require data
processing can cause excessive tabification. For example, consider
the following python snipet...
temp = my_re1.match(exp)
if temp:
# do something with temp
else:
temp =
En Thu, 05 Apr 2007 18:08:46 -0300, [EMAIL PROTECTED]
[EMAIL PROTECTED] escribió:
I am trying to write a parser for a text string. Specifically, I am
trying to take a filename that contains meta-data about the content of
the A/V file (mpg, mp3, etc.).
I first split the filename into
21 matches
Mail list logo
