Re: [Python-3000] lambda

Olivier Verdier wrote: > On 26/03/2008, *Nick Coghlan* <[EMAIL PROTECTED] > Lambda calculus is a > well established field of mathematics, so it's a perfectly valid name > for the construct. > > In my university in Sweden lambda calculus is never taught neither in > pure nor applied m

Re: [Python-3000] Using *a for packing in lists and other places

Thomas Wouters wrote: > > On Sat, Mar 15, 2008 at 2:58 PM, Terry Reedy <[EMAIL PROTECTED] > > wrote: > > | Also, yielding everything from an iterator: > | > | >>> def flatten(iterables): > | ... for it in iterables: > | ... yield *it > >

Re: [Python-3000] ABC for Inequalities

Guido van Rossum wrote: > On Feb 11, 2008 7:31 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> [GvR] >>> The problem is that if you have two instance x, >>> y such that isinstance(x, TotalOrdering) and isinstance(y, >>> TotalOrdering) you still don't know if x < y is defined. (For example, >>>

Re: [Python-3000] Thoughts on collections.Container and collections.Iterable

Neil Toronto wrote: > Guido van Rossum wrote: >> I would need to think more about this. I'm tempted not to do this, and >> let these ABCs denote the *explicit* presence of __contains__ and >> __iter__, respectively. Something that's iterable but doesn't >&g

Re: [Python-3000] Thoughts on collections.Container and collections.Iterable

Guido van Rossum wrote: > I would need to think more about this. I'm tempted not to do this, and > let these ABCs denote the *explicit* presence of __contains__ and > __iter__, respectively. Something that's iterable but doesn't > implement __contains__ supports the 'in' operator very inefficiently

Re: [Python-3000] Armin's attribute lookup caching for 3.0

Neil Toronto wrote: > Phillip J. Eby wrote: >> That having been said, the idea that the statement 'SomeBaseClass.foo = >> 23' is actually going to walk through cache entries and invoke a >> callback for *every* subclass of SomeBaseClass in the program makes me a

Re: [Python-3000] Armin's attribute lookup caching for 3.0

Phillip J. Eby wrote: > At 12:14 PM 12/7/2007 -0700, Neil Toronto wrote: >> I found updating caches from setattr to be faster than invalidating >> entries. > > Really? Even on the SpecialClassAttribute test? I'd have assumed that > Armin's invalidation flag

[Python-3000] Armin's attribute lookup caching for 3.0

I couldn't help myself. Such a beautiful thing had to be spread, and it was *easy* to put it in 3.0 because types are simpler. A patch is here: http://bugs.python.org/issue1568 If users are going to be encouraged to subclass from the ABC hierarchy for new container and numeric types, they'

Re: [Python-3000] bytes and dicts (was: PEP 3137: Immutable Bytes and Mutable Buffer)

Jim Jewett wrote: > On 9/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > >> The question is whether it's worth the effort to raise TypeError when >> the *potential* exists that a certain hash sequence *could* raise this >> TypeError. >> > > Bugs depending on the hash sequence are exa

Re: [Python-3000] Python-love (was Release 3.0a1 Countdown)

Guido van Rossum wrote: > Thanks everyone for the large number of improvements that came in this week! Can I echo this in general? I just lurk here, being fascinated by the distributed language development process, so I don't have much license to post and steal precious developer attention. But

Re: [Python-3000] Immutable bytes type and dbm modules

Greg Ewing wrote: > Guido van Rossum wrote: > >> That would imply that b"..." should return a mutable bytes object, >> which many people have objected to. >> > > I'm still very uncomfortable about this. It's so > completely unlike anything else in the language. > I have a strong feeling tha

Re: [Python-3000] Announcing PEP 3136

Giovanni Bajo wrote: > On 03/07/2007 9.17, Neil Toronto wrote: > >> Greg Ewing wrote: >> >>> On 30/06/2007 22.54, Matt Chisholm wrote: >>> >>> >>> >>>> I've created and submitted a new PEP proposing support fo

Re: [Python-3000] Announcing PEP 3136

Greg Ewing wrote: > On 30/06/2007 22.54, Matt Chisholm wrote: > > >> I've created and submitted a new PEP proposing support for labels in >> Python's break and continue statements. >> >> http://www.python.org/dev/peps/pep-3136/ >> > > -1. Confusing nested loops are best broken out into > se

Re: [Python-3000] Python 3000 Status Update (Long!)

Andrew McNabb wrote: > On Fri, Jun 22, 2007 at 01:32:42PM -0600, Neil Toronto wrote: > >>> (imap is faster in this case because the built-in name 'abs' is looked >>> up only once -- in the genexp, it's looked up each time, sigh -- >>> possibly the

Re: [Python-3000] Python 3000 Status Update (Long!)

Alex Martelli wrote: > $ python -mtimeit -s'import itertools as it' -s'L=range(-7,17)' 'for x > in it.imap(abs,L): pass' > 10 loops, best of 3: 3 usec per loop > $ python -mtimeit -s'import itertools as it' -s'L=range(-7,17)' 'for x > in (abs(y) for y in L): pass' > 10 loops, best of 3: 4.4

Re: [Python-3000] PEP 3131 accepted

Josiah Carlson wrote: > Thank you for hitting home that unless people use Emacs, their tools > arent sufficient for Python development. I still don't believe that my > concerns have been addressed. And I certainly don't believe that those > Ka-Ping brought up (which are better than mine) have been

Re: [Python-3000] Wither PEP 335 (Overloadable Boolean Operators)?

Giovanni Bajo wrote: > On 19/05/2007 3.21, Guido van Rossum wrote: > While reviewing PEPs, I stumbled over PEP 335 ( Overloadable Boolean Operators) by Greg Ewing. It is time to reject it due to lack of interest, or revive it! >>> Didn't you post something about

Re: [Python-3000] Support for PEP 3131 - discussion on python zope users group

Guillaume Proux wrote: > Hello, > > Just to let you know that a discussion on japanese python users group > is going on regarding this issue. > > Most people feel like the PEP3131 would be a welcome addition. > -> some people point out the fact that special characters like the > greek letters would

Re: [Python-3000] Poll: Lazy Unicode Strings For Py3k

Paul Prescod wrote: > String concatenation is a known issue in Python programming and > workarounds for it are common obfuscations in a language otherwise > famous for being clean. So I vote +1 on it. I abstain on slicing. > Seconded: +1 on concatenation, no opinion on the rest. It'd be great t

Re: [Python-3000] self-contained exceptions

Guido van Rossum wrote: > On 1/4/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >> At 01:41 AM 1/4/2007 -0600, Ka-Ping Yee wrote: >> >>> How about this? >>> >>> except ExcType, e: >>> try: >>> # body >>> finally: >>> e = None >>> >> I

Re: [Python-3000] iostack and Oh Oh

Guido van Rossum wrote: > That sounds like a reasonable summary to me. One nit below. > Ditto. It was nice to see all the ambiguity cleared up in one fell swoop. Nicely done. > On 12/7/06, Talin <[EMAIL PROTECTED]> wrote: > >> [2] The reason I think 'interface' are misleading is due to its

Re: [Python-3000] how about switching to a preprocessor? (Re: A better way to initialize PyTypeObject)

Barry Warsaw wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Dec 2, 2006, at 3:58 PM, Neil Toronto wrote: > > >> One potential problem with this idea is that you can't drop into C >> code >> without calling an external C functio

Re: [Python-3000] how about switching to a preprocessor? (Re: A better way to initialize PyTypeObject)

Fredrik Lundh wrote: > Brett Cannon wrote: > > >> So you are basically saying you want the preprocessor step to be >> lightweight enough that you always develop with the file before the >> preprocessor is run instead of with some generated file, right? >> > > exactly. the developer shoul

Re: [Python-3000] Builtin iterator type

Guido van Rossum wrote: > I realize that Java- and Zope-style interfaces *seem* to be all about > syntax (they define names and signatures of methods but not semantics) > but IMO that's only a theoretical objection; in *practice* these > interfaces have strong connotations of semantics (albeit writ

Re: [Python-3000] Draft PEP for outer scopes

Josiah Carlson wrote: >"Michael Urman" <[EMAIL PROTECTED]> wrote: > > >>I personally expect that while there is a theoretical clash between >>variable names in nested scopes, that's already a poor coding >>decision. The module level globals should not unintentionally collide >>with function-loca

Re: [Python-3000] The meaning of "global variable"

Greg Ewing wrote: >Mike Krell wrote: > > >> This is also why I advocate the spelling "use", because >>ISTM "use x" pretty much means exactly what it says. >> >> > >I beg to differ -- it means nothing at all to >me. At least "global" or "nonlocal" sound like >they have *something* to do with

Re: [Python-3000] Draft PEP for outer scopes

Greg Ewing wrote: > Ka-Ping Yee wrote: > > >> nonlocal x = y = 0 >> >> is equivalent to >> >> nonlocal x; x = y = 0 >> > > This is far from obvious. And what happens if > you want both x and y to be nonlocal? Can you > write > >nonlocal x = nonlocal y = 0 > > If so, this is gett

Re: [Python-3000] Draft PEP for outer scopes

Ka-Ping Yee wrote: > Hi folks, > > I have finally completed a draft of a PEP on rebinding of names > in outer scopes. I've tried to go back and gather all of the > (amazingly numerous) proposals -- if i've forgotten or misattributed > any, let me know and i'll be happy to correct them. > > I look

Re: [Python-3000] The meaning of "global variable"

Ron Adam wrote: > Mike Krell wrote: > >>> How about [...] using 'parent' as the keyword? >>> >> I once proposed 'parent' in a similar thread a long time ago. >> >> It's a non-starter because it's a commonly used variable name. >> >>Mike >> > > > I thought it might be. > > How abo

Re: [Python-3000] Draft PEP for outer scopes

Ka-Ping Yee wrote: > Hi folks, > > I have finally completed a draft of a PEP on rebinding of names > in outer scopes. I've tried to go back and gather all of the > (amazingly numerous) proposals -- if i've forgotten or misattributed > any, let me know and i'll be happy to correct them. > > I look

Re: [Python-3000] Alternatives to 'outer'

Aahz wrote: > Did anyone else think "outies" and "innies" when reading the Subject: > line? > The real question is who didn't? Um, to put this back on track, by analogy, uh... outies are less frequent in the general population, just like they should be in code. Or something. Steven Bethard

Re: [Python-3000] Sky pie: a "var" keyword

Nick Coghlan wrote: >> The only sane proposal i've seen that consistently addresses all >> these cases, doesn't create new ambiguous situations, and doesn't >> break most existing Python code is the "nonlocal" declaration. >> >> nonlocal x >> >> means >> >> "Don't make a new binding for x i

Re: [Python-3000] ugly pie: a "var" keyword

Antoine Pitrou wrote: > Le lundi 09 octobre 2006 à 12:49 +0200, Georg Brandl a écrit : > >> They wouldn't be "local" unless declared with "var", I assume. >> > > Besides, in a well-written program, you will mostly access local > variables (and attributes and methods), so let's make the clea

Re: [Python-3000] Sky pie: a "var" keyword

Neil Toronto wrote: > Marcin 'Qrczak' Kowalczyk wrote: > >> It should be: >> >> var x = 0 >> def f(): >>print x >>x = 3 >> >> for the global variable, and: >> >> var x = 0 >> def f(): >>

Re: [Python-3000] Sky pie: a "var" keyword

Fredrik Lundh wrote: > Neil Toronto wrote: > > >> Heck no. An assignment would modify an existing variable only. >> > > what's an "existing variable"? how would STORE_GLOBAL work under your > proposal? > I haven't got a clue wha

Re: [Python-3000] Sky pie: a "var" keyword

Marcin 'Qrczak' Kowalczyk wrote: > It should be: > > var x = 0 > def f(): >print x >x = 3 > > for the global variable, and: > > var x = 0 > def f(): >var x >print x >x = 3 > > for the local variable. > > There are a few sane choices for the semantics of 'var': > > 1. The varia

Re: [Python-3000] Sky pie: a "var" keyword

Fredrik Lundh wrote: > Neil Toronto wrote: > > >> A "var" keyword fixes them all. The "global" gotcha: >> >> x = 0 >> def f(): >>print x # no exception - prints "0" >>x = 3 >> >> def g(): >&

[Python-3000] Sky pie: a "var" keyword

As long as patches are flying willy-nilly and we're just kicking around ideas like puppies, I thought I'd offer one of my own. No, not a puppy. An idea. Of course, if it ends up beaten to death, I might rather it were a puppy. My apologies if it's been discussed in some other form. It occurs t