Samuele Pedroni wrote:
well, I think some people desire a more streamlined way of writing code
like:
def f(...)
...
def g(...)
...
x = h(...,f,g)
Using the recently-proposed 'where' facility, this could
be written
x = h(..., f, g) where:
def f(...):
...
def g(...):
Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> >
> >>Josiah Carlson wrote:
> >>
> >>
> >>>Since PEP 310 was already mentioned, can we just say that the discussion
> >>>can be boiled down to different ways of spelling __enter__/__exit
Josiah Carlson wrote:
Greg Ewing <[EMAIL PROTECTED]> wrote:
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
w
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > Since PEP 310 was already mentioned, can we just say that the discussion
> > can be boiled down to different ways of spelling __enter__/__exit__ from
> > PEP 310?
>
> It's not quite the same thing. PEP 310 suggests a mechanis
Samuele Pedroni wrote:
My point is that a suite-based syntax
can only be a half substitute for lambda and anyway requiring a suite
seems overkill and unnatural for the just 1 expression case, for example
predicates. IOW a suite-based syntax is not a lambda killer in itself, I
would not try to stres
Brian Sabbey wrote:
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a
substitute of lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further
arguments.
I do not see why you say suite-based thunks cannot be
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a substitute of
lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further
arguments.
I do not see why you say suite-based thunks cannot be used in the case in
Brian Sabbey wrote:
be guaranteed to run under all conditions, I think it would be
useful if it could be arranged so that
for x in somegenerator(): ... raise Blather ...
would caused any finallies that the generator was suspended inside
to be executed. Then the semantics would be the same as if the
be guaranteed to run under all conditions, I think it
would be useful if it could be arranged so that
for x in somegenerator():
...
raise Blather
...
would caused any finallies that the generator was suspended
inside to be executed. Then the semantics would be the
same as if the for-loop-
Josiah Carlson wrote:
Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
with a fixed control flow -- do something on entry, do the
cod
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Brian Sabbey wrote:
>
> > How about something like below? In the same way
> > that "self" is passed "behind the scenes" as the first argument, so can
> > the thunk be.
> >
> > with stopwatch() result dt:
> > a()
> > b()
> > print 'it took', d
Brian Sabbey wrote:
How about something like below? In the same way
that "self" is passed "behind the scenes" as the first argument, so can
the thunk be.
with stopwatch() result dt:
a()
b()
print 'it took', dt, 'seconds to compute'
Something like that would be better, yes. Maybe even ju
On Mon, 14 Mar 2005, Greg Ewing wrote:
Brian Sabbey wrote:
The problem with creating a new mechanism is that sometimes you will want
to loop. For example, reading a bunch of items from a shared resource,
modifying them, and sending them back. A new, non-looping mechanism will
not be adequate f
Brian Sabbey wrote:
The problem with creating a new mechanism is that sometimes you will
want to loop. For example, reading a bunch of items from a shared
resource, modifying them, and sending them back. A new, non-looping
mechanism will not be adequate for this because it cannot loop,
If ther
On Sun, 13 Mar 2005, Greg Ewing wrote:
Brian Sabbey wrote:
I prefer re-using the 'for' loop for this purpose because it allows the
problem to be solved in a general way by re-using a structure with which
most users are already familiar, and uses generators, which are easier to
use in this case t
Brian Sabbey wrote:
I prefer re-using the 'for' loop for this purpose because it allows the
problem to be solved in a general way by re-using a structure with which
most users are already familiar, and uses generators, which are easier
to use in this case than defining a class with __exit__, __e
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> On Sat, 12 Mar 2005, Josiah Carlson wrote:
>
> > I stand by my "clever hack" statement, and I will agree to disagree with
> > you on it, like I agree to disagree with you about both the necessity of
> > passing arbitrary values back into a generator (I
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I stand by my "clever hack" statement, and I will agree to disagree with
you on it, like I agree to disagree with you about both the necessity of
passing arbitrary values back into a generator (I think it is poor
style, and too much brain overhead to wo
On Sat, 12 Mar 2005, Steven Bethard wrote:
Brian Sabbey <[EMAIL PROTECTED]> wrote:
I agree that this is a confusing way to use generators. But it is the
expected way to use "code blocks" as found in other languages. It would
take some getting used to that 'for' can be used this way, but I think i
Brian Sabbey <[EMAIL PROTECTED]> wrote:
>
> On Sat, 12 Mar 2005, Josiah Carlson wrote:
>
> > I say it is magical. Why? The way you propose it, 'yield' becomes an
> > infix operator, with the name provided on the left being assigned a
> > value produced by something that isn't explicitly called
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> I agree that this is a confusing way to use generators. But it is the
> expected way to use "code blocks" as found in other languages. It would
> take some getting used to that 'for' can be used this way, but I think it
> would be worth it.
I guess I nee
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I say it is magical. Why? The way you propose it, 'yield' becomes an
infix operator, with the name provided on the left being assigned a
value produced by something that isn't explicitly called, referenced, or
otherwise, by the right. In fact, I would s
On Sat, 12 Mar 2005, Steven Bethard wrote:
The goals behind this seem a lot like the goals of PEP 288[1]. I
remember discussions suggesting code like:
def gen():
a, b, c=3 = yield 1
yield a + b*c
g = gen()
print g.next() # prints 1
print g.next(1, 2) # prints 7
But as you can see, this creat
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> (I) Give generators a __call__ method as an alternative to 'next'.
> Method __call__ should take a single parameter: a function. Using
> __call__ will cause the generator to start executing normally, but when a
> 'yield' is reached, the generator will invo
Brian Sabbey <[EMAIL PROTECTED]> wrote:
>
> On Fri, 11 Mar 2005, Josiah Carlson wrote:
>
> > My first reaction to the proposal was "ick". Why? Because every time
> > I've seen a mechanism for modifying the internals of generators
> > constructed using yield, the syntax has been awful; in my op
On Fri, 11 Mar 2005, Josiah Carlson wrote:
My first reaction to the proposal was "ick". Why? Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
(whether my opinion means anything is another matter),
Brian Sabbey <[EMAIL PROTECTED]> wrote:
> I would like to get some feedback on a proposal to introduce
> smalltalk/ruby-like "code blocks" to python. Code blocks are, among other
> things, a clean way to solve the "acquire/release" problem [1][2]. This
> proposal also touches on some of the pr
I would like to get some feedback on a proposal to introduce
smalltalk/ruby-like "code blocks" to python. Code blocks are, among other
things, a clean way to solve the "acquire/release" problem [1][2]. This
proposal also touches on some of the problems PEP 288 [3] deals with.
The best discuss
28 matches
Mail list logo
