Re: [Python-Dev] [Python-checkins] cpython (2.7): Closes #14306: clarify expensiveness of try-except and update code snippet

2012-03-18 Thread Nick Coghlan 
On Sun, Mar 18, 2012 at 1:58 AM, georg.brandl
 wrote:
> +catching an exception is expensive.  In versions of Python prior to 2.0 it 
> was
> +common to use this idiom::

Actually, given the "prior to 2.0" caveat, "mydict.has_key(key)" is
right: the "key in mydict" version was only added in 2.2.

This answer probably needs more improvements than just modernising the
example that is already there.

Cheers,
Nick.

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

Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock

2012-03-18 Thread Michael Foord 

On 16 Mar 2012, at 11:54, Nick Coghlan wrote:

> On Thu, Mar 15, 2012 at 6:27 AM, Michael Foord
>  wrote:
>> On the topic of docs mock documentation is about eight pages long. My 
>> intention was to strip this down to just the api documentation, along with a 
>> link to the docs on my site for further examples and so on. I was encouraged 
>> here at the sprints to include the full documentation instead (minus the 
>> mock library comparison page and the front page can be cut down). So this is 
>> what I am now intending to include. It does mean the mock documentation will 
>> be "extensive".
> 
> Don't forgot you also have the option of splitting out a separate
> HOWTO tutorial section, leaving the main docs as a pure API reference.
> (I personally find that style easier to use than the ones which try to
> address both needs in the main module docs).
> 


The docs are already organised as API docs and then simple and advanced HOWTO 
style sections. There are minimal examples inline with the API docs and 
separate paragraphs of explanations below on particular topics. Feel free to 
critique the mock docs as they are, or wait until I have committed modified 
versions.

Michael

> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





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

Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock

2012-03-18 Thread Martin v. Löwis 
> The commingling of extensive examples with regular docs has
> made it difficult to lookup functionality in argparse for example.

I have now come to think that this should be considered a subordinate
use case. The primary use case of the documentation should be copy-paste
style examples. At least, that's the feedback I always get for the
Python documentation (typically contrasting it with the PHP
documentation, where the specification-style portion is typically
ignored by readers, which then move on to the user-contributed
examples).

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

[Python-Dev] [RELEASED] Second release candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3

2012-03-18 Thread Benjamin Peterson 
We're chuffed to announce the immediate availability of the second release
candidates for Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3. The only change from the
first release candidates is the patching of an additional security hole.

The security issue fixed in the second release candidates is in the expat XML
parsing library. expat had the same hash security issue detailed below as
Python's core types. The hashing algorithm used in the expat library is now
randomized. A more thorough explanation of the "hash attack" security hole
follows.

The main impetus for these releases is fixing a security issue in Python's hash
based types, dict and set, as described below. Python 2.7.3 and 3.2.3 include
the security patch and the normal set of bug fixes. Since Python 2.6 and 3.1 are
maintained only for security issues, 2.6.8 and 3.1.5 contain only various
security patches.

The security issue exploits Python's dict and set implementations. Carefully
crafted input can lead to extremely long computation times and denials of
service. [1] Python dict and set types use hash tables to provide amortized
constant time operations. Hash tables require a well-distributed hash function
to spread data evenly across the hash table. The security issue is that an
attacker could compute thousands of keys with colliding hashes; this causes
quadratic algorithmic complexity when the hash table is constructed. To
alleviate the problem, the new releases add randomization to the hashing of
Python's string types (bytes/str in Python 3 and str/unicode in Python 2),
datetime.date, and datetime.datetime. This prevents an attacker from computing
colliding keys of these types without access to the Python process.

Hash randomization causes the iteration order of dicts and sets to be
unpredictable and differ across Python runs. Python has never guaranteed
iteration order of keys in a dict or set, and applications are advised to never
rely on it. Historically, dict iteration order has not changed very often across
releases and has always remained consistent between successive executions of
Python. Thus, some existing applications may be relying on dict or set ordering.
Because of this and the fact that many Python applications which don't accept
untrusted input are not vulnerable to this attack, in all stable Python releases
mentioned here, HASH RANDOMIZATION IS DISABLED BY DEFAULT. There are two ways to
enable it. The -R commandline option can be passed to the python executable. It
can also be enabled by setting an environmental variable PYTHONHASHSEED to
"random". (Other values are accepted, too; pass -h to python for complete
description.)

More details about the issue and the patch can be found in the oCERT advisory
[1] and the Python bug tracker [2].

These releases are releases candidates and thus not recommended for production
use. Please test your applications and libraries with them, and report any bugs
you encounter. We are especially interested in any buggy behavior observed using
hash randomization. Excepting major calamity, final versions should appear after
several weeks.

Downloads are at

http://python.org/download/releases/2.6.8/
http://python.org/download/releases/2.7.3/
http://python.org/download/releases/3.1.5/
http://python.org/download/releases/3.2.3/

Please test these candidates and report bugs to

http://bugs.python.org/

With regards,
The Python release team
Barry Warsaw (2.6), Georg Brandl (3.2), Benjamin Peterson (2.7 and 3.1)

[1] http://www.ocert.org/advisories/ocert-2011-003.html
[2] http://bugs.python.org/issue13703
___
Python-Dev mailing list
[email protected]
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 czar for PEP 3144?

2012-03-18 Thread Peter Moody 
On Mon, Mar 12, 2012 at 9:15 AM, Peter Moody  wrote:

>>> - iterable APIs should consistently produce iterators (leaving users
>>> free to wrap list() around the calls if they want the concrete
>>> realisation)

I might've missed earlier discussion somewhere, but can someone point
me at an example of an iteratable api in ipaddr/ipaddress where an
iterator isn't consistently produced?

Cheers,
peter

-- 
Peter Moody      Google    1.650.253.7306
Security Engineer  pgp:0xC3410038
___
Python-Dev mailing list
[email protected]
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 czar for PEP 3144?

2012-03-18 Thread Nick Coghlan 
On Mon, Mar 19, 2012 at 12:44 PM, Peter Moody  wrote:
> On Mon, Mar 12, 2012 at 9:15 AM, Peter Moody  wrote:
>
 - iterable APIs should consistently produce iterators (leaving users
 free to wrap list() around the calls if they want the concrete
 realisation)
>
> I might've missed earlier discussion somewhere, but can someone point
> me at an example of an iteratable api in ipaddr/ipaddress where an
> iterator isn't consistently produced?

There was at least one that I recall, now to find it again...

And searching for "list" in the PEP 3144 branch source highlights
subnet() vs iter_subnets() as the main problem child:

https://code.google.com/p/ipaddr-py/source/browse/branches/3144/ipaddress.py#1004

A single "subnets()" method that produced the iterator would seem to
make more sense (with a "list()" call wrapped around it when the
consumer really wants a concrete list).

There are a few other cases that produce a list that are less clearcut.

I *think* summarising the address range could be converted to an
iterator, since the "networks" accumulation list doesn't get
referenced by the summarising algorithm.

Similarly, there doesn't appear to be a compelling reason for
"address_exclude" to produce a concrete list (I also noticed a couple
of "assert True == False" statements in that method for "this should
never happen" code branches. An explicit "raise AssertionError" is a
better way to handle such cases, so the code remains present even
under -O and -OO)

Collapsing the address list has to build the result list anyway to
actually handle the deduplication part of its job, so returning a
concrete list makes sense in that case.

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

Re: [Python-Dev] cpython: PEP 417: Adding unittest.mock

2012-03-18 Thread Nick Coghlan 
On Mon, Mar 19, 2012 at 11:19 AM, "Martin v. Löwis"  wrote:
>> The commingling of extensive examples with regular docs has
>> made it difficult to lookup functionality in argparse for example.
>
> I have now come to think that this should be considered a subordinate
> use case. The primary use case of the documentation should be copy-paste
> style examples. At least, that's the feedback I always get for the
> Python documentation (typically contrasting it with the PHP
> documentation, where the specification-style portion is typically
> ignored by readers, which then move on to the user-contributed
> examples).

That's why the 3.2 logging docs are such a good model to follow. They
have *4* pieces:

- the formal API reference ("What features does logging offer?" and
"Exactly how does the X API work, again?")
- a "quick start" tutorial ("What's the bare minimum I need to know to
get started with the logging module?")
- an "advanced" tutorial ("What are some other cool things the logging
infrastructure lets me do?")
- a "cookbook" section ("How do I achieve task Y with the logging module?")

The first of those is in the standard library *reference*, with clear
pointers directly to the other 3 (which live in the "HOWTO" section of
the docs).

Different audiences have different needs. If you just want to get
something working quickly and aren't interested in understanding the
details right now, then "cargo cult programming" can be a good way to
go and "cookbook" style docs are a great resource for that. If you're
just trying to remember a precise incantation for something you
already know the module can do, then you want a formal reference that
spells out the API details. Tutorials land somewhere in between -
trying to teach people enough about the module that they can make more
effective use of both the formal API reference (when figuring things
out from scratch) and the cookbook examples (when trying to accomplish
a common task without caring too much about the details of how and why
it works).

As much as I like argparse, the existing docs don't do a great job of
advertising its capabilities, since they're currently a mixture of
tutorial-and-reference-and-cookbook that means they don't excel at
serving any of the possible audiences. (I've posted a few suggestions
on the issue tracker for specific changes I think would help improve
the situation).

The key point though is that there are multiple reasons people look up
documentation, and the appropriate structure varies based on the
reason someone is reading the docs at all.

Cheers,
Nick.

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

[Python-Dev] inspect.py change for pygame

2012-03-18 Thread ncdave4life 
I noticed that pydoc doesn't work for pygame under python 3.2.1 for Win32:

NotImplementedError: scrap module not available (ImportError: No module
named scrap)

I made a small patch to inspect.py to solve the problem (I just added a
try/expect around the failing statement in ismethoddescriptor).   Here's the
diff:
http://www.burtonsys.com/python32/inspect.diff
http://www.burtonsys.com/python32/inspect.diff 

With that patch, pydoc works with pygame, and reports just a few issues:
*scrap* = 
*sndarray* = 
*surfarray* = 

Sorry, I'm a newbie to python-dev, so please forgive my ignorance, but what
do I need to do get this fix (or something similar) into a future release?

--
View this message in context: 
http://python.6.n6.nabble.com/inspect-py-change-for-pygame-tp4631993p4631993.html
Sent from the Python - python-dev mailing list archive at Nabble.com.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inspect.py change for pygame

2012-03-18 Thread Brian Curtin 
On Sun, Mar 18, 2012 at 23:13, ncdave4life  wrote:
> I noticed that pydoc doesn't work for pygame under python 3.2.1 for Win32:
>
> NotImplementedError: scrap module not available (ImportError: No module
> named scrap)
>
> I made a small patch to inspect.py to solve the problem (I just added a
> try/expect around the failing statement in ismethoddescriptor).   Here's the
> diff:
> http://www.burtonsys.com/python32/inspect.diff
> http://www.burtonsys.com/python32/inspect.diff
>
> With that patch, pydoc works with pygame, and reports just a few issues:
> *scrap* = 
> *sndarray* = 
> *surfarray* = 
>
> Sorry, I'm a newbie to python-dev, so please forgive my ignorance, but what
> do I need to do get this fix (or something similar) into a future release?

Patches to fix Python should be posted to http://bugs.python.org/.
>From there they'll be classified, reviewed, and if all is well,
committed. It's much easier for patches to be tracked on there instead
of email.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] inspect.py change for pygame

2012-03-18 Thread ncdave4life 
Thank you, Brian!

On Mon, Mar 19, 2012 at 12:20 AM, Brian Curtin [via Python] <
[email protected]> wrote:

> On Sun, Mar 18, 2012 at 23:13, ncdave4life <[hidden 
> email]>
> wrote:
> > ...Sorry, I'm a newbie to python-dev, so please forgive my ignorance,
> but what
> > do I need to do get this fix (or something similar) into a future
> release?
>
> Patches to fix Python should be posted to http://bugs.python.org/.
> From there they'll be classified, reviewed, and if all is well,
> committed. It's much easier for patches to be tracked on there instead
> of email.
>


--
View this message in context: 
http://python.6.n6.nabble.com/inspect-py-change-for-pygame-tp4631993p4632010.html
Sent from the Python - python-dev mailing list archive at Nabble.com.___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com