Re: [Python-Dev] __objclass__ documentation

2013-10-13 Thread Ethan Furman 

On 10/12/2013 11:18 PM, Cameron Simpson wrote:

On 12Oct2013 15:03, Ethan Furman  wrote:

It was pointed in Issue16938[1] that __objclass__ is not documented anywhere.

Is the following an appropriate description? (in Doc/reference/datamodel.rst in 
user-defined functions)
   +-+---+---+
   | :attr:`__objclass__`| The class this object belongs |   |
   | | to; useful when the object is |   |
   | | a descriptor, or a virtual or |   |
   | | dynamic class attribute, and  |   |
   | | it's __class__ attribute does |   |


"its" please. Like "his", "her", "their".


Right.




   | | not match the class it is |   |
   | | associated with, or it is not |   |
   | | in that class' ``__dict__``.  |   |
   +-+---+---+
[1] http://bugs.python.org/issue16938


I'd make this two sentences. Just turn the semicolon into a full
stop, and commence "This is useful when".

I had trouble with the end. How about:

   or it is not in __class__.__dict__

Do I misunderstand?


You have it right.  Good change.

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change PEP 399 import recommendation

2013-10-13 Thread Stefan Behnel 
Antoine Pitrou, 12.10.2013 23:40:
> On Sat, 12 Oct 2013 23:35:23 +0200
> Christian Heimes wrote:
>> A directory with pure Python modules is less cumbersome than a couple
>> of facade modules or intended code in try/except ImportError blocks.
> 
> I don't find it cumbersome to be explicit here. It makes it obvious
> what happens. It also makes it extra easy to import the pure Python if
> desired (for example for unit tests, or for benchmarking).

I agree. I find it much easier to read a plain and obvious

try:
   from _cmodule import *
except ImportError:
   from _pymodule import *

in a facade module than

# lots and lots
# of unused
# Python code
# here ...

# ... and then this, well hidden at the end, telling
# me that I just waded through the entirely wrong code:

try:
   from _cmodule import *
except ImportError:
   pass

As I said, that's different for the case where the C module replaces only a
somewhat small part of the Python code, but for the case of an (almost)
complete replacement, I would like to see the 3-files approach as the One
Way To Do It.

Stefan


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Right place for PBKDF2 wrapper

2013-10-13 Thread Christian Heimes 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am 13.10.2013 08:32, schrieb Nick Coghlan:
> +1 to hashlib from me (especially since we used that as the best 
> available home for compare_digest).

I'm afraid your memory doesn't serve you well. :(
compare_digest is implemented in _operator.c. Its official home is
hmac.compare_digest.

Christian

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJSWnhsAAoJEMeIxMHUVQ1FeCoP/1iuk+IKsDXYnwvFPqD9XAQV
2Bjs8ohY7pP1fSiupgf3Rc88OqYnsbdldo4DJICkCAsrygGEVncQZ2S4+qCkjdIZ
xW0IT5NmUR3VapoLOUbom/giODp/cQiEl/aVHhJlp7xbcv2RBoTQoqYprNxqOv3s
tGn8hbC3ptdn/g+eF9SqHNEIAC30YqoqHbKNJXfCtZ8rhG3I2ww90IRdmx0d0Iv9
ZfMqSz6gCqTomoxgb/2l/alSyGqoKky9nHvPGdgbJcUugI+RUInQae/ZBzBEvBbq
odtu9cfxnRwkX11dioNnVjL8nV99UskA2CRVEQxk+TO3weNsWI6Er0SgFm8Rd6g9
ElW9YnMnenW/SgNLLGj8tklHheAspoI3HlFaEszEdR/6WAAkd9BjD42Ku598W1ZH
HVPzlnQPO1/HOP7GHPekVzMco9CBNcSSSg7DrK15WQbJRqid9c7NDM9HouSX6cdo
OnMewGg5Q3lq4zWDstSI5VEfjHn/ZEGG1HHXQkP3LEnmqb1gFlL7Y+i5rCr0Kp4q
u4xKMlnoq/K5GXd7YmJ6DktLn5bOmfIyDIct6hncr6uZa0pLsFBJ0xOJ6ZkqVvNY
SJHzcwjoN+AB2SpALzZjCjhn3OioCTwQ5j/Ah3QqT0+l1Ynkv7LBy6XuSvAa/Nky
2az2mBUKYqagFPMNiRl4
=G4qD
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __objclass__ documentation

2013-10-13 Thread Nick Coghlan 
On 13 Oct 2013 08:27, "Ethan Furman"  wrote:
>
> It was pointed in Issue16938[1] that __objclass__ is not documented anywhere.
>
> Is the following an appropriate description? (in Doc/reference/datamodel.rst 
> in user-defined functions)
>
>
>
>   +-+---+---+
>   | :attr:`__objclass__`| The class this object belongs |   |
>   | | to; useful when the object is |   |
>   | | a descriptor, or a virtual or |   |
>   | | dynamic class attribute, and  |   |
>   | | it's __class__ attribute does |   |
>   | | not match the class it is |   |
>   | | associated with, or it is not |   |
>   | | in that class' ``__dict__``.  |   |
>   +-+---+---+

I think this is inaccurate. The meaning of __objclass__ as described
in PEP 252 is to denote unbound callable descriptors that only work
with a specific type. That's why it's mostly gone in Python 3.

It should be documented, but the documentation should say something like:

__objclass__: Indicates this callable requires an instance of the
given type (or a subclass) as its first positional argument. For
example, CPython sets this for unbound methods that are implemented in
C rather than Python.

The offending block of code in the inspect module
(http://hg.python.org/cpython/file/default/Lib/inspect.py#l366) that
prompted http://bugs.python.org/issue16938 just looks flat out broken
to me. There's *zero* reason to expect that __class__ on the result of
retrieving an attribute from an object will appear in the MRO for that
object. I just missed that detail when reviewing
http://bugs.python.org/issue19030 :)

I'll reply on the tracker with some additional details/suggestions.

Cheers,
Nick.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change PEP 399 import recommendation

2013-10-13 Thread Stefan Krah 
Stefan Behnel  wrote:
> in a facade module than
> 
> # lots and lots
> # of unused
> # Python code
> # here ...
> 
> # ... and then this, well hidden at the end, telling
> # me that I just waded through the entirely wrong code:
> 
> try:
>from _cmodule import *
> except ImportError:
>pass

I don't care much about the directory versus facade module approach, but the
above is really worth noting.  For decimal, I find the three-files approach
easier to manage: All private symbols of the Python version are automatically
no longer imported; they don't have to be deleted when the C version is
used.  Also, the new scheme uncovered some missing symbols in __all__.

The downside for CPython is just a slightly more cluttered directory listing
(and the doctests get a bit messier).


The other implementations could import their (hypothetical) accelerators
in the facade module and override selected symbols there (I think Nick
mentioned that already).


Stefan Krah


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Right place for PBKDF2 wrapper

2013-10-13 Thread Nick Coghlan 
On 13 October 2013 20:39, Christian Heimes  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am 13.10.2013 08:32, schrieb Nick Coghlan:
>> +1 to hashlib from me (especially since we used that as the best
>> available home for compare_digest).
>
> I'm afraid your memory doesn't serve you well. :(
> compare_digest is implemented in _operator.c. Its official home is
> hmac.compare_digest.

*sigh* Well, we knew that was an unintuitive home when we picked it :P

We'll get the standard library's crypto APIs to a sensible state some day :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Antoine Pitrou 
On Sun, 13 Oct 2013 16:57:09 +1000
Nick Coghlan  wrote:
> 
> For the record, this thread did prompt me to consider the new construct
> anew, but on reflection, I still consider it a reasonable addition to
> contextlib.
> 
> It substantially improves the simple cases it is intended to help with,
> and, if anything, makes overly broad exception suppression *more* obviously
> dubious (because the name of the construct doesn't match the consequences
> for multi-line suites).

Why? Anyone can still write "try ... except".

The only sticking point for this construct is that it allows to save
one or two lines in rather uncommon cases (because most of the time you
should do something on an exception, not "ignore" it). The saving is
not worth it.

Basically instead of:

  try:
  # something
  except FooException:
  pass

You write:

  from contextlib import ignore
  with ignore(FooException):
  # something

There's actually more typing involved, and one more API to know about...
It is just another case of those "one-liners" that we generally refrain
from adding to the stdlib.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Nick Coghlan 
On 13 October 2013 22:34, Antoine Pitrou  wrote:
> On Sun, 13 Oct 2013 16:57:09 +1000
> Nick Coghlan  wrote:
>>
>> For the record, this thread did prompt me to consider the new construct
>> anew, but on reflection, I still consider it a reasonable addition to
>> contextlib.
>>
>> It substantially improves the simple cases it is intended to help with,
>> and, if anything, makes overly broad exception suppression *more* obviously
>> dubious (because the name of the construct doesn't match the consequences
>> for multi-line suites).
>
> Why? Anyone can still write "try ... except".
>
> The only sticking point for this construct is that it allows to save
> one or two lines in rather uncommon cases (because most of the time you
> should do something on an exception, not "ignore" it). The saving is
> not worth it.
>
> Basically instead of:
>
>   try:
>   # something
>   except FooException:
>   pass
>
> You write:
>
>   from contextlib import ignore
>   with ignore(FooException):
>   # something
>
> There's actually more typing involved, and one more API to know about...
> It is just another case of those "one-liners" that we generally refrain
> from adding to the stdlib.

It meets my threshold for inclusion (albeit only just). Your objection
has been noted. I still do not agree. Now, can you please just let the
matter drop?

That's the way this works (unless you think this is such a disastrous
addition that you want to appeal to Guido to strip me of my
responsibilities as contextlib maintainer and go hunting for a new
one).

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Antoine Pitrou 
On Sun, 13 Oct 2013 22:50:07 +1000
Nick Coghlan  wrote:
> That's the way this works (unless you think this is such a disastrous
> addition that you want to appeal to Guido to strip me of my
> responsibilities as contextlib maintainer and go hunting for a new
> one).

Wow... I don't think challenging others to "strip you of your
responsibilities" is a reasonable way to address criticism.

And for the record, it's not *my* objection; several other core
developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Antoine Pitrou 
On Sun, 13 Oct 2013 16:05:40 +0200
Antoine Pitrou  wrote:
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan  wrote:
> > That's the way this works (unless you think this is such a disastrous
> > addition that you want to appeal to Guido to strip me of my
> > responsibilities as contextlib maintainer and go hunting for a new
> > one).
> 
> Wow... I don't think challenging others to "strip you of your
> responsibilities" is a reasonable way to address criticism.
> 
> And for the record, it's not *my* objection; several other core
> developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.

And, by the way, thanks for the doc changes: they make the concerns
clear.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Serhiy Storchaka 

13.10.13 15:50, Nick Coghlan написав(ла):

On 13 October 2013 22:34, Antoine Pitrou  wrote:

There's actually more typing involved, and one more API to know about...
It is just another case of those "one-liners" that we generally refrain
from adding to the stdlib.


It meets my threshold for inclusion (albeit only just). Your objection
has been noted. I still do not agree. Now, can you please just let the
matter drop?


Not only Antoine's objection. Many other people consider this at least 
useless.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Victor Stinner 
2013/10/13 Antoine Pitrou :
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan  wrote:
>> That's the way this works (unless you think this is such a disastrous
>> addition that you want to appeal to Guido to strip me of my
>> responsibilities as contextlib maintainer and go hunting for a new
>> one).
>
> Wow... I don't think challenging others to "strip you of your
> responsibilities" is a reasonable way to address criticism.
>
> And for the record, it's not *my* objection; several other core
> developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.

You can also count me as -1: the context manager looks like it ignores
the exception, whereas it does not: you exit immediatly the block when
the exception occurs. It's maybe an issue with the name.

Like Antoine, I'm not sure that we need a new context manage to save 2 lines.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __objclass__ documentation

2013-10-13 Thread Ethan Furman 

On 10/13/2013 04:44 AM, Nick Coghlan wrote:

On 13 Oct 2013 08:27, "Ethan Furman"  wrote:


It was pointed in Issue16938[1] that __objclass__ is not documented anywhere.

Is the following an appropriate description? (in Doc/reference/datamodel.rst in 
user-defined functions)



   +-+---+---+
   | :attr:`__objclass__`| The class this object belongs |   |
   | | to; useful when the object is |   |
   | | a descriptor, or a virtual or |   |
   | | dynamic class attribute, and  |   |
   | | it's __class__ attribute does |   |
   | | not match the class it is |   |
   | | associated with, or it is not |   |
   | | in that class' ``__dict__``.  |   |
   +-+---+---+


I think this is inaccurate. The meaning of __objclass__ as described
in PEP 252 is to denote unbound callable descriptors that only work
with a specific type. That's why it's mostly gone in Python 3.


PEP 252 has this comment:

[Editor's note: the ideas described in this PEP have been incorporated
 into Python.  The PEP no longer accurately describes the implementation.]



It should be documented, but the documentation should say something like:

__objclass__: Indicates this callable requires an instance of the
given type (or a subclass) as its first positional argument. For
example, CPython sets this for unbound methods that are implemented in
C rather than Python.



The offending block of code in the inspect module
(http://hg.python.org/cpython/file/default/Lib/inspect.py#l366) that
prompted http://bugs.python.org/issue16938 just looks flat out broken
to me. There's *zero* reason to expect that __class__ on the result of
retrieving an attribute from an object will appear in the MRO for that
object. I just missed that detail when reviewing
http://bugs.python.org/issue19030 :)


Actually, it's the other way around -- the code currently in inspect.py at that point was prompted by this issue (and 
tracked in Issue 19030).  Interestingly enough, with the current changes in 16938 I can remove the __objclass__ 
attribute I had added to Enum to get around this.


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Ethan Furman 

On 10/13/2013 05:34 AM, Antoine Pitrou wrote:

On Sun, 13 Oct 2013 16:57:09 +1000
Nick Coghlan  wrote:


For the record, this thread did prompt me to consider the new construct
anew, but on reflection, I still consider it a reasonable addition to
contextlib.

It substantially improves the simple cases it is intended to help with,
and, if anything, makes overly broad exception suppression *more* obviously
dubious (because the name of the construct doesn't match the consequences
for multi-line suites).


Why? Anyone can still write "try ... except".


True, but Raymond's example of

with ignore(OSError):
os.remove('somefile')

struck a chord -- I've used the try ... except version of that many times, and each time it's been a pain.  I now agree 
this context manager is a win.


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Victor Stinner 
2013/10/13 Ethan Furman :
> True, but Raymond's example of
>
> with ignore(OSError):
> os.remove('somefile')

And what about:

with ignore(OSError):
  os.remove('file1')
  os.remove('file2')

?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Nick Coghlan 
On 14 October 2013 01:05, Victor Stinner  wrote:
> 2013/10/13 Ethan Furman :
>> True, but Raymond's example of
>>
>> with ignore(OSError):
>> os.remove('somefile')
>
> And what about:
>
> with ignore(OSError):
>   os.remove('file1')
>   os.remove('file2')

It's just as broken as the try/except equivalent. I consider that a
feature, not a bug.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Nick Coghlan 
On 14 October 2013 00:05, Antoine Pitrou  wrote:
> On Sun, 13 Oct 2013 22:50:07 +1000
> Nick Coghlan  wrote:
>> That's the way this works (unless you think this is such a disastrous
>> addition that you want to appeal to Guido to strip me of my
>> responsibilities as contextlib maintainer and go hunting for a new
>> one).
>
> Wow... I don't think challenging others to "strip you of your
> responsibilities" is a reasonable way to address criticism.
>
> And for the record, it's not *my* objection; several other core
> developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.

When people keep complaining after I have posted, as the module
maintainer, saying:

==
"For the record, this thread did prompt me to consider the new
construct anew, but on reflection, I still consider it a reasonable
addition to contextlib.

It substantially improves the simple cases it is intended to help
with, and, if anything, makes overly broad exception suppression
*more* obviously dubious (because the name of the construct doesn't
match the consequences for multi-line suites)."
==

Then, yes, I think challenging people to try to get me booted as
module maintainer for contextlib is a *precisely* proportionate
response. Getting to decide what colour the bikeshed is painted (and
if we even have a bikeshed at all) is what being a module maintainer
*means*.

I had previously agreed it was a borderline decision. I stated that I
had reviewed that decision. I stated that I hadn't changed my mind.
Yet people kept complaining. That's a pretty clear statement that they
don't trust my judgement.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Antoine Pitrou 
On Mon, 14 Oct 2013 01:20:30 +1000
Nick Coghlan  wrote:
> 
> Then, yes, I think challenging people to try to get me booted as
> module maintainer for contextlib is a *precisely* proportionate
> response.

Because I don't agree with you on one instance doesn't mean I usually
*distrust* your judgement. Reasonable organizations have ways to change
decisions that doesn't involve overthrowing people (think about appeal
courts, for example). This is much better than expecting some select
people to be infallible kings :-)

Personally, I generally trust you to 1) make enough research and/or
gather enough material 2) take informed decisions that do justice to the
community's ethos (after, sometimes, a certain amount of arguing :-)).
If my criticism came accross as criticizing your competence, then I'm
sorry: that was not my intent.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread PJ Eby 
On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou  wrote:
> And for the record, it's not *my* objection; several other core
> developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.

FWIW, I'm -1 also; the thread quickly convinced me that this is a
horrible idea, at least with the current name.

The feature itself I consider +0, maybe +0.5 if a good but short name
can be found.  I kind of like "abort_on()" as an accurate description
of what it actually does, but it most certainly does not *ignore*
exceptions, and it's going to create problems as soon as anybody adds
more than one statement to the block, and then reads their code back
without *really* thinking about it.  Not to mention how it's going to
bite people who copy and modify code snippets containing it.


On Sun, Oct 13, 2013 at 11:11 AM, Nick Coghlan  wrote:
> It's just as broken as the try/except equivalent. I consider that a
> feature, not a bug.

(Note: the following rant is about the *name*, not the context manager itself.)

Misleadingness and lack of readability is not a feature, it's a bug.

For example, even though I've been coding in Python since 1997, and
even participated in the original design process for "with", I *still*
misread the "with ignore:" block as ignoring the exceptions until I
*really* thought about it.

Wait, no, I misread it *entirely*, until somebody *else* pointed it out.  ;-)

And this is *despite* knowing on a gut level that *actually* ignoring
all the errors in a block *isn't possible in Python*.

I would not give most people much chance of noticing they made this
mistake, and even less chance of finding the problem afterwards.

This is like the infamous Stroop test, where you have a word like
"brown" only it's printed in blue ink and you have to say "blue" to
get the answer right.

If you've never taken a Stroop test, by the way, it's *really* hard.
It almost literally makes your brain *hurt* to disregard the text and
say the ink color instead, because your brain automatically reads the
word before you can stop it, so you are straining to stop yourself
from saying it so you can then try to *think* what color you're
supposed to say, and then your brain reads the word *again*, and...
well, it's really quite unpleasant is what it is.

Anyway, this feature, with its current name, is just the same: you
have to override your instinctive response to understand what it
*really* does, in any but the one-liner case.

And you have to do it *every time you read it in code*.

Only, because it'll mostly be used in the one-line case, you'll get
used to it being correct, until one day you make a change without
thinking, and create a bug that lies dormant for an extended period.

Plus, as soon as people see it being used, they'll think, "oh cool",
and use it in their code, not even knowing or thinking that it does
something they don't want, because they will never read the docs in
the first place.  (As Guido says, people learn languages by example.)

So call it "catching".  Call it "catch_and_exit_on".  Even "passing"
or "skipping" would be better.  And maybe "abort_on" or
"abort_without_raising" would be better still, as they describe what
will *really* happen.

But calling it "ignore" isn't "fits your brain", it's "abuses your
brain in a cruelly misleading manner".
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change PEP 399 import recommendation

2013-10-13 Thread Oscar Benjamin 
On 12 October 2013 17:55, Christian Heimes  wrote:
> Am 12.10.2013 17:37, schrieb Nick Coghlan:
>> I think the default recommendation in PEP 399 still makes sense - 2
>> modules are easy to manage than three and the idiom allows for easy
>> partial replacement.
>
> We could ues yet another approach and put the pure Python implementation
> of modules into another directory (e.g. Lib/pystdlib or Lib/purepython).
> This directory is appended to sys.path. Alternative implementations of
> Python or platforms without the necessary bits and pieces would import
> the Python-only version from that directory. C modules can be renamed so
> CPython picks them up in favor of the pure Python modules. No hacks, no
> facade module, no slow down and it's easy to understand, too.
>
> The approach can be used for stat, operator, decimal and perhaps other
> modules, too.

CPython preferentially imports extension modules over .py modules with
the same name. This is what happens when you use Cython in "pure"
mode: You have a pure mod.py file and an "augmenting" mod.pxd that
contains the annotations relevant to Cython. The resulting extension
module is mod.{pyd,so} and is imported by CPython if present. This way
you don't need an additional directory/module.


Oscar
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread R. David Murray 
+1 to the below.

I don't have a strong opinion about the feature itself.  The number of
times I can imagine using it in code is pretty close to zero, but
might not actually turn out to *be* zero, you never know.

But the name hurts my brain for the reasons PJ explains :)

--David

PS: I think you are overreacting, Nick.  After all, you did yourself
once argue Guido into submission :)

On Sun, 13 Oct 2013 12:00:25 -0400, PJ Eby  wrote:
> On Sun, Oct 13, 2013 at 10:05 AM, Antoine Pitrou  wrote:
> > And for the record, it's not *my* objection; several other core
> > developers have said -1 too: Ezio, Serhiy, Giampaolo, etc.
> 
> FWIW, I'm -1 also; the thread quickly convinced me that this is a
> horrible idea, at least with the current name.
> 
> The feature itself I consider +0, maybe +0.5 if a good but short name
> can be found.  I kind of like "abort_on()" as an accurate description
> of what it actually does, but it most certainly does not *ignore*
> exceptions, and it's going to create problems as soon as anybody adds
> more than one statement to the block, and then reads their code back
> without *really* thinking about it.  Not to mention how it's going to
> bite people who copy and modify code snippets containing it.
> 
> 
> On Sun, Oct 13, 2013 at 11:11 AM, Nick Coghlan  wrote:
> > It's just as broken as the try/except equivalent. I consider that a
> > feature, not a bug.
> 
> (Note: the following rant is about the *name*, not the context manager 
> itself.)
> 
> Misleadingness and lack of readability is not a feature, it's a bug.
> 
> For example, even though I've been coding in Python since 1997, and
> even participated in the original design process for "with", I *still*
> misread the "with ignore:" block as ignoring the exceptions until I
> *really* thought about it.
> 
> Wait, no, I misread it *entirely*, until somebody *else* pointed it out.  ;-)
> 
> And this is *despite* knowing on a gut level that *actually* ignoring
> all the errors in a block *isn't possible in Python*.
> 
> I would not give most people much chance of noticing they made this
> mistake, and even less chance of finding the problem afterwards.
> 
> This is like the infamous Stroop test, where you have a word like
> "brown" only it's printed in blue ink and you have to say "blue" to
> get the answer right.
> 
> If you've never taken a Stroop test, by the way, it's *really* hard.
> It almost literally makes your brain *hurt* to disregard the text and
> say the ink color instead, because your brain automatically reads the
> word before you can stop it, so you are straining to stop yourself
> from saying it so you can then try to *think* what color you're
> supposed to say, and then your brain reads the word *again*, and...
> well, it's really quite unpleasant is what it is.
> 
> Anyway, this feature, with its current name, is just the same: you
> have to override your instinctive response to understand what it
> *really* does, in any but the one-liner case.
> 
> And you have to do it *every time you read it in code*.
> 
> Only, because it'll mostly be used in the one-line case, you'll get
> used to it being correct, until one day you make a change without
> thinking, and create a bug that lies dormant for an extended period.
> 
> Plus, as soon as people see it being used, they'll think, "oh cool",
> and use it in their code, not even knowing or thinking that it does
> something they don't want, because they will never read the docs in
> the first place.  (As Guido says, people learn languages by example.)
> 
> So call it "catching".  Call it "catch_and_exit_on".  Even "passing"
> or "skipping" would be better.  And maybe "abort_on" or
> "abort_without_raising" would be better still, as they describe what
> will *really* happen.
> 
> But calling it "ignore" isn't "fits your brain", it's "abuses your
> brain in a cruelly misleading manner".
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Submitting PEP 453 (pip bootstrapping) for pronouncement

2013-10-13 Thread Nick Coghlan 
The feedback on the previous version of PEP 453 could be summed up as
"yes for 3.4, no for 2.7 and 3.3", and I've now updated the PEP
accordingly.

HTML: http://www.python.org/dev/peps/pep-0453/
Main diff: http://hg.python.org/peps/rev/405b80d54b7d (there are
additional minor cleanup diffs after that one)

Updates that directly affect the proposal:

- *all* functional changes are now 3.4 only
- still proposes docs changes for 2.7 & 3.3
- since ``ensurepip`` now never contacts PyPI, we tweaked the proposal
to include updating source installs (via "make install" and "make
altinstall") to invoke ensurepip by default, to be consistent with the
Windows and Mac OS X binary installers. The proposal is explicit that
there will be a mechanism to opt out of that step (we haven't decided
on a exact mechanism yet, but a make variable seems likely). We had
chosen to make invoking ensurepip a separate step back when the
proposal still involved implicitly contacting PyPI, but with that
aspect removed, we realised our original rationale for the
cross-platform inconsistency was no longer valid.

Other changes:

- dropped rationale that was no longer relevant with the reduced scope
- explicitly noted the rejection of making functional changes in 2.7 and 3.3
- noted current effort to create a Windows installer for pip
- noted possibility of a future PEP to provide a combined CPython 2.7,
pip and Python Launcher installer from python.org

Cheers,
Nick.

=

PEP: 453
Title: Explicit bootstrapping of pip in Python installations
Version: $Revision$
Last-Modified: $Date$
Author: Donald Stufft ,
Nick Coghlan 
BDFL-Delegate: Martin von Löwis
Status: Draft
Type: Process
Content-Type: text/x-rst
Created: 10-Aug-2013
Post-History: 30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013,
  23-Sep-2013, 29-Sep-2013, 13-Oct-2013


Abstract


This PEP proposes that the
`Installing Python Modules `__ guide in
Python 2.7, 3.3 and 3.4 be updated to officially recommend the use of ``pip``
as the default installer for Python packages, and that appropriate technical
changes be made in Python 3.4 to provide ``pip`` by default in support of
that recommendation.


Rationale
=

There are two related, but distinct rationales for the proposal in this
PEP. The first relates to the experience of new users, while the second
relates to better enabling the evolution of the broader Python packaging
ecosystem.


Improving the new user experience
-

Currently, on systems without a platform package manager and repository,
installing a third-party Python package into a freshly installed Python
requires first identifying an appropriate package manager and then
installing it.

Even on systems that *do* have a platform package manager, it is unlikely to
include every package that is available on the Python Package Index, and
even when a desired third-party package is available, the correct name in
the platform package manager may not be clear.

This means that, to work effectively with the Python Package Index
ecosystem, users must know which package manager to install, where to get
it, and how to install it. The effect of this is that third-party Python
projects are currently required to choose from a variety of undesirable
alternatives:

* Assume the user already has a suitable cross-platform package manager
  installed.
* Duplicate the instructions and tell their users how to install the
  package manager.
* Completely forgo the use of dependencies to ease installation concerns
  for their users.

All of these available options have significant drawbacks.

If a project simply assumes a user already has the tooling then beginning
users may get a confusing error message when the installation command
doesn't work. Some operating systems may ease this pain by providing a
global hook that looks for commands that don't exist and suggest an OS
package they can install to make the command work, but that only works
on systems with platform package managers that include a package that
provides the relevant cross-platform installer command (such as many major
Linux distributions). No such assistance is available for Windows and
Mac OS X users, or more conservative Linux distributions. The challenges
of dealing with this problem for beginners (who are often also completely
new to programming, the use of command line tools and editing system
environment variables) are a regular feature of feedback the core Python
developers receive from professional educators and others introducing new
users to Python.

If a project chooses to duplicate the installation instructions and tell
their users how to install the package manager before telling them how to
install their own project then whenever these instructions need updates
they need updating by every project that has duplicated them. This is
particular problematic when there are multiple competing inst

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Alexander Belopolsky 
On Sun, Oct 13, 2013 at 1:01 PM, R. David Murray  wrote:
> But the name hurts my brain

I did not think I would weigh in on this because Ramond's and Nick's
position seemed quite rational and the issue minor, but surprisingly
this thread does not seem to end.

The feature (*and* its name) is a fine solution for the problem that
it solves and is an improvement over status quo.

I find

with ignore(OSError):
 os.unlink(path)

much easier to read than

try:
   os.unlink(path)
except OSError:
   pass

Yes, this feature can be abused with multiple statements in the with
block, but so can try/except.   People who write code using contextlib
are expected to know that it is not a good idea to keep resources
longer than necessary and multiple unrelated statements within the
with block will raise a mental red flag.   It is also easy for
lint-like tools to warn about abuse of ignore().

I also believe that any of the proposed alternative names will make
canonical usage (such as in the unlink example above) harder to
understand.  Let's not try to improve readability of bad code at the
expense of good code.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread R. David Murray 
On Sun, 13 Oct 2013 13:58:56 -0400, Alexander Belopolsky 
 wrote:
> The feature (*and* its name) is a fine solution for the problem that
> it solves and is an improvement over status quo.
> 
> I find
> 
> with ignore(OSError):
>  os.unlink(path)
> 
> much easier to read than
> 
> try:
>os.unlink(path)
> except OSError:
>pass
> 
> Yes, this feature can be abused with multiple statements in the with
> block, but so can try/except.   People who write code using contextlib
> are expected to know that it is not a good idea to keep resources
> longer than necessary and multiple unrelated statements within the
> with block will raise a mental red flag.   It is also easy for
> lint-like tools to warn about abuse of ignore().

With blocks *very often* include multiple lines of code, because
the resource shouldn't be released until all those lines are done.
try/except blocks with more than a couple lines of code are a
code smell.  with replaces try/finally, not try/except.

I have no problem with Nick deciding that none of the arguments
convince him and leaving it in.  We'll see how it turns out 
in practice :)

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change PEP 399 import recommendation

2013-10-13 Thread Stefan Behnel 
Oscar Benjamin, 13.10.2013 18:35:
> CPython preferentially imports extension modules over .py modules with
> the same name. This is what happens when you use Cython in "pure"
> mode: You have a pure mod.py file and an "augmenting" mod.pxd that
> contains the annotations relevant to Cython. The resulting extension
> module is mod.{pyd,so} and is imported by CPython if present. This way
> you don't need an additional directory/module.

While it may work, I wouldn't really recommend that for manually written
modules. For Cython, it's a nice feature because you get the same thing,
just in native code. It also helps with stack traces because Python can
extract the source code lines for exceptions raised in native code from the
original .py file.

For manually written modules, the source code is naturally unrelated
between both implementations. You want to test both separately and may even
want to import one or the other specifically for other reasons. Explicitly
given them different names is very helpful here.

Stefan


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Alexander Belopolsky 
On Sun, Oct 13, 2013 at 2:09 PM, R. David Murray  wrote:
> with replaces try/finally, not try/except.

with ignore(..) is different.  This is one of the things that I like
about it - a demonstration of a context manager that replaces
try/except.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting PEP 453 (pip bootstrapping) for pronouncement

2013-10-13 Thread Paul Moore 
On 13 October 2013 13:43, Nick Coghlan  wrote:
> Accordingly, in addition to adding the option to extract and install ``pip``
> during installation, this PEP proposes that the Windows installer (and
> ``sysconfig``) in Python 3.4 and later be updated to:
>
> - install scripts to PythonXY\bin rather than PythonXY\Tools\Scripts
> - add PythonXY\bin to the Windows PATH (in addition to PythonXY) when the
>   PATH modification option is enabled during installation

Then implication of this is that venv (and virtualenv, but that's less
relevant to python-dev) should be updated to use a "bin" directory on
Windows rather than the current "Scripts" directory. This would only
be for 3.4, which means that virtualenv will need to make the
directory name conditional on version, I guess.

Paul.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Change PEP 399 import recommendation

2013-10-13 Thread Victor Stinner 
Le 13 oct. 2013 10:19, "Stefan Behnel"  a écrit :
> I agree. I find it much easier to read a plain and obvious
>
> try:
>from _cmodule import *
> except ImportError:
>from _pymodule import *
>
> in a facade module ...

I miss maybe something. I don't understand why you would like to use the
Python implementation if a C implementation is available and probably
(much) faster.

Maybe developers of PyPy, IronPython and Jython appreciate our effort to
provide a Python implementation which is up to date and well tested. But
why should we pay a price (bad performance) if the module is not (never?
who uses _pyio?) used in CPython. If another Python uses it, the file can
be renamed (ex: _pyio.py becomes simply io.py).

IMO if the C module is complete (has no extra functions in the "facade"
module), it should get the main name (ex: decimal, not _decimal).

It was discussed to put the Python implementation in anothet directory.
Good idea, but only put the directory in sys.path for unit tests (prepend
it to sys.path to load the Python module).

I am only talking of C module which does not need anything of the "facade"
module.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread PJ Eby 
On Sun, Oct 13, 2013 at 1:58 PM, Alexander Belopolsky
 wrote:
> People who write code using contextlib
> are expected to know

People who *read* that code while learning Python cannot be expected
to know that it is not really possible to ignore errors in Python.

If this feature is used under any name that implies such, it will
within a few years become a FAQ and well-known wart, not to mention a
meme that "contextlib.ignore() is buggy, it only works if the error is
thrown from a single operation performed in C".

I say this latter phrasing because now that I've had time to think
about it, it is not at all merely a question of whether you wrap a
single line or single operation.

Quick, is this a safe use, or not:

with ignore(OSError):
 delete_widget_files(spam)

It sort of depends on the implementation of delete_widget_files, doesn't it?

In contrast:

   with abort_on(OSError):
 delete_widget_files(spam)

it's immediately clear that the error isn't going to be ignored; the
operation will be aborted.  Very different concept.


> that it is not a good idea to keep resources
> multiple unrelated statements within the
> with block will raise a mental red flag.

How will someone know this when they are reading code they found on
the internet?

It's one thing to have an operation whose name implies, "you need to
do more research to understand this".  But it's an entirely different
(and dangerous) thing to have an operation whose name implies you
already know everything you need to know, no need to think or study
further...  especially if what you know is actually wrong!


> It is also easy for
> lint-like tools to warn about abuse of ignore().

Since it's not sufficient to require a single operation, how will a
lint-like tool check this?

For example:

with ignore(AnError, OtherError):
 ping.pongy(foo, bar.spam(), fizzy())

Is this valid code, or not?  If you can't tell, how will a non-human
lint tool tell?


> Let's not try to improve readability of bad code

Actually, I want the good code to be "readable" in the sense of
understanding what the operation does, so that people copying it don't
end up with a serious misunderstanding of how the context manager
actually works.

There is no way that naive users aren't going to read it as ignoring
errors, and use it with something like:

with ignore(OSError):
for f in myfiles: os.unlink(f)

But this version is obviously *wrong*:

with abort_on(OSError):
for f in myfiles: os.unlink(f)

Upon looking at this code, you will quickly realize that you don't
intend to abort the loop, only the unlink, and will therefore rewrite
it to put the loop on the outside.

So, I am only trying to "improve readability of bad code" in the sense
of making it *obvious* that the code is in fact bad.  ;-)

(To put it another way, "ignore()" improves the readability of bad
code in the above example, because it makes the bad code look like
it's good.)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Nick Coghlan 
On 14 Oct 2013 01:45, "Antoine Pitrou"  wrote:
>
> On Mon, 14 Oct 2013 01:20:30 +1000
> Nick Coghlan  wrote:
> >
> > Then, yes, I think challenging people to try to get me booted as
> > module maintainer for contextlib is a *precisely* proportionate
> > response.
>
> Because I don't agree with you on one instance doesn't mean I usually
> *distrust* your judgement. Reasonable organizations have ways to change
> decisions that doesn't involve overthrowing people (think about appeal
> courts, for example). This is much better than expecting some select
> people to be infallible kings :-)

I think I'm mostly irritated by the fact that this thread (which is almost
completely inconsequential for the overall language design regardless of
whether the feature stays or goes) attracts dozens of posts, while actually
hard 3.x usability problems like getting the codec support back to parity
with 2.x are still languishing for lack of interest. These days it seems
progress is only made on the latter when I work on it as a means of
procrastinating on something else :P

> Personally, I generally trust you to 1) make enough research and/or
> gather enough material 2) take informed decisions that do justice to the
> community's ethos (after, sometimes, a certain amount of arguing :-)).
> If my criticism came accross as criticizing your competence, then I'm
> sorry: that was not my intent.

I suspect lack of sleep was also a factor in my poor reaction ;)

PJE's articulation of the potential for misinterpretation as the equivalent
of VB's "on error resume next" for users learning by example is an
interesting one.

I'm actually tempted to move this particular feature out to contextlib2 for
the time being (similar to what I did with ExitStack and some other
experimental features that never made it back into the stdlib version). A
pull request at https://bitbucket.org/ncoghlan/contextlib2 to bring it up
to date with the latest contextlib code would likely help push me in that
direction (it's not quite a matter of simply copying the current stdlib
code, since contextlib2 still supports some of those experimental APIs I
didn't end up merging).

Cheers,
Nick.

>
> Regards
>
> Antoine.
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Submitting PEP 453 (pip bootstrapping) for pronouncement

2013-10-13 Thread Nick Coghlan 
On 14 Oct 2013 04:26, "Paul Moore"  wrote:
>
> On 13 October 2013 13:43, Nick Coghlan  wrote:
> > Accordingly, in addition to adding the option to extract and install
``pip``
> > during installation, this PEP proposes that the Windows installer (and
> > ``sysconfig``) in Python 3.4 and later be updated to:
> >
> > - install scripts to PythonXY\bin rather than PythonXY\Tools\Scripts
> > - add PythonXY\bin to the Windows PATH (in addition to PythonXY) when
the
> >   PATH modification option is enabled during installation
>
> Then implication of this is that venv (and virtualenv, but that's less
> relevant to python-dev) should be updated to use a "bin" directory on
> Windows rather than the current "Scripts" directory. This would only
> be for 3.4, which means that virtualenv will need to make the
> directory name conditional on version, I guess.

The sysconfig directory scheme will change accordingly, so it may be
possible to leverage that by basing the virtualenv layout on the default
scheme.

Cheers,
Nick.

>
> Paul.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

2013-10-13 Thread Glenn Linderman 

On 10/12/2013 11:57 PM, Nick Coghlan wrote:


For the record, this thread did prompt me to consider the new 
construct anew, but on reflection, I still consider it a reasonable 
addition to contextlib.


It substantially improves the simple cases it is intended to help 
with, and, if anything, makes overly broad exception suppression 
*more* obviously dubious (because the name of the construct doesn't 
match the consequences for multi-line suites).


For the record, the logic in the last paragraph is the most dubious 
thing I've ever seen you post.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com