Re: [Python-Dev] [Python-checkins] peps: Record Guido's acceptance of PEP 380

[Barry Warsaw]

On Jun 26, 2011, at 05:02 AM, nick.coghlan wrote:

>http://hg.python.org/peps/rev/9f7a0b4e38a7
>changeset:   3889:9f7a0b4e38a7
>user:Nick Coghlan 
>date:Sun Jun 26 13:02:17 2011 +1000
>summary:
>  Record Guido's acceptance of PEP 380
>
>files:
>  pep-0380.txt |  10 --
>  1 files changed, 8 insertions(+), 2 deletions(-)
>
>
>diff --git a/pep-0380.txt b/pep-0380.txt
>--- a/pep-0380.txt
>+++ b/pep-0380.txt
>@@ -3,11 +3,11 @@
> Version: $Revision$
> Last-Modified: $Date$
> Author: Gregory Ewing 
>-Status: Draft
>+Status: Accepted
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 13-Feb-2009
>-Python-Version: 3.x
>+Python-Version: 3.3
> Post-History:

Please add a Resolution header as per PEP 1.

Thanks!
-Barry


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

Re: [Python-Dev] [Python-checkins] cpython (3.2): #11669: rephrase footnote in the Compound Statements page.

[Nick Coghlan]

On Sun, Jun 26, 2011 at 6:38 PM, ezio.melotti
 wrote:
> -.. [#] The exception is propagated to the invocation stack only if there is 
> no
> -   :keyword:`finally` clause that negates the exception.
> +.. [#] The exception is propagated to the invocation stack unless
> +   there is a :keyword:`finally` clause which happens to raise another
> +   exception. That new exception causes the old one to be lost.

I believe the footnote was talking about this case:

>>> def f():
...   try:
... raise Exception()
...   finally:
... return "What exception?"
...
>>> f()
'What exception?'

The new wording doesn't accurately reflect that.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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-checkins] cpython (3.2): #11669: rephrase footnote in the Compound Statements page.

[Sandro Tosi]

Hi Nick,
given I'm "guilty" for this patch, I'd reply :)

On Sun, Jun 26, 2011 at 15:55, Nick Coghlan  wrote:
> On Sun, Jun 26, 2011 at 6:38 PM, ezio.melotti
>  wrote:
>> -.. [#] The exception is propagated to the invocation stack only if there is 
>> no
>> -   :keyword:`finally` clause that negates the exception.
>> +.. [#] The exception is propagated to the invocation stack unless
>> +   there is a :keyword:`finally` clause which happens to raise another
>> +   exception. That new exception causes the old one to be lost.
>
> I believe the footnote was talking about this case:
>
 def f():
> ...   try:
> ...     raise Exception()
> ...   finally:
> ...     return "What exception?"
> ...
 f()
> 'What exception?'
>
> The new wording doesn't accurately reflect that.

I gave my interpretation of the footnote at:
http://bugs.python.org/issue11669#msg139092 . Does this clarify it?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
___
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] Issue10403 - using 'attributes' instead of members in documentation

[Senthil Kumaran]

Hello! 

http://bugs.python.org/issue10403 is a documentation bug which talks
about using the term 'attribute' instead of the term 'member' when it
denotes the class attributes. Agreed.

But the discussion goes on to mention that,

"Members and methods" should just be "attributes".

I find this bit odd. If the two terms are used together, then
replacing it with attributes is fine. But the term 'methods' cannot be
replaced with 'attributes' as it changes the meaning.

Take this case,

   :class:`BZ2File` provides all of the methods specified by the
   :class:`io.BufferedIOBase`, except for :meth:`detach` and :meth:`truncate`.
   Iteration and the :keyword:`with` statement are supported.

is correct, whereas replacing "methods with attributes" would make it as

   :class:`BZ2File` provides all of the attributes specified by the
   :class:`io.BufferedIOBase`, except for :meth:`detach` and :meth:`truncate`.
   Iteration and the :keyword:`with` statement are supported.

It does not seem correct.

My stance is, "It is attributes instead of term members and the term method
when it denotes methods can be left as such." Can I still hold on to that and
modify the patch which Adam has submitted or the 'attribute' substitution
everywhere makes sense?


Thanks,
Senthil
___
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] Issue10403 - using 'attributes' instead of members in documentation

[Terry Reedy]

On 6/26/2011 2:52 PM, Senthil Kumaran wrote:


http://bugs.python.org/issue10403 is a documentation bug which talks
about using the term 'attribute' instead of the term 'member' when it
denotes the class attributes. Agreed.

But the discussion goes on to mention that,

"Members and methods" should just be "attributes".


The terms 'member' ('data attribute' in modern terms) and 'method' go 
back to original Python when builtin types (or instances thereof) had 
members, methods, neither, or possibly both (but I do not remember 
anything with both). I believe there were separate builtin functions for 
retrieving them. "Member' is obsolete; 'method' definitely is not.



I find this bit odd. If the two terms are used together, then
replacing it with attributes is fine.


Agreed.


But the term 'methods' cannot be
replaced with 'attributes' as it changes the meaning.


Also agreed.


Take this case,

:class:`BZ2File` provides all of the methods specified by the
:class:`io.BufferedIOBase`, except for :meth:`detach` and :meth:`truncate`.
Iteration and the :keyword:`with` statement are supported.

is correct, whereas replacing "methods with attributes" would make it as

:class:`BZ2File` provides all of the attributes specified by the
:class:`io.BufferedIOBase`, except for :meth:`detach` and :meth:`truncate`.
Iteration and the :keyword:`with` statement are supported.

It does not seem correct.


It may not even be correct. I would leave it as is unless there are 
inherited data attributes so that the correction makes more sense than 
the original. A blind change of 'method' to 'attribute' is wrong.



My stance is, "It is attributes instead of term members and the term method
when it denotes methods can be left as such." Can I still hold on to that and
modify the patch which Adam has submitted


Yes.


or the 'attribute' substitution everywhere makes sense?


No.

My strong history-based opinions ;-).

--
Terry Jan Reedy

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

Re: [Python-Dev] ctypes: Configurable bitfield allocation strategy

[Vlad Riscutia]

Well it's not really layout, because alignment is handled by pack option. It
is how the field gets allocated. At this point I believe it will be more
complex to come up with custom allocation option, precisely because it's up
to each compiler to allocate the structure. Such flexibility will add a lot
of complexity and it might not payoff. This is debatable, but I would go
with a 3 option strategy at this point - native, GCC, MSVC and if we
actually find interop issues with other compilers we can look into custom
allocation.

I will try to refactor the C code to more easily accommodate a mode option
(while leaving behavior the same for now), then we can decide how the
library interface should look like.

Thank you,
Vlad

On Sat, Jun 25, 2011 at 4:37 PM, Greg Ewing wrote:

> Vlad Riscutia wrote:
>
>> Longer term though, I think it would be better to add a property on the
>> Structure class for configurable allocation strategy, for example Native
>> (default), GCC, MSVC
>>
>
> It could also be good to have a mode which lets you specify
> *exactly* how the bits are laid out, independent of any
> particular compiler.
>
> --
> 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/**
> riscutiavlad%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (3.2): #11669: rephrase footnote in the Compound Statements page.

[Nick Coghlan]

On Mon, Jun 27, 2011 at 12:02 AM, Sandro Tosi  wrote:
> I gave my interpretation of the footnote at:
> http://bugs.python.org/issue11669#msg139092 . Does this clarify it?

No, because while there *are* ways a finally clause can kill an
exception completely, reraising another exception is not really one of
them (as we set __context__ appropriately in that case, even if it
means forcing instantiation of an as yet unrealised exception).

>From PEP 3134:

"This PEP handles exceptions that occur during 'except' blocks and
'finally' blocks in the same way.  Reading the traceback makes it
clear where the exceptions occurred, so additional mechanisms for
distinguishing the two cases would only add unnecessary complexity."

And from the interactive prompt:

>>> try:
...   raise TypeError
... except TypeError:
...   raise ValueError
...
Traceback (most recent call last):
  File "", line 2, in 
TypeError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 4, in 
ValueError
>>> try:
...   raise TypeError
... finally:
...   raise ValueError
...
Traceback (most recent call last):
  File "", line 2, in 
TypeError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 4, in 
ValueError

Note that PEP 3134 exception chaining means the original exception is
not lost in either case - it is available via the __context__
attribute of the subsequent exception.

However, *other* control flow statements in a finally clause *can*
mean that an exception is lost completely, just as if it had been
caught and not reraised:

- the "return" example from my first message ('yield' will allow the
exception to propagate when the generator is resumed)
- 'break' in a loop ('continue' is not permitted inside a 'finally' clause)

The old wording was at least vaguely right ("there are ways that a
finally clause can kill an exception, but we aren't going to tell you
what they are"). The new wording is precisely wrong, as it excludes
the return and break cases (in both 2.x and 3.x) and, in 3.x, fails to
note that the old exception isn't lost completely due to exception
chaining (even if it is indeed hidden from any exception handlers in
the current call stack).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Issue10403 - using 'attributes' instead of members in documentation

[Nick Coghlan]

On Mon, Jun 27, 2011 at 7:52 AM, Terry Reedy  wrote:
>> or the 'attribute' substitution everywhere makes sense?
>
> No.
>
> My strong history-based opinions ;-).

+1 to what Terry said.

"Members" is a historical relic that is best replaced by "attributes"
or "data attributes" if we want to explicitly exclude methods for some
reason. "Methods" is a subset of attributes that explicitly excludes
data attributes.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] EuroPython Language Summit report

[P.J. Eby]

At 12:32 PM 6/25/2011 -0400, R. David Murray wrote:

So your proposed code would allow me, when writing a generator in
my code, do something that would allow me to yield up all the
values from an arbitrary generator I'm calling, over which I have
no control (ie: I can't modify its code)?


With a decorator on your own function, yes.  See:

  http://mail.python.org/pipermail/python-dev/2010-July/102320.html

for details.  Mostly, though, that proposal was a suggestion for how 
the "optimized" implementation would work - i.e., a suggestion that 
PEP 380 be implemented that way under the hood, by implicitly turning 
'yield from' into 'yield From()' and wrapping the generator itself 
with another From() instance.


(IOW, that was a proposal for how to avoid the extra overhead of 
recursive yielding in a series of nested yield-from's.)


___
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