Brian Sabbey wrote:
I made an example implementation, and this wasn't an issue. It took
some code to stick the thunk into the argument list, but it was pretty
straightforward.
What does your implementation do with something like
f() + g():
...
? (A syntax error, I would hope.)
While no dou
Steven Bethard wrote:
line = None
@withfile("readme.txt")
def print_readme(fileobj):
lexical line
for line in fileobj:
print line
print "last line:" line
Since the name of the function isn't important,
that could be reduced to
@withfile("readme.txt")
def _(fileobj):
...
(Dis
Guido van Rossum wrote:
Perhaps it could be even simpler:
[assignment_target '=']* expr ':' suite
I don't like that so much. It looks like you're
assigning the result of expr to assignment_target,
and then doing something else.
This would just be an extension of the regular assignment stateme
Ka-Ping Yee wrote:
Can you explain what you meant by currying here? I know what
the word "curry" means, but i am having a hard time seeing how
it applies to your example.
It's currying in the sense that instead of one function
which takes all the args at once, you have a function
that takes some o
Martin v. LÃwis 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 she
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 han
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 c
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
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
Assign(lhs=Slice(
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
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 comp
I do not know that I have ever needed 'anonymous blocks', and I have
therefore not followed this discussion in detail, but I appreciate Python's
beauty and want to see it maintained. So I have three comments and
yet-another syntax proposal that I do not remember seeing (but could have
missed)
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 state
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, a
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
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
unnecessary, because abu
On Thu, 21 Apr 2005, Guido van Rossum wrote:
> The use cases where the block actually returns a value are probably
> callbacks for things like sort() or map(); I have to admit that I'd
> rather keep lambda for these (and use named functions for longer
> blocks) than introduce an anonymous block syn
[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
unnecessary, because abusing the for-loo
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 deli
Guido van Rossum wrote:
>>So the two things I thought were glitches are actually cancelling each
>>other out. Very good. Thanks for your help.
>
>
> Though I wonder why it was written so delicately.
Don't know; Jeremy wrote those functions back in 2001 to add nested scopes. If
he remembers he
[Ping]
> It sounds like you are very close to simply translating
>
> expression... function_call(args):
> suite
>
> into
>
> expression... function_call(args)(suitefunc)
Actually, I'm abandinging this interpretation; see my separate (long) post.
--
--Guido van Rossum (home pag
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):
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:
the_l
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 abo
On 4/21/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
> 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
Scott David Daniels <[EMAIL PROTECTED]> writes:
> What should marshal / unmarshal do with floating point NaNs (the case we
> are worrying about is Infinity) ? The current behavior is not perfect.
So, after a fair bit of hacking, I think I have most of a solution to
this, in two patches:
make
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
>
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
> 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/)
_
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > 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 callabl
James Y Knight wrote:
> If it was possible to assign to a variable to a variable bound outside
> your function, but still in your lexical scope, I think it would fix
> this issue. That's always something I've thought should be possible,
> anyways. I propose to make it possible via a declaration sim
> 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 r
Guido van Rossum wrote:
> > So while:
> > fooble(arg)
> > is pretty nasty, documentation that tells me that 'arg' is a string is
> > probably enough to set me on the right track. But if the
> > documentation tells me that arg is a thunk/block, that's almost
> > certainly not enough to get me g
Michael Chermside wrote:
There is one exception... matching strings. There we have a powerful
means of specifying patterns (regular expressions), and a multi-way
branch based on the content of a string is a common situation. A new
way to write this:
s = get_some_string_value()
if s == '':
I 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
> Python.
N
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 tha
[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
>
>
> So while:
> fooble(arg)
> is pretty nasty, documentation that tells me that 'arg' is a string is
> probably enough to set me on the right track. But if the
> documentation tells me that arg is a thunk/block, that's almost
> certainly not enough to get me going. I also need to know how that
[Brian Sabbey]
> >> If suites were commonly used as above to define properties, event handlers
> >> and other callbacks, then I think most people would be able to comprehend
> >> what the first example above is doing much more quickly than the second.
[Fredrik]
> > wonderful logic, there. good lu
> So the two things I thought were glitches are actually cancelling each
> other out. Very good. Thanks for your help.
Though I wonder why it was written so delicately. Would explicit
INCREF/DECREF really have hurt the performance that much? This is only
the bytecode compiler, which isn't on the
Michael Hudson wrote:
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, t
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").ad
On 4/21/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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
> > p
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
Pyth
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-w
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
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 i
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
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'
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:
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 if they existed ;-)):
>
> def strawma
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
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
> > du
53 matches
Mail list logo
