Re: [Python-Dev] Re: anonymous blocks

On Mon, 25 Apr 2005, Brett C. wrote: > It executes the body, calling next() on the argument name on each > time through until the iteration stops. There's a little more to it than that. But on the whole I do support the goal of finding a simple, short description of what this construct is intende

Re: [Python-Dev] Re: anonymous blocks

Greg Ewing wrote: > Brett C. wrote: > >> And before anyone decries the fact that this might confuse a newbie >> (which >> seems to happen with every advanced feature ever dreamed up), remember >> this >> will not be meant for a newbie but for someone who has experience in >> Python and >> iterator

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside wrote: if the answer is that we want to prohibit nothing, then the right solution is macros. I'm not sure about that. Smalltalk manages to provide very reasonable-looking user-defined control structures without using compile-time macros, just normal runtime evaluation together wit

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside wrote: I've been following this conversation, and it sounds to me as if we are stumbling about in the dark, trying to feel our way toward something very useful and powerful. I think Jim is right, what we're feeling our way toward is macros. I considered saying something like that

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Jim Jewett wrote: defmacro myresource(filename): with myresource("thefile"): def reader(): ... def writer(): ... def fn(): -1. This is ugly. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury,

Re: [Python-Dev] site enhancements (request for review)

Bob Ippolito wrote: A few weeks ago I put together a patch to site.py for Python 2.5 that solves three major deficiencies: > > [concerning .pth files] While we're on the subject of .pth files, what about the idea of scanning the directory containing the main .py file

Re: [Python-Dev] Re: switch statement

Donovan Baarda wrote: Agreed. I don't find any switch syntaxes better than if/elif/else. Speed benefits belong in implementation optimisations, not new bad syntax. Two things are mildly annoying about if-elif chains as a substitute for a switch statement: 1) Repeating the name of the thing being sw

Re: [Python-Dev] Re: Re: anonymous blocks

Terry Reedy wrote: Not supporting iterables makes it harder to write a class which is inherently usable in a with block, though. The natural way to make iterable classes is to use 'yield' in the definition of __iter__ - if iter() is not called, then that trick can't be used. If you're defining i

Re: [Python-Dev] Re: Caching objects in memory

Guido van Rossum wrote: But for *immutable* objects (like numbers, strings and tuples) the implementation is free to use caching. In practice, I believe ints between -5 and 100 are cached, and 1-character strings are often cached (but not always). Also, string literals that resemble Python identifi

Re: [Python-Dev] Re: anonymous blocks

Brett C. wrote: And before anyone decries the fact that this might confuse a newbie (which seems to happen with every advanced feature ever dreamed up), remember this will not be meant for a newbie but for someone who has experience in Python and iterators at the minimum, and hopefully with generat

[Python-Dev] Weekly Python Patch/Bug Summary

Patch / Bug Summary ___ Patches : 316 open ( +2) / 2831 closed ( +7) / 3147 total ( +9) Bugs: 908 open (+10) / 4941 closed (+20) / 5849 total (+30) RFE : 178 open ( +1) / 153 closed ( +2) / 331 total ( +3) New / Reopened Patches __ package_d

Re: [Python-Dev] Re: anonymous blocks

Guido van Rossum wrote: with VAR = EXPR: BODY This would translate to the following code: it = EXPR err = None while True: try: if err is None: VAR = it.next() else: VAR = it.next_ex(err) except StopIter

Re: [Python-Dev] defmacro (was: Anonymous blocks)

A couple of examples out of my tired head (solely from a user perspective) :-) Embedding domain specific language (ex.: state machine): stateful Person: state Calm(initial=True): def react(event): self.chill_pill.take() ignore(event) state Furious: def react(event):

Re: [Python-Dev] Re: anonymous blocks

Tim Delaney wrote: There aren't many builtins that have magic names, and I don't think this should be one of them - it has obvious uses other than as an implementation detail. I think there's some confusion here. As I understood the suggestion, __next__ would be the Python name of the method corr

[Python-Dev] Re: Re: Caching objects in memory

"Terry Reedy" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Guido: > > But for *immutable* objects (like numbers, strings and tuples) the > implementation is free to use caching. In practice, I believe ints > between -5 and 100 are cached, and 1-character strings are often > cache

Re: [Python-Dev] Re: switch statement

On Mon, 2005-04-25 at 21:21 -0400, Brian Beck wrote: > Donovan Baarda wrote: > > Agreed. I don't find any switch syntaxes better than if/elif/else. Speed > > benefits belong in implementation optimisations, not new bad syntax. > > I posted this 'switch' recipe to the Cookbook this morning, it save

[Python-Dev] Re: switch statement

Donovan Baarda wrote: > Agreed. I don't find any switch syntaxes better than if/elif/else. Speed > benefits belong in implementation optimisations, not new bad syntax. I posted this 'switch' recipe to the Cookbook this morning, it saves some typing over the if/elif/else construction, and people se

Re: [Python-Dev] Re: switch statement

On Mon, 2005-04-25 at 18:20 -0400, Jim Jewett wrote: [...] > If speed for a limited number of cases is the only advantage, > then I would say it belongs in (at most) the implementation, > rather than the language spec. Agreed. I don't find any switch syntaxes better than if/elif/else. Speed be

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Robert Brewer wrote: Shane Hathaway wrote: Robert Brewer wrote: So currently, all subclasses just override __set__, which leads to a *lot* of duplication of code. If I could write the base class' __set__ to call "macros" like this: def __set__(self, unit, value): self.begin() if s

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Robert Brewer wrote: > I still prefer more methods, because my actual use-cases are more > complicated. Your solution would work for the specific case I gave, but > try factoring in: > > * A subclass which needs to share locals between begin and post, instead > of pre and post. > > or > > * A se

[Python-Dev] Re: switch statement

M.-A. Lemburg wrote: > Having a simple switch statement > would enable writing very fast parsers in Python - ... > Instead of having one function call per token, you'd > only have a single dict lookup. > BTW, has anyone in this thread actually read the PEP 275 ? I haven't actually seen any use c

Re: [Python-Dev] defmacro (was: Anonymous blocks)

It seems that what you call macros is really an unlimited preprocessor. I'm even less interested in that topic than in macros, and I haven't seen anything here to change my mind. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Pytho

Re: [Python-Dev] Re: anonymous blocks

Paul Moore wrote: Hmm, it took me a while to get this, but what you're ssaying is that if you modify Guido's "what I really want" solution to use VAR = next(it, exc) then this builtin next makes "API v2" stuff using __next__ work while remaining backward compatible with old-style "API v1" stuff

Re: [Python-Dev] defmacro (was: Anonymous blocks)

On 4/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > It could also be done (though not as cleanly) by making macros act as > > import hooks. > Brrr. What about imports that aren't at the top level (e.g. inside a > function)? Bad style already. :D If you want to use the macro, you have to

Re: [Python-Dev] Re: switch statement

On 4/25/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Shannon -jj Behrens wrote: > > On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > > >>Fredrik Lundh wrote: > >> > >>>PS. a side effect of the for-in pattern is that I'm beginning to feel > >>>that Python > >>>might need a nice "switch" st

RE: [Python-Dev] defmacro (was: Anonymous blocks)

Shane Hathaway wrote: > Robert Brewer wrote: > > So currently, all subclasses just override __set__, which leads to a > > *lot* of duplication of code. If I could write the base > class' __set__ > > to call "macros" like this: > > > > def __set__(self, unit, value): > > self.begin() >

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Robert Brewer wrote: > So currently, all subclasses just override __set__, which leads to a > *lot* of duplication of code. If I could write the base class' __set__ > to call "macros" like this: > > def __set__(self, unit, value): > self.begin() > if self.coerce: >

[Python-Dev] Re: Re: Caching objects in memory

Guido: But for *immutable* objects (like numbers, strings and tuples) the implementation is free to use caching. In practice, I believe ints between -5 and 100 are cached, and 1-character strings are often cached (but not always). Hope this helps! I would think this is in the docs somewhere but p

[Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside: > There are lots of things one might want to replace within macros, from > identifiers to punctuation, but I'd be willing to live with just two of > them: expressions, and "series-of-statements" (that's almost the same as > a block). There are only two places I'd want to be able

RE: [Python-Dev] defmacro (was: Anonymous blocks)

Guido van Rossum wrote: > > Why not just introduce macros? > > Because I've been using Python for 15 years without needing them? > Sorry, but "why not add feature X" is exactly what we're trying to > AVOID here. You've got to come up with some really good use cases > before we add new features. "I

RE: [Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside wrote: > Jim: > > Why not just introduce macros? If the answer is "We > > should, it is just hard to code", then use a good > > syntax for macros. If the answer is "We don't want > > xx sss (S\ > to ever be meaningful", then we need to figure out exactly what to > > prohi

Re: [Python-Dev] defmacro (was: Anonymous blocks)

> It could also be done (though not as cleanly) by making macros act as > import hooks. > > import defmacro# Stop processing until defmacro is loaded. > # All future lines will be > preprocessed by the >

RE: [Python-Dev] defmacro (was: Anonymous blocks)

Guido writes: > My problem with macros is actually more practical: Python's compiler > is too dumb. I am assuming that we want to be able to import macros > from other modules, and I am assuming that macros are expanded by the > compiler, not at run time; but the compiler doesn't follow imports > (

[Python-Dev] defmacro (was: Anonymous blocks)

Guido: > My problem with macros is actually more practical: Python's compiler > is too dumb. I am assuming that we want to be able to import macros > from other modules, and I am assuming that macros are expanded by the > compiler, not at run time; but the compiler doesn't follow imports ... Expa

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Aahz wrote: On Mon, Apr 25, 2005, Shane Holloway (IEEE) wrote: Interfaces:: def interface(interfaceName, *bases, ***aBlockSuite): blockGlobals = aBlockSuite.globals().copy() blockGlobals.update(aBlockSuite.locals()) blockLocals = {} exec aBlock in blockGlobals, block

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside wrote: > In other words, rather than hearing what we'd like to be able to DO > with blocks, I'd like to hear what we want to PROHIBIT DOING with > blocks. I think this might be a fruitful way of thinking about the > problem which might make it easier to evaluate syntax suggestions

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Paul Moore wrote: > I think the key difference with macros is that they act at compile > time, not at run time. There is no intention here to provide any form > of compile-time processing, and that makes all the difference. > > What I feel is the key concept here is that of "injecting" code into a

Re: [Python-Dev] defmacro (was: Anonymous blocks)

On Mon, Apr 25, 2005, Shane Holloway (IEEE) wrote: > > Interfaces:: > > def interface(interfaceName, *bases, ***aBlockSuite): > blockGlobals = aBlockSuite.globals().copy() > blockGlobals.update(aBlockSuite.locals()) > blockLocals = {} > > exec aBlock in blockGl

Re: [Python-Dev] Re: anonymous blocks

On 4/25/05, Tim Delaney <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > but for backwards compatibility with the existing argument-less next() > > API I'm introducing a new iterator API next_ex() which takes an > > exception argument. If that argument is None, it should behave just > >

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside wrote: Jim Jewett writes: As best I can tell, the anonymous blocks are used to take care of boilerplate code without changing the scope -- exactly what macros are used for. Folks, I think that Jim is onto something here. I've been following this conversation, and it sounds to me

Re: [Python-Dev] defmacro (was: Anonymous blocks)

On 4/25/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > I've been following this conversation, and it sounds to me as if we > are stumbling about in the dark, trying to feel our way toward something > very useful and powerful. I think Jim is right, what we're feeling our > way toward is macros.

Re: [Python-Dev] defmacro (was: Anonymous blocks)

Michael Chermside wrote: Jim Jewett writes: As best I can tell, the anonymous blocks are used to take care of boilerplate code without changing the scope -- exactly what macros are used for. Folks, I think that Jim is onto something here. I've been following this conversation, and it sounds

Re: [Python-Dev] Re: Caching objects in memory

> I was in my second class of the Python workshop I'm giving here in one > Argentine University, and I was explaining how to think using > name/object and not variable/value. > > Using id() for being pedagogic about the objects, the kids saw that > id(3) was always the same, but id([]) not. I expl

Re: [Python-Dev] defmacro (was: Anonymous blocks)

> I've been following this conversation, and it sounds to me as if we > are stumbling about in the dark, trying to feel our way toward something > very useful and powerful. I think Jim is right, what we're feeling our > way toward is macros. > > The problem, of course, is that Guido (and others!)

Re: [Python-Dev] Re: Caching objects in memory

On 4/22/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > Is there a document that details which objects are cached in memory > > (to not create the same object multiple times, for performance)? > > why do you think you need to know? I was in my second class of the Python workshop I'm giving here

RE: [Python-Dev] defmacro (was: Anonymous blocks)

Jim Jewett writes: > As best I can tell, the anonymous blocks are used to take > care of boilerplate code without changing the scope -- exactly > what macros are used for. Folks, I think that Jim is onto something here. I've been following this conversation, and it sounds to me as if we are stumb

[Python-Dev] Re: Re: anonymous blocks

"Brett C." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > And before anyone decries the fact that this might confuse a newbie > (which > seems to happen with every advanced feature ever dreamed up), remember > this > will not be meant for a newbie but for someone who has experien

RE: [Python-Dev] Re: anonymous blocks

> Mixing both suggestions: > > from as : > > > That resembles an import statement which some > may consider good (syntax/keyword reuse) or > very bad (confusion?, value focus). I have just noticed that this whole notion is fairly similar to the "local" statement in ML, the syntax for

[Python-Dev] Re: Re: anonymous blocks

"Skip Montanaro" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Guido> with VAR = EXPR: >Guido> BODY > > What about a multi-variable case? Will you have to introduce a new level > of > indentation for each 'with' var? I would expect to see the same structure u

[Python-Dev] Re: Re: anonymous blocks

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Guido van Rossum wrote: > > statement expansion", I think we can expect EXPR to produce a value > > that is already an iterator (rather than merely an interable). > > Not supporting iterables makes it harder to write a c

Re: [Python-Dev] Re: anonymous blocks

[ Simon Percivall ]: > [ Terry Reedy ]: > > with as : > > > > would parallel the for-statement header and read smoother to me. > > > > for as : > > > > would not need new keyword, but would require close reading to > > distinguish > > 'as' from 'in'. > > But it also moves the value to the righ

Re: [Python-Dev] Re: anonymous blocks

On 25 apr 2005, at 16.14, Terry Reedy wrote: with as : would parallel the for-statement header and read smoother to me. for as : would not need new keyword, but would require close reading to distinguish 'as' from 'in'. But it also moves the value to the right, removing focus. Wouldn't "from"

[Python-Dev] Re: anonymous blocks

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Guido van Rossum wrote: > >> At the same time, having to use it as follows: >> >> for f in with_file(filename): > < for line in f: >> print process(line) >> >> is really ugly, so we need new synt

[Python-Dev] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug

On Apr 25, 2005, at 7:53 AM, Charles Hartman wrote: Someone should think about rewriting the zipfile module to be less hideous, include a repair feature, and be up to date with the latest specifications . -- and allow *deleting* a file from a zipf

Re: [Python-Dev] Re: anonymous blocks

Guido> At the same time, having to use it as follows: Guido> for f in with_file(filename): Guido> for line in f: Guido> print process(line) Guido> is really ugly, so we need new syntax, which also helps with Guido> keeping 'for' semantically backwa

Re: [Python-Dev] Re: anonymous blocks

Guido van Rossum wrote: It seems that the same argument that explains why generators are so good for defining iterators, also applies to the PEP 310 use case: it's just much more natural to write def with_file(filename): f = open(filename) try: yield f finall

Re: [Python-Dev] Re: switch statement

Shannon -jj Behrens wrote: > On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > >>Fredrik Lundh wrote: >> >>>PS. a side effect of the for-in pattern is that I'm beginning to feel >>>that Python >>>might need a nice "switch" statement based on dictionary lookups, so I can >>>replace multiple ca

[Python-Dev] Re: anonymous blocks

Guido van Rossum wrote: > At the same time, having to use it as follows: > > for f in with_file(filename): < for line in f: > print process(line) > > is really ugly, so we need new syntax, which also helps with keeping > 'for' semantically backwards compatible. So let's use

Re: [Python-Dev] Proper place to put extra args for building

Brett C. wrote: > OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and > distutils.sysconfig . Martin, please double-check I tweaked sysconfig the way > you wanted. It is the way I wanted it, but it doesn't work. Just try and use it for some extension modules to see for yourself, I