Re: [Python-Dev] PEP 340: Breaking out.

[Ka-Ping Yee]

On Thu, 5 May 2005, Delaney, Timothy C (Timothy) wrote:
> Aahz wrote:
> > My standard workaround is using exceptions, but I'm not sure how that
> > interacts with a block:
> >
> > try:
> > for name in filenames:
> > with opened(name) as f:
> > if f.read(2) == 0xFEB0:
> > raise Found
> > except Found:
> > pass
>
> For any sane block iterator, it will work as expected. However, an evil
> block iterator could suppress the `Found` exception.

I was thinking about more use cases for the block statement,
and one of the ideas was an exception-logging block:

def logged_exceptions(file):
try:
yield
except Exception, value:
file.write(repr(value) + '\n')

block logged_exceptions(file):
do stuff
do stuff
do stuff

...but then i wasn't sure whether this was supposed to be
possible in the proposed scheme.  Currently, generators do not
catch exceptions raised in the code that they yield values to,
because the target of the yield is in a higher stack frame.

This makes sense from a language design perspective, since
there is no try...finally construct lexically wrapping the thing
that raises the exception.  In current Python, for example,
this says 'caught outside generator':

def spam_generator():
try:
yield 'spam'
except ValueError, value:
print 'caught inside generator'

try:
g = spam_generator()
i = g.next()
raise ValueError(5)
except ValueError, value:
print 'caught outside generator'

But now i'm confused.  Tim's words above seem to suggest that
the interior generator could actually catch exceptions raised
outside, by whatever is on the other end of the yield.

So, could a block statement really catch that exception inside?
I think it might be too confusing if it were possible.


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

Re: [Python-Dev] Adding DBL_MANTISSA and such to Python

[Josiah Carlson]

"Edward C. Jones" <[EMAIL PROTECTED]> wrote:

> 3. Add full "tostring" and "fromstring" capabilities for Python numeric 
> types. "tostring(x)" would return a string containing the binary 
> representation of x. For example, if x is a Python float, "tostring(x)" 
> would have eight characters. "fromstring(s, atype)" does the reserve, so
>  fromstring(tostring(x), type(x)) == x

For floats:
  struct.pack("d",...)
  struct.unpack("d",...)
For 32-bit signed integers:
  struct.pack("l",...)
  struct.unpack("l",...)
For 64 bit signed integers:
  struct.pack("Q",...)
  struct.unpack("Q",...)

Heck, you can even get big-endian output on little-endian machines (or
vv.) if you want!  Or you can toss the signs on the integers, get shorts,
or even chars.

Python already has such functionality in the standard library, though
perhaps it isn't the most aptly named (being in 'struct' rather than a
'value_packing' module...though its functionality was for packing and
unpacking of c-style structs...).


Alternatively, you can create an array (using similar typecodes), and
use the .tostring() and .fromstring() mechanism.

> 4. Add some functions that process floating point types at a low level. 
> I suggest borrowing from C
>  (mantissa, exponent) = frexp(x)

What about the sign?  Here's an implementation for you that includes the
sign...

def frexp(f):
if not isinstance(f, float):
raise TypeError, "Requires float argument"

v, = struct.unpack(">Q", struct.pack(">d", f))
#we ignore denormalized values, NANs, and infinities...
return v>>63, 1 + (v&(2**52-1))/(2.0**52), ((v>>52)&2047)-1023


Is that enough?  Or did you want to convert back into a float?

def inv_frexp(sign, mantissa, exponent):
#I don't know what this is normally called in C...
v = bool(sign)*2**63
v += (abs(int(exponent+1023))&2047)*2**52
v += abs(int(((mantissa-1)*2**52)))&(2**52-1)

f, = struct.unpack(">d", struct.pack(">Q", v))
return f

Yeah, there's some bit work in there, and some is merely protection
against foolish inputs, but it's not that bad.

 - 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

[Python-Dev] python-dev Summary for 2005-04-16 through 2005-04-30 [draft]

[Tony Meyer]

Here's April Part Two.  If anyone can take their eyes of the anonymous block
threads for a moment and give this a once-over, that would be great!  Please
send any corrections or suggestions to Tim (tlesher at gmail.com), Steve
(steven.bethard at gmail.com) and/or me, rather than cluttering the list.
Ta!

==
Summary Announcements
==

---
Exploding heads
---

After a gentle introduction for our first summary, python-dev really let
loose last fortnight; not only with the massive PEP 340 discussion, but
also more spin-offs than a `popular`_ `TV`_ `series`_, and a few
stand-alone threads.

Nearly a week into May, and the PEP 340 talk shows no sign of abating;
this is unfortunate, since Steve's head may explode if he has to write
anything more about anonymous blocks.  Just as well there are three of us!

.. _popular: http://imdb.com/title/tt0060028/
.. _TV: http://imdb.com/title/tt0098844/
.. _series: http://imdb.com/title/tt0247082/

[TAM]

---
PEP 340
---

A request for anonymous blocks by Shannon -jj Behrens launched a
massive discussion about a variety of related ideas. This discussion
is split into different sections for the sake of readability, but
as the sections are extracted from basically the same discussion,
it may be easiest to read them in the following order:

1. `Localized Namespaces`_

2. `The Control Flow Management Problem`_

3. `Block Decorators`_

4. `PEP 310 Updates Requested`_

5. `Sharing Namespaces`_

6. `PEP 340 Proposed`_

[SJB]


=
Summaries
=


Localized Namespaces


Initially, the "anonymous blocks" discussion focused on introducing
statement-local namespaces as a replacement for lambda expressions.
This would have allowed localizing function definitions to a single
namespace, e.g.::

foo = property(get_foo) where:
 def get_foo(self):
 ...

where get_foo is only accessible within the ``foo = ...`` assignment
statement. However, this proposal seemed mainly to be motivated by a
desire to avoid "namespace pollution", an issue which Guido felt was not
really that much of a problem.


Contributing threads:

- `anonymous blocks
`__

[SJB]


---
The Control Flow Management Problem
---

Guido suggested that if new syntax were to be introduced for "anonymous
blocks", it should address the more important problem of being able to
extract common patterns of control flow. A very typical example of such
a problem, and thus one of the recurring examples in the thread, is
that of a typical acquire/release pattern, e.g.::

lock.acquire()
try:
   CODE
finally:
   lock.release()

Guido was hoping that syntactic sugar and an appropriate definition of
locking() could allow such code to be written as::

locking(lock):
   CODE

where locking() would factor out the acquire(), try/finally and
release().  For such code to work properly, ``CODE`` would have to
execute in the enclosing namespace, so it could not easily be converted
into a def-statement.

Some of the suggested solutions to this problem:

- `Block Decorators`_

- `PEP 310 Updates Requested`_

- `Sharing Namespaces`_

- `PEP 340 Proposed`_


Contributing threads:

- `anonymous blocks
`__

[SJB]



Block Decorators


One of the first solutions to `The Control Flow Management Problem`_ was
"block decorators".  Block decorators were functions that accepted a
"block object" (also referred to in the thread as a "thunk"), defined a
particular control flow, and inserted calls to the block object at the
appropriate points in the control flow. Block objects would have been
much like function objects, in that they encapsulated a sequence of
statements, except that they would have had no local namespace; names
would have been looked up in their enclosing function.

Block decorators would have wrapped sequences of statements in much the
same way as function decorators wrap functions today. "Block decorators"
would have allowed locking() to be written as::

def locking(lock):
def block_deco(block):
lock.acquire()
try:
block()
finally:
lock.release()
return block_deco

and invoked as::

@locking(lock):
CODE

The implementation of block objects would have been somewhat
complicated if a block object was a first class object and could be
passed to other functions.  This would have required all variables used
in a block object to be "cells" (which provide slower access than
normal name lookup). Additionally, first class block objects, as a type
of callable, would have confused the meaning of the return statement -
should the return exit the block or the enclosing

Re: [Python-Dev] PEP 340: Breaking out.

[Josiah Carlson]

Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> 
> On Wed, 4 May 2005, Shane Hathaway wrote:
> >
> > for name in filenames:
> > opening(name) as f:
> > if f.read(2) == 0xFEB0:
> > break for
> 
> continue with 2
> 


There is something aboutthat I just don't like.
I can't really put my finger on it right now, so perhaps it is merely
personal aesthetics.  I'll sleep on it and see if I can come up with a
good reason why I don't like it.

 - 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] Adding DBL_MANTISSA and such to Python

[Josiah Carlson]

Josiah Carlson <[EMAIL PROTECTED]> wrote:

   unsigned
 vv
> For 64 bit signed integers:
>   struct.pack("Q",...)
>   struct.unpack("Q",...)

My fingers were typing too fast (I do much work with unsigned 64 bit
integers, but not much with unsigned ones).

 - 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] Adding DBL_MANTISSA and such to Python

[Michael Hudson]

"Edward C. Jones" <[EMAIL PROTECTED]> writes:

> Recently I needed some information about the floating point numbers on 
> my machine. So I wrote a tiny C99 program with the line
>
> printf("%a\n", DBL_EPSILON);
>
> The answer was "0x1p-52".
>
> A search of comp.lang.python shows that I was not alone. Here are some 
> ideas.
>
> 1. Add to Python the constants in "float.h" and "limits.h".

Where?

> 2. Add the C99 "%a" format to the "%" operator for strings and allow it 
> in floating point literals.

Is there an implementation of this somewhere?  We mostly certainly are
not demanding a C99 compiler yet.

> 3. Add full "tostring" and "fromstring" capabilities for Python numeric 
> types. "tostring(x)" would return a string containing the binary 
> representation of x. For example, if x is a Python float, "tostring(x)" 
> would have eight characters. "fromstring(s, atype)" does the reserve, so
>  fromstring(tostring(x), type(x)) == x

We have this already in the struct module.  I have a patch that should
improve the robustness of these functions on IEEE-754 platforms in the
face of special values that you can review if you like:

http://python.org/sf/1181301

(my not-so-recent anguished "will one of you bastards please review
this and/or 1180995 for me?" still applies, btw)

> 4. Add some functions that process floating point types at a low level. 
> I suggest borrowing from C
>  (mantissa, exponent) = frexp(x)
> where mantissa is a float and exponent is an int. The mantissa can be 
> 0.0 or 0.5 <= mantissa < 1.0. Also x = mamtissa * 2**exponent. If
> x == 0.0, the function returns (0.0, 0). (This is almost a quote from 
> Harbison and Steele.)

>>> math.frexp(math.pi)
(0.78539816339744828, 2)

What am I missing?

> 5. Add the C99 constants and functions involving special floating point 
> values: "FP_INFINITE", "FP_NAN", "FP_NORMAL", "FP_SUBNORMAL", "FP_ZERO", 
> "fpclassify", "isfinite", "isinf", "isnan", "isnormal", "signbit", 
> "copysign", "nan", "nextafter", and "nexttoward". There has been 
> controversy about these in the past, but I am in favor of them. The 
> documentation should discuss portability.

If you can supply a patch to make all the compilers out there behave
with respect to these functions, I'll be impressed (they seem to exist
on Mac OS X 10.3, dunno if they work though :).

Cheers,
mwh

-- 
  If you're talking "useful", I'm not your bot.
-- Tim Peters, 08 Nov 2001
___
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] Pre-PEP: Unifying try-except and try-finally

[Michael Hudson]

"Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:

> And per the PEP, I think the explaining that::
>
>  try:
>  A
>  except:
>  B
>  else:
>  C
>  finally:
>  D
>
> is *exactly* equivalent to::
>
>  try:
>  try:
>  A
>  except:
>  B
>  else:
>  C
>  finally:
>  D
>
> Resolved all the questions about control flow for me.

Well, yes, that makes sense, but also raises a small "and the point
is...?" flag in my head.

Cheers,
mwh

-- 
  This is the fixed point problem again; since all some implementors
  do is implement the compiler and libraries for compiler writing, the
  language becomes good at writing compilers and not much else!
 -- Brian Rogoff, comp.lang.functional
___
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] PEP 340: propose to get rid of 'as' keyword

[Fredrik Lundh]

Gustavo J. A. M. Carneiro wrote:

>   In that case,
>
>   block VAR1 in EXPR1:
>   BLOCK1
>
> And now I see how using 'for' statements (perhaps slightly changed)
> turned up in the discussion.

you're moving through this discussion exactly backwards; the current
proposal stems from the observation that "for-loop plus generators" in
today's Python does in fact provide a block implementation that solves
many use cases in an elegant way.

PEP 340 builds on this, sorts out a couple of weak points in the current
design, and adds an elegant syntax for most remaining use cases.





___
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] my first post: asking about a "decorator" module

[Raymond Hettinger]

> > Ultimately, some of these will likely end-up in the library.  For
the
> > time being, I think it best that these get posted and evolve either
as
> > Wiki entries or as ASPN entries.  The best practices and proven
winners
> > have yet to emerge.  Solidifying first attempts is likely not a good
> > idea.  Putting tools in the standard library should be the last
> > evolutionary step, not the first.
> 
> Yes, of course. I just wanted to know it there was interest on the
> subject.

Yes, there has been quite a bit of interest including several ASPN
recipes and a wiki:

   http://www.python.org/moin/PythonDecoratorLibrary


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] PEP 340: Breaking out.

[Nick Coghlan]

Steven Bethard wrote:
> Makes me wonder if we shouldn't just return to the __enter__() and
> __exit__() names of PEP 310[1] where for a generator __enter__() is
> just an alias for next().  We could even require Phillip J. Eby's
> "blockgenerator" decorator to rename next() to __enter__(), and add
> the appropriate __exit__() method.

You must be reading my mind or something. . .

Unless there is something in today's 80-odd messages to make it redundant, look 
for a post entitled something like "Minimalist PEP 340 (aka PEP 310 redux)"

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] PEP 340: Breaking out.

[Nick Coghlan]

Alex Martelli wrote:
> Looking for a file with a certain magicnumber in its 1st two bytes...?
> 
> for name in filenames:
>  opening(name) as f:
>  if f.read(2) == 0xFEB0: break
> 
> This does seem to make real-life sense to me...

Also consider the vast semantic differences between:

   locking(lock):
   for item in items:
   if can_handle(item): break

   for item in items:
   locking(lock):
   if can_handle(item): break


Instead of simply acquiring and releasing the lock on each iteration as one 
might expect, moving to the latter version *also* causes every item to be 
checked, instead of only items up to the first one that can be handled. The 
break magically becomes meaningless. How does this even come close to 
executable 
pseudocode?

I also think another factor is that currently, instead of doing try/finally's 
in 
loops, there is a tendency to push the try/finally into a function, then call 
that function inside the loop. The introduction of block statements means that 
a 
number of those inner functions are likely to be handled as block statements 
instead - with the above highly confusing result.

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] PEP 340 -- loose ends

[Nick Coghlan]

Shane Holloway (IEEE) wrote:
> It might actually be workable in the transaction scenario, as well as 
> others.  I'm not sure if I love or hate the idea though.

Given that this is officially a violation of the iterator protocol. . . (check 
the docs for well-behaved iterators)

> Another thing.  In the specification of the Anonymous Block function, is 
> there a reason that "itr = EXPR1" instead of "itr = iter(EXPR1)"?  It 
> seems to be a dis-symmetry with the 'for' loop specification.

Indeed - and a deliberate one, at least partly to discourage caching of block 
iterators.

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] PEP 340: Breaking out.

[Ronald Oussoren]

On 5-mei-2005, at 12:55, Nick Coghlan wrote:

> Alex Martelli wrote:
>
>> Looking for a file with a certain magicnumber in its 1st two  
>> bytes...?
>>
>> for name in filenames:
>>  opening(name) as f:
>>  if f.read(2) == 0xFEB0: break
>>
>> This does seem to make real-life sense to me...
>>
>
> Also consider the vast semantic differences between:
>
>locking(lock):
>for item in items:
>if can_handle(item): break
>
>for item in items:
>locking(lock):
>if can_handle(item): break
>
>
> Instead of simply acquiring and releasing the lock on each  
> iteration as one
> might expect, moving to the latter version *also* causes every item  
> to be
> checked, instead of only items up to the first one that can be  
> handled. The
> break magically becomes meaningless. How does this even come close  
> to executable
> pseudocode?

What's bothering me about the proposed semantics is that block  
statement behaves
like a loop while most use cases do no looping whatsoever.  
Furthermore the it doesn't
feel like loop either. In all three examples on this page I'd assume  
that the break
would break out of the for loop.

Ronald
___
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] PEP 340 -- concept clarification

[Nick Coghlan]

Delaney, Timothy C (Timothy) wrote:
> Nick Coghlan wrote:
> I think if we are going to emphasise the difference, a decorator does
> not go far enough. To use a decorator, this *must* be valid syntax::
> 
> def gen():
> try:
> yield
> finally:
> print 'Done!'
> 
> However, that generator cannot be properly used in a for-loop. So it's
> only realistically valid with the decorator, and used in a block
> statement (resource suite ;)
> 
> My feeling is that the above should be a SyntaxError, as it currently
> is, and that a new keyword is needed which explicitly allows the above,
> and creates an object conforming to the resource protocal (as I called
> it).

I think adding __exit__ and __del__ methods to generators will suffice - for a 
normal generator, it *will* get cleaned up eventually.

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] Pre-PEP: Unifying try-except and try-finally

[Nick Coghlan]

Michael Hudson wrote:
> "Shane Holloway (IEEE)" <[EMAIL PROTECTED]> writes:
> 
> 
>>And per the PEP, I think the explaining that::
>>
>> try:
>> A
>> except:
>> B
>> else:
>> C
>> finally:
>> D
>>
>>is *exactly* equivalent to::
>>
>> try:
>> try:
>> A
>> except:
>> B
>> else:
>> C
>> finally:
>> D
>>
>>Resolved all the questions about control flow for me.
> 
> 
> Well, yes, that makes sense, but also raises a small "and the point
> is...?" flag in my head.

Someone writing a patch and profiling the two versions would serve to convince 
me :)

Cheers,
Nick.

P.S. Well, assuming the flattened version is faster. . .

-- 
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] PEP 340 keyword: after

[Martin v. Löwis]

I haven't followed the PEP 340 discussion in detail,
but as the PEP doesn't list keywords that have been
considered and rejected, I'd like to propose my own:
use "after" instead of "block":

after opening("/etc/passwd") as f:
  for line in f:
 print line.rstrip()

after locking(myLock):
  # code that needs to hold the lock

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] PEP 340 keyword: after

[Rodrigo Dias Arruda Senra]

On Thu, 05 May 2005 14:58:02 +0200
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:

> I haven't followed the PEP 340 discussion in detail,
> but as the PEP doesn't list keywords that have been
> considered and rejected, I'd like to propose my own:
> use "after" instead of "block":
> 
> after opening("/etc/passwd") as f:
>   for line in f:
>  print line.rstrip()
> 
> after locking(myLock):
>   # code that needs to hold the lock
> 

 And *after* fits very nice for the examples above.
 However, it might get weird for:

after transaction(db):
# code inbetween new_trasn/ commit_or_abort

 The code pattern that will 'wrap' the block might
 not always make sense with the chosen keyword, if
 that keyword is not semantically neutral.
 (not time-related, not function-related, etc).

 Notice that is _no keyword_ is chosen, nothing prevents us
 from using (even if by aliasing):

   after_opening("/etc/passwd") as f:
   for line in f:
   print line.rstrip()
 
   after_locking(myLock):
   # code that needs to hold the lock

My two cents.
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] PEP 340 -- loose ends

[Eric Nieuwland]

Reinhold Birkenfeld wrote:
Shane Hathaway wrote:
PEP 340 seems to punish people for avoiding the parentheses:

transaction = begin_transaction()

transaction:
db.execute('insert 3 into mytable')

transaction:
db.execute('insert 4 into mytable')

I expect that only '3' would be inserted in mytable.  The second use of
the transaction iterator will immediately raise StopIteration.

Yes, but wouldn't you think that people would misunderstand it in this way?

This could be solved if the translation of

block EXPR1 as VAR1:
BLOCK1
would change from:
itr = EXPR1  # The iterator
ret = False  # True if a return statement is active
...etc...
to:
itr = iter(EXPR1)  # The iterator
ret = False  # True if a return statement is active
...etc...

--eric___
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] PEP 340: Breaking out.

[Eric Nieuwland]

Ronald Oussoren wrote:
> What's bothering me about the proposed semantics is that block
> statement behaves like a loop while most use cases do no looping 
> whatsoever.
> Furthermore the it doesn't feel like loop either. In all three 
> examples on this page I'd assume
> that the break would break out of the for loop.

I'm bothered the same way.
IMHO control constructs should be very clear. No implicit looping, 
conditionals etc.
Especially since the main reason to have this whole discussion is about 
resource management.
The main pattern of use I have in mind is:

resource = grab/allocate/open/whatever(...)
try:
do something possibly with the resource
except ...:
...
finally:
...
resource.release/deallocate/close/whatever()

This is linear. No looping whatsoever. And easily translated to a 
simple language construct and a protocol:

class resource(object):
def __init__(self,...):
# store resource parameters
def __acquire__(self):
# whatever it takes to grab the resource
def __release__(self):
# free the resource

res = resource(...)
acquire res:
do something possibly with the resource
except ...:
...
finally:
...

The resource is automagically released at the end of the 'acquire' 
block (keyword up for other proposals :-)
An alternative syntax could also be allowed:

acquire resource(...) as res:
...etc...

Then 'res' would be undefined after the 'acquire' block.

--eric

___
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] PEP 340: Non-looping version (aka PEP 310 redux)

[Nick Coghlan]

The discussion on the meaning of break when nesting a PEP 340 block statement 
inside a for loop has given me some real reasons to prefer PEP 310's single 
pass 
semantics for user defined statements (more on that at the end). The suggestion 
below is my latest attempt at combining the ideas of the two PEP's.

For the keyword, I've used the abbreviation 'stmt' (for statement). I find it 
reads pretty well, and the fact that it *isn't* a real word makes it easier for 
me to track to the next item on the line to find out the actual statement name 
(I think this might be similar to the effect of 'def' not being a complete word 
making it easier for me to pick out the function name). I consequently use 
'user 
statement' or 'user defined statement' to describe what PEP 340 calls anonymous 
block statements.

I'm still fine with the concept of not using a keyword at all, though.

Cheers,
Nick.

== User Defined Statement Usage Syntax ==

   stmt EXPR1 [as VAR1]:
   BLOCK1


== User Defined Statement Semantics ==

   the_stmt = EXPR1
   terminated = False
   try:
   stmt_enter = the_stmt.__enter__
   stmt_exit = the_stmt.__exit__
   except AttributeError:
   raise TypeError("User statement required")
   try:
   VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
   except TerminateBlock:
   pass
   # Block is not entered at all in this case
   # If an else clause were to be permitted, the
   # associated block would be executed here
   else:
   try:
   try:
   BLOCK1
   except:
   exc = sys.exc_info()
   terminated = True
   try:
   stmt_exit(*exc)
   except TerminateBlock:
   pass
   finally:
   if not terminated:
   try:
   stmt_exit(TerminateBlock)
   except TerminateBlock:
   pass

Key points:
* The supplied expression must have both __enter__ and __exit__ methods.
* The result of the __enter__ method is assigned to VAR1 if VAR1 is given.
* BLOCK1 is not executed if __enter__ raises an exception
* A new exception, TerminateBlock, is used to signal statement completion
* The __exit__ method is called with the exception tuple if an exception occurs
* Otherwise it is called with TerminateBlock as the argument
* The __exit__ method can suppress an exception by converting it to 
TerminateBlock or by returning without reraising the exception
* return, break, continue and raise StopIteration are all OK inside BLOCK1. 
They 
affect the surrounding scope, and are in no way tampered with by the user 
defined statement machinery (some user defined statements may choose to 
suppress 
the raising of StopIteration, but the basic machinery doesn't do that)
* Decouples user defined statements from yield expressions, the enhanced 
continue statement and generator finalisation.

== New Builtin: statement ==

   def statement(factory):
   try:
  factory.__enter__
  factory.__exit__
  # Supplied factory is already a user statement factory
  return factory
   except AttributeError:
  # Assume supplied factory is an iterable factory
  # Use it to create a user statement factory
  class stmt_factory(object):
  def __init__(*args, **kwds)
  self = args[0]
  self.itr = iter(factory(*args[1:], **kwds))
  def __enter__(self):
  try:
  return self.itr.next()
  except StopIteration:
  raise TerminateBlock
  def __exit__(self, *exc_info):
  try:
  stmt_exit = self.itr.__exit__
  except AttributeError:
  try:
  self.itr.next()
  except StopIteration:
  pass
  raise *exc_info # i.e. re-raise the supplied exception
  else:
  try:
  stmt_exit(*exc_info)
  except StopIteration:
  raise TerminateBlock

Key points:
* The supplied factory is returned unchanged if it supports the statement API 
(such as a class with both __enter__ and __exit__ methods)
* An iterable factory (such as a generator, or class with an __iter__ method) 
is 
converted to a block statement factory
* Either way, the result is a callable whose results can be used as EXPR1 in a 
user defined statement.
* For statements constructed from iterators, the iterator's next() method is 
called once when entering the statement, and the result is assigned to VAR1
* If the iterator has an __exit__ method, it is invoked when the statement is 
exited. The __exit__ method is passed the exception information (which may 
indicate that no exception occurred).
* If the iterator does not have an __exit__ method, it's next

Re: [Python-Dev] PEP 340: Breaking out.

[Steven Bethard]

On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > Makes me wonder if we shouldn't just return to the __enter__() and
> > __exit__() names of PEP 310[1] where for a generator __enter__() is
> > just an alias for next().  We could even require Phillip J. Eby's
> > "blockgenerator" decorator to rename next() to __enter__(), and add
> > the appropriate __exit__() method.
> 
> You must be reading my mind or something. . .
> 
> Unless there is something in today's 80-odd messages to make it redundant, 
> look
> for a post entitled something like "Minimalist PEP 340 (aka PEP 310 redux)"

Yeah, I should have linked to that discussion [1].  I wonder if it
would be possible to update PEP 310 with your ideas, or perhaps start
a new PEP?  I'd like to see a competitor for PEP 340 that addresses
some of the issues that came up, e.g. that the block-statement doesn't
look like a loop, so break and continue might look like they break out
of an enclosing loop.  It might also be a good place to mirror Guido's
PEP 340 examples with PEP 310-style examples -- I know the first
attempts at writing some of them weren't as clean as the later
attempts, so it would be nice to have somewhere to look for the
"current version" of everything.

STeVe

[1]http://mail.python.org/pipermail/python-dev/2005-April/053039.html
-- 
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] Pre-PEP: Unifying try-except and try-finally

[Eric Nieuwland]

Reinhold Birkenfeld wrote:
> Changes to the grammar
>
> The grammar for the try statement, which is currently
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] | 'try' ':' suite 'finally' ':' 
> suite)
>
> would have to become
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] ['finally' ':' suite] |
>'try' ':' suite (except_clause ':' suite)*
>['else' ':' suite] 'finally' ':' suite)

Wouldn't it be easier to change it to:

 try_stmt: ('try' ':' suite (except_clause ':' suite)*
['else' ':' suite] ['finally' ':' suite] )
?

--eric

___
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] PEP 340 keyword: after

[Chris Ryland]

Rodrigo Dias Arruda Senra  gpr.com.br> writes:

>  The code pattern that will 'wrap' the block might
>  not always make sense with the chosen keyword, if
>  that keyword is not semantically neutral.
>  (not time-related, not function-related, etc).
> 
>  Notice that is _no keyword_ is chosen, nothing prevents us
>  from using (even if by aliasing):
> 
>after_opening("/etc/passwd") as f:
>for line in f:
>print line.rstrip()
> 
>after_locking(myLock):
># code that needs to hold the lock

I hate to add to what could be an endless discussion, but... ;-)

In this case, "while" is the better time-related prefix, whether
keyword (hopeless, due to ages-old boolean-controlled loop association)
or function, since you want to imply that the code block is going
on *while* the lock is held or *while* the file is open (and you also
want to imply that afterwards, something else happens, i.e., cleanup).

while_locked(myLock):
# code that needs to hold the lock

--Chris Ryland, Em 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] Pre-PEP: Unifying try-except and try-finally

[Nick Coghlan]

Eric Nieuwland wrote:
> Wouldn't it be easier to change it to:
> 
>  try_stmt: ('try' ':' suite (except_clause ':' suite)*
> ['else' ':' suite] ['finally' ':' suite] )
> ?

What does a try statement with neither an except clause nor a finally clause 
mean?

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] PEP 340 keyword: after

[Michael Hudson]

Chris Ryland <[EMAIL PROTECTED]> writes:

> In this case, "while" is the better time-related prefix, whether

Indeed.

while_execution_is_lexically_in_the_next_block lock(theLock):
   ...

Anyone?  .

Cheers,
mwh

-- 
  Every day I send overnight packages filled with rabid weasels to
  people who use frames for no good reason.
 -- The Usenet Oracle, Oracularity #1017-1
___
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] PEP 340 - Remaining issues

[Paul Moore]

On 5/5/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I wonder if it would be possible to update PEP 310 with your ideas,
> or perhaps start a new PEP?  I'd like to see a competitor for PEP 340 that
> addresses some of the issues that came up, e.g. that the block-statement
> doesn't look like a loop, so break and continue might look like they break
> out of an enclosing loop.

In an attempt to bring things back under control, can I summarise what
I believe are the outstanding issues?

1. Choice (or not) of a keyword. I honestly believe that there will
never be a consensus on this, and we'd be better deferring the
decision to Guido's judgement.

2. Separate protocol or not? I'm not entirely sure I have a view on
this, but it feels related to the looping question below. I do like
being able to write these things as generators, and I don't mind
needing a decorator (although I, personally, don't feel a compelling
*need* for one).

3. Looping blocks, and the break issue. I see a consensus forming here
that blocks should *not* loop. No-one has come up with a strong case
for looping blocks, except the auto_retry example, and Nick (I think
it was Nick Coghlan, sorry if my memory is wrong) demonstrated how to
build this case from a for loop and a non-looping block.

Given that Guido has stated that he is willing to accept a consensus
decision on changes to the PEP, can I suggest that rather than writing
a competitor, someone (who understands the technicalities better than
me) simply propose a modification to PEP 340 that does not loop[1].

I think the separate protocol issue is subtler - maybe it's just a
case of renaming some methods and specifying a decorator, but I really
don't understand the issues at this depth.

I apologise if this post (1) misrepresents anyone's view, or (2)
hinders things rather than helping. But I feel that we are pretty
close to a solution here, and I fear that more competing PEPs will
simply muddy the waters.

Paul.

[1] My simplistic view is that you may be able to get away with
changing the specification of the anonymous blok statement's expansion
just to remove the "while True". There's some fixup needed to avoid
the one "break" in the expansion, and probably a lot of little details
that make this far harder than I'm assuming - but maybe that's the
starting point...
___
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] PEP 340: Breaking out.

[Nick Coghlan]

Steven Bethard wrote:
> I wonder if it
> would be possible to update PEP 310 with your ideas, or perhaps start
> a new PEP?  I'd like to see a competitor for PEP 340 that addresses
> some of the issues that came up, e.g. that the block-statement doesn't
> look like a loop, so break and continue might look like they break out
> of an enclosing loop.  It might also be a good place to mirror Guido's
> PEP 340 examples with PEP 310-style examples -- I know the first
> attempts at writing some of them weren't as clean as the later
> attempts, so it would be nice to have somewhere to look for the
> "current version" of everything.

Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so 
updating it with any of my ideas would be their call.

Either way, my latest and greatest version of the non-looping block statement 
semantics can be found here:
http://mail.python.org/pipermail/python-dev/2005-May/053400.html

Some key advantages of that proposal are:
   1. It's not a loop, so nesting it inside another loop 'just works'
   2. Manual protocol implementations are _significantly_ easier to write
   3. try/finally can be done with generators _without_ changing generators
   4. try/except/else can be done with generators if they provide an __exit__ 
method that raises the exception at the point of the last yield
   5. Clearly distinct construct, no potential for confusion with for loops
   6. Generators must be clearly marked as creating a user defined statement 
(although this could be changed by giving them an __enter__ method and an 
__exit__ method)

The one downside relative to PEP 340 is that looping constructs like auto_retry 
are slightly harder to write, albeit not hugely so (once you remember that an 
iterable can be a class instead of a generator!). On the usage front, I find 
the 
'loop over an iterator returning user defined statements' does a much better 
job 
of making the iteration clear, so I'd be inclined to count that as an advantage 
of a PEP 310 style approach.

Anyway, I've already been spending more time on this than I should (sleep is 
optional, right?), so I won't be prettying it up into PEP format any time soon. 
I have no objection to someone else rolling some of the ideas into a PEP, 
though :)

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] problems with memory management

[Carlos Garcia]

Hi All,
 
 
    I do hava a problem with python 
and it is that it raise an outofmemory (i comment lines in Py.java to avoid 
system.exit, to debug),
i try to debug this issue with jprobe and realize 
that i get the exception even although the java heap is not in the limit, i 
book
64- 256M and the java heap 
was less than 60 M.
 
    The program is a command line 
that receive a line that python parse an call some java classes ti execute the 
appropiate command, 
any idea?
 
Thansk,
 
    
== Carlos 
García    
Phone  : +34 91 714 8796 Lucent 
Technologies  e-mail : [EMAIL PROTECTED] Avenida de 
Bruselas , 8   -  28108 Alcobendas 
(Madrid)==
___
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] PEP 340 keyword: Extended while syntax

[Ron Adam]

I expect there's an obvious reason why this hasn't been suggested 
already that I'm not currently thinking of, but here it is anyway.  :-)


How about an *extended while* syntax as a block keyword alternative?

Reasoning: The block statement resembles a "while" block in some ways in 
that it is a conditional block that may be executed only once, or 
possibly not at all (or many times).  And the word "while" is also 
descriptive of how a block is used.

 while VAR1 from EXPR1():
 BLOCK

This will require a new keyword/operator 'from' to use in a 'from' 
expression:

VAR1 from EXPR1()

Where EXPR1 returns an anonymous iterator, and the expression (VAR1 from 
EXPR1()) evaluates as True only if a value from the EXPR1 iterator is 
received.  Or possibly False if it is received and is None. [* see below]

The "for" tests for the name binding instead of testing the value of 
VAR1, it may also be desirable to check VAR1 for None after it is recieved.

This would be translated as follows:

 1 --> while VAR1 from EXPR1():
  raise an error if EXPR1 is not an iterator.

 2 --> while (VAR1 = _EXPR1_iter.__next__()):   # internal

 3 --> while True: # if VAR1 gets a new value
 or 3 -> while False:  # if VAR1 fails to get a value
 [*]or 3 -> while False:  # if VAR1 receives None

* Undecided on check for None. An iterator could always return 
something, so testing for None would be needed; or it could refuse and 
break the request somehow after it is called. In the later case None 
could be a valid return value it may not desirable to finalize the 
block. A while *might* be able to test for both.

 while VAR1 from EXPR1() and VAR1!=None:

or ...

 while VAR1 from EXPR1() and VAR1:

Order of placement could make a difference.

 while VAR1 and VAR1 from EXPR1():

This would test the *last* VAR1 before getting a new value. That might 
be useful in some situations. This may also be inconsistent with how 
expressions are currently evaluated.  I'm not sure if it's allowed for 
names to rebound while evaluating an expression.


Examples:

 while lock from locking(myLock):
 # Code here executes with myLock held.

 while f from opening("/etc/passwd"):
 for line in f:
 print line.rstrip()

 while retry from auto_retry(3, IOError):
 f = urllib.urlopen("http://python.org/peps/pep-0340.html";)
 print f.read()

 while f from locking_opening(myLock, "/etc/passwd"):
 for line in f:
 print line.rstrip()

 while f from opening(filename, "w"):
 while re_out from redirecting_stdout(f):
 print "Hello world"

 while f, err from opening_w_error("/etc/passwd", "a"):
 if err:
 print "IOError:", err
 else:
 f.write("guido::0:0::/:/bin/sh\n")


Because the *from expression* evaluates to a bool, it might be useful in 
other places, although there may be reason to prevent it from being used 
as such.

 if VAR1 from GEN:
 print VAR1
 else:
 print "GEN didn't give me anything"

Another possibility is the use of xrange() in a block statements/ or 
extended while statements.

 while VAR1 from xrange(100):
 block

This may blur the distinction between "for" loops and "while" loops, 
although it may be a *good* thing since "for" can then always used 
sequences, and the *extended while syntax* always use iterators.  Which 
to use, would be up to the programmer.

With that change xrange() support could be removed from "for" statements 
in Python 3000, (I think Guido wants to do that.), and it then could be 
used with "extended while" statements.

With this suggestion there will still only be two looping constructs, 
"for" and "while", and I think the distinction between a normal "while" 
and an extended "while" is made clear with the "from" keyword.  I think 
this would be much easier to understand, IMO, and also much easier to 
read and teach as well.  It uses already familiar syntax and adds a new 
expression keyword instead of a new statement keyword.

A symbol might be possible instead of "from", so adding new keywords 
could be avoided if "from" is out of the question.


Optimistically,
Ron_Adam


___
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] PEP 340 - Remaining issues

[Nick Coghlan]

Paul Moore wrote:
> 1. Choice (or not) of a keyword. I honestly believe that there will
> never be a consensus on this, and we'd be better deferring the
> decision to Guido's judgement.

The keyword-less approach is less confusing when the block statement is not a 
loop, as that eliminates the suprising behaviour of break and continue 
statements.

If there is a keyword, the wide variety of user-defined statements means that 
any real English word will be a bad fit for at least some of them. Something 
relatively nonsensical, but usefully mnemonic (like 'stmt') may be a good way 
to go.

> 2. Separate protocol or not? I'm not entirely sure I have a view on
> this, but it feels related to the looping question below. I do like
> being able to write these things as generators, and I don't mind
> needing a decorator (although I, personally, don't feel a compelling
> *need* for one).

If the block statement doesn't loop, the PEP 310 protocol makes a lot more 
sense. A function (usable as a generator decorator) can then be provided to 
convert from a callable that returns iterables to a callable that returns 
objects that support the PEP 310 protocol.

> Given that Guido has stated that he is willing to accept a consensus
> decision on changes to the PEP, can I suggest that rather than writing
> a competitor, someone (who understands the technicalities better than
> me) simply propose a modification to PEP 340 that does not loop

My attempt at doing exactly that is "PEP 340: Non-looping version (aka PEP 310 
redux)" [1]

And the seemingly simple change ('run the block at most once') had far more 
wide-ranging ramifications than I expected.

> I think the separate protocol issue is subtler - maybe it's just a
> case of renaming some methods and specifying a decorator, but I really
> don't understand the issues at this depth.

When I was writing my suggested semantics for a non-looping version, the use of 
an iteration protocol (next, StopIteration) became obviously inappropriate. So 
while having a separate protocol is a little murky when block statements are 
loops, the PEP 310 interface protocol is a clear winner when block statements 
are _not_ loops.

> I apologise if this post (1) misrepresents anyone's view, or (2)
> hinders things rather than helping. But I feel that we are pretty
> close to a solution here, and I fear that more competing PEPs will
> simply muddy the waters.

In this case, I think having a separate document (perhaps PEP 310, or maybe a 
Wiki page) to describe how a non-looping block statement can support all of the 
identified use cases for the PEP 340's block statement will be clearer than 
trying to describe the two main alternatives in the same PEP.

Cheers,
Nick.

[1] http://mail.python.org/pipermail/python-dev/2005-May/053400.html

-- 
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] PEP 340: Breaking out.

[Ron Adam]

Eric Nieuwland wrote:

> This is linear. No looping whatsoever. And easily translated to a 
> simple language construct and a protocol:
> 
> class resource(object):
>   def __init__(self,...):
>   # store resource parameters
>   def __acquire__(self):
>   # whatever it takes to grab the resource
>   def __release__(self):
>   # free the resource


I wanted to see what the examples in PEP340 would look like written with 
standard class's using object inheritance and overriding to define
resource managers.  If anyone's interested I can post it.

My block class is non-looping as I found in most cases looping isn't 
required, and looping complicates things because you have to pass around 
a loop expression due to not all loops will want to behave that same way.

The solution was to put the loop in the body method and call a 
repeat_body method (the repeated body section) which is added to the 
class when needed.

Ron_Adam


___
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] problems with memory management

[Terry Reedy]

>I do hava a problem with python and it is that it raise an outofmemory 
>  >(i comment lines in Py.java to avoid system.exit, to debug),


Questions about using current Python belong on the Python list or 
comp.lang.python.  Python-dev is for discussions about developing future 
versions. 



___
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] PEP 340: Non-looping version (aka PEP 310 redux)

[Steven Bethard]

On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The discussion on the meaning of break when nesting a PEP 340 block statement
> inside a for loop has given me some real reasons to prefer PEP 310's single 
> pass
> semantics for user defined statements (more on that at the end). The 
> suggestion
> below is my latest attempt at combining the ideas of the two PEP's.
>
[snip]
> * An iterable factory (such as a generator, or class with an __iter__ method) 
> is
> converted to a block statement factory

I like the non-looping proposal a lot, but I'd still prefer that
iterators were not usable as statements.  As I understand it, the main
motivation for wanting iterators to be usable as statements is that
generators provide a very simple way of creating iterators, and we'd
like to have an equally simple way of creating statments.  The
simplicity of generators is that using a "yield" statement inside a
"def" statement magically modifies the function so that it returns
"iterator" objects.  I'd like to see a parallel for block-statements,
so that using an "XXX" statement inside a "def" statement magically
modifies the function so that it returns "statement" objects.

To illustrate my point, I'm going to assume a no-keyword syntax for
calling statement objects and I'm going to steal your "stmt" keyword
to replace "yield". So, for example, to create the "opening" statement
from PEP 340, you would write it almost exactly the same:

def opening(filename, mode="r"):
f = open(filename, mode)
try:
stmt f
finally:
f.close()

This would create a generator-like object that instead of providing
__iter__() and next() methods, provides __enter__() and __exit__()
methods.  It could then be called like:

opening("temp.txt") as f:
for line in f:
print line

I like this for a few reasons:
* statement-generators (or whatever you want to call them) are just as
easy to declare as normal generators are
* try/finally statements around a "yield" would still be invalid
syntax, as generators can't generally guarantee proper finalization
semantics.
* statement objects can't be accidentally used in for-loops; they
don't have __iter__() or next() methods
* statement objects can be clearly documented separately from iterator
objects; there would be no need for them to refer to each other

I don't know the generator implementation very well, but I would think
that statement-generators could share almost all the code of normal
generators by simply changing the name of a slot or two and adding the
__exit__ code already proposed by PEP 340.

STeVe
-- 
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] PEP 340 keyword: Extended while syntax

[Gustavo Niemeyer]

Greetings,

> Reasoning: The block statement resembles a "while" block in some ways in 
> that it is a conditional block that may be executed only once, or 
> possibly not at all (or many times).  And the word "while" is also 
> descriptive of how a block is used.
> 
>  while VAR1 from EXPR1():
>  BLOCK

This is an interesting propose, but for a different PEP.  In the
current propose VAR1 is not evaluated for truthness, and many of
the usage examples doesn't even require it.

This looks quite strange, for instance:

   while dummy from locking(myLock):
  # Do something

And also, this would require a break necessarily:

   while (foo, bar) from locking():
  # Pass

> This will require a new keyword/operator 'from' to use in a 'from' 
> expression:

'from' is already a keyword, btw.

-- 
Gustavo Niemeyer
http://niemeyer.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] PEP 340: Breaking out.

[Josiah Carlson]

Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> 
> On Thu, 5 May 2005, Josiah Carlson wrote:
> > Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > > continue with 2
> >
> > There is something aboutthat I just don't like.
> 
> Just to clarify: if by  you mean "nesting level", did it appear
> that the 2 in my example was a count of block levels?  I didn't
> mean it that way -- the 2 is a value passed in to the generator
> that appears as the value of the "yield" expression, as in PEP 340.

I remember reading that, but I seem to have forgotten it when I was
composing my reply.  Thankfully, sleeping on it has helped me discover
what I really don't like.  With the 'passing value' semantic, the
 [  ] [  ] is only useful for the deepest loop of
a particular type. Take for example...

for ...:
for ...:
for ...:
break/continue [for]


That break or continue can only affect that last for loop.  It doesn't
make any easier the use of nested fors, nested whiles, or even nested
blocks.  It only really helps you if you mix and match all possible
looping constructs, and even then, only gives the granularity of the
most recent block of a particular type.  In that sense, I think it is a
nonstarter, because it doesn't really add functionality in common uses
of for and while statements.

If one allowed  [] [] , [], then one could
jump to arbitrary loops.  Now, I'm not condoning this, and I don't even
like it.  Sure, it allows breaking or continuing to any for, while, or
block statement in the current scope, but the  argument is as
equivalently ambiguous as package-relative imports using a leading
integer (http://python.org/peps/pep-0328.html).

Now, one can remove ambiguity if we were able to 'label' while loops and
for loops producing  [  ] , [  ], but at that
point we are getting into the discussion of a loop-aware goto with
loop/block cleanup, and a syntax for labeling loops.  Ick.

 - 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] PEP 340: Breaking out.

[Ka-Ping Yee]

On Fri, 6 May 2005, Nick Coghlan wrote:
> Either way, my latest and greatest version of the non-looping block statement
> semantics can be found here:
> http://mail.python.org/pipermail/python-dev/2005-May/053400.html

My mind is not made up, but i did find this proposal pretty appealing.
I'd love to see it described in a complete PEP as that would make it
easier to compare directly -- in particular, comparing a list of use
cases to the one in PEP 340 would be very valuable to this discussion.


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

Re: [Python-Dev] PEP 340 keyword: Extended while syntax

[Ron Adam]

Gustavo Niemeyer wrote:
> Greetings,
> 
> 
>>Reasoning: The block statement resembles a "while" block in some ways in 
>>that it is a conditional block that may be executed only once, or 
>>possibly not at all (or many times).  And the word "while" is also 
>>descriptive of how a block is used.
>>
>> while VAR1 from EXPR1():
>> BLOCK
> 
> 
> This is an interesting propose, but for a different PEP.  

Maybe someone who is more familiar with submitting a PEP could submit it 
as a competing PEP to 340 then.

In the
> current propose VAR1 is not evaluated for truthness, and many of
> the usage examples doesn't even require it.

VAR1 isn't evaluated for truthfulness, but the expression as a whole is. 
  It just says, EXPR1 is a iterator, and VAR1 received a value from it. 
Evaluating to a bool makes it consistent with the 'while' statement 
usage and those checks are all-ready taking place in the block 
statement. Here they are explicit instead of implicit which adds to the 
readability. IMHO of course.

> This looks quite strange, for instance:
> 
>while dummy from locking(myLock):
>   # Do something

I thought of that, but I could get use to it.  The dummy helps make it 
readable although the value may not actually be used in the block.  One 
use with locks is to return a count of the current locks.  Useful for 
monitoring what the iterator is doing.

A shorter "while locking(myLock):" could be used, and the "dummy from" 
be optional.  In that case the returned None would be discarded.

while [NAME from] ITERATOR():

Or it could be made explicit with:

while None == locking(myLock):

Although I suppose this would look strange to some also. In this case, 
an explicit test is being made of the returned VAR1.  Testing for other 
values could be possible.


> And also, this would require a break necessarily:
> 
>while (foo, bar) from locking():
>   # Pass

If the iterator is written without a loop in it, it will only execute 
one yield, so the second time though it will end without returning a 
value.

def locking():
try:
yield lock()
finally:
release lock()

This will execute once in an extended while.

def locking():
try:
while True:
   yield new_lock()
finally:
release_all_locks()

This would need to be broken out of.

>>This will require a new keyword/operator 'from' to use in a 'from' 
>>expression:
> 
> 
> 'from' is already a keyword, btw.

Oh, um... need more sleep. ;-)

So no new keywords would be needed in this example, just an alternate 
use of an existing keyword.  Replace the above with...

 >>This will require *no* new keyword, the keyword/operator 'from' will 
have a new use in an extended while expression:

Since I tend to put imports at the top of my programs and never see 
'from' anywhere else, it didn't ring a bell.

Any reason why they both couldn't work?


Cheers, Ron_Adam


___
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] New Py_UNICODE doc

[Nicholas Bastin]

On May 4, 2005, at 6:03 PM, Martin v. Löwis wrote:

> Nicholas Bastin wrote:
>> "This type represents the storage type which is used by Python
>> internally as the basis for holding Unicode ordinals.  Extension 
>> module
>> developers should make no assumptions about the size of this type on
>> any given platform."
>
> But people want to know "Is Python's Unicode 16-bit or 32-bit?"
> So the documentation should explicitly say "it depends".

The important piece of information is that it is not guaranteed to be a 
particular one of those sizes.  Once you can't guarantee the size, no 
one really cares what size it is.  The documentation should discourage 
developers from attempting to manipulate Py_UNICODE directly, which, 
other than trivia, is the only reason why someone would care what size 
the internal representation is.

--
Nick
___
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] PEP 340: Breaking out.

[Paul Moore]

On 5/5/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so
> updating it with any of my ideas would be their call.

I'm willing to consider an update - I don't know Michael's view. I
currently find myself in the odd situation of defending PEP 340
against PEP 310, though. I'll try to rationalise why below...

> Either way, my latest and greatest version of the non-looping block statement
> semantics can be found here:
> http://mail.python.org/pipermail/python-dev/2005-May/053400.html

I can't reconcile this description with that of PEP 310. The basic
reason is that the styles are very different, compounded by the fact
that I don't have the time to give this the analysis it needs.

My instinct is that if your proposal can't be described in terms of a
relatively small change to one of PEP 310 or 340, then my view is it's
a 3rd proposal in its own right, and I'd rather not open things up
that much again.

> Some key advantages of that proposal are:
>1. It's not a loop, so nesting it inside another loop 'just works'

This, to me, is the main issue

>2. Manual protocol implementations are _significantly_ easier to write

Hmm, I've not tried so I'll have to take your word for this. But I
don't imagine writing manual implementations much - one of the key
features I like about Guido's proposal is that generators can be used,
and the implementation is a clear template, with "yield" acting as a
"put the block here" marker (yes, I know that's an
oversimplification!).

>3. try/finally can be done with generators _without_ changing generators

How is this an advantage? PEP 340 allows try/finally inside generators
- if that counts as "changing generators" I don't see why I care (as a
user). But I think I'm missing something here - I never really
followed (or cared about) the generator finalisation issues.

>4. try/except/else can be done with generators if they provide an __exit__
> method that raises the exception at the point of the last yield

As above - I'm not sure I follow.

>5. Clearly distinct construct, no potential for confusion with for loops

OK, but that's really just saying "not a loop" again.

>6. Generators must be clearly marked as creating a user defined statement
> (although this could be changed by giving them an __enter__ method and an
> __exit__ method)

I still don't see a compelling argument that this is a good thing. I'm
neutral on this.

> The one downside relative to PEP 340 is that looping constructs like 
> auto_retry
> are slightly harder to write, albeit not hugely so (once you remember that an
> iterable can be a class instead of a generator!).

Are you *sure* that's the only downside? Early on in the PEP 340
discussion, generator finalisation was a point of discussion. I didn't
follow the details, but I believe that one of the points of PEP 340
was that it addressed the issues (to some extent - I really don't know
if the generator finalisation PEPs are rendered obsolete by PEP 340,
are completely orthogonal, or somewhere in between). I have no feel
for whether your proposal covers these issues in the same way as PEP
340 does.

And does your proposal allow for "continue EXPR" as supported by PEP
340? I can't see that it could, given that your proposal treats block
statements as not being loops. Having just noticed this, I start to
feel less convinced that block-as-loop is ultimately wrong. There
aren't any examples of continue EXPR included in PEP 340 yet - a fact
that Guido has acknowledged in item 9 of the examples section. Maybe
Philip or one of the other coroutine fans would like to contribute
some examples?

> On the usage front, I find the
> 'loop over an iterator returning user defined statements' does a much better 
> job
> of making the iteration clear, so I'd be inclined to count that as an 
> advantage
> of a PEP 310 style approach.

I can accept that. It's a minor style point either way. The wording of
it - as "returning user defined statements" makes me nervous though,
as it implies that "user-defined statements" are first class objects -
which feels wrong.

> Anyway, I've already been spending more time on this than I should (sleep is
> optional, right?), so I won't be prettying it up into PEP format any time 
> soon.
> I have no objection to someone else rolling some of the ideas into a PEP, 
> though :)

I think *someone* has to care enough (and have the time) to make a
proper PEP out of this. If it's a minor change to either of PEP 310 or
PEP 340, that's OK. If it's too big for that, it needs to be fleshed
out as a full competing PEP in its own right.

Oh - and the promised rationalisation of my preference for PEP 340
over PEP 310. Things I like about PEP 340:

  - Using generators as "templates" with yield as a "put the block
here" placeholder. It may be that a modification of PEP 310 can
provide this, but that PEP doesn't exist yet (sorry!)
  - The coroutine style "continue EXPR"

Re: [Python-Dev] New Py_UNICODE doc

[Nicholas Bastin]

On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:

> Martin v. Löwis wrote:
>> Nicholas Bastin wrote:
>>
>>> "This type represents the storage type which is used by Python
>>> internally as the basis for holding Unicode ordinals.  Extension 
>>> module
>>> developers should make no assumptions about the size of this type on
>>> any given platform."
>>
>>
>> But people want to know "Is Python's Unicode 16-bit or 32-bit?"
>> So the documentation should explicitly say "it depends".
>
> On a related note, it would be help if the documentation provided a
> little more background on unicode encoding.  Specifically, that UCS-2 
> is
> not the same as UTF-16, even though they're both two bytes wide and 
> most
> of the characters are the same.  UTF-16 can encode 4 byte characters,
> while UCS-2 can't.  A Py_UNICODE is either UCS-2 or UCS-4.  It took me

I'm not sure the Python documentation is the place to teach someone 
about unicode.  The ISO 10646 pretty clearly defines UCS-2 as only 
containing characters in the BMP (plane zero).  On the other hand, I 
don't know why python lets you choose UCS-2 anyhow, since it's almost 
always not what you want.

--
Nick

___
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] PEP 340: Breaking out.

[Steven Bethard]

On 5/5/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> And does your proposal allow for "continue EXPR" as supported by PEP
> 340? I can't see that it could, given that your proposal treats block
> statements as not being loops.

Read PEP 340 again -- the "continue EXPR" syntax is orthogonal to the
discussion -- PEP 340 adds it for *all* for loops, so for loops with
the non-looping block statements would also be able to use it.

> The looping behaviour is a (fairly nasty) wart, but I'm not sure I
> would insist on removing it at the cost of damaging other features I
> like.

I don't think it "damages" any features.  Are there features you still
think the non-looping proposal removes?  (I'm not counting orthogonal
feautres like "continue EXPR" which could easily be added as an
entirely separate PEP.)

STeVe
-- 
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] New Py_UNICODE doc

[Shane Hathaway]

Nicholas Bastin wrote:
> 
> On May 4, 2005, at 6:20 PM, Shane Hathaway wrote:
>> On a related note, it would be help if the documentation provided a
>> little more background on unicode encoding.  Specifically, that UCS-2 is
>> not the same as UTF-16, even though they're both two bytes wide and most
>> of the characters are the same.  UTF-16 can encode 4 byte characters,
>> while UCS-2 can't.  A Py_UNICODE is either UCS-2 or UCS-4.  It took me
> 
> 
> I'm not sure the Python documentation is the place to teach someone
> about unicode.  The ISO 10646 pretty clearly defines UCS-2 as only
> containing characters in the BMP (plane zero).  On the other hand, I
> don't know why python lets you choose UCS-2 anyhow, since it's almost
> always not what you want.

Then something in the Python docs ought to say why UCS-2 is not what you
want.  I still don't know; I've heard differing opinions on the subject.
 Some say you'll never need more than what UCS-2 provides.  Is that
incorrect?

More generally, how should a non-unicode-expert writing Python extension
code find out the minimum they need to know about unicode to use the
Python unicode API?  The API reference [1] ought to at least have a list
of background links.  I had to hunt everywhere.

.. [1] http://docs.python.org/api/unicodeObjects.html

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

[Python-Dev] PEP 340: Examples as class's.

[Ron Adam]

Eric Nieuwland wrote:

 > Ron Adam wrote:
 >
 >> Eric Nieuwland wrote:
 >>
 >>> This is linear. No looping whatsoever. And easily translated to a
 >>> simple language construct and a protocol:
 >>>
 >>> class resource(object):
 >>> def __init__(self,...):
 >>> # store resource parameters
 >>> def __acquire__(self):
 >>> # whatever it takes to grab the resource
 >>> def __release__(self):
 >>> # free the resource
 >>
 >>
 >>
 >>
 >> I wanted to see what the examples in PEP340 would look like written with
 >> standard class's using object inheritance and overriding to define
 >> resource managers.  If anyone's interested I can post it.
 >
 >
 > I'm interested.
 >
 >> My block class is non-looping as I found in most cases looping isn't
 >> required, and looping complicates things because you have to pass around
 >> a loop expression due to not all loops will want to behave that same 
way.
 >>
 >> The solution was to put the loop in the body method and call a
 >> repeat_body method (the repeated body section) which is added to the
 >> class when needed.
 >
 >
 > Show us your stuff! ;-)
 >
 > --eric
 >
Ok,  :)

These probably can be improved on, and renamed, and I don't know how 
many problems there may be with it, but they work in these examples. 
This is just one way to do it,  so critique, correct, and improve as 
needed.  Just no flames please.  ;-)

Cheers,  Ron_Adam


# --- start ---
## blockclass.py


##  A base class that manages resource acquire and release.
class Block(object):
"""A manager class for working with resources."""
def __init__(self,*args):
self._cleanup = False
self.__err__ = None
try:
self.start(*args)
self._cleanup = True
except:
raise
def __call__(self, *args):
self.block(*args)
self.__del__()
def __del__(self):
if self._cleanup:
try:
self.final()
self._cleanup = False
except:
raise
if self.__err__:
raise self.__err__
def start(self,*args):
"""Override to add initialization code"""
pass
def final(self):
"""Override to add finalization code"""
pass
def block(self,*args):
"""Override to add main block body"""
pass


## A dummy lock for test calls only
class mylock:
def acquire(self):
print "Lock acquired"
def release(self):
print "Lock released"


## 1. A template for ensuring that a lock, acquired at the start of a
##   block, is released when the block is left:
class Get_Lock(Block):
def start(self, lock):
self.lock = lock
self.lock.acquire()
def final(self):
self.lock.release()
def block(self):
pass

class Lock_It(Get_Lock):
def block(self):
print "Do stuff while locked"
   Lock_It(mylock())()


## 2. A template for opening a file that ensures the file is closed:
class File_Opener(Block):
def start(self, filename, mode='r'):
self.filename = filename
self.mode = mode
self.f = open(filename, mode)
def final(self):
self.f.close()
def block(self):
pass

class Line_Printer(File_Opener):
def block(self):
n = 0
for line in self.f:
print n, line.rstrip()
n += 1

Line_Printer('blockclass.py')()



### 3. A template for committing or rolling back a database:
#def transactional(db):
#try:
#yield
#except:
#db.rollback()
#raise
#else:
#db.commit()

"""I'm not exactly sure how this one should work, so maybe some
one else can give an example using the block class above."""



## 4. A template that tries something up to n times:
import urllib
class Auto_Retry(Block):
def start(self, n=3, exc=Exception):
self.n = n
self.exc = exc
def block(self, *args):
while self.n:
try:
self.repeat_block(*args)
break
except self.exc, self.__err__:
self.n -= 1
def repeat_block(self, *args):
"""Try this block n times"""
pass

class Retry_Url(Auto_Retry):
def repeat_block(self, url):
f = urllib.urlopen(url)
print f.read()

# This could be slow, so wait for it.
try:
Retry_Url(3, IOError)("http://cantfind.com/this.html";)
except IOError, err:
print err

Retry_Url(3, IOError)("http://python.org/peps/pep-0340.html";)



## 5. It is possible to nest blocks and combine templates:
class Lockit(Get_Lock):
def block(self, job):
job()

Lockit(mylock())(Line_Printer("blockclass.py"))



## 7. Redirect stdout temporarily:
import sys
class Redirect_Stdout(Block):
def start(self, handle=sys.stdout):
self.save_stdout = sys.stdout
sys.stdout = handle
def final(self):
sys.stdout.close()
sys.stdout = self.save_std

Re: [Python-Dev] PEP 340: Breaking out.

[Delaney, Timothy C (Timothy)]

Greg Ewing wrote:

> Seems to me it should be up to the block iterator whether
> a break statement gets caught or propagated, since it's
> up to the block iterator whether the construct behaves
> like a loop or not.
> 
> This could be achieved by having a separate exception
> for breaks, as originally proposed.
> 
> If the iterator propagates the Break exception back out,
> the block statement should break any enclosing loop.
> If the iterator wants to behave like a loop, it can
> catch the Break exception and raise StopIteration
> instead.

In this scenario (and I'm not saying I approve or disapprove) I think
BreakIteration should inherit from StopIteration (thus retaining the
existing PEP 340 semantics if uncaught)::

Iteration
 |
 +- ContinueIteration
 |
 +- StopIteration
 |
 +- BreakIteration

I think no matter what it would be useful to be able to separate a break
from a stop sometimes, but there are many cases where they are the same
thing.

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

Re: [Python-Dev] PEP 340: Breaking out.

[Simon Percivall]

On 6 maj 2005, at 03.55, Greg Ewing wrote:
> Seems to me it should be up to the block iterator whether
> a break statement gets caught or propagated, since it's
> up to the block iterator whether the construct behaves
> like a loop or not.

And this is not confusing in what way? Making it depend
means you constantly have to readjust your understanding
of the statement based on the context. And this is _if_
you know how it behaves in the particular case. If you're
trying to understand the source code, having break depend
on something defined somewhere completely else seems like
an obstacle to easy understanding. IMHO, of course.

//Simon

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

Re: [Python-Dev] PEP 340: Breaking out.

[Greg Ewing]

Seems to me it should be up to the block iterator whether
a break statement gets caught or propagated, since it's
up to the block iterator whether the construct behaves
like a loop or not.

This could be achieved by having a separate exception
for breaks, as originally proposed.

If the iterator propagates the Break exception back out,
the block statement should break any enclosing loop.
If the iterator wants to behave like a loop, it can
catch the Break exception and raise StopIteration
instead.

-- 
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] PEP 340: propose to get rid of 'as' keyword

[Greg Ewing]

Fredrik Lundh wrote:

> the current
> proposal stems from the observation that "for-loop plus generators" in
> today's Python does in fact provide a block implementation that solves
> many use cases in an elegant way.
> 
> PEP 340 builds on this, sorts out a couple of weak points in the current
> design, and adds an elegant syntax for most remaining use cases.

I still can't help feeling we're making a cart/horse
ordering error here, though. Part of me regards the
"for-loop plus generators" idea as an elegant hack,
whose elegance only extends as far as it *doesn't*
require anything beyond existing syntax and semantics.
If new syntax and tricky new interactions with iterators
are needed to support it, it doesn't seem so elegant
any more.

-- 
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] PEP 340 - Remaining issues - keyword

[Greg Ewing]

Nick Coghlan wrote:

> Something relatively nonsensical, but usefully mnemonic
 > (like 'stmt') may be a good way to go.

How about 'do'?

   do opening(filename) as f:
 ...

   do locking(obj):
 ...

   do carefully(): # :-)
 ...

-- 
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] PEP 340: Breaking out.

[Greg Ewing]

Simon Percivall wrote:

> And this is not confusing in what way?

I don't think it's any less confusing than having a
construct in the first place which can either be a
loop or not. You need to know the semantics of the
block iterator in order to know whether it's a loop.
Once you know that, you know how break behaves (as
long as the iterator is sanely designed).


  Making it depend
> means you constantly have to readjust your understanding
> of the statement based on the context. And this is _if_
> you know how it behaves in the particular case. If you're
> trying to understand the source code, having break depend
> on something defined somewhere completely else seems like
> an obstacle to easy understanding. IMHO, of course.
> 
> //Simon
> 


-- 
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] PEP 340: Breaking out.

[Greg Ewing]

Delaney, Timothy C (Timothy) wrote:

> In this scenario (and I'm not saying I approve or disapprove) I think
> BreakIteration should inherit from StopIteration (thus retaining the
> existing PEP 340 semantics if uncaught)::

Not sure I understand. The point of my suggestion was
to *not* retain existing PEP 340 semantics if uncaught,
i.e. break an enclosing loop rather than just terminate
the block statement.

-- 
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] Pre-PEP: Unifying try-except and try-finally

[Greg Ewing]

Nick Coghlan wrote:

> What does a try statement with neither an except clause nor a finally clause 
> mean?

I guess it would mean the same as

   if 1:
 ...

Not particularly useful, but maybe it's not worth complexifying
the grammar just for the sake of disallowing it.

Also, some people might find it useful for indenting a block
of code for cosmetic reasons, although that could easily
be seen as an abuse...

-- 
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] PEP 340 - For loop cleanup, and feature separation

[Greg Ewing]

I'm still bothered by the idea of for-loops not participating
in the new generator finalization protocol.

It's all very well to say that iterators designed for block
statements shouldn't be used in for-loops, but there may
be more subtle cases to consider, such as

   def file_frobulations(filenames):
 for filename in filenames:
   block opening(filename) as f:
 yield something_derived_from(f)

This is clearly intended to be a normal iterator, not a
block iterator, and thus should be usable in a for-loop.
But if for-loops don't use the finalization protocol,
it won't be guaranteed to work correctly.

So I think that, in the interests of least surprise,
for-loops should provide the same finalization promises
as block statements.

If that is done, it becomes easier to decide whether
the block statement should loop. The answer is probably
no: If you're writing a loop, you use a for-statement;
if you're not, you use a block-statement. This helps
to clearly differentiate the two, and provide
justification for having two statements.

I'm also starting to like the idea of having a
completely separate protocol for block-statements,
and an adaptor of some kind for using generators to
implement them. We would then have two *totally*
separated new features:

1) A block-statement, and an associated protocol
designed specifically for it, independent of
any existing protocols.

2) A mechanism for passing values and exceptions into
generators, which is useful in its own right and
already has use cases.

With the addition of an adaptor between the block
protocol and the iterator protocol, which can be
implemented *without* needing any further features,
these two features then combine synergistically to
give you block iterators implemented by generators.

This makes a lot more sense to me than trying to
warp the iterator protocol to make it into a block
protocol as well. Let's keep the two things orthogonal.

-- 
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] PEP 340 - For loop cleanup, and feature separation

[Delaney, Timothy C (Timothy)]

Greg Ewing wrote:

> I'm still bothered by the idea of for-loops not participating
> in the new generator finalization protocol.

I agree - that's always been nagging at me too.

The problem with it is that then you either:

1. Have a guarantee that an iterator will be exhausted when the for loop
exits (as per block statements);

OR

2. Rely on garbage collection (reference counting, etc) to ensure
finalisation.

Personally, I'm of the opinion that we should make a significant break
(no pun intended ;) and have for-loops attempt to ensure that iterators
are exhausted. An iterator could be specifically designed to prevent
that if needed, but in the vast majority of cases an iterator is never
used after the for-loop.

An example of an iterator that was specifically designed to continue
working after its initial for-loop would be::

def gen():
try:
setup1()

try:
yield 1
finally:
cleanup1()

except StopIteration:
pass

setup2()

try:
yield 2
finally:
cleanup2()

This allows cleanup, but then continued usage.

> So I think that, in the interests of least surprise,
> for-loops should provide the same finalization promises
> as block statements.

Agreed.

> If that is done, it becomes easier to decide whether
> the block statement should loop. The answer is probably
> no: If you're writing a loop, you use a for-statement;
> if you're not, you use a block-statement. This helps
> to clearly differentiate the two, and provide
> justification for having two statements.

Agreed.

> I'm also starting to like the idea of having a
> completely separate protocol for block-statements

+1

> and an adaptor of some kind for using generators to
> implement them.

My preference would be direct syntactic support...

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