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

[Martin v. Löwis]

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 tried with a harmless GCC
option (-fgcse).

The problem is that distutils only looks at the Makefile, not at the
environment variables. So I changed parse_makefile to do what make does:
fall back to the environment when no makefile variable is set. This was
still not sufficient, since distutils never looks at CFLAGS. So I
changed setup.py and sysconfig.py to fetch CFLAGS, and not bother with
BASECFLAGS and EXTRA_CFLAGS.

setup.py 1.218
NEWS 1.1289
sysconfig.py 1.65

Regards,
Martin
___
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

[Python-Dev] Re: anonymous blocks

[Fredrik Lundh]

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 'with', and then
> the using code becomes again this:
>
> with f = with_file(filename):
> for line in f:
>print process(line)

or

with with_file(filename) as f:
...

?

(assignment inside block-opening constructs aren't used in Python today,
as far as I can tell...)

> Finally, I think it would be cool if the generator could trap
> occurrences of break, continue and return occurring in BODY.  We could
> introduce a new class of exceptions for these, named ControlFlow, and
> (only in the body of a with statement), break would raise BreakFlow,
> continue would raise ContinueFlow, and return EXPR would raise
> ReturnFlow(EXPR) (EXPR defaulting to None of course).
>
> So a block could return a value to the generator using a return
> statement; the generator can catch this by catching ReturnFlow.
> (Syntactic sugar could be "VAR = yield ..." like in Ruby.)

slightly weird, but useful enough to be cool.  (maybe "return value" is enough,
though. the others may be slightly too weird...  or should that return perhaps
be a "continue value"?  you're going back to the top of loop, after all).

 



___
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

Re: [Python-Dev] Re: switch statement

[M.-A. Lemburg]

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 callbacks with a single loop body, without writing too
>>>many
>>>if/elif clauses.
>>
>>PEP 275 anyone ? (http://www.python.org/peps/pep-0275.html)
>>
>>My use case for switch is that of a parser switching on tokens.
>>
>>mxTextTools applications would greatly benefit from being able
>>to branch on tokens quickly. Currently, there's only callbacks,
>>dict-to-method branching or long if-elif-elif-...-elif-else.
> 
> I think "match" from Ocaml would be a much nicer addition to Python
> than "switch" from C.

PEP 275 is about branching based on dictionary lookups which
is somewhat different than pattern matching - for which we
already have lots and lots of different tools.

The motivation behind the switch statement idea is that of
interpreting the multi-state outcome of some analysis that
you perform on data. The main benefit is avoiding Python
function calls which are very slow compared to branching to
inlined Python code.

Having a simple switch statement
would enable writing very fast parsers in Python -
you'd let one of the existing tokenizers such as mxTextTools,
re or one of the xml libs create the token input data
and then work on the result using a switch statement.

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 ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Apr 25 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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

Re: [Python-Dev] Re: anonymous blocks

[Nick Coghlan]

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
finally:
f.close()
than having to write a class with __entry__ and __exit__ and
__except__ methods (I've lost track of the exact proposal at this
point).
Indeed - the transaction example is very easy to write this way:
def transaction():
begin_transaction()
try:
yield None
except:
abort_transaction()
raise
else:
commit_transaction()
> Also note that, unlike the for-loop translation, this does *not*
> invoke iter() on the result of EXPR; that's debatable but given that
> the most common use case should not be an alternate looping syntax
> (even though it *is* technically a loop) but a more general "macro
> 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 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.

Finally, I think it would be cool if the generator could trap
occurrences of break, continue and return occurring in BODY.  We could
introduce a new class of exceptions for these, named ControlFlow, and
(only in the body of a with statement), break would raise BreakFlow,
continue would raise ContinueFlow, and return EXPR would raise
ReturnFlow(EXPR) (EXPR defaulting to None of course).
Perhaps 'continue' could be used to pass a value into the iterator, rather than 
'return'? (I believe this has been suggested previously in the context of for loops)

This would permit 'return' to continue to mean breaking out of the containing 
function (as for other loops).

So a block could return a value to the generator using a return
statement; the generator can catch this by catching ReturnFlow.
(Syntactic sugar could be "VAR = yield ..." like in Ruby.)
So, "VAR = yield x" would expand to something like:
try:
yield x
except ReturnFlow, ex:
VAR = ReturnFlow.value
?
With a little extra magic we could also get the behavior that if the
generator doesn't handle ControlFlow exceptions but re-raises them,
they would affect the code containing the with statement; this means
that the generator can decide whether return, break and continue are
handled locally or passed through to the containing block.
That seems a little bit _too_ magical - it would be nice if break and continue 
were defined to be local, and return to be non-local, as for the existing loop 
constructs. For other non-local control flow, application specific exceptions 
will still be available.

Regardless, the ControlFlow exceptions do seem like a very practical way of 
handling the underlying implementation.

Note that EXPR doesn't have to return a generator; it could be any
object that implements next() and next_ex().  (We could also require
next_ex() or even next() with an argument; perhaps this is better.)
With this restriction (i.e. requiring next_ex, next_exc, or Terry's suggested 
__next__), then the backward's compatible version would be simply your desired 
semantics, plus an attribute check to exclude old-style iterators:

 it = EXPR
 if not hasattr(it, "__next__"):
 raise TypeError("'with' block requires 2nd gen iterator API support")
 err = None
 while True:
 try:
 VAR = it.next(err)
 except StopIteration:
 break
 try:
 err = None
 BODY
 except Exception, err: # Pretend "except Exception:" == "except:"
 pass
The generator objects created by using yield would supply the new API, so would 
be usable immediately inside such 'with' blocks.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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

Re: [Python-Dev] Re: anonymous blocks

[Skip Montanaro]

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 backwards compatible. So let's use
Guido> 'with', and then the using code becomes again this:

Guido> with f = with_file(filename):
Guido> for line in f:
Guido> print process(line)

How about deferring major new syntax changes until Py3K when the grammar and
semantic options might be more numerous?  Given the constraints of backwards
compatibility, adding more syntax or shoehorning new semantics into what's
an increasingly crowded space seems to always result in an unsatisfying
compromise.

Guido> Now let me propose a strawman for the translation of the latter
Guido> into existing semantics. Let's take the generic case:

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?

Skip
___
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

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

[Bob Ippolito]

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 zipfile. As far as I can tell, 
you now can't (except by rewriting everything but that to a new 
zipfile and renaming). Somewhere I saw a patch request for this, but 
it was languishing, a year or more old. Or am I just totally missing 
something?
No, you're not missing anything.  Deleting is hard, I guess.  Either 
you'd have to shuffle the zip file around to reclaim the space, or just 
leave that spot alone and just remove its entry in the central 
directory.  You'd probably want to look at what other software does to 
decide which approach to use (by default?).  I don't see any markers in 
the format that would otherwise let you say "this file was deleted".

-bob
___
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

[Python-Dev] Re: anonymous blocks

[Terry Reedy]

"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 syntax, which also helps with keeping
>> 'for' semantically backwards compatible. So let's use 'with', and then
>> the using code becomes again this:
>>
>> with f = with_file(filename):
>> for line in f:
>>print process(line)
>
> or
>
>with with_file(filename) as f:

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'.

Terry J. Reedy



___
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

Re: [Python-Dev] Re: anonymous blocks

[Simon Percivall]

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"
be a good keyword to overload here?

"in"/"with"/"for"/""  from :

//Simon
___
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

Re: [Python-Dev] Re: anonymous blocks

[Rodrigo Dias Arruda Senra]

[ 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 right, removing focus. Wouldn't  
> "from"
> be a good keyword to overload here?
> 
> "in"/"with"/"for"/""  from :
>  

 I do not have strong feelings about this issue, but for
 completeness sake...

 Mixing both suggestions:

 from  as :
 

 That resembles an import statement which some
 may consider good (syntax/keyword reuse) or
 very bad (confusion?, value focus).

 cheers,
 Senra

-- 
Rodrigo Senra 
--
MSc Computer Engineerrodsenra(at)gpr.com.br  
GPr Sistemas Ltdahttp://www.gpr.com.br/ 
Personal Blog http://rodsenra.blogspot.com/

___
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

[Python-Dev] Re: Re: anonymous blocks

[Terry Reedy]

"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 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.

Would not calling iter() (or .__iter__) explicitly, instead of depending on 
the implicit call of for loops, suffice to produce the needed iterator?

tjr



___
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

[Python-Dev] Re: Re: anonymous blocks

[Terry Reedy]

"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 unpacking as with assignment, for 
loops, and function calls: with a,b,c = x,y,z  and so on.

Terry J. Reedy



___
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

RE: [Python-Dev] Re: anonymous blocks

[Andrew Koenig]

>  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 which looks like this:

local  in  end

The idea is that the first declarations, whatever they are, are processed
without putting their names into the surrounding scope, then the second
declarations are processed *with* putting their names into the surrounding
scope.

For example:

local
fun add(x:int, y:int) = x+y
in
fun succ(x) = add(x, 1)

end

This defines succ in the surrounding scope, but not add.

So in Python terms, I think this would be

local:  in: 

or, for example:

local:  = value
in:
blah
blah
blah



___
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

[Python-Dev] Re: Re: anonymous blocks

[Terry Reedy]

"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 experience in 
> Python and
> iterators at the minimum, and hopefully with generators.  Not exactly 
> meant for
> someone for which raw_input() still holds a "wow" factor for.  =)

I have accepted the fact that Python has become a two-level language: basic 
Python for expressing algorithms + advanced features (metaclasses, 
decorators, CPython-specific introspection and hacks, and now possibly 
'with' or whatever) for solving software engineering issues.  Perhaps there 
should correspondingly be two tutorials.

Terry J. Reedy



___
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

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

[Michael Chermside]

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 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!) are on record as
being opposed to adding macros to Python. (Even "good" macros... think
lisp, not cpp.) I am not quite sure that I am convinced by the argument,
but let me see if I can present it:

  Allowing macros in Python would enable individual programmers or
  groups to easily invent their own "syntax". Eventually, there would
  develop a large number of different Python "dialects" (as some
  claim has happened in the Lisp community) each dependent on macros
  the others lack. The most important casualty would be Python's
  great *readability*.

(If this is a strawman argument, i.e. if you know of a better reason
for keeping macros OUT of Python please speak up. Like I said, I've
never been completely convinced of it myself.)

I think it would be useful if we approached it like this: either what
we want is the full power of macros (in which case the syntax we choose
should be guided by that choice), or we want LESS than the full power
of macros. If we want less, then HOW less?

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. And
if the answer is that we want to prohibit nothing, then the right
solution is macros.

-- Michael Chermside

___
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

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

[Facundo Batista]

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 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 explained to them that
Python, in some circumstances, caches the object, and I kept them
happy enough.

But I really don't know what objects and in which circumstances.

.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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

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

[Guido van Rossum]

> 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!) are on record as
> being opposed to adding macros to Python. (Even "good" macros... think
> lisp, not cpp.) I am not quite sure that I am convinced by the argument,
> but let me see if I can present it:
> 
>   Allowing macros in Python would enable individual programmers or
>   groups to easily invent their own "syntax". Eventually, there would
>   develop a large number of different Python "dialects" (as some
>   claim has happened in the Lisp community) each dependent on macros
>   the others lack. The most important casualty would be Python's
>   great *readability*.
> 
> (If this is a strawman argument, i.e. if you know of a better reason
> for keeping macros OUT of Python please speak up. Like I said, I've
> never been completely convinced of it myself.)

Nor am I; though I am also not completely unconvinced! The argument as
presented here is probably to generic; taken literally, it would argue
against having functions and classes as well...

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
(that happens at run time) so there's no mechanism to tell the
compiler about the new syntax. And macros that don't introduce new
syntax don't seem very interesting (compared to what we can do
already).

> I think it would be useful if we approached it like this: either what
> we want is the full power of macros (in which case the syntax we choose
> should be guided by that choice), or we want LESS than the full power
> of macros. If we want less, then HOW less?
> 
> 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. And
> if the answer is that we want to prohibit nothing, then the right
> solution is macros.

I'm personally at a loss understanding your question here. Perhaps you
could try answering it for yourself?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

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

[Guido van Rossum]

> 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 explained to them that
> Python, in some circumstances, caches the object, and I kept them
> happy enough.
> 
> But I really don't know what objects and in which circumstances.

Aargh! Bad explanation. Or at least you're missing something:
*mutable* objects (like lists) can *never* be cached, because they
have explicit object semantics. For example each time the expression
[] is evaluated it *must* produce a fresh list object (though it may
be recycled from a GC'ed list object -- or any other GC'ed object, for
that matter).

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
probably not in a place where one would ever think to look...

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

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

[Samuele Pedroni]

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 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!) are on record as
being opposed to adding macros to Python. (Even "good" macros... think
lisp, not cpp.) I am not quite sure that I am convinced by the argument,
but let me see if I can present it:
 Allowing macros in Python would enable individual programmers or
 groups to easily invent their own "syntax". Eventually, there would
 develop a large number of different Python "dialects" (as some
 claim has happened in the Lisp community) each dependent on macros
 the others lack. The most important casualty would be Python's
 great *readability*.
(If this is a strawman argument, i.e. if you know of a better reason
for keeping macros OUT of Python please speak up. Like I said, I've
never been completely convinced of it myself.)
 

The typical argument in defense of macros is that macros are just like 
functions, you go to the definition
and see what they does.

But depending on how much variation they offer over the normal grammar 
even eye parsing them may be difficult.

They make it easy to mix to code that is evaluated immediately and code 
that will be evalutated, maybe even repeatedely, later, each
macro having its own rules about this. In most cases the only way  to 
discern this and know what is what is indeed looking at the macro 
definition.

You can get flame wars about whether introducing slightly different 
variations of if is warranted. <.5 wink>

My personal impression is that average macro definitions (I'm thinking 
about Common Lisp or Dylan and similar) are much less
readable that average function definitions. Reading On Lisp may give an 
idea about this. That means that introducing macros in Python, because 
of the importance that readability has in Python, would need a serious 
design effort to make the macro definitions themself readable. I think 
that's a challenging design problem.

Also agree about the technical issues that Guido cited about referencing 
and when macros definition enter in effect etc.

___
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

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

[Paul Moore]

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.

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
template form (try...finally, or try..except..else, or whatever) [1].
This is "traditionally" handled by macros, and I see it as a *good*
sign, that the discussion has centred around runtime mechanisms rather
than compile-time ones.

[1] Specifically, cases where functions aren't enough. If I try to
characterise precisely what those cases are, all I can come up with is
"when the code being injected needs to run in the current scope, not
in the scope of a template function". Is that right?

Paul.
___
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

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

[Shane Holloway (IEEE)]

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 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 am very excited about the discussion of blocks.  I think they can 
potentially address two things that are sticky to express in python 
right now.  The first is to compress the common try/finally use cases 
around resource usage as with files and database commits.  The second is 
language extensibility, which makes us think of what macros did for Lisp.

Language extensibility has two motivations.  First and foremost is to 
allow the programmer to express his or her *intent*.  The second 
motivation is to reuse code and thereby increase productivity.  Since 
methods already allow us to reuse code, our motivation is to increase 
expressivity.  What blocks offer is to make Python's suites something a 
programmer can work with.  Much like using a metaclass putting control 
of class details into the programmer's hands.  Or decorators allowing us 
to modify method semantics.  If the uses of decorators tells us 
anything, I'm pretty sure there are more potential uses of blocks than 
we could shake many sticks at.  ;)

So, the question comes back to what are blocks in the language 
extensibility case?  To me, they would be something very like a code 
object returned from the compile method.  To this we would need to 
attach the globals and locals where the block was from.  Then we could 
use the normal exec statement to invoke the block whenever needed. 
Perhaps we could add a new mode 'block' to allow the ControlFlow 
exceptions mentioned elsewhere in the thread.  We still need to find a 
way to pass arguments to the block so we are not tempted to insert them 
in locals and have them magically appear in the namespace.  ;) 
Personally, I'm rather attached to "as (x, y):" introducing the block.

To conclude, I mocked up some potential examples for your entertainment.  ;)
Thanks for your time and consideration!
-Shane Holloway

Interfaces::
def interface(interfaceName, *bases, ***aBlockSuite):
blockGlobals = aBlockSuite.globals().copy()
blockGlobals.update(aBlockSuite.locals())
blockLocals = {}
exec aBlock in blockGlobals, blockLocals
return iterfaceType(interfaceName, bases, blockLocals)
IFoo = interface('IFoo'):
def isFoo(self): pass
IBar = interface('IBar'):
def isBar(self): pass
IBaz = interface('IBaz', IFoo, IBar):
def isBaz(self): pass
Event Suites::
def eventSinksFor(events, ***aBlockSuite):
blockGlobals = aBlockSuite.globals().copy()
blockGlobals.update(aBlockSuite.locals())
blockLocals = {}
exec aBlock in blockGlobals, blockLocals
for name, value in blockLocals.iteritems():
if aBlockSuite.locals().get(name) is value:
continue
if callable(value):
events.addEventFor(name, value)
def debugScene(scene):
eventSinksFor(scene.events):
def onMove(pos):
print "pos:", pos
def onButton(which, state):
print "button:", which, state
def onKey(which, state):
print "key:", which, state
___
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

Re: [Python-Dev] Re: anonymous blocks

[Paul Moore]

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
> > like next().  Otherwise, if the iterator is a generator, this will
> 
> Might this be a good time to introduce __next__ (having the same signature
> and semantics as your proposed next_ex) and builtin next(obj,
> exception=None)?
> 
> def next(obj, exception=None):
> 
> if hasattr(obj, '__next__'):
> return obj.__next__(exception)
> 
> if exception is not None:
> return obj.next(exception) # Will raise an appropriate exception
> 
> return obj.next()

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 using
0-arg next() (as long as old-style stuff isn't used in a context where
an exception gets passed back in).

I'd suggest that the new builtin have a "magic" name (__next__ being
the obvious one :-)) to make it clear that it's an internal
implementation detail.

Paul.

PS The first person to replace builtin __next__ in order to implement
a "next hook" of some sort, gets shot :-)
___
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

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

[Aahz]

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, blockLocals
> 
> return iterfaceType(interfaceName, bases, blockLocals)
> 
> IFoo = interface('IFoo'):
> def isFoo(self): pass

Where does ``aBlock`` come from?
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"It's 106 miles to Chicago.  We have a full tank of gas, a half-pack of
cigarettes, it's dark, and we're wearing sunglasses."  "Hit it."
___
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

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

[Shane Hathaway]

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
> template form (try...finally, or try..except..else, or whatever) [1].
> This is "traditionally" handled by macros, and I see it as a *good*
> sign, that the discussion has centred around runtime mechanisms rather
> than compile-time ones.
> 
> [1] Specifically, cases where functions aren't enough. If I try to
> characterise precisely what those cases are, all I can come up with is
> "when the code being injected needs to run in the current scope, not
> in the scope of a template function". Is that right?

That doesn't hold if the code being injected is a single Python
expression, since you can put an expression in a lambda and code the
template as a function.  I would say you need a block template when the
code being injected consists of one or more statements that need to run
in the current scope.

Shane
___
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

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

[Shane Hathaway]

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. And
> if the answer is that we want to prohibit nothing, then the right
> solution is macros.

One thing we don't need, I believe, is arbitrary transformation of code
objects.  That's actually already possible, thanks to Python's compiler
module, although the method isn't clean yet.  Zope uses the compiler
module to sandbox partially-trusted Python code.  For example, it
redirects all print statements and replaces operations that change an
attribute with a call to a function that checks access before setting
the attribute.

Also, we don't need any of these macros, AFAICT:

  http://gauss.gwydiondylan.org/books/drm/drm_86.html

Shane
___
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

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

[Shane Holloway (IEEE)]

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, blockLocals
   return iterfaceType(interfaceName, bases, blockLocals)
   IFoo = interface('IFoo'):
   def isFoo(self): pass

Where does ``aBlock`` come from?
Sorry! I renamed ``aBlock`` to ``aBlockSuite``, but missed a few.  ;)
___
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

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

[Jim Jewett]

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 ...

Expanding at run-time is less efficient, but it works at least as well
semantically.  If today's alternative is manual cut-n-paste, I would 
still rather have the computer do it for me, to avoid accidental forks.

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
 # hook collection
...
from defmacro import foo   # installs a foo hook, good for the rest of the file

Michael Chermside:
>> I think it would be useful if we approached it like this: either what
>> we want is the full power of macros (in which case the syntax we choose
>> should be guided by that choice), or we want LESS than the full power
>> of macros. If we want less, then HOW less?

>> 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. And
>> if the answer is that we want to prohibit nothing, then the right
>> solution is macros.

> I'm personally at a loss understanding your question here. Perhaps you
> could try answering it for yourself?

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\http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Michael Chermside]

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
> (that happens at run time) so there's no mechanism to tell the
> compiler about the new syntax. And macros that don't introduce new
> syntax don't seem very interesting (compared to what we can do
> already).

That's good to hear. It expresses fairly clearly what the challenges
are in implementing macros for Python, and expressing the challenges
makes it easier to attack the problem. My interest comes because some
recent syntax changes (generators, generator expressions) have seemed
to me like true language changes, but others (decorators, anonymous-blocks)
to me just cry out "this would be easy as a macro!".



I wrote:
> I think it would be useful if we approached it like this: either what
> we want is the full power of macros (in which case the syntax we choose
> should be guided by that choice), or we want LESS than the full power
> of macros. If we want less, then HOW less?
>
> 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. And
> if the answer is that we want to prohibit nothing, then the right
> solution is macros.

Guido replied:
> I'm personally at a loss understanding your question here. Perhaps you
> could try answering it for yourself?

You guys just think too fast for me. When I started this email, I replied
"Fair enough. One possibility is...". But while I was trying to condense
my thoughts down from 1.5 pages to something short and coherent (it takes
time to write it short) everything I was thinking became obscelete as
both Paul Moore and Jim Jewett did exactly the kind of thinking I was
hoping to inspire:

Paul:
> What I feel is the key concept here is that of "injecting" code into a
> template form (try...finally, or try..except..else, or whatever)
  [...]
> Specifically, cases where functions aren't enough. If I try to
> characterise precisely what those cases are, all I can come up with is
> "when the code being injected needs to run in the current scope, not
> in the scope of a template function". Is that right?

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
> prohibit.
 [...]
> Do we want to limit the changing part (the "anonymous block") to
> only a single suite?  That does work well with the "yield" syntax, but it
> seems like an arbitrary restriction unless *all* we want are resource
> wrappers.
>
> Or do we really just want a way to say that a function should share its
> local namespace with it's caller or callee?  In that case, maybe the answer
> is a "lexical" or "same_namespace" keyword.

My own opinion is that we DO want macros. I prefer a language have a few,
powerful constructs rather than lots of specialized ones. (Yet I still
believe that "doing different things should look different"... which is
why I prefer Python to Lisp.) I think that macros could solve a LOT of
problems.

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 to USE a macro:
where an expression is called for, and where a series-of-statements is
called for. In both cases, I'd be happy with a function-call like syntax
for including the macro.

Well, that's a lot of "wanting"... now I all I need to do is invent a
clever syntax that allows these in an elegant fashion while also solving
Guido's point about imports (hint: the answer is that it ALL happens at
runtime). I'll go think some while you guys zoom past me again. 

-- Michael Chermside

___
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

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

[Guido van Rossum]

> 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
>  # hook collection
> ...
> from defmacro import foo   # installs a foo hook, good for the rest of the 
> file

Brrr. What about imports that aren't at the top level (e.g. inside a function)?

> 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 want macros" just doesn't cut it.

> 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
> prohibit.  Lisp macros are (generally, excluding read macros) limited
> to taking and generating complete S-expressions.  If that isn't enough
> to enforce readability, then limiting blocks to expressions (or even
> statements) probably isn't enough in python.

I suspect you've derailed here. Or perhaps you should use a better
example; I don't understand what the point is of using an example like
"xx sss (S\ Do we want to limit the changing part (the "anonymous block") to
> only a single suite?  That does work well with the "yield" syntax, but it
> seems like an arbitrary restriction unless *all* we want are resource
> wrappers.

Or loops, of course.

Pehaps you've missed some context here? Nobody seems to be able to
come up with other use cases, that's why "yield" is so attractive.

> Or do we really just want a way to say that a function should share its
> local namespace with it's caller or callee?  In that case, maybe the answer
> is a "lexical" or "same_namespace" keyword.  Or maybe just a recipe to make
> exec or eval do the right thing.
> 
> def myresource(rcname, callback, *args):
> rc=open(rcname)
> same_namespace callback(*args)
> close(rc)
> 
> def process(*args):
> ...

But should the same_namespace modifier be part of the call site or
part of the callee? You seem to be tossing examples around a little
easily here.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

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

[Robert Brewer]

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
> > prohibit.
>  [...]
> > Do we want to limit the changing part (the "anonymous block") to
> > only a single suite?  That does work well with the "yield" 
> syntax, but it
> > seems like an arbitrary restriction unless *all* we want 
> are resource
> > wrappers.
> >
> > Or do we really just want a way to say that a function 
> should share its
> > local namespace with it's caller or callee?  In that case, 
> maybe the answer
> > is a "lexical" or "same_namespace" keyword.
> 
> My own opinion is that we DO want macros. I prefer a language 
> have a few,
> powerful constructs rather than lots of specialized ones. (Yet I still
> believe that "doing different things should look 
> different"... which is
> why I prefer Python to Lisp.) I think that macros could solve a LOT of
> problems.
> 
> 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 to USE a macro: where an expression is
> called for, and where a series-of-statements is called for.
> In both cases, I'd be happy with a function-call 
> like syntax for including the macro.

By "function-call like syntax" you mean something like this?

def safe_file(filename, body, cleanup):
f = open(filename)
try:
body()
finally:
f.close()
cleanup()

...

defmacro body:
for line in f:
print line[:line.find(":")]

defmacro cleanup:
print "file closed successfully"

safe_file(filename, body, cleanup)

If macros were to be evaluated at runtime, I'd certainly want to see
them be first-class (meaning able to be referenced and passed around); I
don't have much of a need for anonymous macros.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
___
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

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

[Robert Brewer]

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 want macros" just doesn't cut it.

I had a use-case recently which could be done using macros. I'll let you
all decide whether it would be "better" with macros or not. ;)

My poor-man's ORM uses descriptors to handle the properties of domain
objects, a lot of which need custom triggers, constraint-checking,
notifications, etc. The base class has:

def __set__(self, unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
unit._properties[self.key] = value

At one time, I had something like:

def __set__(self, unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
if self.pre:
self.pre(unit, value)
unit._properties[self.key] = value
if self.post:
self.post(unit, value)

...to run pre- and post-triggers. But that became unwieldy recently when
one of my post functions depended upon calculations inside the
corresponding pre function.

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:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
self.pre()
unit._properties[self.key] = value
self.post()
self.end()

defmacro begin:
pass

defmacro pre:
pass

defmacro post:
pass

defmacro end:
pass


...(which would require macro-blocks which were decidedly *not*
anonymous) then I could more cleanly write a subclass with additional
"macro" methods:

defmacro pre:
old_children = self.children()

defmacro post:
for child in self.children:
if child not in old_children:
notify_somebody("New child %s" % child)


Notice that the "old_children" local gets injected into the namespace of
__set__ (the caller) when "pre" is executed, and is available inside of
"post". The "self" name doesn't need to be rebound, either, since it is
also available in __set__'s local scope. We also avoid all of the
overhead of separate frames.

The above is quite ugly written with callbacks (due to excessive
argument passing), and is currently fragile when overriding __set__ (due
to duplicated code).

I'm sure there are other cases with both 1) a relatively invariant
series of statements and 2) complicated extensions of that series. Of
course, you can do the above with compile() and exec. Maybe I'm just
averse to code within strings.

Some ideas. Now tear 'em apart. :)


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
___
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

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

[Jim Jewett]

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 to USE a macro:
> where an expression is called for, and where a series-of-statements is
> called for. In both cases, I'd be happy with a function-call like syntax
> for including the macro.

I have often wanted to replace (parts of) strings, either because I'm 
writing a wrapper or because I want a non-English version to be loadable
without having to wrap strings in my own source code.  This is best done
as an import hook, but if I had read-write access to (a copy of) the source
code, I would use it.  I'm not sure I want that door opened, because if I start 
needing to parse regex substitions just to get a source code listing
... I won't
be happy.

I do think macros should be prevented from "changing the level" of the
code it replaces.  Any suites/statements/expressions (including parentheses 
and strings) that are open before the macro must still be open afterwards,
and any opened inside the macro must be closed inside the macro.

For example

def foo(x):
print x
macro1(x)
print x

might print different values for x on the two lines, but I would be less 
comfortable if it could result in any of the following:

def foo(x):
print x
while True:# An invisible loop, because of 
print x   # Changing the indent level

def foo(x):
print x
return   # and you thought it would print twice! 
(This one is iffy)
print x   

def foo(x)
print x
[("""(unclosed string or paren eats up the rest of the file...)
print x

def foo(x)
"Hah!  my backspaces and rubouts eliminated the print statements!"

def foo(x)
print x
def anotherfunc(x, y, z):
print x   # Hey, I didn't even mess with the indent!

And to be honest, even

def foo(x):
macro1(x)
stmt1()# syntax error, except for the macro, so not ambiguous

expanding to

def foo(x)
while x:
print x # macro does not end on same indent level
stmt1()

is ... not something I want to worry about when I'm reading.

Michael Chermside:
> (hint: the answer is that it ALL happens at runtime).

I have mixed feelings on this.  It is more powerful that way,
but it also limits future implementations -- and I'm not sure
the extra power is entirely a good thing.

defmacro():
print x # Hey, x was in global scope at runtime when *I* tested

On The Other Hand, this certainly isn't the only piece of python
that could *usually* be moved to compile-time, and I suppose it
could piggyback on whatever extension is used for speeding up
attribute lookup.

-jJ
___
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

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

[Terry Reedy]

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
probably not in a place where one would ever think to look...

---
I am sure that the fact that immutables *may* be cached is in the ref 
manual, but I have been under the impression that the private, *mutable* 
specifics for CPython are intentionally omitted so that people will not 
think of them as either fixed or as part of the language/library.

I have previously suggested that there be a separate doc for CPython 
implementation details like this that some people want but which are not 
part of the language or library definition.

Terry J. Reedy




___
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

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

[Shane Hathaway]

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:
> value = self.coerce(unit, value)
> oldvalue = unit._properties[self.key]
> if oldvalue != value:
> self.pre()
> unit._properties[self.key] = value
> self.post()
> self.end()
> 
> defmacro begin:
> pass
> 
> defmacro pre:
> pass
> 
> defmacro post:
> pass
> 
> defmacro end:
> pass

Here is a way to write that using anonymous blocks:

def __set__(self, unit, value):
with self.setting(unit, value):
if self.coerce:
value = self.coerce(unit, value)
oldvalue = unit._properties[self.key]
if oldvalue != value:
with self.changing(oldvalue, value):
unit._properties[self.key] = value

def setting(self, unit, value):
# begin code goes here
yield None
# end code goes here

def changing(self, oldvalue, newvalue):
# pre code goes here
yield None
# post code goes here


> ...(which would require macro-blocks which were decidedly *not*
> anonymous) then I could more cleanly write a subclass with additional
> "macro" methods:
> 
> defmacro pre:
> old_children = self.children()
> 
> defmacro post:
> for child in self.children:
> if child not in old_children:
> notify_somebody("New child %s" % child)

def changing(self, oldvalue, newvalue):
old_children = self.children()
yield None
for child in self.children:
if child not in old_children:
notify_somebody("New child %s" % child)

Which do you prefer?  I like fewer methods. ;-)

Shane
___
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

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

[Robert Brewer]

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 self.coerce:
> > value = self.coerce(unit, value)
> > oldvalue = unit._properties[self.key]
> > if oldvalue != value:
> > self.pre()
> > unit._properties[self.key] = value
> > self.post()
> > self.end()
> > 
> > defmacro begin:
> > pass
> > 
> > defmacro pre:
> > pass
> > 
> > defmacro post:
> > pass
> > 
> > defmacro end:
> > pass
> 
> Here is a way to write that using anonymous blocks:
> 
> def __set__(self, unit, value):
> with self.setting(unit, value):
> if self.coerce:
> value = self.coerce(unit, value)
> oldvalue = unit._properties[self.key]
> if oldvalue != value:
> with self.changing(oldvalue, value):
> unit._properties[self.key] = value
> 
> def setting(self, unit, value):
>   # begin code goes here
> yield None
> # end code goes here
> 
> def changing(self, oldvalue, newvalue):
> # pre code goes here
> yield None
> # post code goes here
> 
...
> Which do you prefer?  I like fewer methods. ;-)

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 set of 10 subclasses which need the same begin() but different end()
code.

Yielding seems both too restrictive and too inside-out to be readable,
IMO.


Robert Brewer
MIS
Amor Ministries
[EMAIL PROTECTED]
___
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

Re: [Python-Dev] Re: switch statement

[Shannon -jj Behrens]

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" statement based on dictionary lookups, so I can
> >>>replace multiple callbacks with a single loop body, without writing too
> >>>many
> >>>if/elif clauses.
> >>
> >>PEP 275 anyone ? (http://www.python.org/peps/pep-0275.html)
> >>
> >>My use case for switch is that of a parser switching on tokens.
> >>
> >>mxTextTools applications would greatly benefit from being able
> >>to branch on tokens quickly. Currently, there's only callbacks,
> >>dict-to-method branching or long if-elif-elif-...-elif-else.
> >
> > I think "match" from Ocaml would be a much nicer addition to Python
> > than "switch" from C.
> 
> PEP 275 is about branching based on dictionary lookups which
> is somewhat different than pattern matching - for which we
> already have lots and lots of different tools.
> 
> The motivation behind the switch statement idea is that of
> interpreting the multi-state outcome of some analysis that
> you perform on data. The main benefit is avoiding Python
> function calls which are very slow compared to branching to
> inlined Python code.
> 
> Having a simple switch statement
> would enable writing very fast parsers in Python -
> you'd let one of the existing tokenizers such as mxTextTools,
> re or one of the xml libs create the token input data
> and then work on the result using a switch statement.
> 
> 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'll admit that I haven't because dict-based lookups aren't as
interesting to me as an Ocaml-style match statement.  Furthermore, the
argument "Instead of having one function call per token, you'd only
have a single dict lookup" isn't very compelling to me personally,
because I don't have such a performance problem in my applications,
which isn't to say that it isn't important or that you don't have a
valid point.

Best Regards,
-jj

-- 
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.
___
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

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

[Jim Jewett]

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 ensure it was already imported.

That said, I did say it wasn't as clean; think of it like pre-caching which 
dictionary that resolved an attribute lookup.  Don't start with the complexity, 
but consider not making the optimization impossible.
 
> > Why not just introduce macros?

> Because I've been using Python for 15 years without needing them?

And also without anonymous blocks or generator finalizers or resource
managers.

> Sorry, but "why not add feature X" is exactly what we're trying to
> AVOID here.

If anything is added, it might be better to add a single generalized tool 
instead of several special cases -- unless the tool is so general as to be 
hazardous.  Unlimited macros are that hazardous.

> >  If the answer is "We don't want
> >
> > xx sss (S\ >
> > to ever be meaningful", then we need to figure out exactly what to
> > prohibit.  

> I don't understand what the point is of using an example like
> "xx sss (S\> [yield works great for a single "anonymous block", but not so 
>>  great for several blocks per macro/template.]

> Pehaps you've missed some context here? Nobody seems to be able to
> come up with other [than resource wrappers] use cases, that's why 
> "yield" is so attractive.

Sorry; to me it seemed obvious that you would occasionally want to 
interleave the macro/template and the variable portion.  Robert Brewer 
has since provided good examples at

http://mail.python.org/pipermail/python-dev/2005-April/052923.html
http://mail.python.org/pipermail/python-dev/2005-April/052924.html

> > Or do we really just want a way to say that a function should share its
> > local namespace with it's caller or callee?  In that case, maybe the answer
> > is a "lexical" or "same_namespace" keyword.  Or maybe just a recipe to make
> > exec or eval do the right thing.

> But should the same_namespace modifier be part of the call site or
> part of the callee? 

IMHO, it should be part of the calling site, because it is the calling site
that could be surprised to find its own locals modified.  The callee 
presumably runs through a complete call before it has a chance to
be surprised.  

I did leave the decision open because I'm not certain that mention-in-caller
wouldn't end up contorting a common code style.  (It effectively forces
the macro to be in control, and the "meaningful" code to be callbacks.)

-jJ
___
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

Re: [Python-Dev] Re: anonymous blocks

[Tim Delaney]

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 using
0-arg next() (as long as old-style stuff isn't used in a context where
an exception gets passed back in).
Yes, but it could also be used (almost) anywhere an explicit obj.next() is 
used.

it = iter(seq)
while True:
   print next(it)
for loops would also change to use builtin next() rather than calling 
it.next() directly.

I'd suggest that the new builtin have a "magic" name (__next__ being
the obvious one :-)) to make it clear that it's an internal
implementation detail.
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.

PS The first person to replace builtin __next__ in order to implement
a "next hook" of some sort, gets shot :-)
Damn! There goes the use case ;)
Tim Delaney 

___
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

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

[Guido van Rossum]

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/)
___
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

[Python-Dev] Re: switch statement

[Jim Jewett]

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 cases outside of parsers 
branching on a constant token.  When I see stacked
elif clauses, the condition almost always includes some 
computation (perhaps only ".startswith" or "in" or a regex 
match), and there are often cases which look at a second 
variable.

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.  

-jJ
___
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

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

[Shane Hathaway]

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 set of 10 subclasses which need the same begin() but different end()
> code.
> 
> Yielding seems both too restrictive and too inside-out to be readable,
> IMO.

Ok, that makes sense.  However, one of your examples seemingly pulls a
name, 'old_children', out of nowhere.  That's hard to fix.  One of the
greatest features of Python is the simple name scoping; we can't lose that.

Shane
___
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

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

[Samuele Pedroni]

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 self.coerce:
   value = self.coerce(unit, value)
   oldvalue = unit._properties[self.key]
   if oldvalue != value:
   self.pre()
   unit._properties[self.key] = value
   self.post()
   self.end()
   defmacro begin:
   pass
   
   defmacro pre:
   pass
   
   defmacro post:
   pass
   
   defmacro end:
   pass
Here is a way to write that using anonymous blocks:
   def __set__(self, unit, value):
   with self.setting(unit, value):
   if self.coerce:
   value = self.coerce(unit, value)
   oldvalue = unit._properties[self.key]
   if oldvalue != value:
   with self.changing(oldvalue, value):
   unit._properties[self.key] = value
   def setting(self, unit, value):
# begin code goes here
   yield None
   # end code goes here
   def changing(self, oldvalue, newvalue):
   # pre code goes here
   yield None
   # post code goes here
...
Which do you prefer?  I like fewer methods. ;-)

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 set of 10 subclasses which need the same begin() but different end()
code.
Yielding seems both too restrictive and too inside-out to be readable,
IMO.

it seems what you are asking for are functions that are evaluated in 
namespace of the caller:

- this seems fragile, the only safe wat to implement 'begin' etc is to 
exactly know what goes on in __set__ and what names are used there

- if you throw in deferred evaluation for exprs or suites passed in
as arguments and even without considering that, it seems pretty horrid 
implementation-wise

Notice that even in Common Lisp you cannot really do this, you could 
define a macro that produce a definition for __set__ and takes fragments 
corresponding to begin ... etc


___
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

Re: [Python-Dev] Re: switch statement

[Donovan Baarda]

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
benefits belong in implementation optimisations, not new bad syntax.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
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

[Python-Dev] Re: switch statement

[Brian Beck]

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 seemed to
like it. Take a look:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410692

--
Brian Beck
Adventurer of the First Order

___
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

Re: [Python-Dev] Re: switch statement

[Donovan Baarda]

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 saves
> some typing over the if/elif/else construction, and people seemed to
> like it. Take a look:
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410692

Very clever... you have shown that current python syntax is capable of
almost exactly replicating a C case statement.

My only problem is C case statements are ugly. A simple if/elif/else is
much more understandable to me. 

The main benefit in C of case statements is the compiler can optimise
them. This copy of a C case statement will be slower than an
if/elif/else, and just as ugly :-)

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
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

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

[Terry Reedy]

"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
> cached (but not always).
>
> Hope this helps! I would think this is in the docs somewhere but
> probably not in a place where one would ever think to look...
>
> ---

To be clearer, the above quotes what Guido wrote in the post of his that I 
am responding to.  Only the below is my response.

> I am sure that the fact that immutables *may* be cached is in the ref 
> manual, but I have been under the impression that the private, *mutable* 
> specifics for CPython are intentionally omitted so that people will not 
> think of them as either fixed or as part of the language/library.
>
> I have previously suggested that there be a separate doc for CPython 
> implementation details like this that some people want but which are not 
> part of the language or library definition.
>
Terry J. Reedy



___
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

Re: [Python-Dev] Re: anonymous blocks

[Greg Ewing]

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
corresponding to the tp_next typeslot, analogously with
__len__, __iter__, etc.
There would be a builtin function next(obj) which would
invoke obj.__next__(), for use by Python code. For loops
wouldn't use it, though; they would continue to call the
tp_next typeslot directly.
Paul Moore wrote: 
PS The first person to replace builtin __next__ in order to implement
a "next hook" of some sort, gets shot :-)
I think he meant next(), not __next__. And it wouldn't
work anyway, since as I mentioned above, C code would
bypass next() and call the typeslot directly.
I'm +1 on moving towards __next__, BTW. IMO, that's the
WISHBDITFP. :-)
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Michael Walter]

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):
  self.say("Macros are the evil :)")
  react(event) # xD

p = Person()
p.become(Furious)
p.react(42)

---

Embedding domain specific language (ex.: markup language):

# no, i haven't thought about whether the presented syntax as such is
unambiguous
# enough to make sense
def hello_world():
  :
:
  : "Tralalalala"
:
  for g in uiods:
: uido2str(g)

---

Embedding domain-specific language (ex.: badly-designed database table):

deftable Player:
  id: primary_key(integer) # does this feel backward?
  handle: string
  fans: m2n_assoc(Fan)

---

Control constructs:

forever:
  print "tralalala"

unless you.are(LUCKY):
  print "a"


I'm not sure whether this the Python you want it to become, so in a
certain sense I feel kind of counterproductive now (sublanguage design
is hard at 11 PM, which might actually prove someone's point that the
language designer shouldn't allow people to do such things. I'm sure
other people are more mature or at least less tired than me, though,
so I beg to differ :-),
Michael


On 4/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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/)
> ___
> 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/michael.walter%40gmail.com
>
___
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

Re: [Python-Dev] Re: anonymous blocks

[Greg Ewing]

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 StopIteration:
break
try:
err = None
BODY
except Exception, err: # Pretend "except Exception:" == "except:"
if not hasattr(it, "next_ex"):
raise
I like the general shape of this, but I have one or two
reservations about the details.
1) We're going to have to think carefully about the naming of
functions designed for use with this statement. If 'with'
is going to be in there as a keyword, then it really shouldn't
be part of the function name as well. Instead of
  with f = with_file(pathname):
...
I would rather see something like
  with f = opened(pathname):
...
This sort of convention (using a past participle as a function
name) would work for some other cases as well:
  with some_data.locked():
...
  with some_resource.allocated():
...
On the negative side, not having anything like 'with' in the
function name means that the fact the function is designed for
use in a with-statement could be somewhat non-obvious. Since
there's not going to be much other use for such a function,
this is a bad thing.
It could also lead people into subtle usage traps such as
  with f = open(pathname):
...
which would fail in a somewhat obscure way.
So maybe the 'with' keyword should be dropped (again!) in
favour of
  with_opened(pathname) as f:
...
2) I'm not sure about the '='. It makes it look rather deceptively
like an ordinary assignment, and I'm sure many people are going
to wonder what the difference is between
  with f = opened(pathname):
do_stuff_to(f)
and simply
  f = opened(pathname)
  do_stuff_to(f)
or even just unconsciously read the first as the second without
noticing that anything special is going on. Especially if they're
coming from a language like Pascal which has a much less magical
form of with-statement.
So maybe it would be better to make it look more different:
  with opened(pathname) as f:
...
* It seems to me that this same exception-handling mechanism
would be just as useful in a regular for-loop, and that, once
it becomes possible to put 'yield' in a try-statement, people
are going to *expect* it to work in for-loops as well.
Guido has expressed concern about imposing extra overhead on
all for-loops. But would the extra overhead really be all that
noticeable? For-loops already put a block on the block stack,
so the necessary processing could be incorporated into the
code for unwinding a for-block during an exception, and little
if anything would need to change in the absence of an exception.
However, if for-loops also gain this functionality, we end up
with the rather embarrassing situation that there is *no difference*
in semantics between a for-loop and a with-statement!
This could be "fixed" by making the with-statement not loop,
as has been suggested. That was my initial thought as well,
but having thought more deeply, I'm starting to think that
Guido was right in the first place, and that a with-statement
should be capable of looping. I'll elaborate in another post.
So a block could return a value to the generator using a return
statement; the generator can catch this by catching ReturnFlow.
(Syntactic sugar could be "VAR = yield ..." like in Ruby.)
This is a very elegant idea, but I'm seriously worried by the
possibility that a return statement could do something other
than return from the function it's written in, especially if
for-loops also gain this functionality. Intercepting break
and continue isn't so bad, since they're already associated
with the loop they're in, but return has always been an
unconditional get-me-out-of-this-function. I'd feel uncomfortable
if this were no longer true.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

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_data chops off first char of default package  (2005-04-15)
   http://python.org/sf/1183712  opened by  Wummel

[ast] fix for 1183468: return/yield in class  (2005-04-16)
   http://python.org/sf/1184418  opened by  logistix

urllib2 dloads failing through HTTP proxy w/ auth  (2005-04-18)
   http://python.org/sf/1185444  opened by  Mike Fleetwood

binascii.b2a_qp does not handle binary data correctly  (2005-04-18)
   http://python.org/sf/1185447  opened by  Eric Huss

Automatically build fpectl module from setup.py  (2005-04-18)
   http://python.org/sf/1185529  opened by  Jeff Epler

Typo in Curses-Function doc  (2005-04-20)
   http://python.org/sf/1186781  opened by  grzankam

subprocess: optional auto-reaping fixing os.wait() lossage  (2005-04-21)
   http://python.org/sf/1187312  opened by  Mattias Engdegård

Add const specifier to PySpam_System prototype  (2005-04-21)
   http://python.org/sf/1187396  opened by  Luis Bruno

Don't assume all exceptions are SyntaxError's  (2005-04-25)
   http://python.org/sf/1189210  opened by  John Ehresman

Patches Closed
__

fix typos in Library Reference  (2005-04-10)
   http://python.org/sf/1180062  closed by  doerwalter

[AST] Fix for core in test_grammar.py  (2005-04-08)
   http://python.org/sf/1179513  closed by  nascheme

Implemented new 'class foo():pass' syntax  (2005-04-03)
   http://python.org/sf/1176019  closed by  nascheme

range() in for loops, again  (2005-04-12)
   http://python.org/sf/1181334  closed by  arigo

Info Associated with Merge to AST  (2005-01-07)
   http://python.org/sf/1097671  closed by  kbk

New / Reopened Bugs
___

Minor error in tutorial  (2005-04-14)
CLOSED http://python.org/sf/1183274  opened by  Konrads Smelkovs

check for return/yield outside function is wrong  (2005-04-15)
   http://python.org/sf/1183468  opened by  Neil Schemenauer

try to open /dev/null as directory  (2005-04-15)
   http://python.org/sf/1183585  opened by  Roberto A. Foglietta

PyDict_Copy() can return non-NULL value on error  (2005-04-15)
CLOSED http://python.org/sf/1183742  opened by  Phil Thompson

Popen4 wait() fails sporadically with threads  (2005-04-15)
   http://python.org/sf/1183780  opened by  Taale Skogan

return val in __init__ doesn't raise TypeError in new-style  (2005-04-15)
CLOSED http://python.org/sf/1183959  opened by  Adal Chiriliuc

dest parameter in optparse  (2005-04-15)
   http://python.org/sf/1183972  opened by  ahmado

Missing trailing newline with comment raises SyntaxError  (2005-04-15)
   http://python.org/sf/1184112  opened by  Eric Huss

example broken in section 1.12 of Extending & Embedding  (2005-04-16)
   http://python.org/sf/1184380  opened by  bamoore

Read-only property attributes raise wrong exception  (2005-04-16)
CLOSED http://python.org/sf/1184449  opened by  Barry A. Warsaw

itertools.imerge: merge sequences  (2005-04-18)
CLOSED http://python.org/sf/1185121  opened by  Jurjen N.E. Bos

pydoc doesn't find all module doc strings  (2005-04-18)
   http://python.org/sf/1185124  opened by  Kent Johnson

PyObject_Realloc bug in obmalloc.c  (2005-04-19)
   http://python.org/sf/1185883  opened by  Kristján Valur

python socketmodule dies on ^c  (2005-04-19)
CLOSED http://python.org/sf/1185931  opened by  nodata

tempnam doc doesn't include link to tmpfile  (2005-04-19)
   http://python.org/sf/1186072  opened by  Ian Bicking

[AST] genexps get scoping wrong  (2005-04-19)
   http://python.org/sf/1186195  opened by  Brett Cannon

[AST] assert failure on ``eval("u'\Ufffe'")``  (2005-04-19)
   http://python.org/sf/1186345  opened by  Brett Cannon

[AST] automatic unpacking of arguments broken  (2005-04-19)
   http://python.org/sf/1186353  opened by  Brett Cannon

Python Programming FAQ should be updated for Python 2.4  (2005-02-09)
CLOSED http://python.org/sf/1119439  reopened by  montanaro

nntplib shouldn't raise generic EOFError  (2005-04-20)
   http://python.org/sf/1186900  opened by  Matt Roper

TypeError message on bad iteration is misleading  (2005-04-21)
   http://python.org/sf/1187437  opened by  Roy Smith

Pickle with HIGHEST_PROTOCOL "ord() expected..."  (2005-04-22)
CLOSED http://python.org/sf/1188175  opened by  Heiko Selber

Rebuilding from source on RH9 fails (_tkinter.so missing)  (2005-04-22)
   http://python.org/sf/1188231  opened by  Marty Heyman

Python 2.4 Not Recognized by Any Programs  (2005-04-23)
   http://python.org/sf/1188637  opened by  Yoshi Nagasaki

zipfile module and 2G boundary  (2005-04-24)
   http://python.org/sf/1189216  opened by  Bob Ippolito

Seg Fault wh

Re: [Python-Dev] Re: anonymous blocks

[Greg Ewing]

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 generators.
This is dangerously close to the "you don't need to know about
it if you're not going to use it" argument, which is widely
recognised as false. Newbies might not need to know all the
details of the implementation, but they will need to know
enough about the semantics of with-statements to understand
what they're doing when they come across them in other people's
code.
Which leads me to another concern. How are we going to explain
the externally visible semantics of a with-statement in a way
that's easy to grok, without mentioning any details of the
implementation?
You can explain a for-loop pretty well by saying something like
"It executes the body once for each item from the sequence",
without having to mention anything about iterators, generators,
next() methods, etc. etc. How the items are produced is completely
irrelevant to the concept of the for-loop.
But what is the equivalent level of description of the
with-statement going to say?
"It executes the body with... ???"
And a related question: What are we going to call the functions
designed for with-statements, and the objects they return?
Calling them generators and iterators (even though they are)
doesn't seem right, because they're being used for a purpose
very different from generating and iterating.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Greg Ewing]

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 identifiers
are often interned, although this is not guaranteed.
And this only applies to literals, not strings constructed
dynamically by the program (unless you explicitly apply
intern() to them).
Python 2.3.4 (#1, Jun 30 2004, 16:47:37)
[GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "foo" is "foo"
True
>>> "foo" is "f" + "oo"
False
>>> "foo" is intern("f" + "oo")
True
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Greg Ewing]

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 it by means of a generator, you don't
need a class at all -- just make the whole thing a generator
function.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

Re: [Python-Dev] Re: switch statement

[Greg Ewing]

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 switched on all the time,
   and the operator being used for comparison.
2) The first case is syntactically different from subsequent ones,
   even though semantically all the cases are equivalent.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Greg Ewing]

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 for .pth files? This would make it easier to
have collections of Python programs sharing a common
set of modules, without having to either install them
system-wide or write hairy sys.path-manipulating code
or use platform-dependent symlink or PATH hacks.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Greg Ewing]

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,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Greg Ewing]

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 about 3 posts ago,
but I was afraid of getting stoned for heresy...
  ... Eventually, there would
  develop a large number of different Python "dialects" (as some
  claim has happened in the Lisp community) each dependent on macros
  the others lack. The most important casualty would be Python's
  great *readability*.

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.
From that quote, it would seem what we want to do is prohibit
anything that would make code less readable. Or prohibit
anything that would permit creating a new dialect. Or something.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

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

[Greg Ewing]

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 with block arguments. It does this by starting
out with a fairly minimal and very flexible syntax.
This raises the question of why people feel the need for
macros in Lisp or Scheme, which have an even more minimal
and flexible syntax. I think part of the reason is that
the syntax for passing an unevaluated block is too obtrusive.
In Scheme you can define a function (not macro) that is
used like this:
  (with-file "foo/blarg"
 (lambda (f)
(do-something-with f)))
But there is a natural tendency to want to be able to
cut out the lambda cruft and just write something like:
  (with-file "foo/blarg" (f)
 (do-something-with f))
and for that you need a macro.
The equivalent in Smalltalk would be something like
  File open: "foo/blarg" do: [:f f something]
which doesn't look too bad (compared to the rest of
the language!) because the block-passing syntax is
fairly unobtrusive.
So in summary, I don't think you necessarily *need*
macros to get nice-looking user-defined control structures.
It depends on other features of the language.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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

Re: [Python-Dev] Re: anonymous blocks

[Brett C.]

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
>> iterators at the minimum, and hopefully with generators.
> 
> 
> This is dangerously close to the "you don't need to know about
> it if you're not going to use it" argument, which is widely
> recognised as false. Newbies might not need to know all the
> details of the implementation, but they will need to know
> enough about the semantics of with-statements to understand
> what they're doing when they come across them in other people's
> code.
> 

I am not saying it is totally to be ignored by people staring at Python code,
but we don't need to necessarily spell out the intricacies.

> Which leads me to another concern. How are we going to explain
> the externally visible semantics of a with-statement in a way
> that's easy to grok, without mentioning any details of the
> implementation?
> 
> You can explain a for-loop pretty well by saying something like
> "It executes the body once for each item from the sequence",
> without having to mention anything about iterators, generators,
> next() methods, etc. etc. How the items are produced is completely
> irrelevant to the concept of the for-loop.
> 
> But what is the equivalent level of description of the
> with-statement going to say?
> 
> "It executes the body with... ???"
> 

It executes the body, calling next() on the argument name on each time through
until the iteration stops.

> And a related question: What are we going to call the functions
> designed for with-statements, and the objects they return?
> Calling them generators and iterators (even though they are)
> doesn't seem right, because they're being used for a purpose
> very different from generating and iterating.
> 

I like "managers" since they are basically managing resources most of the time
for the user.

-Brett
___
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

Re: [Python-Dev] Re: anonymous blocks

[Ka-Ping Yee]

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 intended to do.  If it can be described accurately in a sentence
or two, that's a good sign that the semantics are sufficiently clear
and simple.

> I like "managers" since they are basically managing resources
> most of the time for the user.

No, please let's not call them that.  "Manager" is a very common word
to describe all kinds of classes in object-oriented designs, and it is
so generic as to hardly mean anything.  (Sorry, i don't have a better
alternative at the moment.)


-- ?!ng
___
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