Brett C. wrote:
Works for me. If no one objects I will check in the change for CFLAGS to make
it ``$(BASECFLAGS) $(OPT) $EXTRA_CFLAGS`` soon (is quoting it enough to make
sure that it isn't evaluated by configure but left as a string to be evaluated
by the shell when the Makefile is
On 4/20/05, Samuele Pedroni [EMAIL PROTECTED] wrote:
def do():
print setup
try:
yield None
finally:
print tear down
doesn't quite work (if it did, all you would need is syntactic sugar
for for
dummy in).
PEP325 is about
Shannon -jj Behrens [EMAIL PROTECTED] writes:
On 4/20/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
My use case for switch is that of a parser switching on tokens.
mxTextTools applications would greatly benefit from being able
to branch on tokens quickly. Currently, there's only callbacks,
I can post an alternative, inspired by this bit of Haskell (I've
deliberately left out the Haskell type annotation for this):
zoneOpts argv =
case getOpt Permute options argv of
(o,n,[]) - return (o,n)
(_,_,errs) - error errs
which could, in a future Python, look something like:
Josiah Carlson wrote:
for my purposes, I've found that the #1 callback killer in contemporary
Python
is for-in:s support for the iterator protocol:
...
and get shorter code that runs faster. (see cElementTree's iterparse for
an excellent example. for typical use cases, it's nearly
On Apr 21, 2005, at 6:28 AM, Fredrik Lundh wrote:
Glyph Lefkowitz wrote:
Despite being guilty of propagating this style for years myself, I
have to disagree. Consider the
following network-conversation using Twisted style (which, I might
add, would be generalizable to
other Twisted-like systems
Guido van Rossum wrote:
IMO this is clearer, and even shorter!
But it clutters the namespace with objects you don't need.
Why do people care about cluttering namespaces so much? I thought
thats' what namespaces were for -- to put stuff you want to remember
for a bit. A function's local namespace
Andrew McGregor writes:
I can post an alternative, inspired by this bit of Haskell
[...]
The intent is that within the case, the bit before each : is a boolean
expression, they're evaluated in order, and the following block is
executed for the first one that evaluates to be True.
If we're
On Wed, 2005-04-20 at 18:59 -0700, Brett C. wrote:
So no leak. Yes, there should be more explicit refcounting to be proper, but
the compiler cheats in a couple of places for various reasons. But basically
everything is fine since st-st_cur and st-st_stack are only played with
refcount-wise
Michael Chermside wrote:
Now the pattern matching is more interesting, but again, I'd need to
see a proposed syntax for Python before I could begin to consider it.
If I understand it properly, pattern matching in Haskell relies
primarily on Haskell's excellent typing system, which is absent in
Bob Ippolito wrote:
def strawman(self):
def sayGoodbye(mingleResult):
def goAway(goodbyeResult):
self.loseConnection()
self.send(goodbye).addCallback(goAway)
def mingle(helloResult):
self.send(nice weather we're having).addCallback(sayGoodbye)
[Greg Ewing]
My current thought is that it should look like this:
with_file(filename) as f:
do_something_with(f)
The success of this hinges on how many use cases can
be arranged so that the word 'as' makes sense in that
position.
[...]
This way, the syntax is just
expr
Fredrik Lundh wrote:
Regardless, I believe that solving generator finalization (calling all
enclosing finally blocks in the generator) is a worthwhile problem to
solve. Whether that be by PEP 325, 288, 325+288, etc., that should be
discussed. Whether people use it as a pseudo-block, or decide
In case my point about the difference between thunks and other
callables (specifically decorators) slipped by, consider the
documentation for staticmethod, which takes a callable. All the
staticmethod documentation says about that callable's parameters is:
A static method does not
It strikes me that with something like this lexical declaration, we
could abuse decorators as per Carl Banks's recipe[1] to get the
equivalent of thunks:
abuse being the operative word.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 4/21/05, Guido van Rossum [EMAIL PROTECTED] wrote:
It strikes me that with something like this lexical declaration, we
could abuse decorators as per Carl Banks's recipe[1] to get the
equivalent of thunks:
abuse being the operative word.
Yup. I was just drawing the parallel between:
Samuele Pedroni [EMAIL PROTECTED] writes:
Michael Hudson wrote:
[pattern matching]
Can you post a quick summary of how you think this would work?
Well, Python lists are used more imperatively and are not made up
with cons cells, we have dictionaries which because of ordering
issues are
Greg Ewing wrote:
I also have a thought concerning whether the block
argument to the function should come first or last or
whatever. My solution is that the function should take
exactly *one* argument, which is the block. Any other
arguments are dealt with by currying. In other words,
with_file
I've been thinking about this a lot, but haven't made much
progess. Here's a brain dump.
I've been thinking about integrating PEP 325 (Resource-Release Support
for Generators) into the for-loop code, so that you could replace
the_lock.acquire()
try:
BODY
finally:
On Thu, 21 Apr 2005, Guido van Rossum wrote:
Perhaps it could be even simpler:
[assignment_target '=']* expr ':' suite
This would just be an extension of the regular assignment statement.
It sounds like you are very close to simply translating
expression... function_call(args):
Guido van Rossum wrote:
I've been thinking about this a lot, but haven't made much
progess. Here's a brain dump.
I've been thinking about integrating PEP 325 (Resource-Release Support
for Generators) into the for-loop code, so that you could replace
[SNIP - using 'for' syntax to delineate
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put all of
this
effort into trying to come up with some way to handle cleanup in a
generator.
I.e. PEP 325.
But (as I explained, and you agree) that still doesn't
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to handle cleanup in a
generator.
I.e. PEP 325.
But (as I explained,
On Thu, Apr 21, 2005, Guido van Rossum wrote:
Perhaps the most important lesson we've learned in this thread is that
the 'with' keyword proposed in PEP 310 is redundant -- the syntax
could just be
[VAR '=']* EXPR ':'
BODY
IOW the regular assignment / expression statement
Guido or perhaps even (making for VAR optional in the for-loop syntax)
Guido with
Guido in synchronized(the_lock):
Guido BODY
This could be a new statement, so the problematic issue of implicit
try/finally in every for statement wouldn't be necessary. That
Ka-Ping Yee wrote:
It seems to me that, in general, Python likes to use keywords for
statements and operators for expressions.
Probably worth noting that 'for', 'in' and 'if' in generator
expressions and list comprehensions blur this distinction somewhat...
Steve
--
You can wordify anything
At 06:10 PM 04/21/2005 +0100, Michael Hudson wrote:
But the visitor pattern is pretty grim, really. It would be nice (tm)
to have something like:
match node in:
Assign(lhs=Var(_), rhs=_):
# lhs, rhs bound in here
Assign(lhs=Subscr(_,_), rhs=_):
# ditto
Guido van Rossum wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put all of
this
effort into trying to come up with some way to handle cleanup in a generator.
I.e. PEP 325.
But (as I explained, and you agree) that still doesn't render PEP 310
Bob Ippolito wrote:
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to handle cleanup in a
generator.
On Apr 22, 2005, at 12:28 AM, Brett C. wrote:
Bob Ippolito wrote:
On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
Guido van Rossum [EMAIL PROTECTED] wrote:
[Brett]
I think I agree with Samuele that it would be more pertinent to put
all of this
effort into trying to come up with some way to
Martin v. Lwis wrote:
Brett C. wrote:
Works for me. If no one objects I will check in the change for CFLAGS to make
it ``$(BASECFLAGS) $(OPT) $EXTRA_CFLAGS`` soon (is quoting it enough to make
sure that it isn't evaluated by configure but left as a string to be evaluated
by the shell when the
31 matches
Mail list logo
