> I would do what Barry suggests: rephrase the module to document the
> deprecation/removal procedure. This, of course, needs
> consensus/pronouncement, too, but I think I would put the following
> aspects into it:
>
> Requirements
>
> Removal of module needs proper advance warning fo
One other thought: In deciding how long to leave module in, we should
consider that Python books are updated infrequently, if at all. It
would be a bummer if code in them stopped working as advertised.
Raymond
___
Python-Dev mailing list
[EMAIL PRO
> I'm happy to adjust details of the procedures - but it seems we
disagree
> on the principles.
Not really. I have no objection to making module deprecation/removal
rare or even not doing it at all. Personally, I've never asked for a
module deprecation and don't expect to.
I also agree that m
There is one other issue that should get addressed, modules in limbo.
I'm concerned about the old email modules. They haven't been deprecated
and may stay around for a good while. However, some SF requests have
been passed over on the basis that the modules are supplanted and will
be phased out.
> > Instead, there should be a clear decision to deprecate or not. If
that
> > entails a comp.lang.python.announce notice and comment period, so be
it.
> > Once a decision is made, document it, add a warning, and wait.
>
> Ok, that might be reasonable.
Please word the PEP accordingly.
> > Once
> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to fight -- any ideas?
* Ask a prominent PSF member,
Acceptance for Py2.4 partially hinges on how quickly third party apps
have their binaries updated.
I wonder if there is anything we can do to help.
Raymond
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Tuure Laurinolli
Sent: Tuesday, December 07, 20
The Dec 12th check-ins break tests on WinME:
test_glob.py
Traceback (most recent call last):
File "test_glob.py", line 78, in test_glob_one_directory
eq(self.glob('a*'), map(self.norm, ['a', 'aab', 'aaa']))
File "test_glob.py", line 67, in assertSequencesEqual_noorder
sel
> So how about a slogan like "Code it Fast, with Python", or "Python:
Code
> Fast" -- one which emphasizes the (easily defended) claim that
development
> time is shorter with Python, but which at the same time manages to
> associate the word "fast" with "Python".
I always liked: "Python, the lang
> The Wiki entry seems to reinforce the impression that bugged Guido to
> begin with. It provides a bunch of "but ..." explanations about why
> Python's speed isn't that important. Python is slow, but "speed of
> development is far more important."
I felt the same way when reading it. Also, it
> > FWIW, the tests at issue pass on WinXP for me today w/ current CVS.
Tests pass here too.
Raymond
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
[Armin]
> Crash. Which means that there is no way in 2.4.0 to marshal an object
in the
> > old version format as a string -- you'd have to work around by
writing a real
> > file and reading it back :-(
[Aahz]
> Brown bag time?
Perhaps a rather quick Py2.4.1 would be in order.
Ideally, it shoul
> Raymond Hettinger wrote:
> > Perhaps a rather quick Py2.4.1 would be in order.
> >
> > Ideally, it should include other important fixes:
> [...]
> > * Fix for off-by-one bug in urllib.URLopener.retrieve
> >http://www.python.org/sf/810023
> >(ass
[Reinhold Birkenfeld]
> just felt a little bored and tried to review a few (no-brainer) patches.
Thanks, please assign to me and I'll apply them.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
[Guido van Rossum]
> > Let's get rid of unbound methods.
+1
[Jim Fulton]
> duck typing?
Requiring a specific interface instead of a specific type.
[Guido]
> > Does anyone think this is a bad idea?
[Jim]
> It *feels* very disruptive to me, but I'm probably wrong.
> We'll still need unbound
Would it be helpful for me to move the peepholer out of compile.c into a
separate source file?
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
omp_size, filenamesize, extra_size = fields
filename = g.getgroup('c', offset=16, times=filenamesize)
extra = g.getgroup('c', times=extra_size)
r.advance(comp_size)
print filename, hex(crc32), comp_size, uncomp_size
[Ilya Sandler]
> I view struct module as a low-level (un)packing library on top on
which
> a more complex stuff can be built and I am simply suggesting a way to
> improve this low level functionality...
> > > We could have an optional offset argument for
> > >
> > > unpack(format, buffer, offset=No
> Instead, I would suggest that even a very limited initial
> implementation of StructReader() like object suggested by Raymond
would
> be more useful...
I have a draft patch also.
Let's work out improvements off-list (perhaps on ASPN).
Feel free to email me directly.
Raymond
__
est of the
CSV module because it also accepts/returns a list of fieldnames and a
sequence of records.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/362715
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
lso, it is not clear to me how or if existing manual adaption practices
should change. For example, if I need a file-like interface to a
string, I currently wrap it with StringIO. How will that change it the
future? By an explicit adapt/conform pair? Or by strings knowing how
to conform to fil
adapters
> think a bit more about the kind of adapter that they are providing.
Using optional arguments may not be the most elegant or extensible
approach. Perhaps a registry table or adapter attributes would fare
better.
Raymond Hettinger
___
Py
[Alex]
> So, as per discussion here, I have prepared a patch (to the
maintenance
> branch of 2.3, to start with) which adds unit tests to highlight these
> issues, and fixes them in copy.py. This patch should go in the
> maintenance of 2.3 and 2.4, but in 2.5 a different approach based on
> new sp
[Guido van Rossum]
> There's one other problem that Phillip tries to tackle in his
> proposal: how to implement the "rich" version of an interface if all
> you've got is a partial implementation (e.g. you might have readline()
> but you need readlines()). I think this problem is worthy of a
> solut
pack the temporary argument tuple.
Even then, I don't see how to overcome the need to set useful default
values for optional object arguments.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> > In theory, I don't see how you could improve on METH_O and METH_NOARGS.
> > The only saving is the time for the flag test (a predictable branch).
> > Offsetting that savings is the additional time for checking min/max args
> > and for constructing a C call with the appropriate number of args.
> [Anthony Baxter]
> > I didn't see any replies to the last post, so I'll ask again with a
> > better subject line - as I said last time, as far as I'm aware, I'm
> > not aware of anyone having done a fix for the issue Tim identified
> > ( http://www.python.org/sf/1069160 )
> >
> > So, my question
> Iterators are for single sequential access. It's a feature that you
> have to import itertools (or at least that you have to invoke its
> special operations) -- iterators are not sequences and shouldn't be
> confused with such.
FWIW, someone (Bengt Richter perhaps) once suggested syntactic suppo
[Anthony Baxter]
> >>> I'm
> >>> not aware of anyone having done a fix for the issue Tim identified
> >>> ( http://www.python.org/sf/1069160 )
[Raymond Hettinger]
> > Any chance of this getting fixed before 2.4.1 goes out in February?
[Timbot]
&
> I agree that METH_O and METH_NOARGS are near
> optimal wrt to performance. But if we could have one METH_UNPACKED
> instead of 3 METH_*, I think that would be a win.
. . .
> Sorry, I meant eliminated w/3.0.
So, leave METH_O and METH_NOARGS alone. They can't be dropped until 3.0
and they can'
> Last August, James Knight posted to python-dev, "There's a fair number
> of classes that claim they are defined in __builtin__, but do not
> actually appear there". There was a discussion and James submitted
> this patch:
>
>
http://sourceforge.net/tracker/index.php?func=detail&aid=1009811&group
[James Y Knight]
> > Basically, I'd like to see them be given a binding somewhere, and
have
> > their claimed module agree with that, but am not particular as to
> > where. Option #2 seemed to be rejected last time, and option #1 was
> > given approval, so that's what I wrote a patch for. It sounds
> > Basically, I'd like to see them be given a binding somewhere, and
have
> > their claimed module agree with that, but am not particular as to
where.
>
> I think I cannot agree with this as a goal regardless of the
consequences.
Other than a vague feeling of completeness is there any reason thi
Neal Norwitz
> I thought about making a p3k branch in CVS
I had hoped for the core of p3k to be built for scratch so that even the
most pervasive and fundamental implementation choices would be open for
discussion:
* Possibly write in C++.
* Possibly replace bytecode with Forth style threaded co
[Anthony]
> While this is undoubtedly a bug fix, I'm not sure that it should be
> backported - it will break people's code that is "working" now (albeit
> in a faulty way). What do people think?
I concur -- the balance of risks is towards the patch causing more harm
than good.
Raymond
_
> Would it be possible to release a 2.3.4a that has just the fix over
and
> above the released version? In this case it turns out that the fix
nearly
> coincided with the release of 2.3.5 and 2.4.1. Would you do an
> accelerated
> release if this had come up right after they were released?
Just
[Skip]
> If lists are conceptually like vectors or
> arrays
> in other languages and tuples are like C structs or Pascal records,
then
> by
> converting from list to tuple form you've somehow muddied the data
> structure
> water just to take advantage of tuples' immutability.
In the context of lit
[Neal]
> I think I implemented this once. I'll try to see if I can find a
> patch. It wasn't too difficult, but I'm not sure if the patch was
> clean.
If the opportunity arises, another worthwhile peepholer buildout would
be to recognize if-elif chains that can be transformed to a single
lookup
> Modified Files:
> Tag: release23-maint
> test_copy.py
> Log Message:
> fix bug 1114776
Don't forget release24-maint.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
Any objections to replacing the likes of types.IntType and
types.ListType with int and list?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/optio
The most recent test_codecs check-in (1.19) is failing on a MSCV6.0
compilation running on WinMe:
--
Ran 35 tests in 1.430s
FAILED (failures=1)
Traceback (most recent call last):
File "\py25\lib\test\test_codecs.py", line 786,
xcept TypeError:
self.dict = None
def __contains__(self, key):
try:
return key in self.dict
except TypeError:
return tuple.__contains__(self, key)
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Nick Coghlan]
> If itertools was a hybrid module, the handy 3-4 liners could go in the Python
> section, with the heavy lifting done by the underlying C module. The Python
> equivalents to the current C code could also be placed in the hybrid module
> (as
> happens with some of the other hybrid m
> but refactoring the contains code to use find_internal sounds like a
good
> first step. any takers?
>
>
I'm up for it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
> Let's keep the really long-running tests out
> of the regular test suite.
For test_subprocess, consider adopting the technique used by
test_decimal. When -u decimal is not specified, a small random
selection of the resource intensive tests are run. That way, all of the
tests eventually get run
ct.
This is a more complicated than the original frozenset version of the
patch, so I would like to get feedback on whether you guys think it is
worth it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
> I'm unclear why the list in "for x in [1,2,3]" or "if x not in
[1,2,3]"
> can't fairly easily be recognized as a constant and just be placed in
the
> constants array.
That part got done (at least for the if-statement).
The question is whether the type transformation idea should be carried a
st
> > Raymond then
> translated
> >
> > for x in [1,2,3]:
> >
> > to
> >
> > for x in frozenset([1,2,3]):
That's not right. for-statements are not touched.
> I may be missing something here (didn't follow the whole thread) but
> those two are not functionally equal.
> The docstring on fro
> Wouldn't it help a lot more if the compiler would detect that
> (1,2,3) is immutable and convert it into a constant at
> compile time ?!
Yes. We've already gotten it to that point:
Python 2.5a0 (#46, Feb 15 2005, 19:11:35) [MSC v.1200 32 bit (Intel)] on
win32
>>> import dis
>>> dis.dis(compile
> >>Wouldn't it help a lot more if the compiler would detect that
> >>(1,2,3) is immutable and convert it into a constant at
> >>compile time ?!
> >
> >
> > Yes. We've already gotten it to that point:
. . .
>
> Cool. Does that work for all tuples in the program ?
It is limited to just tuples of
> I'm very glad you introduced the optimization of building small
> constant tuples at compile-time. IMO, that was a pure win.
It's been out in the wild for a while now with no issues. I'm somewhat
happy with it.
> the transformation isn't semantically correct on the
> face of it.
Well that
> > This is something I've typed way too many times:
> >
> > Py> class C():
> > File "", line 1
> > class C():
> > ^
> > SyntaxError: invalid syntax
> >
> > It's the asymmetry with functions that gets to me - defining a
> > function with no arguments still requires parentheses in
> > > This is something I've typed way too many times:
> > >
> > > Py> class C():
> > >File "", line 1
> > > class C():
> > > ^
> > > SyntaxError: invalid syntax
> > >
> > > It's the asymmetry with functions that gets to me - defining a
> > > function with no arguments still r
I noticed that UserString objects have methods that do not accept other
UserString objects as arguments:
>>> from UserString import UserString
>>> UserString('slartibartfast').count(UserString('a'))
Traceback (most recent call last):
File "", line 1, in -toplevel-
UserString('slartibartfas
n the standard library and test suite.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> Where are the attempts to speed up function/method calls? That's an
> area where we could *really* use a breakthrough...
At one time you had entertained treating some of the builtin calls as
fixed. Is that something you want to go forward with? It would entail
a "from __future__" and transitio
Paul Moore wrote:
> Personally, I'd rather see partial as it stands, with its current
> limitations, included. The alternative seems to be a potentially long
> discussion, petering out without conclusion, and the whole thing
> missing Python 2.5. (I know that's a long way off, but this already
> h
> But this all reminds me of the discussion
> over itemgetter/attrgetter. They also special-case particular uses of
> lambda, and in those cases the stated benefits were speed and
> (arguably) readability (I still dislike the names, personally).
I wouldn't use those as justification for partial().
> I did a quick experiment:
>
> >python -m timeit -s "from operator import itemgetter; l=range(8)"
> "itemgetter(1)(l)"
> 100 loops, best of 3: 0.548 usec per loop
>
> >python -m timeit -s "l=range(8)" "(lambda x:x[1])(l)"
> 100 loops, best of 3: 0.597 usec per loop
>
> That's far less o
> > Are you sure about that? Contriving examples is easy, but download
a
> > few modules, scan them for use cases, and you may find, as I did,
that
> > partial() rarely applies. The argument order tends to be
problematic.
>
> So would you like to see the decision to accept PEP 309 reverted?
I w
> > Along the way, they should assess whether
> > it is as applicable as expected, whether the existing limitations
are
> > problematic, and whether performance is an issue.
>
> Ah, so you question the specification, not the implementation of it.
My only issue with the PEP is that it seemed much
[Martin]
> It seems to me that the patch will be committed shortly, assuming
> somebody corrects the remaining flaws in the implementation. I could
> do that, but I would prefer if somebody contributed an updated patch.
Done.
Raymond
___
Python-Dev ma
[Peter Harris]
> I look forward to the day when I can just use it.
You PEP is marked as final. The code has been checked in to CVS and
will be in Py2.5.
Congrats,
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
h
> A recent question on c.l.p pointed out that the 2.4 Decimal
implementation
> raises TypeError directly for operator arguments it doesn't
understand,
> instead
> of returning NotImplemented.
>
> Obviously, this creates problems for anyone trying to define a class
that
> 'plays
> nicely' with Deci
> Nick Coghlan writes:
> > I'm actually half-tempted to suggest that [map, filter and reduce]
> should be
> > aliased in the functional module for 2.5 (in addition to being in
> builtins -
> ala
> > the contents of the exceptions module).
>
> Well, I think it's a good idea, so I'll formally propos
> > SF bug #1155938: Missing None check for __init__().
>
> Won't this break working (but erroneous) code? If so,
> should it be applied to the 2.4 branch?
Hmm, more than one poster found the error message to be helpful in
detecting buggy code. The non-None return value was a pretty good
indicat
, rank, proficiency
sorted(soldierdata, key=attrgetter('unit', 'rank', 'proficiency'))
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
> Michael Chermside suggested:
> import warnings
>
> def deprecated(func):
> """This is a decorator which can be used to mark functions
> as deprecated. It will result in a warning being emmitted
> when the function is used."""
> def newFunc(*args, **kwargs)
[Aahz]
> Gee, I just found out I could have used an OrderedDict today. (We're
> using a dict that we're now having to add an auxilliary list to to
track
> when keys are added.) (This isn't particularly an argument in favor
of
> adding OrderedDict to stdlib, but it's another use case. Each dict
k
> > If I read the proposal correctly, order would be determined by when
the
> > key was first encountered. Presumably, that would mean that the
related
> > value would also be the first encountered (not overridden by
later-added
> > keys as dictated by your business requirements).
>
> Hm
to a regular
dictionary before ordereddict sees it.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
any
thoughts on the design.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
icate. Also, it avoids the kind of errors/confusion that people
currently experience with Python's unique implementation of "and" and
"or".
Returning the last element is not evil; it's just weird, unexpected, and
non-obvious. Resist the urge to get tricky with
> BTW I definitely expect having to defend removing
> map/filter/reduce/lambda with a PEP; that's much more controversial
> because it's *removing* something and hence by definition breaking
> code.
I suspect that lambda will be the only bone of contention. The reduce()
function can be moved to
[Alex]
> If you're considering revisions to sum's design, my suggestion would
be
> to find a way to let the user tell sum to use a more accurate approach
> when summing floats.
FWIW, when accuracy is an issue, I use:
sum(sorted(data, key=abs))
Raymond
__
[Alex]
> > FWIW, when accuracy is an issue, I use:
> >
> >sum(sorted(data, key=abs))
>
> ...and you may still lose a LOT of accuracy that way:-(.
>
> Raymond, you technically reviewed the 2nd ed Cookbook -- don't you
> recall the sidebar about why partials are the RIGHT way to do
> summations
m.itervalues(), key=abs), 0.0)
The implementation can be tweaked to consume the error term right away
so the queue won't grow by more than few pending items. Also, the speed
can be boosted by localizing frexp, exp2sum.pop, and queue.append.
> the queue can be expected to grow to about half the length
> of the original iterable by the time the original iterable is
> exhausted.
>
> >x = z
> >mant, exp = frexp(x)
> >exp2sum[exp] = x
> >return sum(sorted(exp2sum.itervalues(), key=abs), 0.0)
> >
> > The
[GvR]
> > - Before anybody asks, I really do think the reason this is
requested
> > at all is really just to save typing; there isn't the "avoid double
> > evaluation" argument that helped acceptance for assignment operators
> > (+= etc.), and I find redability is actually improved with 'for'.
{Ne
> OTOH 0 is more compatible and None is a strong candidate too...
None is useless as a default return value for summation. Any code
outside the summation would have to explicitly test for that value.
Stick with zero. Theoretical musings are no reason to make this
function hard to use.
> But I'
lity to descend through nested iterables (similar to
what os.walk does for directories). The one wrinkle is having a
stoplist argument to specify types that should be considered atomic
eventhough they might be iterable (strings for example).
Raymond Hettinger
___
[Tim]
> For contrast, here's one that doesn't use frexp(), and is probably
> faster because of that; internally, len(sums) probably won't exceed 5
> in real life (but could get as large as 2K for pathological inputs,
> spanning fp's full dynamic range):
>
> def summer4(iterable):
> sums = [0.0
> I'm happy to announce the release of Python 2.4.1 (final).
Woohoo!
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40
> Tag: release24-maint
> handlers.py
> Log Message:
> Added optional encoding argument to File based handlers and improved
error
> handling for SysLogHandler
Are you sure you want to backport an API change and new feature?
Raymond
___
Pytho
ns so he can help manage outstanding bugs and patches.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%4
Does anyone know what has become of the following developers and perhaps
have their current email addresses? Are any of these folks still active
in Python development?
Ben Gertzfield
Charles G Waldman
Eric Price
Finn Bock
Ken Manheimer
Moshe Zadka
Raymond Hettinger
> [Raymond Hettinger]
> > Does anyone know what has become of the following developers and
perhaps
> > have their current email addresses?
[Tim Peters]
> How about we exploit that if someone is a Python developer on SF, they
> necessarily have an SF email address ($(SFNAME)@
bjects:
>>> class Boom(Exception):
pass
>>> x = 10
>>> if x != 5:
raise Boom("Value must be a five", x)
Traceback (most recent call last):
File "", line 2, in -toplevel-
raise Boom("Value must be a five", x)
Bo
[Nick Coghlan]
> Are context diffs still favoured for patches?
>
> The patch submission guidelines [1] still say that, but is it actually
> true
> these days? I personally prefer unified diffs, but have been
generating
> context
> diffs because of what the guidelines say.
Submit whichever is the
am of Steve Bethard, Tim Lesher,
> and Tony Meyer. We're trying a collaborative approach to the
> summaries: each fortnight, we'll be getting together in a virtual
> smoke-filled back room to divide up the interesting threads.
Both your process and
lementation */
_PyUnicode_Fini();
#endif
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
lear-cut way to know which should be removed when
unregister() is called.
Likewise, I suspect that exposing the stack will create more pitfalls
and risks than it could provide in benefits. Dealing with a stack of
functions is likely to be clumsy at best.
Raymond Hettinger
__
[Raymond Hettinger]
> << Will mull it over for a while. My first impression is that
try/finally
> is a better tool for the scenario you outlined. >>
[Nick Jacobson]
> You're right. try/finally takes care of my sample scenario. There
may
> still be a case to
I haven't heard back from Greg Stein, Jim Fulton, or Paul Prescod.
If anyone can get in touch with them, that would be great.
I suspect that Jim may want to keep the commit privileges active
and that Paul and Greg are done with commits for the time being.
Raymond Hett
Thanks for the note.
Let me know if you need to be switched on again at some point.
Raymond Hettinger
> -Original Message-
> From: Paul Prescod [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 30, 2005 4:39 PM
> To: Raymond Hettinger
> Cc: python-dev@python.org
> Su
I just made a first reading of the PEP and want to clarify my
understanding of how it fits with existing concepts.
Is it correct to say that "continue" parallel's its current meaning and
returns control upwards (?outwards) to the block iterator that called
it?
Likewise, is it correct that "yield"
[Raymond]
> > Likewise, is it correct that "yield" is anti-parallel to the current
> > meaning? Inside a generator, it returns control upwards to the
caller.
> > But inside a block-iterator, it pushes control downwards (?inwards)
to
> > the block it controls.
[Guido van Rossum]
> I have a hard ti
> > In contrast, the new use of yield differs in that the suspended
frame
> > transfers control from the encloser to the enclosed.
>
> Why does your notion of who encloses whom suddenly reverse when you go
> from a for-loop to a block-statement? This all feels very strange to
> me.
After another
> But there are several separable proposals in the PEP. Using "continue
> EXPR" which calls its.__next__(EXPR) which becomes the return value of
> a yield-expression is entirely orthogonal (and come to think of it the
> PEP needs a motivating example for this).
>
> And come to think of it, using a
> it's not infeasible to add a close() method to
> generators as a shortcut for this:
>
> def close(self):
> try:
> self.__exit__(StopIteration)
> except StopIteration:
> break
> else:
> # __exit__() didn't
> raise Runtime
1001 - 1100 of 1487 matches
Mail list logo
