"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> It's the responsibility of a coroutine scheduler to take a snapshot() when
> a task is suspended, and to swap() it in when resumed. So it doesn't
> matter that you've changed what thread you're running in, as long as you
> keep the context with the
At 07:30 PM 10/19/2005 -0700, Josiah Carlson wrote:
>What about a situation in which corutines are handled by multiple
>threads? Any time a corutine passed from one thread to another, it
>would lose its state.
It's the responsibility of a coroutine scheduler to take a snapshot() when
a task is s
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> For efficiency's sake, however, CPython could simply store the
> execution context dictionary in its "thread state" structure, creating
> an empty dictionary at thread initialization time. This would make it
> somewhat easier to offer a C API for acce
This is still rather rough, but I figured it's easier to let everybody fill
in the remaining gaps by arguments than it is for me to pick a position I
like and try to convince everybody else that it's right. :) Your feedback
is requested and welcome.
PEP: XXX
Title: Task-local Variables
Autho
Michel Pelletier <[EMAIL PROTECTED]> wrote:
>
> Martin Blais wrote:
> > Hi
> >
> > Just wondering, would anyone think of it as a good idea if the
> > enumerate() builtin could accept a "start" argument? I've run across
> > a few cases where this would have been useful. It seems generic
> > eno
> We yield values from inside for loops all over the place, but the
> yielded value is very rarely just the index value (only 1 of 14 yields)
> , but something calculated from the index value, so the new syntax would
> not be useful, unless it was something that provided access to the index
> item
Martin Blais wrote:
> Hi
>
> Just wondering, would anyone think of it as a good idea if the
> enumerate() builtin could accept a "start" argument? I've run across
> a few cases where this would have been useful. It seems generic
> enough too.
+1, but something more useful might be a a cross bet
Andrew Koenig wrote:
>> Sure, that would work. Or even this, if the scheduler would
>>automatically recognize generator objects being yielded and so would run
>>the the nested coroutine until finish:
>
>
> This idea has been discussed before. I think the problem with recognizing
> generators a
Hi
Just wondering, would anyone think of it as a good idea if the
enumerate() builtin could accept a "start" argument? I've run across
a few cases where this would have been useful. It seems generic
enough too.
___
Python-Dev mailing list
Python-Dev@py
On 10/19/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> letting "class" inject a slightly magic "self" variable into the class
> namespace ?
>
> class C:
>
> foo = property(self.getFoo, self.setFoo, None, 'the foo property')
>
> def getFoo(self):
> return self._foo
Guido van Rossum wrote:
> OK, so how's this for a radical proposal.
>
> Let's change the property built-in so that its arguments can be either
> functions or strings (or None). If they are functions or None, it
> behaves exactly like it always has.
>
> If an argument is a string, it should be a me
At 12:46 PM 10/19/2005 -0700, Josiah Carlson wrote:
>[EMAIL PROTECTED] wrote:
> > > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
> >
> > Phillip> Not unless the tuple is passed in as an abstract syntax
> tree or
> > Phillip> something.
> >
> > Hmmm... Maybe I misread somethi
Jim Jewett <[EMAIL PROTECTED]> wrote:
> (In http://mail.python.org/pipermail/python-dev/2005-October/057409.html,)
> Nick Coghlan suggested allowing attribute references as binding targets.
>
> >x = property("Property x (must be less than 5)")
>
> >def x.get(instance): ...
>
> Josiah s
[EMAIL PROTECTED] wrote:
>
> > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
>
> Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
> >> >> :
> >> >>
> >> ...
> >>
> Steve> Wow, that's really neat. And you save a keyword! ;-)
> >>
>
> "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes:
Phillip> At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
>> >> :
>> >>
>> ...
>>
Steve> Wow, that's really neat. And you save a keyword! ;-)
>>
>> Two if you add a builtin called "function
Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 10/16/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
[snip]
> > What I'm saying is that whether or not you can modify the contents of
> > stack frames via tricks, you shouldn't. Why? Because as I said, if the
> > writer wanted you to be hacking arou
Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> (In http://mail.python.org/pipermail/python-dev/2005-October/057251.html)
> Eyal Lotem wrote:
>
> > Name: Attribute access for all namespaces ...
>
> > global x ; x = 1
> > Replaced by:
> > module.x = 1
>
> Attribute access as an option wou
JanC <[EMAIL PROTECTED]> wrote:
>
> On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Until Microsoft adds kernel support for fork, don't expect standard
> > Windows Python to support it.
>
> AFAIK the NT kernel has support for fork, but the Win32 subsystem
> doesn't support it (you can
At 11:43 AM 10/19/2005 -0500, [EMAIL PROTECTED] wrote:
> >> :
> >>
> ...
>
> Steve> Wow, that's really neat. And you save a keyword! ;-)
>
>Two if you add a builtin called "function" (get rid of "def").
Not unless the tuple is passed in as an abstract syntax tree or somethi
>> :
>>
...
Steve> Wow, that's really neat. And you save a keyword! ;-)
Two if you add a builtin called "function" (get rid of "def").
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
I'm still making slow progress on this front. I have a versioned
merged to the CVS head. I'd like to make a final pass over the patch.
I'd upload it to SF, but I can't connect to a web server there. If
anyone would like to eyeball that patch before I commit it, I can
email it to you.
Jeremy
O
At 07:47 PM 10/19/2005 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > Note that a "where" or "given" statement like this could make it a
> > little easier to drop lambda.
>
>I think the "lambda will disappear in Py3k" concept might have been what
>triggered the original 'where' statement dis
Michele Simionato wrote:
> This reminds me of an idea I have kept in my drawer for a couple of years or
> so.
> Here is my proposition: we could have the statement syntax
>
> :
>
>
> to be syntactic sugar for
>
> = (, , )
>
[snip]
> BTW, if the proposal was implemented, the 'class' would be
(In http://mail.python.org/pipermail/python-dev/2005-October/057409.html,)
Nick Coghlan suggested allowing attribute references as binding targets.
>x = property("Property x (must be less than 5)")
>def x.get(instance): ...
Josiah shivered and said it was hard to tell what was even inte
(In http://mail.python.org/pipermail/python-dev/2005-October/057251.html)
Eyal Lotem wrote:
> Name: Attribute access for all namespaces ...
> global x ; x = 1
> Replaced by:
> module.x = 1
Attribute access as an option would be nice, but might be slower.
Also note that one common us
On 10/14/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Until Microsoft adds kernel support for fork, don't expect standard
> Windows Python to support it.
AFAIK the NT kernel has support for fork, but the Win32 subsystem
doesn't support it (you can only use it with the POSIX subsystem).
--
JanC
Hi Michele,
> Property p():
> "I am a property"
> def fget(self):
> pass
> def fset(self):
> pass
> def fdel(self):
> pass
In effect this is quite similar to the proposal I've done (except that
you've reversed the traditional assignment order from "p = Pro
On 10/19/05, Paul Moore <[EMAIL PROTECTED]> wrote:
>
> One question - in the expansion, "name" is used on both sides of the
> assignment. Consider
>
> something name():
>
>
> This expands to
>
> name = something(name, (), )
>
> What should happen if name wasn't defined before? A li
Phillip J. Eby wrote:
> Note that a "where" or "given" statement like this could make it a
> little easier to drop lambda.
I think the "lambda will disappear in Py3k" concept might have been what
triggered the original 'where' statement discussion.
The idea was to be able to lift an arbitrary s
On 10/19/05, Michele Simionato <[EMAIL PROTECTED]> wrote:
> On 10/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I wonder if at some point in the future Python will have to develop a
> > macro syntax so that you can write
> >
> > Property foo:
> > def get(self): return self._foo
Josiah Carlson wrote:
>> Another option would be to allow attribute reference targets when binding
>> function names:
>
> *shivers at the proposal* That's scary. It took me a few minutes just
> to figure out what the heck that was supposed to do.
Yeah, I think it's a concept with many, many mo
Stefan Rank <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> I think there is no need for a special @syntax for this to work.
>
> I suppose it would be possible to allow a trailing block after any
> function invocation, with the effect of creating a new namespace that
> gets treated as co
On 10/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I wonder if at some point in the future Python will have to develop a
> macro syntax so that you can write
>
> Property foo:
> def get(self): return self._foo
> ...etc...
This reminds me of an idea I have kept in my dra
on 18.10.2005 19:17 Antoine Pitrou said the following:
>>What would this mythical block statement look like that would make
>>properties easier to write than the above late-binding or the subclass
>>Property recipe?
>
> I suppose something like:
>
> class C(object):
> x = prop:
>
34 matches
Mail list logo
