Re: [Python-Dev] defmacro

[Stephen J. Turnbull]

> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:

Greg> This raises the question of why people feel the need for
Greg> macros in Lisp or Scheme, which have an even more minimal
Greg> and flexible syntax. I think part of the reason is that the
Greg> syntax for passing an unevaluated block is too obtrusive.
Greg> [... T]here is a natural tendency to want to be able to cut
Greg> out the lambda cruft

This doesn't feel right to me.  By that argument, people would want
to "improve"

  (mapcar (lambda (x) (car x)) list-of-lists)

to

  (mapcar list-of-lists (x) (car x))

Have you ever heard someone complain about that lambda, though?

My feeling is that the reason for macros in Lisps is that people want
control structures to look like control structures, not like function
calls whose actual arguments "just happen" to be anonymous function
objects.  In this context, the lambda does not merely bind f, it also
excludes a lot of other possibilities.  I mean when I see

   (with-locked-file "foo/blarg"
  (lambda (f)
 (do-something-with f)))

I go "What's this?  Oh, here the file is obviously important, and
there we have a function of one formal argument with no actual
arguments, so it must be that we're processing the file with the
function."  This emphasizes the application of this function to that
file too much for my taste, and I will assume that the behavior of the
block is self-contained---it had better not depend on free variables.

But with

   (with-locked-file (f "foo/blarg")
  (do-something-with-as-modified-by f x))

there's no particular need for the block to exclusively concentrate on
handling f, and there's nothing disconcerting about the presence of x.
N.B. for non-Lispers: in Common Lisp idiom the list (f "foo/blarg")
may be treated as two arguments, but associating f with "foo/blarg" in
some way.  I think in this context it is much more readable.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
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)

[Bob Ippolito]

On Apr 26, 2005, at 1:12 AM, Greg Ewing wrote:
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.
I don't think I'd ever use that, but it doesn't sound like a terrible 
idea.

-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

Re: [Python-Dev] Re: switch statement

[Stephen J. Turnbull]

> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:

Greg> Two things are mildly annoying about if-elif chains as a
Greg> substitute for a switch statement:

Greg> 1) Repeating the name of the thing being switched on all the
Greg> time, and the operator being used for comparison.

What's worse, to my mind, is the not infrequent case where the thing
being switched on or the operator changes.  Sure, that's bad style,
but sometimes you have to read other people's code like that.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
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

[Guido van Rossum]

> Greg> 1) Repeating the name of the thing being switched on all the
> Greg> time, and the operator being used for comparison.
> 
> What's worse, to my mind, is the not infrequent case where the thing
> being switched on or the operator changes.  Sure, that's bad style,
> but sometimes you have to read other people's code like that.

You mean like this?

if x > 0:
   ...normal case...
elif y > 0:
abnormal case...
else:
...edge case...

You have guts to call that bad style! :-)

-- 
--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] site enhancements (request for review)

[Guido van Rossum]

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

I do that all the time without .pth files -- I just put all the common
modules in a package and place the package in the directory containing
the "main" .py files.

I do have use cases where for reasons of separate development cycles
(etc.) I have some code (usually experimental or "unofficial" in some
way)  in a different place that also needs access to the same set of
common modules, and there I use explicit sys.path manipulations. I
think that even if the proposed feature was available I wouldn't
switch to it -- it's too easy to forget about the .pth file and be
confused when it points to the wrong place. That's also the reason why
I don't use symlinks or $PYTHONPATH for this purpose. EIBTI. :-)

-- 
--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: RE: [Python-Dev] defmacro (was: Anonymous blocks)

[flaig]

Actually I was thinking of something related the other day: Wouldn't it be nice 
to be able to define/overload not only operators but also control structures? 
That way Python's core language could be kept simple and free of "featuritis" 
while at the same time everyone who desires a match/case or repeat/until 
statement, or anything more sophisticated, could implement it for himself. 

If you suspect that good old Lisp is on my mind, you are probably right :) . 
Actually, the idea of a programming language whose structures can be adapted to 
everyone's personal style is still very appealing to me.

I have no very distinct ideas about how such a thing might be designed (and 
still less whether it could be made to work efficiently), but perhaps somewhat 
like this (just to clarify along which paths my thoughts are currently moving):

structure whaddayacallit: # name only as a comment
   def opening_clause:
  statements
   def alternative_clause_1:
  statements
   def *alternative_clause_2: # the asterisk to indicate that this may occur 
several times
  statements
   def closing-clause:
  statements

e.g.:

structure multiple_switch:
   condition = None
   def switch(self, c): # condition must be passed as a lambdoid function
  self.condition, self.finished = c, False
   def *case(self, x, statements): # so must the statements subordinate to the 
new "case" expression
  if self.condition( x ):
  statements()
  self.finished = True
  break structure
   def otherwise(self, statements);
  if not self.finished:
  statements()

and the application:

switch my_favourite_language:
case Python:
print "Hi Guido"
case Perl:
print "Hi Larry"
otherwise:
print "Hi pleb"

At least to me, this has a definitively macroish flavour... and not in the 
#dumbdown style of C. Or rather say, macros might be a generalized way to 
achieve this, if they are intelligently designed. (<= That at least shouldn't 
be the problem, since this is the Python community and not M$'s development 
department :-) .)

Do you think any of this might make sense?

-- Rüdiger Marcus


PS. Aahz: When describing Ruby as the "antithesis" of Python recently I was 
thinking in Laskerian rather than Hegelian terms... the differences are not 
really big, but Ruby has always been positioned as a deliberate challenge to 
Python.



Date: Mon, 25 Apr 2005 09:42:54 -0700
> From: Michael Chermside <[EMAIL PROTECTED]>
> Subject: RE: [Python-Dev] defmacro (was: Anonymous blocks)
> To: python-dev@python.org
> Cc: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain;   charset=ISO-8859-1
> 
> 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
> ===
Chevalier Dr. Dr. Ruediger Marcus Flaig
   Institute for Immunology
   University of Heidelberg
   Im Neuenheimer Feld 305, D-69120 Heidelberg, FRG
   <[EMAIL PROTECTED]>



--
Diese E-Mail wurde mit http://www.mail-inspector.de verschickt
Mail Inspector ist ein kostenloser Service von http://www.is-fun.net
Der Absender 

Re: [Python-Dev] Re: anonymous blocks

[Guido van Rossum]

[Greg Ewing]
> I like the general shape of this, but I have one or two
> reservations about the details.

That summarizes the feedback so far pretty well. I think we're on to
something. And I'm not too proud to say that Ruby has led the way here
to some extent (even if Python's implementation would be fundamentally
different, since it's based on generators, which has some different
possibilities and precludes some Ruby patterns).

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

Of course. I only used 'with_opened' because it's been the running
example in this thread.

> 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():
>  ...


Or how about

with synchronized(some_resource):
...

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

This seems a pretty mild problem; one could argue that every function
is only useful in a context where its return type makes sense, and we
seem to be getting along just fine with naming conventions (or just
plain clear naming).

> It could also lead people into subtle usage traps such as
> 
>with f = open(pathname):
>  ...
> 
> which would fail in a somewhat obscure way.

Ouch. That one hurts. (I was going to say "but f doesn't have a next()
method" when I realized it *does*. :-) It is *almost* equivalent to

for f in open(pathname):
...

except if the "..." block raises an exception.  Fortunately your
proposal to use 'as' makes this mistake less likely.

> So maybe the 'with' keyword should be dropped (again!) in
> favour of
> 
>with_opened(pathname) as f:
>  ...

But that doesn't look so great for the case where there's no variable
to be assigned to -- I wasn't totally clear about it, but I meant the
syntax to be

with [VAR =] EXPR: BLOCK

where VAR would have the same syntax as the left hand side of an
assignment (or the variable in a for-statement).

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

Right.

> So maybe it would be better to make it look more different:
> 
>with opened(pathname) as f:
>  ...

Fredrik said this too, and as long as we're going to add 'with' as a
new keyword, we might as well promote 'as' to become a real
keyword. So then the syntax would become

with EXPR [as VAR]: BLOCK

I don't see a particular need for assignment to multiple VARs (but VAR
can of course be a tuple of identifiers).

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

(You can already put a yield inside a try-except, just not inside a
try-finally.)

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

Probably.

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

There would still be the difference that a for-loop invokes iter() and
a with-block doesn't.

Also, for-loops that don't exhaust the iterator leave it available for
later use. I believe there are even examples of this pattern, where
one for-loop searches the iterable for some kind of marker value and
the next for-loop iterates over the remaining items. For example:

f = open(messagefile)
# Process message headers
for line in f:
if not line.strip():
break
if line[0].isspace():
addcontinuation(line)
else:
addheader(line)
# Process mes

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

[Rodrigo Dias Arruda Senra]

[ Michael Walter ]:
> A couple of examples out of my tired head (solely from a user perspective) :-)
> 
> Embedding domain specific language (ex.: state machine):
> ...
> 
> Embedding domain specific language (ex.: markup language):
> ...
> 
> Embedding domain-specific language (ex.: badly-designed database table):
> ...
>
> ..., which might actually prove someone's point that the
> language designer shouldn't allow people to do such things.

 The whole macros issue comes to a tradeoff between
 power+expressiviness X readability. 

 IMVHO, macros are readability assassins. The power (for any developer)
 to introduce new syntax is *not* a desirable feature, but something
 to be avoided. And that alone should be a stronger argument than
 a hundred use cases. 

 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

Re: [Python-Dev] Re: anonymous blocks

[Greg Ewing]

Brett C. wrote:
It executes the body, calling next() on the argument
> name on each time through until the iteration stops.
But that's no good, because (1) it mentions next(),
which should be an implementation detail, and (2)
it talks about iteration, when most of the time
the high-level intent has nothing to do with iteration.
In other words, this is too low a level of explanation.
Greg

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

On 4/26/05, Rodrigo Dias Arruda Senra <[EMAIL PROTECTED]> wrote:
>  IMVHO, macros are readability assassins. The power (for any developer)
>  to introduce new syntax is *not* a desirable feature, but something
>  to be avoided. And that alone should be a stronger argument than
>  a hundred use cases.

Personally, I believe that EDSLs can improve usability of a library.
I've been following this list for quite a while, and trying to see
what lengths (hacks) people go (use) to implement "sexy" syntax can
give you quite an idea that custom syntax matters. And surely all of
these tricks (hacks) are way harder to use than a EDSL would be.

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

[Reinhold Birkenfeld]

Guido van Rossum wrote:
> [Greg Ewing]
>> I like the general shape of this, but I have one or two
>> reservations about the details.
> 
> That summarizes the feedback so far pretty well. I think we're on to
> something. And I'm not too proud to say that Ruby has led the way here
> to some extent (even if Python's implementation would be fundamentally
> different, since it's based on generators, which has some different
> possibilities and precludes some Ruby patterns).

Five random thoughts:

1. So if break and continue are allowed in with statements only when there
   is an enclosing loop, it would be a inconsistency; consider

 for item in seq:
with gen():
continue

   when the generator gen catches the ContinueFlow and does with it what it 
wants.
   It is then slightly unfair not to allow

 with x:
 continue

   Anyway, I would consider both counterintuitive. So what about making 
ReturnFlow,
   BreakFlow and ContinueFlow "private" exceptions that cannot be caught in 
user code
   and instead introducing a new statement that allows passing data to the 
generator?

2. In process of handling this, would it be reasonable to (re)introduce a 
combined
   try-except-finally statement with defined syntax (all except before finally) 
and
   behavior (finally is always executed)?

5. What about the intended usage of 'with' as in Visual B.. NO, NO, NOT THE 
WHIP!

   (not that you couldn't emulate this with a clever "generator":
  def short(x):
  yield x

  with short(my.long["object"]reference()) as _:
  _.spam = _.ham = _.eggs()

yours,
Reinhold

-- 
Mail address is perfectly valid!

___
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:
[snip]
- I think there's a better word than Flow, but I'll keep using it
  until we find something better.
How about simply reusing Iteration (ala StopIteration)?
  Pass in 'ContinueIteration' for 'continue'
  Pass in 'BreakIteration' for 'break'
  Pass in 'AbortIteration' for 'return' and finalisation.
And advise strongly *against* intercepting AbortIteration with anything other 
than a finally block.

- The new __next__() API can also (nay, *must*, to make all this work
  reliably) be used to define exception and cleanup semantics for
  generators, thereby rendering obsolete PEP 325 and the second half
  of PEP 288.  When a generator is GC'ed (whether by reference
  counting or by the cyclical garbage collector), its __next__()
  method is called with a BreakFlow exception instance as argument (or
  perhaps some other special exception created for the purpose).  If
  the generator catches the exception and yields another value, too
  bad -- I consider that broken behavior.  (The alternative would be
  to keep calling __next__(BreakFlow()) until it doesn't return a
  value, but that feels uncomfortable in a finalization context.)
As suggested above, perhaps the exception used here should be the exception that 
is raised when a 'return' statement is encountered inside the block, rather than 
the more-likely-to-be-messed-with 'break' statement.

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

[Greg Ewing]

Guido van Rossum wrote:
[Greg Ewing]
* 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.
(You can already put a yield inside a try-except, just not inside a
try-finally.)
Well, my point still stands. People are going to write
try-finally around their yields and expect the natural
thing to happen when their generator is used in a
for-loop.
There would still be the difference that a for-loop invokes iter() and
a with-block doesn't.
>
> Also, for-loops that don't exhaust the iterator leave it available for
> later use.
Hmmm. But are these big enough differences to justify
having a whole new control structure? Whither TOOWTDI?
"""
The statement:
for VAR in EXPR:
BLOCK
does the same thing as:
with iter(EXPR) as VAR:# Note the iter() call
BLOCK
except that:
- you can leave out the "as VAR" part from the with-statement;
- they work differently when an exception happens inside BLOCK;
- break and continue don't always work the same way.
The only time you should write a with-statement is when the
documentation for the function you are calling says you should.
"""
Surely you jest. Any newbie reading this is going to think
he hasn't a hope in hell of ever understanding what is going
on here, and give up on Python in disgust.

I'm seriously worried by the
possibility that a return statement could do something other
than return from the function it's written in.

Let me explain the use cases that led me to throwing that in
Yes, I can see that it's going to be necessary to treat
return as an exception, and accept the possibility that
it will be abused. I'd still much prefer people refrain
from abusing it that way, though. Using "return" to spell
"send value back to yield statement" would be extremely
obfuscatory.
(BTW ReturnFlow etc. aren't great
names.  Suggestions?)
I'd suggest just calling them Break, Continue and Return.
synchronized(lock):
BLOCK
transactional(db):
BLOCK
forever():
BLOCK
opening(filename) as f:
BLOCK
Hey, I like that last one! Well done!
One last thing: if we need a special name for iterators and generators
designed for use in a with-statement, how about calling them
with-iterators and with-generators.
Except that if it's no longer a "with" statement, this
doesn't make so much sense...
Greg


___
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

[Reinhold Birkenfeld]

Nick Coghlan wrote:
> Guido van Rossum wrote:
> [snip]
>> - I think there's a better word than Flow, but I'll keep using it
>>   until we find something better.
> 
> How about simply reusing Iteration (ala StopIteration)?
> 
>Pass in 'ContinueIteration' for 'continue'
>Pass in 'BreakIteration' for 'break'
>Pass in 'AbortIteration' for 'return' and finalisation.
> 
> And advise strongly *against* intercepting AbortIteration with anything other 
> than a finally block.

Hmmm... another idea: If break and continue return keep exactly the current
semantics (break or continue the innermost for/while-loop), do we need
different exceptions at all? AFAICS AbortIteration (+1 on the name) would be
sufficient for all three interrupting statements, and this would prevent
misuse too, I think.

yours,
Reinhold

-- 
Mail address is perfectly valid!

___
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] Removing --with-wctype-functions support

[S . Çağlar Onur]

Hi;

I just subscribed this list, so i don't know whether this discussed
before. If so, sorry.

I want to know status of
http://mail.python.org/pipermail/python-dev/2004-December/050193.html
this thread. Will python remove wctype functions support from its core?
If it will, what about locale-dependent case conversation functions? 

Without this support python behaves wrong in tr_TR.UTF-8 locale. As a
side effect, this problem reported to Gentoo Linux to add a wctype
support to current python ebuild
( http://bugs.gentoo.org/show_bug.cgi?id=69322 ), but they don't want to
add any removed feature to their ebuilds, and also not break anything
because portage is built on python.

So :), what will the feature of wctype?

Yours
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.uludag.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


signature.asc
Description: Bu dijital olarak =?iso-8859-9?Q?imzalanm=FD=FE?= ileti	=?iso-8859-9?Q?par=E7as=FDd=FDr?=
___
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]

Reinhold Birkenfeld wrote:
Nick Coghlan wrote:
Guido van Rossum wrote:
[snip]
- I think there's a better word than Flow, but I'll keep using it
 until we find something better.
How about simply reusing Iteration (ala StopIteration)?
  Pass in 'ContinueIteration' for 'continue'
  Pass in 'BreakIteration' for 'break'
  Pass in 'AbortIteration' for 'return' and finalisation.
And advise strongly *against* intercepting AbortIteration with anything other 
than a finally block.

Hmmm... another idea: If break and continue return keep exactly the current
semantics (break or continue the innermost for/while-loop), do we need
different exceptions at all? AFAICS AbortIteration (+1 on the name) would be
sufficient for all three interrupting statements, and this would prevent
misuse too, I think.
No, the iterator should be able to keep state around in the case of 
BreakIteration and ContinueIteration, whereas AbortIteration should shut the 
whole thing down.

In particular "VAR = yield None" is likely to become syntactic sugar for:
  try:
yield None
  except ContinueIteration, exc:
VAR = ContinueIteration.value
We definitely don't want that construct swallowing AbortIteration.
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

[Michael Hudson]

Whew!  This is a bit long...
On 25 Apr 2005, at 00:57, Guido van Rossum wrote:
After reading a lot of contributions (though perhaps not all -- this
thread seems to bifurcate every time someone has a new idea :-)
I haven't read all the posts around the subject, I'll have to admit.  
I've read the one I'm replying and its followups to pretty carefully, 
though.

I'm back to liking yield for the PEP 310 use case. I think maybe it was
Doug Landauer's post mentioning Beta, plus scanning some more examples
of using yield in Ruby. Jim Jewett's post on defmacro also helped, as
did Nick Coghlan's post explaining why he prefers 'with' for PEP 310
and a bare expression for the 'with' feature from Pascal (and other
languages :-).
The history of iterators and generators could be summarized by saying 
that an API was invented, then it turned out that in practice one way 
of implementing them -- generators -- was almost universally useful.

This proposal seems a bit like an effort to make generators good at 
doing something that they aren't really intended -- or dare I say 
suited? -- for.  The tail wagging the dog so to speak.

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()
This is a syntax error today, of course.  When does the finally: clause 
execute  with your proposal? [I work this one out below :)]

than having to write a class with __entry__ and __exit__ and
__except__ methods (I've lost track of the exact proposal at this
point).

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,
This is a non-starter, I hope.  I really meant what I said in PEP 310 
about loops being loops.

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)
Now let me propose a strawman for the translation of the latter into
existing semantics. Let's take the generic case:
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

(The variables 'it' and 'err' are not user-visible variables, they are
internal to the translation.)
This looks slightly awkward because of backward compatibility; what I
really want is just this:
it = EXPR
err = None
while True:
try:
VAR = it.next(err)
except StopIteration:
break
try:
err = None
BODY
except Exception, err: # Pretend "except Exception:" == 
"except:"
pass

but for backwards compatibility with the existing argument-less next()
API
More than that: if I'm implementing an iterator for, uh, iterating, why 
would one dream of needing to handle an 'err' argument in the next() 
method?

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
raised that exception in the generator's frame (at the point of the
suspended yield).  If the iterator is something else, the something
else is free to do whatever it likes; if it doesn't want to do
anything, it can just re-raise the exception.
Ah, this answers my 'when does finally' execute question above.
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).
Well, this is quite a big thing.
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.)
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.
Note that EXPR doesn't have to re

Re: [Python-Dev] Re: anonymous blocks

[Michael Hudson]

On 26 Apr 2005, at 15:13, Michael Hudson wrote:
So, here's a counterproposal!
And a correction!
with expr as var:
   ... code ...
is roughly:
def _(var):
... code ...
try:
expr(_)
except Return, e:
return e.value
Cheers,
mwh
___
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]

Michael Hudson wrote:
This is a non-starter, I hope.  I really meant what I said in PEP 310 
about loops being loops.
The more I play with this, the more I want the 'with' construct to NOT be a loop 
construct.

The main reason is that it would be really nice to be able to write and use a 
multipart code template as:

def template():
  # pre_part_1
  yield None
  # post_part_1
  yield None
  # pre_part_2
  yield None
  # post_part_2
  yield None
  # pre_part_3
  yield None
  # post_part_3
def user():
  block = template()
  with block:
# do_part_1
  with block:
# do_part_2
  with block:
# do_part_3
If 'with' is a looping construct, the above won't work, since the first usage 
will drain the template.

Accordingly, I would like to suggest that 'with' revert to something resembling 
the PEP 310 definition:

resource = EXPR
if hasattr(resource, "__enter__"):
VAR = resource.__enter__()
else:
VAR = None
try:
try:
BODY
except:
raise # Force realisation of sys.exc_info() for use in __exit__()
finally:
if hasattr(resource, "__exit__"):
VAR = resource.__exit__()
else:
VAR = None
Generator objects could implement this protocol, with the following behaviour:
def __enter__():
try:
return self.next()
except StopIteration:
raise RuntimeError("Generator exhausted, unable to enter with 
block")
def __exit__():
try:
return self.next()
except StopIteration:
return None
def __except__(*exc_info):
pass
def __no_except__():
pass
Note that the code template can deal with exceptions quite happily by utilising 
sys.exc_info(), and that the result of the call to __enter__ is available 
*inside* the with block, while the result of the call to __exit__ is available 
*after* the block (useful for multi-part blocks).

If I want to drain the template, then I can use a 'for' loop (albeit without the 
cleanup guarantees).

Taking this route would mean that:
  * PEP 310 and the question of passing values or exceptions into iterators 
would again become orthogonal
  * Resources written using generator syntax aren't cluttered with the 
repetitive try/finally code PEP 310 is trying to eliminate
  * 'for' remains TOOW to write an iterative loop
  * it is possible to execute _different_ suites between each yield in the 
template block, rather than being constrained to a single suite as in the 
looping case.
  * no implications for the semantics of 'return', 'break', 'continue'
  * 'yield' would not be usable inside a with block, unless the AbortIteration 
concept was adopting for forcible generator termination.

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

[Python-Dev] Re: anonymous blocks vs scope-collapse

[Jim Jewett]

Michael Hudson:

> This proposal seems a bit like an effort to make generators good at 
> doing something that they aren't really intended -- or dare I say 
> suited? -- for. 

I think it is more an effort to use the right keyword, which has 
unfortunately already been claimed by generators (and linked
to iterators).

yield

is a sensible way for code to say "your turn, but come back later".

But at the moment, it means "I am producing an intermediate value",
and the way to call that function is to treat it as an iterator (which
seems to imply looping over a closed set, so don't send in more
information after the initial setup).

Should we accept that "yield" is already used up, or should we
shoehorn the concepts until they're "close enough"?

> So, here's a counterproposal!

> with expr as var:
> ... code ...

> is roughly:

> def _(var):
>  ... code ...
> __private = expr
> __private(_)

...

> The need for approximation in the above translation is necessary 
> because you'd want to make assignments in '...code...' affect the scope 
> their written in, 

To me, this seems like the core requirement.  I see three sensible paths:

(1)  Do nothing.

(2)  Add a way to say "Make this function I'm calling use *my* locals 
and globals."  This seems to meet all the agreed-upon-as-good use 
cases, but there is disagreement over how to sensibly write it.  The 
calling function is the place that could get surprised, but people
who want thunks seem to want the specialness in the called function.

(3)  Add macros.  We still have to figure out how to limit their obfuscation.
Attempts to detail that goal seem to get sidetracked.

-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: Re: anonymous blocks

[Terry Reedy]

"Greg Ewing" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

> Terry Reedy wrote:

The part you quoted was by Nick Coghlan, not me, as indicated by the >> 
(now >>>) instead of > (which would now be >>) in front of the lines.

>>>Not supporting iterables makes it harder to write a class which is
...



___
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

[Andrew Koenig]

> This doesn't feel right to me.  By that argument, people would want
> to "improve"
> 
>   (mapcar (lambda (x) (car x)) list-of-lists)
> 
> to
> 
>   (mapcar list-of-lists (x) (car x))
> 
> Have you ever heard someone complain about that lambda, though?

Wel  Shouldn't you have written

(mapcar car list-of-lists)

or am I missing something painfully obvious?

___
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/25/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > 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:

Not really. It's easier for me to show that id(3) is always the same
and id([]) not, and let the kids see that's not so easy and you'll
have to look deeper if you want to know better.

If I did id(3) and id(500), then the difference would look more
subtle, and I would had to explain it longer. Remember, it was the
second day (2 hours per day).


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

These are exactly my doubts, ;).

.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] Re: Caching objects in memory

[Facundo Batista]

On 4/26/05, Greg Ewing <[EMAIL PROTECTED]> wrote:

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

This simplifies the whole thing.

If the issue arises again, my speech will be: "Don't worry about that,
Python worries for you". :D

And I *someone* in particular keeps interested in it (I'm pretty sure
the whole class won't), I'll explain it to him better, and with more
time.

Thank you!

.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] Re: anonymous blocks vs scope-collapse

[Guido van Rossum]

> (2)  Add a way to say "Make this function I'm calling use *my* locals
> and globals."  This seems to meet all the agreed-upon-as-good use
> cases, but there is disagreement over how to sensibly write it.  The
> calling function is the place that could get surprised, but people
> who want thunks seem to want the specialness in the called function.

I think there are several problems with this. First, it looks
difficult to provide semantics that cover all the corners for the
blending of two namespaces. What happens to names that have a
different meaning in each scope? (E.g. 'self' when calling a method of
another object; or any other name clash.) Are the globals also
blended? How? Second, this construct only makes sense for all
callables; you seem to want to apply it for function (and I suppose
methods, whether bound or not), but it makes no sense when the
callable is implemented as a C function, or is a class, or an object
with a __call__ method. Third, I expect that if we solve the first two
problems, we'll still find that for an efficient implementation we
need to modify the bytecode of the called function.

If you really want to pursue this idea beyond complaining "nobody
listens to me" (which isn't true BTW), I suggest that you try to
define *exactly* how you think it should work. Try to make sure that
it can be used in a "statement context" as well as in an "expression
context". You don't need to come up with a working implementation, but
you should be able to convince me (or Raymond H :-) that it *can* be
implemented, and that the performance will be reasonable, and that it
won't affect performance when not used, etc.

If you think that's beyond you, then perhaps you should accept "no" as
the only answer you're gonna get. Because I personally strongly
suspect that it won't work, so the burden of "proof", so to speak, is
on you.

> (3)  Add macros.  We still have to figure out how to limit their obfuscation.
> Attempts to detail that goal seem to get sidetracked.

No, the problem is not how to limit the obfuscation. The problem is
the same as for (2), only more so: nobody has given even a *remotely*
plausible mechanism for how exactly you would get code executed at
compile time. You might want to look at Boo, a Python-inspired
language that translates to C#. They have something they call
syntactic macros: http://boo.codehaus.org/Syntactic+Macros .

-- 
--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: anonymous blocks

[Samuele Pedroni]

Michael Hudson wrote:
The history of iterators and generators could be summarized by saying 
that an API was invented, then it turned out that in practice one way 
of implementing them -- generators -- was almost universally useful.

This proposal seems a bit like an effort to make generators good at 
doing something that they aren't really intended -- or dare I say 
suited? -- for.  The tail wagging the dog so to speak.

it is fun because the two of us sort of already had this discussion in 
compressed form a lot of time ago:

http://groups-beta.google.com/groups?q=with+generators+pedronis&hl=en
not that I was really conviced about my idea at the time which was very 
embrional,  and in fact I'm bit skeptical right now about how much 
bending or not of generators makes sense, especially for a learnability 
point of view.
___
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

[Michael Hudson]

Samuele Pedroni <[EMAIL PROTECTED]> writes:

> Michael Hudson wrote:
>
>> The history of iterators and generators could be summarized by
>> saying that an API was invented, then it turned out that in practice
>> one way of implementing them -- generators -- was almost universally
>> useful.
>>
>> This proposal seems a bit like an effort to make generators good at
>> doing something that they aren't really intended -- or dare I say
>> suited? -- for.  The tail wagging the dog so to speak.
>>
> it is fun because the two of us sort of already had this discussion in
> compressed form a lot of time ago:

Oh yes.  That was the discussion that led to PEP 310 being written.

> http://groups-beta.google.com/groups?q=with+generators+pedronis&hl=en

At least I'm consistent :)

> not that I was really conviced about my idea at the time which was
> very embrional,  and in fact I'm bit skeptical right now about how
> much bending or not of generators makes sense, especially for a
> learnability point of view.

As am I, obviously.

Cheers,
mwh

-- 
  Agh, the braindamage!  It's not unlike the massively
  non-brilliant decision to use the period in abbreviations
  as well as a sentence terminator.  Had these people no
  imagination at _all_? -- Erik Naggum, comp.lang.lisp
___
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

[ron adam]

Hi, this is my first post here and I've been following this very 
interesting discussion as is has developed. 

A really short intro about me,  I was trained as a computer tech in the 
early 80's... ie. learned transistors, gates, logic etc...  And so my 
focus tends to be from that of a troubleshooter.  I'm medically retired 
now (not a subject for here) and am looking for something meaningful and 
rewarding that I can contribute to with my free time.

I will not post often at first as I am still getting up to speed with 
CVS and how Pythons core works.  Hopefully I'm not lagging this 
discussion too far or adding unneeded noise to it.  :-)

So maybe the 'with' keyword should be dropped (again!) in
favour of
  with_opened(pathname) as f:
...
But that doesn't look so great for the case where there's no variable
to be assigned to -- I wasn't totally clear about it, but I meant the
syntax to be
   with [VAR =] EXPR: BLOCK
where VAR would have the same syntax as the left hand side of an
assignment (or the variable in a for-statement).
I keep wanting to read it as:
  with OBJECT [from EXPR]: BLOCK
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.
Below is what gives me the clearest picture so far.  To me there is 
nothing 'anonymous' going on here.  Which is good I think. :-)

After playing around with Guido's example a bit, it looks to me the role 
of a 'with' block is to define the life of a resource object.  so "with 
OBJECT: BLOCK" seems to me to be the simplest and most natural way to 
express this.

def with_file(filename, mode):
  """ Create a file resource """
  f = open(filename, mode)
  try:
  yield f# use yield here
  finally:
  # Do at exit of 'with : '
  f.close
# Get a resource/generator object and use it.
f_resource = with_file('resource.py', 'r')
with f_resource:
  f = f_resource.next()   # get values from yields
  for line in f:
  print line,
# Generator resource with yield loop.
def with_file(filename):
  """ Create a file line resource """
  f = open(filename, 'r')  try:
  for line in f:
  yield line
  finally:
  f.close()
 # print lines in this file.
f_resource = with_file('resource.py')
with f_resource:
  while 1:
  line = f_resource.next()
  if line == "":
  break
  print line,
The life of an object used with a 'with' block is shorter than that of 
the function it is called from, but if the function is short, the life 
could be the same as the function. Then the 'with' block could be 
optional if the resource objects __exit__ method is called when the 
function exits, but that may require some way to tag a resource as being 
different from other class's and generators to keep from evaluating 
__exit__ methods of other objects.
As far as looping behaviors go, I prefer the loop to be explicitly 
defined in the resource  or the body of the 'with', because it looks to 
be more flexible.

Ron_Adam
# "The right question is a good start to finding the correct answer."
___
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

[Aahz]

On Tue, Apr 26, 2005, Guido van Rossum wrote:
>
> Now there's one more twist, which you may or may not like.  Presumably
> (barring obfuscations or bugs) the handling of BreakFlow and
> ContinueFlow by an iterator (or generator) is consistent for all uses
> of that particular iterator.  For example synchronized(lock) and
> transactional(db) do not behave as loops, and forever() does.  Ditto
> for handling ReturnFlow.  This is why I've been thinking of leaving
> out the 'with' keyword: in your mind, these calls would become new
> statement types, even though the compiler sees them all the same:
> 
> synchronized(lock):
> BLOCK
> 
> transactional(db):
> BLOCK
> 
> forever():
> BLOCK
> 
> opening(filename) as f:
> BLOCK

That's precisely why I think we should keep the ``with``: the point of
Python is to have a restricted syntax and requiring a prefix for these
constructs makes it easier to read the code.  You'll soon start to gloss
over the ``with`` but it will be there as a marker for your subconscious.
-- 
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

[Python-Dev] atexit missing an unregister method

[Nick Jacobson]

I was looking at the atexit module the other day; it seems like an elegant 
way to ensure that resources are cleaned up (that the garbage collector 
doesn't take care of).

But while you can mark functions to be called with the 'register' method, 
there's no 'unregister' method to remove them from the stack of functions to 
be called.  Nor is there any way to view this stack and e.g. call 'del' on a 
registered function.

This would be useful in the following scenario, in which x and y are 
resources that need to be cleaned up, even in the event of a program exit:

import atexit
def free_resource(resource):
   ...
atexit.register(free_resource, x)
atexit.register(free_resource, y)
# do operations with x and y, potentially causing the program to exit
...
# if nothing caused the program to unexpectedly quit, close the resources
free_resource(x)
free_resource(y)
#unregister the functions, so that you don't try to free the resources 
twice!
atexit.unregisterall()

Alternatively, it would be great if there were a way to view the stack of 
registered functions, and delete them from there.

--Nick Jacobson
_
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

___
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] atexit missing an unregister method

[Guido van Rossum]

On 4/26/05, Nick Jacobson <[EMAIL PROTECTED]> wrote:
> I was looking at the atexit module the other day; it seems like an elegant
> way to ensure that resources are cleaned up (that the garbage collector
> doesn't take care of).
> 
> But while you can mark functions to be called with the 'register' method,
> there's no 'unregister' method to remove them from the stack of functions to
> be called.  Nor is there any way to view this stack and e.g. call 'del' on a
> registered function.
> 
> This would be useful in the following scenario, in which x and y are
> resources that need to be cleaned up, even in the event of a program exit:
> 
> import atexit
> 
> def free_resource(resource):
> ...
> 
> atexit.register(free_resource, x)
> atexit.register(free_resource, y)
> # do operations with x and y, potentially causing the program to exit
> ...
> # if nothing caused the program to unexpectedly quit, close the resources
> free_resource(x)
> free_resource(y)
> #unregister the functions, so that you don't try to free the resources
> twice!
> atexit.unregisterall()
> 
> Alternatively, it would be great if there were a way to view the stack of
> registered functions, and delete them from there.

Methinks that the resource cleanup routines ought to be written so as
to be reentrant. That shouldn't be too hard (you can always maintain a
global flag that means "already called").

-- 
--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] atexit missing an unregister method

[Skip Montanaro]

Nick> But while you can mark functions to be called with the 'register'
Nick> method, there's no 'unregister' method to remove them from the
Nick> stack of functions to be called.  Nor is there any way to view
Nick> this stack and e.g. call 'del' on a registered function.

Nick> This would be useful in the following scenario, in which x and y
Nick> are resources that need to be cleaned up, even in the event of a
Nick> program exit:

Nick> import atexit

Nick> def free_resource(resource):
Nick> ...

Nick> atexit.register(free_resource, x)
Nick> atexit.register(free_resource, y)
Nick> # do operations with x and y, potentially causing the program to exit
Nick> ...
Nick> # if nothing caused the program to unexpectedly quit, close the 
resources
Nick> free_resource(x)
Nick> free_resource(y)
Nick> #unregister the functions, so that you don't try to free the 
resources 
Nick> twice!
Nick> atexit.unregisterall()

This seems like a poor argument for unregistering exit handlers.  If you've
registered an exit handler, why then explicitly do what you've already asked
the system to do?  Also, your proposed unregisterall() function would be
dangerous.  As an application writer you don't know what other parts of the
system (libraries you use, for example) might have registered exit
functions.

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

Re: [Python-Dev] atexit missing an unregister method

[Aahz]

On Tue, Apr 26, 2005, Nick Jacobson wrote:
>
> I was looking at the atexit module the other day; it seems like an elegant 
> way to ensure that resources are cleaned up (that the garbage collector 
> doesn't take care of).
> 
> But while you can mark functions to be called with the 'register' method, 
> there's no 'unregister' method to remove them from the stack of functions 
> to be called.  Nor is there any way to view this stack and e.g. call 'del' 
> on a registered function.
> 
> This would be useful in the following scenario, in which x and y are 
> resources that need to be cleaned up, even in the event of a program exit:
> 
> import atexit
> 
> def free_resource(resource):
>...
> 
> atexit.register(free_resource, x)
> atexit.register(free_resource, y)

This seems like the wrong way.  Why not do this:

class ResourceCleanup:
def register(self, resource, func): ...
def unregister(self, resource): ...
def __call__(self): ...

handler = ResourceCleanup)
atexit.register(handler)
handler.register(x, free_resource)
do(x)
handler.unregister(x)

Probably further discussion should go to comp.lang.python
-- 
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] Removing --with-wctype-functions support

[Martin v. Löwis]

S.ÃaÄlar Onur wrote:
> I want to know status of
> http://mail.python.org/pipermail/python-dev/2004-December/050193.html
> this thread. 

The status is that they are still there.

> Will python remove wctype functions support from its core?

I don't know what MAL's plans are these days, but it is likely that
he will remove the functions from the places where they are used
at the moment.

> If it will, what about locale-dependent case conversation functions? 
> 
> Without this support python behaves wrong in tr_TR.UTF-8 locale.

I can sympathise with the problem. IMO, the right solution is to provide
them throught the locale module. That would have the advantage that
the choice of locale-awareness of Unicode case conversions (etc.) is
a per-script decision, rather than an interpreter built-time decision.

Patches in this direction (adding the functions to _localemodule.c)
are welcome, independent of whether they are removed from the methods
on Unicode objects. Such functions should probably polymorphically
operate both on byte strings and Unicode strings, allowing to deprecate
the locale-specific methods on strings as well.

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

RE: [Python-Dev] atexit missing an unregister method

[Raymond Hettinger]

[Nick Jacobson]
> I was looking at the atexit module the other day; it seems like an
elegant
> way to ensure that resources are cleaned up (that the garbage
collector
> doesn't take care of).
> 
> But while you can mark functions to be called with the 'register'
method,
> there's no 'unregister' method to remove them from the stack of
functions
> to
> be called.  
 . . .
> Alternatively, it would be great if there were a way to view the stack
of
> registered functions, and delete them from there.



Please file a feature request on SourceForge.

Will mull it over for a while.  My first impression is that try/finally
is a better tool for the scenario you outlined.  

The issue with unregister() is that the order of clean-up calls is
potentially significant.  If the same function is listed more than once,
there would be no clear-cut way to know which should be removed when
unregister() is called.

Likewise, I suspect that exposing the stack will create more pitfalls
and risks than it could provide in benefits.  Dealing with a stack of
functions is likely to be clumsy at best.


Raymond Hettinger
___
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] Removing --with-wctype-functions support

[M.-A. Lemburg]

Martin v. LÃwis wrote:
S.ÃaÄlar Onur wrote:
I want to know status of
http://mail.python.org/pipermail/python-dev/2004-December/050193.html
this thread. 

The status is that they are still there.
Due to lack of time on my part.
Will python remove wctype functions support from its core?

I don't know what MAL's plans are these days, but it is likely that
he will remove the functions from the places where they are used
at the moment.
Right. I haven't heard any complaints, so that's the plan.
If it will, what about locale-dependent case conversation functions? 

Without this support python behaves wrong in tr_TR.UTF-8 locale.
Could you be more specific about the problem ? It's probably
best to open a bug report in SourceForge.
I can sympathise with the problem. IMO, the right solution is to provide
them throught the locale module. That would have the advantage that
the choice of locale-awareness of Unicode case conversions (etc.) is
a per-script decision, rather than an interpreter built-time decision.
Patches in this direction (adding the functions to _localemodule.c)
are welcome, independent of whether they are removed from the methods
on Unicode objects. Such functions should probably polymorphically
operate both on byte strings and Unicode strings, allowing to deprecate
the locale-specific methods on strings as well.
+1, though we will only want to deprecate the "locale dependency",
not the methods themselves ;-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Apr 26 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

[Python-Dev] Re: atexit missing an unregister method

[Nick Jacobson]

<< This seems like a poor argument for unregistering exit handlers.  If 
you've
registered an exit handler, why then explicitly do what you've already asked
the system to do? >>

1. To free up memory for the rest of the program.
2. If the following block is in a loop, and you need to allocate & then 
deallocate resources multiple times.:

<< atexit.register(free_resource, x)
atexit.register(free_resource, y)
# do operations with x and y, potentially causing the program to exit
...
# if nothing caused the program to unexpectedly quit, close the resources
free_resource(x)
free_resource(y) >>
<<  Also, your proposed unregisterall() function would be
dangerous.  As an application writer you don't know what other parts of the
system (libraries you use, for example) might have registered exit
functions.
Skip >>
That's true...it would probably be better to expose the stack of registered 
functions.  That way you can manually unregister functions you've 
registered.

--Nick Jacobson
_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

___
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: atexit missing an unregister method

[Nick Jacobson]

Raymond Hettinger wrote:
<< Will mull it over for a while.  My first impression is that try/finally
is a better tool for the scenario you outlined.  >>
You're right.  try/finally takes care of my sample scenario.  There may 
still be a case to be made for atexit.unregister(), though.

--Nick Jacobson
_
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

___
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] python.org crashing Mozilla?

[Heiko Wundram]

Am Dienstag, 26. April 2005 22:53 schrieb Paul Dubois:
> Three different computers running Linux / Mozilla are crashing Mozilla
> when directed to python.org. A Netscape works ok. Are we hacked or are
> we showing off?

Firefox on Gentoo works okay...?

-- 
--- Heiko.
listening to: Incubus - Megalomaniac
  see you at: http://www.stud.mh-hannover.de/~hwundram/wordpress/


pgpFEmDQR8jXl.pgp
Description: PGP signature
___
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] Problem with embedded python

[Ugo Di Girolamo]

I have the following code, that seems to make sense to me. 


However, it crashes about 1/3 of the times. 


My platform is Python 2.4.1 on WXP (I tried the release version from 
the msi and the debug version built by me, both downloaded today to 
have the latest version). 


The crash happens while the main thread is in Py_Finalize. 
I traced the crash to _Py_ForgetReference(op) in object.c at line 1847, 
where I have op->_ob_prev == NULL.


What am I doing wrong? I'm definitely not too sure about the way I'm 
handling the GIL. 


Thanks in adv for any suggestion/ comment


Cheers and ciao 


Ugo 


// TestPyThreads.py // 
#include  
#include "Python.h" 


int main() 
{ 
PyEval_InitThreads(); 
Py_Initialize(); 
PyGILState_STATE main_restore_state = PyGILState_UNLOCKED; 
PyGILState_Release(main_restore_state); 


// start the thread 
{ 
PyGILState_STATE state = PyGILState_Ensure(); 
int trash = PyRun_SimpleString( 
"import thread\n" 
"import time\n" 
"def foo():\n" 
"  f = open('pippo.out', 'w', 0)\n" 
"  i = 0;\n" 
"  while 1:\n" 
"f.write('%d\\n'%i)\n" 
"time.sleep(0.01)\n" 
"i += 1\n" 
"t = thread.start_new_thread(foo, ())\n" 
); 
PyGILState_Release(state); 
} 


// wait 300 ms 
Sleep(300); 


PyGILState_Ensure(); 
Py_Finalize(); 
return 0; 

} 
___
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]

Phillip J. Eby wrote:
At 09:12 PM 4/24/05 -0600, Steven Bethard wrote:
I guess it would be helpful to see example where the looping
with-block is useful.

Automatically retry an operation a set number of times before hard failure:
with auto_retry(times=3):
do_something_that_might_fail()
Process each row of a database query, skipping and logging those that 
cause a processing error:

with x,y,z = log_errors(db_query()):
do_something(x,y,z)
You'll notice, by the way, that some of these "runtime macros" may be 
stackable in the expression.
These are also possible by combining a normal for loop with a non-looping with 
(but otherwise using Guido's exception injection semantics):

def auto_retry(attempts):
success = [False]
failures = [0]
except = [None]
def block():
try:
yield None
except:
failures[0] += 1
else:
success[0] = True
while not success[0] and failures[0] < attempts:
yield block()
if not success[0]:
raise Exception # You'd actually propagate the last inner failure
for attempt in auto_retry(3):
with attempt:
do_something_that_might_fail()
The non-looping version of with seems to give the best of both worlds - 
multipart operation can be handled by multiple with statements, and repeated use 
of the same suite can be handled by nesting the with block inside iteration over 
an appropriate generator.

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: atexit missing an unregister method

[Martin v. Löwis]

Nick Jacobson wrote:
> You're right.  try/finally takes care of my sample scenario.  There may
> still be a case to be made for atexit.unregister(), though.

No. Anybody in need of such a feature can easily unregister it.

allregistrations=[]

def _run():
  for fn in allregistrations:
fn()

atexit.register(_run)

def register(fn):
  allregistrations.append(fn)

def unregister(fn):
  allregistrations.remove(fn)

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 vs scope-collapse

[Jim Jewett]

>> (2)  Add a way to say "Make this function I'm calling use *my* locals
>> and globals."  This seems to meet all the agreed-upon-as-good use
>> cases, but there is disagreement over how to sensibly write it.  The
>> calling function is the place that could get surprised, but people
>> who want thunks seem to want the specialness in the called function.

> I think there are several problems with this. First, it looks
> difficult to provide semantics that cover all the corners for the
> blending of two namespaces. What happens to names that have a
> different meaning in each scope? 

Programming error.  Same name ==> same object.  

If a function is using one of _your_ names for something incompatible,
then don't call that function with collapsed scope.  The same "problem"
happens with globals today.  Code in module X can break if module Y
replaces (not shadows, replaces) a builtin with an incompatible object.

Except ...
> (E.g. 'self' when calling a method of
> another object; or any other name clash.) 

The first argument of a method *might* be a special case.  It seems
wrong to unbind a bound method.  On the other hand, resource
managers may well want to use unbound methods for the called
code.

> Are the globals also blended?  How?

Yes.  The callee does not even get to see its normal namespace.
Therefore, the callee does not get to use its normal name resolution.

If the name normally resolves in locals (often inlined to a tuple, today), 
it looks in the shared scope, which is "owned" by the caller.  This is 
different from a free variable only because the callee can write to this 
dictionary.

If the name is free in that shared scope, (which implies that the 
callee does not bind it, else it would be added to the shared scope) 
then the callee looks up the caller's nested stack and then to the 
caller's globals, and then the caller's builtins.

> Second, this construct only makes sense for all callables; 

Agreed.  

But using it on a non-function may cause surprising results
especially if bound methods are not special-cased.

The same is true of decorators, which is why we have (at least 
initially) "function decorators" instead of "callable decorators".

> it makes no sense when the callable is implemented as
> a C function, 

Or rather, it can't be implemented, as the compiler may well
have optimized the variables names right out.  Stack frame
transitions between C and python are already special.

> or is a class, or an object with a __call__ method. 

These are just calls to __init__ (or __new__) or __call__.
These may be foolish things to call (particularly if the first
argument to a method isn't special-cased), but ... it isn't
a problem if the class is written appropriately.  If the class
is not written appropriately, then don't call it with collapsed 
scope.

> Third, I expect that if we solve the first two
> problems, we'll still find that for an efficient implementation we
> need to modify the bytecode of the called function.

Absolutely.  Even giving up the XXX_FAST optimizations would 
still require new bytecode to not assume them.  (Deoptimizing 
*all* functions, in *all* contexts, is not a sensible tradeoff.)

Eventually, an optimizing compiler could do the right thing, but ... 
that isn't the point.  

For a given simple algorithm, interpeted python is generally slower 
than compiled C, but we write in python anyhow -- it is fast enough, 
and has other advantages.  The same is true of anything that lets 
me not cut-and-paste.  

> Try to make sure that it can be used in a "statement context" 
> as well as in an "expression context". 

I'm not sure I understand this.  The preferred way would be
to just stick the keyword before the call.  Using 'collapse', it
would look like:

def foo(b):
c=a
def bar():
a="a1"
collapse foo("b1")
print b, c# prints "b1", "a1"
a="a2"
foo("b2")# Not collapsed this time
print b, c# still prints "b1", "a1"

but I suppose you could treat it like the 'global' keyword

def bar():
a="a1"
collapse foo   # forces foo to always collapse when called within bar
foo("b1")
print b, c# prints "b1", "a1"
a="a2"
foo("b2")# still collapsed
print b, c# now prints "b2", "a2"

>> [Alternative 3 ... bigger that merely collapsing scope]
>> (3)  Add macros.  We still have to figure out how to limit their obfuscation.
>> Attempts to detail that goal seem to get sidetracked.

> No, the problem is not how to limit the obfuscation. The problem is
> the same as for (2), only more so: nobody has given even a *remotely*
> plausible mechanism for how exactly you would get code executed at
> compile time.

macros can (and *possibly* should) be evaluated at run-time.  

Compile time should be possible (there is an interpreter running) and 
faster, but ... is certainly not required.

Even if the macros just rerun 

Re: [Python-Dev] Problem with embedded python

[Martin v. Löwis]

Ugo Di Girolamo wrote:
> What am I doing wrong?

This is not the forum to ask this question, please use
python-list@python.org instead.

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

RE: [Python-Dev] Problem with embedded python

[Ugo Di Girolamo]

Sorry.

will do.

Ugo


-Original Message-
From: "Martin v. Löwis" [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 26, 2005 2:31 PM
To: Ugo Di Girolamo
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Problem with embedded python


Ugo Di Girolamo wrote:
> What am I doing wrong?

This is not the forum to ask this question, please use
python-list@python.org instead.

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

Re: [Python-Dev] Re: anonymous blocks vs scope-collapse

[Paul Moore]

On 4/26/05, Jim Jewett <[EMAIL PROTECTED]> wrote:
> I'm not sure I understand this.  The preferred way would be
> to just stick the keyword before the call.  Using 'collapse', it
> would look like:
> 
> def foo(b):
> c=a
> def bar():
> a="a1"
> collapse foo("b1")
> print b, c# prints "b1", "a1"
> a="a2"
> foo("b2")# Not collapsed this time
> print b, c# still prints "b1", "a1"

*YUK* I spent a long time staring at this and wondering "where did b come from?"

You'd have to come up with a very compelling use case to get me to like this.

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

[Python-Dev] python.org crashing Mozilla?

[Paul Dubois]

Three different computers running Linux / Mozilla are crashing Mozilla 
when directed to python.org. A Netscape works ok. Are we hacked or are 
we showing off?


___
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 vs scope-collapse

[Guido van Rossum]

[Jim Jewett]
> >> (2)  Add a way to say "Make this function I'm calling use *my* locals
> >> and globals."  This seems to meet all the agreed-upon-as-good use
> >> cases, but there is disagreement over how to sensibly write it.  The
> >> calling function is the place that could get surprised, but people
> >> who want thunks seem to want the specialness in the called function.

[Guido]
> > I think there are several problems with this. First, it looks
> > difficult to provide semantics that cover all the corners for the
> > blending of two namespaces. What happens to names that have a
> > different meaning in each scope?

[Jim]
> Programming error.  Same name ==> same object.

Sounds like a recipe for bugs to me. At the very least it is a total
breach of abstraction, which is the fundamental basis of the
relationship between caller and callee in normal circumstances. The
more I understand your proposal the less I like it.

> If a function is using one of _your_ names for something incompatible,
> then don't call that function with collapsed scope.  The same "problem"
> happens with globals today.  Code in module X can break if module Y
> replaces (not shadows, replaces) a builtin with an incompatible object.
> 
> Except ...
> > (E.g. 'self' when calling a method of
> > another object; or any other name clash.)
> 
> The first argument of a method *might* be a special case.  It seems
> wrong to unbind a bound method.  On the other hand, resource
> managers may well want to use unbound methods for the called
> code.

Well, what would you pass in as the first argument then?

> > Are the globals also blended?  How?
> 
> Yes.  The callee does not even get to see its normal namespace.
> Therefore, the callee does not get to use its normal name resolution.

Another breach of abstraction: if a callee wants to use an imported
module, the import should be present in the caller, not in the callee.

This seems to me to repeat all the mistakes of the dynamic scoping of
early Lisps (including GNU Emacs Lisp I believe).

It really strikes me as an endless source of errors that these
blended-scope callees (in your proposal) are ordinary
functions/methods, which means that they can *also* be called without
blending scopes. Having special syntax to define a callee intended for
scope-blending seems much more appropriate (even if there's also
special syntax at the call site).

> If the name normally resolves in locals (often inlined to a tuple, today),
> it looks in the shared scope, which is "owned" by the caller.  This is
> different from a free variable only because the callee can write to this
> dictionary.

Aha! This suggests that a blend-callee needs to use different bytecode
to avoid doing lookups in the tuple of optimized locals, since the
indices assigned to locals in the callee and the caller won't match up
except by miracle.

> If the name is free in that shared scope, (which implies that the
> callee does not bind it, else it would be added to the shared scope)
> then the callee looks up the caller's nested stack and then to the
> caller's globals, and then the caller's builtins.
> 
> > Second, this construct only makes sense for all callables;

(I meant this to read "does not make sense for all callables".)

> Agreed.

(And I presume you read it that way. :-)

> But using it on a non-function may cause surprising results
> especially if bound methods are not special-cased.
> 
> The same is true of decorators, which is why we have (at least
> initially) "function decorators" instead of "callable decorators".

Not true. It is possible today to write decorators that accept things
other than functions -- in fact, this is often necessary if you want
to write decorators that combine properly with other decorators that
don't return function objects (such as staticmethod and classmethod).

> > it makes no sense when the callable is implemented as
> > a C function,
> 
> Or rather, it can't be implemented, as the compiler may well
> have optimized the variables names right out.  Stack frame
> transitions between C and python are already special.

Understatement of the year. There just is no similarity between C and
Python stack frames. How much do you really know about Python's
internals???

> > or is a class, or an object with a __call__ method.
> 
> These are just calls to __init__ (or __new__) or __call__.

No they're not. Calling a class *first* creates an instance (calling
__new__ if it exists) and *then* calls __init__ (if it exists).

> These may be foolish things to call (particularly if the first
> argument to a method isn't special-cased), but ... it isn't
> a problem if the class is written appropriately.  If the class
> is not written appropriately, then don't call it with collapsed
> scope.

That's easy for you to say. Since the failure behavior is so messy I'd
rather not get started.

> > Third, I expect that if we solve the first two
> > problems, we'll still find that for an efficient implementation we
> > nee

RE: [Python-Dev] Re: atexit missing an unregister method

[Raymond Hettinger]

[Raymond Hettinger]
> << Will mull it over for a while.  My first impression is that
try/finally
> is a better tool for the scenario you outlined.  >>


[Nick Jacobson]
> You're right.  try/finally takes care of my sample scenario.  There
may
> still be a case to be made for atexit.unregister(), though.

Now is the time to move the discussion to SF feature requests or to
comp.lang.python.  If you devote time to "making a case", then also
devote equal effort to researching the hazards and API issues.  

"Potentially useful" is usually trumped by "potentially harmful".  Also,
if the API is awkward or error-prone, that is a bad sign.

Specifically, consider whether exposing the data structure opens the
possibility of accidentally violating invariants assumed by other calls
of atexit().

With respect to the API, consider whether you could explain to a newbie
(who has just finished the tutorial) how to access the structure, lookup
a target function, and make appropriate modifications without breaking
anything else.



Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: anonymous blocks vs scope-collapse

[Guido van Rossum]

[Paul Moore]
> *YUK* I spent a long time staring at this and wondering "where did b come 
> from?"
> 
> You'd have to come up with a very compelling use case to get me to like this.

I couldn't have said it better.

I said it longer though. :-)

-- 
--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] python.org crashing Mozilla?

[Fred L. Drake, Jr.]

On Tuesday 26 April 2005 16:53, Paul Dubois wrote:
 > Three different computers running Linux / Mozilla are crashing Mozilla
 > when directed to python.org. A Netscape works ok. Are we hacked or are
 > we showing off?

Paul,

My Firefox 1.0.2 is fine.  What version(s) of Mozilla, and what host 
platforms, would be helpful.


  -Fred

-- 
Fred L. Drake, Jr.
___
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: a few SF bugs which can (probably) be closed

[Terry Reedy]

"Ilya Sandler" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Here a few sourceforge bugs which can probably be closed:
>
> [ 1168983 ] : ftplib.py string index out of range
> Original poster reports that the problem disappeared after a patch
> committed by Raymond

Not clear to me if this is really finished or not.  Leaving for Raymond or 
... .  Closed 3 below.

> [ 1178863 ] Variable.__init__ uses self.set(), blocking specialization
> seems like a dup of 1178872

Closed latter.

> [ 415492 ] Compiler generates relative filenames
> seems to have been fixed at some point. I could not reproduce it with
> python2.4
>
> [ 751612 ] smtplib crashes Windows Kernal.
> Seems like an obvious Windows bug (not python's bug) and seems to be
> unreproducible

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

[Python-Dev] scope-collapse

[Jim Jewett]

[Jim Jewett]
>> >> (2)  Add a way to say "Make this function I'm calling use *my* locals
>> >> and globals."  This seems to meet all the agreed-upon-as-good use
>> >> cases, but there is disagreement over how to sensibly write it.

[Guido]
>> > What happens to names that have a
>> > different meaning in each scope?

[Jim]
>> Programming error.  Same name ==> same object.

> Sounds like a recipe for bugs to me. At the very least it is a total
> breach of abstraction, which is the fundamental basis of the
> relationship between caller and callee in normal circumstances.

Yes.  Collapsing scope is not a good idea in general.  But there
is no way to avoid (some version of) it under the thunk or even
the resource-manager suggestions.  I interpret that to mean that
either 
The code *can* get ugly and you rely on conventions.
or 
These constructs should not be added to the language.

The pretend-it-is-a-generator proposals try to specify that only 
certain names will be shared, in only certain ways.  That might
work (practicality beats purity) but I suspect it will evolve into a
wart.  It won't be quite strong enough to solve the problem 
completely (particularly with multiple blocks), but it will be 
strong enough to obfuscate when mishandled.

>> Yes.  The callee does not even get to see its normal namespace.
>> Therefore, the callee does not get to use its normal name resolution.

> This seems to me to repeat all the mistakes of the dynamic scoping 
> of early Lisps (including GNU Emacs Lisp I believe).

With one exception -- the caller must state explicitly that the collapse
it happening, and even then, it only goes down one level at a time.
Still an ugly tool, but at least not an ugly surprise.

> It really strikes me as an endless source of errors that these
> blended-scope callees (in your proposal) are ordinary
> functions/methods, which means that they can *also* be called without
> blending scopes. Having special syntax to define a callee intended for
> scope-blending seems much more appropriate (even if there's also
> special syntax at the call site).

This might well be a good restriction.  The number of times it causes
annoyance (why do I have to code this twice?) should be outweighed
by the number of times it saves a surprise (oops -- those functions 
both defined the same keyword argument).

>> If the name normally resolves in locals (often inlined to a tuple, today),
>> it looks in the shared scope, which is "owned" by the caller.  This is
>> different from a free variable only because the callee can write to this
>> dictionary.

> Aha! This suggests that a blend-callee needs to use different bytecode
> to avoid doing lookups in the tuple of optimized locals

Yes.  I believe the translation is mechanical, so that the compiler could
choose (or create) the right version based on the caller, but ... I agree
that making them a separate kind of callable would simplify things.

> (I meant this to read "does not make sense for all callables".)
> (And I presume you read it that way. :-)

nah... I think it takes special justification to do use anything but
duck typing in python.  If functions can intersperse with boilerplate,
than other callables (and even other suites, such as class definitions) 
should be able to do the same.  But I also agree that it makes sense 
to wait until it can be done sensibly.

Just as @decorator only applies to functions (even if the specific
decorator could accept something else), this interspersing should
probably not apply to non-functions until the "but I can't use a 
function" use cases are clear.

>> For a given simple algorithm, interpeted python is generally slower
>> than compiled C, but we write in python anyhow -- it is fast enough,
>> and has other advantages.  The same is true of anything that lets
>> me not cut-and-paste.

> Whatever. Any new feature that causes a measurable slowdown for code
> that does *not* need the feature has a REALLY hard time getting
> accepted,

Agreed.  But the scope-collapse penalty is restricted to the caller
(which ordered the collapse) and the immediate callees during
the collapsed call.  

>> I'm not sure I understand this.  The preferred way would be
>> to just stick the keyword before the call.  Using 'collapse', it
>> would look like:
  # (Added comment to make the ugliess
potential more explicit)
>> def foo(b): # Yes, parameters are in the namespace.  
>> c=a
>> def bar():
>> a="a1"
>> collapse foo("b1")
>> print b, c# prints "b1", "a1"
>> a="a2"
>> foo("b2")# Not collapsed this time
>> print b, c# still prints "b1", "a1"

> I'm trying to sensitize you to potential uses like this:

> def bar():
>a = "a1"
>print collapse foo("b1")

In this case, it would print None, as foo didn't bother to return anything.

> but I suppose you could treat it like the 'global' keyword

>> def ba

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

[Charles Hartman]

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?

Charles Hartman
___
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] atexit missing an unregister method

[Greg Ewing]

Nick Jacobson wrote:
But while you can mark functions to be called with the 'register' 
method, there's no 'unregister' method to remove them from the stack of 
functions to be called.
You can always build your own mechanism for managing
cleanup functions however you want, and register a
single atexit() hander to invoke it. I don't think
there's any need to mess with the way atexit()
currently works.
--
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] Re: scope-collapse (was: anonymous blocks)

[Robert Brewer]

[Jim Jewett]
> (2)  Add a way to say "Make this function I'm calling 
> use *my* locals and globals."  This seems to meet all
> the agreed-upon-as-good use cases, but there is disagreement
> over how to sensibly write it.  The calling function is
> the place that could get surprised, but people who want
> thunks seem to want the specialness in the 
> called function.

[Guido]
> I think there are several problems with this. First, it looks
> difficult to provide semantics that cover all the corners for the
> blending of two namespaces. What happens to names that have a
> different meaning in each scope?

[Jim]
> Programming error.  Same name ==> same object.

[Guido]
> Sounds like a recipe for bugs to me. At the very least it is a total
> breach of abstraction, which is the fundamental basis of the
> relationship between caller and callee in normal circumstances. The
> more I understand your proposal the less I like it.

[Jim]
> If a function is using one of _your_ names for something 
> incompatible, then don't call that function with collapsed
> scope.  The same "problem" happens with globals today.
> Code in module X can break if module Y replaces (not shadows,
> replaces) a builtin with an incompatible object.
> 
> Except ...
> (E.g. 'self' when calling a method of
> another object; or any other name clash.)
> 
> The first argument of a method *might* be a special case.  It seems
> wrong to unbind a bound method.  On the other hand, resource
> managers may well want to use unbound methods for the called
> code.

Urg. Please, no. If you're going to blend scopes, the callee should have
nothing passed to it. Why would you possibly want it when you already
have access to both scopes which are to be blended?


[Guido]
> Are the globals also blended?  How?

[Jim]
> Yes.  The callee does not even get to see its normal namespace.
> Therefore, the callee does not get to use its normal name 
> resolution.

[Guido]
> Another breach of abstraction: if a callee wants to use an imported
> module, the import should be present in the caller, not in the callee.

Yes, although if a callee wants to use a module that has not been
imported by the caller, it should be able to do so with a new import
statement (which then affects the namespace of the caller).

[Guido again]
> It really strikes me as an endless source of errors that these
> blended-scope callees (in your proposal) are ordinary
> functions/methods, which means that they can *also* be called without
> blending scopes. Having special syntax to define a callee intended for
> scope-blending seems much more appropriate (even if there's also
> special syntax at the call site).

Agreed. They shouldn't be ordinary functions at all, in my mind. That
means one can also mark the actual call on the callee side, instead of
the caller side; in other words, you wouldn't need a "collapse" keyword
at all if you formed the callee with a "defmacro" or other (better ;)
keyword. I guess if y'all find it surprising, you could keep "collapse".


[Jim]
> If the name normally resolves in locals (often inlined to a 
> tuple, today),
> it looks in the shared scope, which is "owned" by the 
> caller.  This is
> different from a free variable only because the callee can 
> write to this
> dictionary.

[Guido]
> Aha! This suggests that a blend-callee needs to use different bytecode
> to avoid doing lookups in the tuple of optimized locals, since the
> indices assigned to locals in the callee and the caller won't match up
> except by miracle.

[Guido]
> Third, I expect that if we solve the first two
> problems, we'll still find that for an efficient implementation we
> need to modify the bytecode of the called function.

[Jim]
> Absolutely.  Even giving up the XXX_FAST optimizations would
> still require new bytecode to not assume them.  (Deoptimizing
> *all* functions, in *all* contexts, is not a sensible tradeoff.)

I'm afraid I'm only familiar with CPython, but wouldn't callee locals
just map to XXX_FAST indices via the caller's co_names tuple?

Remapping jump targets, on the other hand, would be something to quickly
ban. You shouldn't be able to write trash like:

defmacro keepgoing:
else:
continue

[Guido]
> Try to make sure that it can be used in a "statement context"
> as well as in an "expression context".
...
> I'm trying to sensitize you to potential uses like this:
> 
> def foo(b):
> c=a
> def bar():
> a = "a1"
> print collapse foo("b1")

If the callees aren't real functions and don't get passed anything, the
"sensible" approach would be to disallow expression-context use of them.
Rewrite the above to:

defcallee foo:
c = a

def bar():
a = "a1"
collapse foo
print c


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

Re: [Python-Dev] defmacro

[Greg Ewing]

Stephen J. Turnbull wrote:
This doesn't feel right to me.  By that argument, people would want
to "improve"
  (mapcar (lambda (x) (car x)) list-of-lists)
to
  (mapcar list-of-lists (x) (car x))
I didn't claim that people would feel compelled to eliminate
all uses of lambda; only that, in those cases where they
*do* feel so compelled, they might not if lambda weren't
such a long word.
I was just trying to understand why Smalltalkers seem to
get on fine without macros, whereas Lispers feel they are
needed. I think Smalltalk's lightweight block-passing
syntax has a lot to do with it.
--
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] defmacro (was: Anonymous blocks)

[Jim Jewett]

>> >> (3)  Add macros.  We still have to figure out how to limit their
obfuscation.

>> > nobody has given even a *remotely*
>> > plausible mechanism for how exactly you would get code executed at
>> > compile time.
 
>> macros can (and *possibly* should) be evaluated at run-time.

> We must still have very different views on what a macro is.

In a compiled language, it is (necessarily) compiled.  In an interpreted
language, it doesn't have to be.

> After a macros is run, there is new syntax that needs to be parsed 
> and compiled to bytecode.   ... anything that requires invoking the
> compiler each time a macro is used will be so slow that nobody will
> want to use it.

I had been thinking that the typical use would be during function (or
class) definition.  The overhead would be similar to that of decorators,
and confined mostly to module loading.

I do see your point that putting a macro call inside a function could be
slow -- but I'm not sure that is a reason to forbid it.

>> Even if the macros just rerun the same boilerplate code less efficiently,
>> it is still good to have that boilerplate defined once, instead of cutting
>> and pasting.  Or, at least, it is better *if* that once doesn't become
>> unreadable in the process.

> I am unable to assess the value of this mechanism unless you make a
> concrete proposal. You seem to have something in mind but you're not
> doing a good job getting it into mine...

I'm not confident that macros are even a good idea; I just don't want
a series of half-macros.  That said, here is a strawman.

defmacro boiler1(name, rejects):
def %(name) (*args):
for a in args:
if a in %(rejects):
print "Don't send me %s" % a
...
boiler1(novowels, "aeiouy")
boiler2(nokey5, "jkl")

I'm pretty sure that a real version should accept suites instead of just
arguments, and the variable portion might even be limited to suites 
(as in the thunk discussion).  It might even be reasonable to mark
macro calls as different from function calls.

template novowels from boiler1("aeiou"):


but I can't help thinking that multiple suites should be possible, and
then they should be named, and ... that spurred at least one 
objection.  http://mail.python.org/pipermail/python-dev/2005-April/052949.html

-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

[Greg Ewing]

Shane Holloway (IEEE) wrote:
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. 
There's no need for all that. They're just callable objects.
--
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:
I had been thinking that the typical use would be during function (or
class) definition.  The overhead would be similar to that of decorators,
and confined mostly to module loading.
But that's too late, unless you want to resort to bytecode
hacking. By the time the module is loaded, its source code
has long since been compiled into code objects.
--
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] scope-collapse

[Guido van Rossum]

[Jim jewett]
> The pretend-it-is-a-generator proposals try to specify that only
> certain names will be shared, in only certain ways.

Huh? I don't see it this way. There is *no* sharing between the frame
of the generator and the frame of the block. The block is a permanent
part of the frame surrounding the with-statement, so all names are
shared there.

> > Would make more sense if the collapse keyword was at the module level.
> 
> ???  Are you suggesting that everything defined in the module must live
> in a single namespace, just because the collapse was wanted in one place?

No, I was just proposing putting 'collapse foo' in the module, which
would mean that (a) the definition of foo is intended to be a macro,
and (b) all uses of foo are intended to call that macro.

But I still think this whole proposal is built on quicksand, so don't
take that suggestion too seriously.

-- 
--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: [Pythonmac-SIG] zipfile still has 2GB boundary bug

[Guido van Rossum]

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

Please don't propose a grand rewrite (even it's only a single module).
Given that the API is mostly sensible, please propose gradual
refactoring of the implementation, perhaps some new API methods, and
so on. Don't throw away the work that went into making it work in the
first place!

http://www.joelonsoftware.com/articles/fog69.html

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

[Greg Ewing]

[EMAIL PROTECTED] wrote:
Actually I was thinking of something related the other day:
> Wouldn't it be nice to be able to define/overload not only
> operators but also control structures?
That triggered off something in my mind that's somewhat
different from what you went on to talk about.
So far we've been talking about ways of defining new
syntax. But operator overloading isn't creating new
syntax, it's giving a new meaning to existing syntax.
So the statement equivalent of that would be defining
new meanings for *existing* control structures!
For example, when you write
  while expr:
...
it gets turned into
  expr.__while__(thunk)
etc.
No, I'm not really serious about this -- it was just
a wild thought!
--
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: scope-collapse (was: anonymous blocks)

[Jim Jewett]

On 4/26/05, Robert Brewer <[EMAIL PROTECTED]> wrote:
> [Jim]
> > Absolutely.  Even giving up the XXX_FAST optimizations would
> > still require new bytecode to not assume them.

> I'm afraid I'm only familiar with CPython, but wouldn't callee locals
> just map to XXX_FAST indices via the caller's co_names tuple?

Only if all names are in the caller's tuple.

In your example at
http://mail.python.org/pipermail/python-dev/2005-April/052924.html

two of the callees wanted a shared old_children, but that name didn't 
appear in the caller, so I wouldn't expect the compiler to make room
for it in the tuple.

-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 vs scope-collapse

[Josiah Carlson]

[Guido]
> OK, now you *must* look at the Boo solution.
> http://boo.codehaus.org/Syntactic+Macros

That is an interesting solution, requiring macro writers to actually
write an AST modifier seems pretty reasonable to me.  Whether we want
macros or not... 

 - Josiah

___
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

[Brian Sabbey]

Nick Coghlan wrote:
Accordingly, I would like to suggest that 'with' revert to something 
resembling the PEP 310 definition:

   resource = EXPR
   if hasattr(resource, "__enter__"):
   VAR = resource.__enter__()
   else:
   VAR = None
   try:
   try:
   BODY
   except:
   raise # Force realisation of sys.exc_info() for use in __exit__()
   finally:
   if hasattr(resource, "__exit__"):
   VAR = resource.__exit__()
   else:
   VAR = None
Generator objects could implement this protocol, with the following 
behaviour:

   def __enter__():
   try:
   return self.next()
   except StopIteration:
   raise RuntimeError("Generator exhausted, unable to enter with 
block")

   def __exit__():
   try:
   return self.next()
   except StopIteration:
   return None
   def __except__(*exc_info):
   pass
   def __no_except__():
   pass
One peculiarity of this is that every other 'yield' would not be allowed 
in the 'try' block of a try/finally statement (TBOATFS).  Specifically, a 
'yield' reached through the call to __exit__ would not be allowed in the 
TBOATFS.

It gets even more complicated when one considers that 'next' may be called 
inside BODY.  In such a case, it would not be sufficient to just disallow 
every other 'yield' in the TBOATFS.  It seems like 'next' would need some 
hidden parameter that indicates whether 'yield' should be allowed in the 
TBOATFS.

(I assume that if a TBOATFS contains an invalid 'yield', then an exception 
will be raised immediately before its 'try' block is executed.  Or would 
the exception be raised upon reaching the 'yield'?)


These are also possible by combining a normal for loop with a non-looping
with (but otherwise using Guido's exception injection semantics):
def auto_retry(attempts):
   success = [False]
   failures = [0]
   except = [None]
   def block():
   try:
   yield None
   except:
   failures[0] += 1
   else:
   success[0] = True
   while not success[0] and failures[0] < attempts:
   yield block()
   if not success[0]:
   raise Exception # You'd actually propagate the last inner failure
for attempt in auto_retry(3):
   with attempt:
   do_something_that_might_fail()
I think your example above is a good reason to *allow* 'with' to loop. 
Writing 'auto_retry' with a looping 'with' would be pretty straightforward 
and intuitive.  But the above, non-looping 'with' example requires two 
fairly advanced techniques (inner functions, variables-as-arrays trick) 
that would probably be lost on some python users (and make life more 
difficult for the rest).

But I do see the appeal to having a non-looping 'with'.  In many (most?) 
uses of generators, 'for' and looping 'with' could be used 
interchangeably.  This seems ugly-- more than one way to do it and all 
that.

-Brian
___
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]

Nick Coghlan wrote:
def template():
  # pre_part_1
  yield None
  # post_part_1
  yield None
  # pre_part_2
  yield None
  # post_part_2
  yield None
  # pre_part_3
  yield None
  # post_part_3
def user():
  block = template()
  with block:
# do_part_1
  with block:
# do_part_2
  with block:
# do_part_3
That's an interesting idea, but do you have any use cases
in mind?
I worry that it will be too restrictive to be really useful.
Without the ability for the iterator to control which blocks
get executed and when, you wouldn't be able to implement
something like a case statement, for example.
--
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: [Pythonmac-SIG] zipfile still has 2GB boundary bug

[Bob Ippolito]

On Apr 26, 2005, at 8:24 PM, Guido van Rossum 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?
Please don't propose a grand rewrite (even it's only a single module).
Given that the API is mostly sensible, please propose gradual
refactoring of the implementation, perhaps some new API methods, and
so on. Don't throw away the work that went into making it work in the
first place!
Well, I didn't necessarily mean it should be thrown away and started 
from scratch -- however, once you get all the ugly out of it, there's 
not much left!  Obviously there's something wrong with the way it's 
written if it took years and *several passes* to correctly identify and 
fix a simple format character case bug.  Most of this can be blamed on 
the struct module, which is more obscure and error-prone than writing 
the same code in C.

One of the most useful things that could happen to the zipfile module 
would be a stream interface for both reading and writing.  Right now 
it's slow and memory hungry when dealing with large chunks.  The use 
case that lead me to fix this bug is a tool that archives video to zip 
files of targa sequences with a reference QuickTime movie.. so I end up 
with thousands of bite sized chunks.

This >2GB bug really caused me some grief in that I didn't test with 
such large sequences because I didn't have any.  I didn't end up 
finding out about it until months later because client *ignored* the 
exceptions raised by the GUI and came back to me with broken zip files. 
 Fortunately the TOC in a zip file can be reconstructed from an 
otherwise pristine stream.  Of course, I had to rewrite half of the 
zipfile module to come up with such a recovery program, because it's 
not designed well enough to let me build such a tool on top of it.

Another "bug" I ran into was that it has some crazy default for the 
ZipInfo record: it assumes the platform ("create_system") is Windows 
regardless of where you are!  This caused some really subtle and 
annoying issues with some unzip tools (of course, on everyone's 
machines except mine).  Fortunately someone was able to figure out why 
and send me a patch, but it was completely unexpected and I didn't see 
such craziness documented anywhere.  If it weren't for this patch, it'd 
either still be broken, or I'd have switched to some other way of 
creating archives!

The zipfile module is good enough to create input files for zipimport.. 
which is well tested and generally works -- barring the fact that 
zipimport has quite a few rough edges of its own.  I certainly wouldn't 
recommend it for any heavy duty tasks in its current state.

-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

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

[Alan McIntyre]

Bob Ippolito wrote:

> One of the most useful things that could happen to the zipfile module
> would be a stream interface for both reading and writing.  Right now
> it's slow and memory hungry when dealing with large chunks.  The use
> case that lead me to fix this bug is a tool that archives video to zip
> files of targa sequences with a reference QuickTime movie.. so I end
> up with thousands of bite sized chunks.

While it's probably not an improvement on the order of magnitude you're
looking for, there's a patch (1121142) that lets you read large items
out of a zip archive via a file-like object.  I'm occasionally running
into the 2GB problem myself, so if any changes are made to get around
that I can at least help out by testing it against some "real-life" data
sets.

Alan
___
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 vs scope-collapse

[Greg Ewing]

I don't think this proposal has any chance as long as
it's dynamically scoped.
It mightn't be so bad if it were lexically scoped,
i.e. a special way of defining a function so that
it shares the lexically enclosing scope. This
would be implementable, since the compiler has
all the necessary information about both scopes
available.
Although it might be better to have some sort of
"outer" declaration for rebinding in the enclosing
scope, instead of doing it on a whole-function basis.
--
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]

Facundo Batista wrote:
Aargh! Bad explanation. Or at least you're missing something:
Not really. It's easier for me to show that id(3) is always the same
and id([]) not, and let the kids see that's not so easy and you'll
have to look deeper if you want to know better.
I think Guido was saying that it's important for them to
know that mutable objects are never in danger of being
shared, so you should at least tell them that much.
Otherwise they may end up worrying unnecessarily that
two of their lists might get shared somehow behind
their back.
--
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

[Stephen J. Turnbull]

> "Andrew" == Andrew Koenig <[EMAIL PROTECTED]> writes:

Andrew> Wel  Shouldn't you have written

Andrew> (mapcar car list-of-lists)

Andrew> or am I missing something painfully obvious?

Greg should have written

(with-file "foo/blarg" 'do-something-with)

too.  I guess I should have used do-something-with, too.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
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: [Pythonmac-SIG] zipfile still has 2GB boundary bug

[Shane Hathaway]

Bob Ippolito wrote:
> The zipfile module is good enough to create input files for zipimport..
> which is well tested and generally works -- barring the fact that
> zipimport has quite a few rough edges of its own.  I certainly wouldn't
> recommend it for any heavy duty tasks in its current state.

That's interesting because Java seems to suffer from similar problems.
In the early days of Java, although a jar file was a zip file, Java
wouldn't read jar files created by the standard zip utilities I used.  I
think the distinction was that the jar utility stored the files
uncompressed.  Java is fixed now, but I think it illustrates that zip
files are non-trivial.

BTW, I don't think the jar utility can delete files from a zip file
either. ;-)

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] Re: [Pythonmac-SIG] zipfile still has 2GB boundary bug

[Guido van Rossum]

> > Please don't propose a grand rewrite (even it's only a single module).
> > Given that the API is mostly sensible, please propose gradual
> > refactoring of the implementation, perhaps some new API methods, and
> > so on. Don't throw away the work that went into making it work in the
> > first place!
> 
> Well, I didn't necessarily mean it should be thrown away and started
> from scratch

Well, you *did* say "rewrite". :-)

>  -- however, once you get all the ugly out of it, there's
> not much left!  Obviously there's something wrong with the way it's
> written if it took years and *several passes* to correctly identify and
> fix a simple format character case bug.  Most of this can be blamed on
> the struct module, which is more obscure and error-prone than writing
> the same code in C.

I think the reason is different -- it just hasn't had all that much
use beyond the one use case for which it was written (zipping up the
Python library). Also, don't underestimate the baroqueness of the zip
spec.

> One of the most useful things that could happen to the zipfile module
> would be a stream interface for both reading and writing.  Right now
> it's slow and memory hungry when dealing with large chunks.  The use
> case that lead me to fix this bug is a tool that archives video to zip
> files of targa sequences with a reference QuickTime movie.. so I end up
> with thousands of bite sized chunks.

Sounds like a use case nobody else has tried yet.

> This >2GB bug really caused me some grief in that I didn't test with
> such large sequences because I didn't have any.  I didn't end up
> finding out about it until months later because client *ignored* the
> exceptions raised by the GUI and came back to me with broken zip files.
>   Fortunately the TOC in a zip file can be reconstructed from an
> otherwise pristine stream.  Of course, I had to rewrite half of the
> zipfile module to come up with such a recovery program, because it's
> not designed well enough to let me build such a tool on top of it.

Given more typical use cases for zip files (sending around collections
of source files) I'm not surprised that a bug that only occurs for
files >2GB remained hidden for so long.

I don't remember if you have Python CVS permissions, but you sound
like you really know the module as well as the zip file spec, so I'm
hoping that you'll find the time to do some reconstructive surgery on
the zip module for Python 2.5, without breaking the existing APIs. I
like the idea you have for a stream API; I recall that the one time I
had to use it I was surprised that the API dealt with files as string
buffers exclusively.

> Another "bug" I ran into was that it has some crazy default for the
> ZipInfo record: it assumes the platform ("create_system") is Windows
> regardless of where you are!

I vaguely recall that the initial author was a Windows-head; perhaps
he didn't realize how useful the module would be on other platforms,
or that it would make any difference at all.

> This caused some really subtle and
> annoying issues with some unzip tools (of course, on everyone's
> machines except mine).  Fortunately someone was able to figure out why
> and send me a patch, but it was completely unexpected and I didn't see
> such craziness documented anywhere.  If it weren't for this patch, it'd
> either still be broken, or I'd have switched to some other way of
> creating archives!
> 
> The zipfile module is good enough to create input files for zipimport..
> which is well tested and generally works -- barring the fact that
> zipimport has quite a few rough edges of its own.  I certainly wouldn't
> recommend it for any heavy duty tasks in its current state.

So, please fix it!

-- 
--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] site enhancements (request for review)

[Greg Ewing]

Guido van Rossum wrote:
I do that all the time without .pth files -- I just put all the common
modules in a package and place the package in the directory containing
the "main" .py files.
That's fine as long as you're willing to put all the
main .py files together in one directory, with everything
else below it, but sometimes it's not convenient to do that.
I had a use for this the other night, involving two
applications which each consisted of multiple .py
files (belonging only to that application) plus some
shared ones. I wanted to have a directory for each
application containing all the files private to that
application.
> it's too easy to forget about the .pth file and be
confused when it points to the wrong place.
I don't think I would be confused by that. I would
consider the .pth file to be a part of the source
code of the application, to be maintained along with
it. If I got an ImportError for one of the shared
modules, checking the .pth file would be a natural
thing to do -- just as would checking the sys.path
munging code if it were being done that way. And
a .pth file would be much easier to maintain than
the hairy-looking code you need to write to munge
sys.path in an equivalent way.
That's also the reason why
I don't use symlinks or $PYTHONPATH for this purpose.
Another reason for avoiding that is portability. My first
attempt at solving the aforementioned problem used
symlinks. Trouble is, it also had to work on Windows
running under Virtual PC mounting the source directory
from the host system as a file share, and it turns out
that reading a unix symlink from the Windows end just
returns the contents of the link. Aaarrghh! Braindamage!
--
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

[Guido van Rossum]

> > [Greg Ewing]
> >>* 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]
> > (You can already put a yield inside a try-except, just not inside a
> > try-finally.)

[Greg]
> Well, my point still stands. People are going to write
> try-finally around their yields and expect the natural
> thing to happen when their generator is used in a
> for-loop.

Well, the new finalization semantics should take care of that when
their generator is finalized -- its __next__() will be called with
some exception.  But as long you hang on to the generator, it will not
be finalized, which is distinctly different from the desired
with-statement semantics.

> > There would still be the difference that a for-loop invokes iter()
> > and a with-block doesn't.
>  >
>  > Also, for-loops that don't exhaust the iterator leave it
>  > available for later use.
> 
> Hmmm. But are these big enough differences to justify
> having a whole new control structure? Whither TOOWTDI?

Indeed, but apart from declaring that henceforth the with-statement
(by whatever name) is the recommended looping construct and a
for-statement is just a backwards compatibility macro, I just don't
see how we can implement the necessary immediate cleanup semantics of
a with-statement.  In order to serve as a resource cleanup statement
it *must* have stronger cleanup guarantees than the for-statement can
give (if only for backwards compatibility reasons).

> > """
> > The statement:
> >
> > for VAR in EXPR:
> > BLOCK
> >
> > does the same thing as:
> >
> > with iter(EXPR) as VAR:# Note the iter() call
> > BLOCK
> >
> > except that:
> >
> > - you can leave out the "as VAR" part from the with-statement;
> > - they work differently when an exception happens inside BLOCK;
> > - break and continue don't always work the same way.
> >
> > The only time you should write a with-statement is when the
> > documentation for the function you are calling says you should.
> > """
> 
> Surely you jest. Any newbie reading this is going to think
> he hasn't a hope in hell of ever understanding what is going
> on here, and give up on Python in disgust.

And surely you exaggerate.  How about this then:

The with-statement is similar to the for-loop.  Until you've
learned about the differences in detail, the only time you should
write a with-statement is when the documentation for the function
you are calling says you should.

> >>I'm seriously worried by the
> >>possibility that a return statement could do something other
> >>than return from the function it's written in.
> 
> > Let me explain the use cases that led me to throwing that in
> 
> Yes, I can see that it's going to be necessary to treat
> return as an exception, and accept the possibility that
> it will be abused. I'd still much prefer people refrain
> from abusing it that way, though. Using "return" to spell
> "send value back to yield statement" would be extremely
> obfuscatory.

That depends on where you're coming from.  To Ruby users it will look
completely natural because that's what Ruby uses.  (In fact it'll be a
while before they appreciate the deep differences between yield in
Python and in Ruby.)

But I accept that in Python we might want to use a different keyword
to pass a value to the generator.  I think using 'continue' should
work; continue with a value has no precedent in Python, and continue
without a value happens to have exactly the right semantics anyway.

> > (BTW ReturnFlow etc. aren't great
> > names.  Suggestions?)
> 
> I'd suggest just calling them Break, Continue and Return.

Too close to break, continue and return IMO.

> > One last thing: if we need a special name for iterators and
> > generators designed for use in a with-statement, how about calling
> > them with-iterators and with-generators.
> 
> Except that if it's no longer a "with" statement, this
> doesn't make so much sense...

Then of course we'll call it after whatever the new statement is going
to be called.  If we end up calling it the foible-statement, they will
be foible-iterators and foible-generators.

Anyway, I think I'll need to start writing a PEP.  I'll ask the PEP
editor for a number.

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