>def g():
>yield 42
>return 43
I don't see how the allowing return values in generators can fail to
be confusing for people new to Python. Of course, there are limits to
the degree that we should let people who are bad at Python dictate our
code practices, but I really just fee
Jim Jewett wrote:
I still don't see why it needs to be a return statement. Why not make
the intent of g explicit
def g():
yield 42
raise StopIteration(43)
Because it would be tedious and ugly, and would actually make
the intent *less* clear in the intended use cases. When
Brett Cannon wrote:
> On Thu, Mar 26, 2009 at 18:05, Terry Reedy wrote:
>> If one adds type annotations so that values can be unboxed, would not
>> Cython, etc, do even better for speedup?
>
> Nope as Unladen is planning to re-implement the eval loop, something Cython
> doesn't optimize without th
P.J. Eby wrote:
Could we at least have some syntax like 'return from yield with 43', to
distinguish it from a regular return, clarify that it's returning a
value to a yield-from statement, and emphasize that you need a
yield-from to call it?
You don't, though -- yield-from just happens to be
Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
Perhaps the exception used i
On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby wrote:
>> What I don't like is the confusion of adding "return values" to generators,
>> at least using the 'return' statement.
At Fri Mar 27 04:39:48 CET 2009, Guido van Rossum replied:
> I'm +1 on "yield from" and +0 on return values in generators.
>
On 26 Mar, 07:22 pm, ba...@python.org wrote:
One thing that /would/ be helpful though is the ability to list all
the resources under a specific package path. This is (I think) one
use case that pkg_resource fails to support and it's the one place
that I've had to drop down to file system intro
Nick Coghlan wrote:
Since correctly written generators are permitted to
convert GeneratorExit to StopIteration, the 'yield from' expression
should detect when that has happened and reraise the original exception.
I'll have to think about that a bit, but you're
probably right.
it is also neces
P.J. Eby wrote:
In particular, it should explain why these choices are so costly as to
justify new syntax and a complex implementation:
If avoiding trampolines was the only reason for
yield-from, that mightn't be enough justification
on its own. But it addresses several other use
cases as well.
P.J. Eby wrote:
And they *still* wouldn't be able to do away with their trampolines --
It's not really about doing away with trampolines anyway.
You still need at least one trampoline-like thing at the
top. What you do away with is the need for creating
special objects to yield, and the attend
Guido van Rossum wrote:
(Well here is Greg's requested use case for .send(). :-)
There was a complaint that my return-value-with-send
example was too much of a coroutine scenario, so I
was hoping to find something un-coroutine-like. But
if coroutines are the main uses for send in the first
pla
P.J. Eby wrote:
> As someone else suggested, moving some of the functionality to PEP 302
> interfaces would also help. Most of the code, though, deals with
> locating/inspecting installed distributions, resolving version
> requirements, and managing sys.path. And most of the nastiest
> complexit
On Thu, Mar 26, 2009 at 11:26 PM, Alexandre Vassalotti
wrote:
> On Thu, Mar 26, 2009 at 11:40 PM, Collin Winter wrote:
>> In fact, right now I'm adding a last few tests before putting our cPickle
>> patches up on the tracker for further review.
>>
>
> Put me in the nosy list when you do; and when
Olemis Lang wrote:
... well ... it is too long ... :-§ ... perhaps it is better this way ...
--lmdtbicdfyeiwdimoweiiiapiyssiansey ... :P
Isn't that the name of a town in Wales somewhere?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
On Thu, Mar 26, 2009 at 11:40 PM, Collin Winter wrote:
> In fact, right now I'm adding a last few tests before putting our cPickle
> patches up on the tracker for further review.
>
Put me in the nosy list when you do; and when I get some free time, I
will give your patches a complete review. I've
Guido van Rossum wrote:
Can I suggest that API this takes a glob-style pattern?
Globs would be nice to have, but the minimum
needed is some kind of listdir-like functionality.
Globbing can be built on that if need be.
--
Greg
___
Python-Dev mailing l
At 04:08 PM 3/27/2009 +1300, Greg Ewing wrote:
You can't expect to improve something like that by
stuffing yield-from into the existing framework, because
the point of yield-from is to render the framework
itself unnecessary.
But it doesn't. You still need *something* that processes the
yield
At 10:39 PM 3/26/2009 -0500, Guido van Rossum wrote:
That +0 could turn into a +1 if there was a way to flag this as an
error (at runtime), at least if the return is actually executed:
def g():
yield 42
return 43
for x in g():
print x# probably expected to print 42 and then 43
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> I'll gladly take that as an added rationalization of my plea not to
>> change datetime.
>
> In the case of datetime, could perhaps just the
> module name be changed so that it's not the same
> as a name inside the m
On Thu, Mar 26, 2009 at 8:05 PM, Terry Reedy wrote:
> An ars technica articla just linked to in a python-list post
>
> http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars
>
> calls the following project "Google launched"
> http://code.googl
On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby wrote:
> At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote:
>> There is some clear low-hanging fruit for Greg's proposal
>> where no trampoline or helpers are needed -- but where currently
>> refactoring complex code containing many yield statements is
>
On Thu, Mar 26, 2009 at 5:21 AM, Greg Ewing wrote:
> Here's a new draft of the PEP. I've added a Motivation
> section and removed any mention of inlining.
>
> There is a new expansion that incorporates recent ideas,
> including the suggested handling of StopIteration raised
> by a throw() call (i.
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to
change datetime.
In the case of datetime, could perhaps just the
module name be changed so that it's not the same
as a name inside the module? Maybe call it
date_time or date_and_time.
--
Greg
__
On Thu, Mar 26, 2009 at 18:05, Terry Reedy wrote:
> An ars technica articla just linked to in a python-list post
>
>
> http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars
>
> calls the following project "Google launched"
> http://code.goog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 10:07 PM, Guido van Rossum wrote:
If it really is a common habit to have single-file modules with
associated data files directly rooted under a namespace package, we
could change the API to allow passing in a module and have it b
On Thu, Mar 26, 2009 at 4:33 PM, P.J. Eby wrote:
> At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
>>
>> 2009/3/26 Barry Warsaw :
>> > BTW, under a better name, I would support putting pkg_resources in the
>> > stdlib.
>>
>> Last time I looked it was an incredibly complicated piece of code th
Antoine Pitrou wrote:
There seems to be a misunderstanding as to how generators
are used in Twisted. There isn't a global "trampoline" to schedule generators
around. Instead, generators are wrapped with a decorator (*) which collects each
yielded value (it's a Deferred object) and attaches to it
On Thu, Mar 26, 2009 at 6:49 PM, P.J. Eby wrote:
> At 11:27 PM 3/26/2009 +, Paul Moore wrote:
>>
>> What I'd really like is essentially some form of "virtual filesystem"
>> access to stuff addressed relative to a Python package name,
>
> Note that relative to a *Python package name* isn't quit
An ars technica articla just linked to in a python-list post
http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars
calls the following project "Google launched"
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
(Though the project
At 11:27 PM 3/26/2009 +, Paul Moore wrote:
What I'd really like is essentially some form of "virtual filesystem"
access to stuff addressed relative to a Python package name,
Note that relative to a *Python package name* isn't quite as useful,
due to namespace packages. To be unambiguous a
2009/3/26 Barry Warsaw :
> Let me clarify my position: I just want the functionality (preferably in the
> stdlib); I don't really care how it's spelled (except please not
> pkg_resource.whatever() :).
Agreed. My one major reservation is that conceptually, the whole
pkg_resource infrastructure seem
My notes from the "2 to 3 porting" session of Python Language Summit at
PyCon. There were some agreements in this session that people wanted
recorded. Happy to provide clarification in my notes aren't clear.
## python 2 to 3 migration
- 2to3 distutils flag (part of install or sdist)
- 2to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 3:14 PM, Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:53 PM, Barry Warsaw
wrote:
BTW, under a better name, I would support putting pkg_resources in
the
stdlib.
... or a subset of it ? or integrating its features with PE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 3:07 PM, Olemis Lang wrote:
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be helpful though is the
At 03:28 PM 3/26/2009 -0500, Guido van Rossum wrote:
2009/3/26 Barry Warsaw :
> BTW, under a better name, I would support putting pkg_resources in the
> stdlib.
Last time I looked it was an incredibly complicated piece of code that
would have to be refactored considerably before it would be
main
2009/3/26 :
> I'm trying to get the powers that be at work to enable post-commit hooks for
> our Subversion repositories. Here's the default, sans comments:
>
> REPOS="$1"
> REV="$2"
>
> commit-email.pl "$REPOS" "$REV" commit-watch...@example.org
> log-commit.py --repository "$REPOS"
At 12:27 PM 3/26/2009 -0700, Guido van Rossum wrote:
There is some clear low-hanging fruit for Greg's proposal
where no trampoline or helpers are needed -- but where currently
refactoring complex code containing many yield statements is
cumbersome due to the nee to write each "subroutine" call as
At 12:20 PM 3/26/2009 -0700, Guido van Rossum wrote:
By brittle I meant again having to be aware of those details of the
mechanism that exist because of syntactic limitations, e.g.
accidentally writing "return X" instead of "yield Return(X)".
In that case, you'd either have a syntax error under
I'm trying to get the powers that be at work to enable post-commit hooks for
our Subversion repositories. Here's the default, sans comments:
REPOS="$1"
REV="$2"
commit-email.pl "$REPOS" "$REV" commit-watch...@example.org
log-commit.py --repository "$REPOS" --revision "$REV"
Does
2009/3/26 Barry Warsaw :
> BTW, under a better name, I would support putting pkg_resources in the
> stdlib.
Last time I looked it was an incredibly complicated piece of code that
would have to be refactored considerably before it would be
maintainable by the core developers. I never did manage to
On Thu, Mar 26, 2009 at 3:03 PM, wrote:
>
> Tres> Exactly: I never use easy_isntall to put packages into the system
> Tres> python. in fact, I only use it inside a virtalenv-generated
> Tres> isolated environment.
>
> While standing in line for lunch today, someone (don't know his name)
On Thu, Mar 26, 2009 at 2:53 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>
>> {{{
>
> [x for x in dir(pkg_resources) if all(y in x for y in ['dir',
> 'resource_'])]
>>
>> ['resource_isdir', 'resource_list
On Thu, Mar 26, 2009 at 2:52 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
>
> One thing that /would/ be helpful though is the ability to list all the
> resources under a specific package path. This is (I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
s...@pobox.com wrote:
> Tres> Exactly: I never use easy_isntall to put packages into the system
> Tres> python. in fact, I only use it inside a virtalenv-generated
> Tres> isolated environment.
>
> While standing in line for lunch today,
Tres> Exactly: I never use easy_isntall to put packages into the system
Tres> python. in fact, I only use it inside a virtalenv-generated
Tres> isolated environment.
While standing in line for lunch today, someone (don't know his name)
suggested that easy_install needs an --i-am-an-i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Olemis Lang wrote:
> On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Barry Warsaw wrote:
>>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>>
For case one, where I want to
2009/3/26 Toshio Kuratomi :
> Guido van Rossum wrote:
>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>>> I think Distutils (and therefore Setuptools) should provide some APIs
>>> to play with special files (like resources) and to mark them as being
>>> special,
>>> no matter where they en
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
{{{
[x for x in dir(pkg_resources) if all(y in x for y in ['dir',
'resource_'])]
['resource_isdir', 'resource_listdir']
BTW, under a better name, I would support putting pkg_resources in the
st
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Barry Warsaw wrote:
>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>
>>> For case one, where I want to install additional functionality into my
>>> system Python interpreter "fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:43 PM, Olemis Lang wrote:
One thing that /would/ be helpful though is the ability to list
all the
resources under a specific package path. This is (I think) one
use case
that pkg_resource fails to support and it's the one pl
On Wed, Mar 25, 2009 at 8:36 AM, Tarek Ziadé wrote:
> On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote:
>> Paul Moore gmail.com> writes:
>>>
>>> 3. Setuptools, unfortunately, has divided the Python distribution
>>> community quite badly.
>>
>> Wait a little bit, and it's gonna be even worse
On Thu, Mar 26, 2009 at 2:47 PM, Olemis Lang wrote:
> On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Barry Warsaw wrote:
>>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>>
For case one, where I want to install addi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:41 PM, Tarek Ziadé wrote:
I think shutil.copytree new ignore mechanism handles this use case
pretty well (see the ignore_patterns factory in
http://docs.python.org/library/shutil.html)
Maybe we could use the same pattern.
Th
On Thu, Mar 26, 2009 at 2:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Barry Warsaw wrote:
>> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>>
>>> For case one, where I want to install additional functionality into my
>>> system Python interpreter "fo
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
>
>>> One thing that /would/ be helpful though is the ability to list all the
>>> resources under a specific package path. This is (I thi
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
>
>>> One thing that /would/ be helpful though is the ability to list all the
>>> resources under a specific package path. This is (I thi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Mar 25, 2009, at 6:06 PM, Tennessee Leeuwenburg wrote:
>
>> For case one, where I want to install additional functionality into my
>> system Python interpreter "forever", it would be great to have my
>> system
>> manage this.
On Thu, Mar 26, 2009 at 1:54 PM, Guido van Rossum wrote:
> 2009/3/26 Toshio Kuratomi :
>> Guido van Rossum wrote:
>>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
I think Distutils (and therefore Setuptools) should provide some APIs
to play with special files (like resources) and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
One thing that /would/ be helpful though is the ability to list all
the
resources under a specific package path. This is (I think) one use
case
that pkg_resource fails to support and it's the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tennessee Leeuwenburg wrote:
> I would suggest there may be three use cases for Python installation tools.
> Bonus -- I'm not a web developer! :)
> Case One: Developer wishing to install additional functionality into the
> system Python interpreter for
On Thu, Mar 26, 2009 at 12:22 PM, Barry Warsaw wrote:
> On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote:
>> 2009/3/26 Toshio Kuratomi :
>>> Depending on the definition of a "resource" there's additional
>>> information that could be needed. For instance, if resource includes
>>> message catal
On Thu, Mar 26, 2009 at 10:19 AM, P.J. Eby wrote:
> At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote:
>>
>> Guido van Rossum python.org> writes:
>> >
>> > That's stating it a little too strongly. Phillip has shown how with
>> > judicious use of decorators and helper classes you can get a
>> > re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Reedy wrote:
> 5. Much of this discussion reminds me of the debates between lumping and
> splitting of taxonomic categories in biology. Like that debate, it will
> continue forever.
Funny, I was thinking the same thing, only with respect to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 26, 2009, at 1:54 PM, Guido van Rossum wrote:
2009/3/26 Toshio Kuratomi :
Depending on the definition of a "resource" there's additional
information that could be needed. For instance, if resource includes
message catalogs, then being a
On Thu, Mar 26, 2009 at 10:07 AM, P.J. Eby wrote:
> At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote:
>> ISTR that the motivation for adding new syntax is that the best you
>> can do using a trampoline library is still pretty cumbersome to use
>> when you have to write a lot of tasks and subtas
2009/3/26 Toshio Kuratomi :
> Guido van Rossum wrote:
>> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>>> I think Distutils (and therefore Setuptools) should provide some APIs
>>> to play with special files (like resources) and to mark them as being
>>> special,
>>> no matter where they en
Guido van Rossum wrote:
> On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
>> I think Distutils (and therefore Setuptools) should provide some APIs
>> to play with special files (like resources) and to mark them as being
>> special,
>> no matter where they end up in the target system.
>>
>> So
At 10:56 AM 3/26/2009 +, Antoine Pitrou wrote:
Guido van Rossum python.org> writes:
>
> That's stating it a little too strongly. Phillip has shown how with
> judicious use of decorators and helper classes you can get a
> reasonable approximation, and I think Twisted uses something like
> thi
At 08:43 PM 3/26/2009 +1200, Greg Ewing wrote:
Trying to think of a better usage example that
combines send() with returning values, I've realized
that part of the problem is that I don't actually
know of any realistic uses for send() in the first
place.
Can anyone point me to any? Maybe it will
At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote:
ISTR that the motivation for adding new syntax is that the best you
can do using a trampoline library is still pretty cumbersome to use
when you have to write a lot of tasks and subtasks, and when using
tasks is just a tool for getting things d
On Wed, Mar 25, 2009 at 9:40 PM, Tarek Ziadé wrote:
> I think Distutils (and therefore Setuptools) should provide some APIs
> to play with special files (like resources) and to mark them as being special,
> no matter where they end up in the target system.
>
> So the code inside the package can us
David Cournapeau wrote:
>> I won't argue for setuptools' implementation of multi-version. It
>> sucks. But multi-version can be done well. Sonames in C libraries are
>> a simple system that does this better.
>
> I would say simplistic instead of simple :) what works for C won't
> necessarily wo
On Wed, Mar 25, 2009 at 6:08 PM, Barry Warsaw wrote:
> On Mar 25, 2009, at 11:35 AM, Olemis Lang wrote:
>
>> Yes you're right, Trac requires .egg files for local plugins installs
>> (... in /plugins folder ;) so that not all environments but only one
>> be able to use the plugin ... but that's not
On Thu, Mar 26, 2009 at 2:24 AM, Nick Coghlan wrote:
> Greg Ewing wrote:
>> Nick Coghlan wrote:
>>
>>> I think the main thing that may be putting me off is the amount of
>>> energy that went into deciding whether or not to emit Py3k warnings or
>>> DeprecationWarning or PendingDeprecationWarning f
2009/3/25 Tennessee Leeuwenburg :
> I would suggest there may be three use cases for Python installation tools.
> Bonus -- I'm not a web developer! :)
> Case One: Developer wishing to install additional functionality into the
> system Python interpreter forever
> Case Two: Developer wishing to inst
On Mar 25, 2009, at 11:02 PM, Nick Coghlan wrote:
That is, the full workflow that should really be happening is
something like the following:
Developer(s)
|
V
(distutils/setuptools/pip/zc.buildout/etc)
Greg Ewing wrote:
> Here's a new draft of the PEP. I've added a Motivation
> section and removed any mention of inlining.
I like this version a lot better - reading the two examples on your site
helped as well.
> There is a new expansion that incorporates recent ideas,
> including the suggested h
Guido van Rossum python.org> writes:
>
> That's stating it a little too strongly. Phillip has shown how with
> judicious use of decorators and helper classes you can get a
> reasonable approximation, and I think Twisted uses something like
> this, so it's not just theory. I think the best you can
Here's a new draft of the PEP. I've added a Motivation
section and removed any mention of inlining.
There is a new expansion that incorporates recent ideas,
including the suggested handling of StopIteration raised
by a throw() call (i.e. if it wasn't the one thrown in,
treat it as a return value)
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> I think the main thing that may be putting me off is the amount of
>> energy that went into deciding whether or not to emit Py3k warnings or
>> DeprecationWarning or PendingDeprecationWarning for use of the old
>> threading API.
>
> Having made that de
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Although the PEP may still want to mention how one would write *tests*
>> for these things. Will the test drivers themselves need to be generators
>> participating in some kind of trampoline setup?
>
> I don't see that tests are fundamentally different
Le Thursday 26 March 2009 04:58:51 Tarek Ziadé, vous avez écrit :
> - Here are the first results for the packaging survey:
> http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first-results/
How do you remove a package ?
Wow, 275 hits for "manually" and 79 for "fail at uninstallation"
Trying to think of a better usage example that
combines send() with returning values, I've realized
that part of the problem is that I don't actually
know of any realistic uses for send() in the first
place.
Can anyone point me to any? Maybe it will help
to inspire a better example.
--
Greg
Nick Coghlan wrote:
Although the PEP may still want to mention how one would write *tests*
for these things. Will the test drivers themselves need to be generators
participating in some kind of trampoline setup?
I don't see that tests are fundamentally different
from any other code that wants
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of
energy that went into deciding whether or not to emit Py3k warnings or
DeprecationWarning or PendingDeprecationWarning for use of the old
threading API.
Having made that decision, though, couldn't the result
Guido van Rossum wrote:
That's all good. I just don't think that a presentation in terms of
code in-lining is a good idea.
I was trying to describe it in a way that would give
some insight into *why* the various aspects of the
formal definition are the way they are. The inlining
concept seemed
86 matches
Mail list logo
