Sorin Stelian | 21 May 2013 18:50
Picon
Favicon

Is thread-safe smtpd desired/possible?

Hi,

I am posting this here since I could find no active maintainer of the smtpd module.

In my work as a test engineer for Axis (www.axis.com) I encountered the need of having thread-safe SMTP
servers. I know the use case of several SMTP servers running in concurrent threads might seem odd, but it
can actually be quite useful for testing purposes.

I have implemented (for my own use) a possible solution which basically means that every SMTP channel has
its own socket map, instead of using asyncore's global socket map. It would not involve any change in asyncore.

Looking at the disucssion from http://bugs.python.org/issue11959 it seems to me that such a solution
would not be accepted. Do you think that modifying asyncore is more feasible? If not, is this something
that might be looked at?

I can provide code if needed, but I would first like to know your thoughts about this.

Best regards,
Sorin
Antoine Pitrou | 21 May 2013 17:57

PEP 442 delegate


Hello,

I would like to nominate Benjamin as BDFL-Delegate for PEP 442.
Please tell me if you would like to object :)

Regards

Antoine.

Olemis Lang | 20 May 2013 18:37
Picon
Gravatar

Re: Purpose of Doctests [Was: Best practices for Enum]

---------- Forwarded message ----------
From: Olemis Lang <olemis <at> gmail.com>
Date: Mon, 20 May 2013 11:33:42 -0500
Subject: Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]
To: Antoine Pitrou <solipsis <at> pitrou.net>

On 5/20/13, Antoine Pitrou <solipsis <at> pitrou.net> wrote:
> On Sat, 18 May 2013 23:41:59 -0700
> Raymond Hettinger <raymond.hettinger <at> gmail.com> wrote:
>>
>> We should continue to encourage users to make thorough unit tests
>> and to leave doctests for documentation.  That said, it should be
>> recognized that some testing is better than no testing.  And doctests
>> may be attractive in that regard because it is almost effortless to
>> cut-and-paste a snippet from the interactive prompt.  That isn't a
>> best practice, but it isn't a worst practice either.
>
> There are other reasons to hate doctest, such as the obnoxious
> error reporting.  Having to wade through ten pages of output to find
> what went wrong is no fun.
>

+1

FWIW , while using dutest [1]_ each interactive example will be a test
case and therefore the match for that particular assertion will be
reported using the usual unittest output format

.. [1] dutest
        (https://pypi.python.org/pypi/dutest)
(Continue reading)

Ethan Furman | 20 May 2013 15:12
Picon
Gravatar

PEP 409 and the stdlib

As a quick reminder, PEP 409 allows this:

     try:
         ...
     except AnError:
         raise SomeOtherError from None

so that if the exception is not caught, we get the traditional single exception traceback, instead of the new:

     During handling of the above exception, another exception occurred

My question:

How do we go about putting this in the stdlib?  Is this one of the occasions where we don't do it unless we're
modifying 
a module already for some other reason?

For that matter, should we?

Pros:  Makes tracebacks much less confusing, especially coming from a library

Cons:  Could hide bugs unrelated to what is being caught and transformed

--
~Ethan~
Guido van Rossum | 20 May 2013 03:46
Favicon

What if we didn't have repr?

On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith <greg <at> krypto.org> wrote:
> Now you've got me wondering what Python would be like if repr, `` and
> __repr__ never existed as language features. Upon first thoughts, I actually
> don't see much downside (no, i'm not advocating making that change).
> Something to ponder.

I have pondered it many times, although usually in the form "Why do we
need both str and repr?"

Unfortunately I always come back to the same issue: I really want
print() of a string to write just the characters of the string
(without quotes), but I also really want the >>> prompt to write the
string with quotes (and escapes). Moreover, these are just two
examples of the different use cases -- repr() is more useful whenever
you are writing a value for a debugging purpose (e.g. when logging),
and str() is more useful when writing a value as "output" of a
program.

One could argume that the only type for which it makes sense to
distinguish between the two is str itself -- indeed I rarely define
different __repr__ and __str__ functions for new classes I create (but
I do note that PEP 435 does define them differently for enum members).
But for the str type, it's pretty important to have str(s) equal to s,
and it's also pretty important to have a way to produce a string
literal from a string value. And it would be annoying if we only had
str()/__str__() as a general protocol and repr() was just a string
method -- imagine the number of times people would be calling s.repr()
in order to have unambiguous debug output only to get a traceback
because s is None or some other non-str object...

(Continue reading)

Demian Brecht | 20 May 2013 00:29
Picon
Gravatar

Why is documentation not inline?

This is more out of curiosity than to spark change (although I
wouldn't argue against it): Does anyone know why it was decided to
document external to source files rather than inline?

When rapidly digging through source, it would be much more helpful to
see parameter docs than to either have to find source lines (that can
easily be missed) to figure out the intention. Case in point, I've
been digging through cookiejar.py and request.py to figure out their
interactions. When reading through build_opener, it took me a few
minutes to figure out that each element of *handlers can be either an
instance /or/ a class definition (I was looking at how to define a
custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware
that there's some documentation at the top of request.py, but it would
have been helpful to have it right in the definition of build_opener.

It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?

Thanks,

--
Demian Brecht
http://demianbrecht.github.com
Richard Oudkerk | 19 May 2013 17:59
Picon

Async subprocesses on Windows with tulip

Attached is a pretty trivial example of asynchronous interaction with a 
python subprocess using tulip on Windows.  It does not use transports or 
protocols -- instead sock_recv() and sock_sendall() are used inside tasks.

I am not sure what the plan is for dealing with subprocesses currently. 
  Shall I just add this to the examples folder for now?

-- 
Richard
'''
Example of asynchronous interaction with a subprocess on Windows.

This requires use of overlapped pipe handles and (a modified) iocp proactor.
'''

import itertools
import logging
import msvcrt
import os
import subprocess
import sys
import tempfile
import _winapi

import tulip
from tulip import _overlapped, windows_events, events

PIPE = subprocess.PIPE
(Continue reading)

Raymond Hettinger | 19 May 2013 08:41
Picon

Re: Purpose of Doctests [Was: Best practices for Enum]


On May 14, 2013, at 9:39 AM, Gregory P. Smith <greg <at> krypto.org> wrote:

Bad: doctests.

I'm hoping that core developers don't get caught-up in the "doctests are bad meme".

Instead, we should be clear about their primary purpose which is to test
the examples given in docstrings.   In many cases, there is a great deal 
of benefit to docstrings that have worked-out examples (see the docstrings
in the decimal module for example).  In such cases it is also worthwhile 
to make sure those examples continue to match reality. Doctests are
a vehicle for such assurance.  In other words, doctests have a perfectly
legitimate use case.

We should continue to encourage users to make thorough unit tests
and to leave doctests for documentation.  That said, it should be
recognized that some testing is better than no testing.  And doctests
may be attractive in that regard because it is almost effortless to
cut-and-paste a snippet from the interactive prompt.  That isn't a
best practice, but it isn't a worst practice either.

Another meme that I hope dispel is the notion that the core developers
are free to break user code (such as doctests) if they believe the
users aren't coding in accordance with best practices.   Our goal is to
improve their lives with our modifications, not to make their lives 
more difficult.

Currently, we face an adoption problem with Python 3.  At PyCon,
an audience of nearly 2500 people said they had tried Python 3 
but weren't planning to convert to it in production code.  All of the
coredevs are working to make Python 3 more attractive than Python 2,
but we also have to be careful to not introduce obstacles to conversion.
Breaking tests makes it much harder to convert (especially because
people need to rely on their tests to see if the conversion was successful).


Raymond


P.S.  Breaking doctests should also be seen as a "canary in a coal mine."
When they break, it also means that printed examples are out of date,
that code parsers may break, that diffs start being different, that programs
that feed into other programs (perhaps via pipes and filters) may be changing
their interface, etc.     Occasionally, we make need to break such things but
there should be a compelling offsetting benefit (i.e. evaluating thoughtfully
whether "I'm trying to help you by making your constant integers have a
nicer repr" is worth "Sorry, I broke your tests, made your published examples
out of date, and slowed down your code."   -- in some modules it will be worth it,
but in others we should value stability over micro-improvments).


<div>
<br><div>
<div>On May 14, 2013, at 9:39 AM, Gregory P. Smith &lt;<a href="mailto:greg <at> krypto.org">greg <at> krypto.org</a>&gt; wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Bad: doctests.</div></blockquote>
</div>
<div><br></div>
<div>I'm hoping that core developers don't get caught-up in the "doctests are bad meme".</div>
<div><br></div>
<div>Instead, we should be clear about their primary purpose which is to test</div>
<div>the examples given in docstrings. &nbsp; In many cases, there is a great deal&nbsp;</div>
<div>of benefit to&nbsp;docstrings that have worked-out examples (see the docstrings</div>
<div>in the decimal module for example). &nbsp;In such cases&nbsp;it is also worthwhile&nbsp;</div>
<div>to make sure those examples continue to match&nbsp;reality. Doctests are</div>
<div>a vehicle for such assurance. &nbsp;In other words, doctests have a perfectly</div>
<div>legitimate use case.</div>
<div><br></div>
<div>We should continue to encourage users to make thorough unit tests</div>
<div>and to leave doctests for documentation. &nbsp;That said, it should be</div>
<div>recognized that some testing is better than no testing. &nbsp;And doctests</div>
<div>may be attractive in that regard because it is almost effortless to</div>
<div>cut-and-paste a snippet from the interactive prompt. &nbsp;That isn't a</div>
<div>best practice, but it isn't a worst practice either.</div>
<div><br></div>
<div>Another meme that I hope dispel is the notion that the core developers</div>
<div>are free to break user code (such as doctests) if they believe the</div>
<div>users aren't coding in accordance with best practices. &nbsp; Our goal is to</div>
<div>improve their lives with our modifications, not to make their lives&nbsp;</div>
<div>more difficult.</div>
<div><br></div>
<div>Currently, we face an adoption problem with Python 3. &nbsp;At PyCon,</div>
<div>an audience of nearly 2500 people said they had tried Python 3&nbsp;</div>
<div>but weren't planning to convert to it in production code. &nbsp;All of the</div>
<div>coredevs are working to make&nbsp;Python 3 more attractive&nbsp;than Python 2,</div>
<div>but we also have to be careful to not introduce obstacles to conversion.</div>
<div>Breaking tests makes it much harder to convert (especially because</div>
<div>people need to rely on their tests to see if the conversion was successful).</div>
<div><br></div>
<div><br></div>
<div>Raymond</div>
<div><br></div>
<div><br></div>
<div>P.S. &nbsp;Breaking doctests should also be seen as a "canary in a coal mine."</div>
<div>When they break, it also means that printed examples are out of date,</div>
<div>that code parsers may break, that diffs start being different, that programs</div>
<div>that feed into other programs (perhaps via pipes and filters) may be changing</div>
<div>their interface, etc. &nbsp; &nbsp; Occasionally, we make need to break such things but</div>
<div>there should be a compelling offsetting benefit (i.e. evaluating thoughtfully</div>
<div>whether&nbsp;"I'm trying to help you by making your constant integers have a</div>
<div>nicer repr" is worth "Sorry, I broke your tests, made your published examples</div>
<div>out of date, and slowed down your code." &nbsp; -- in some modules it will be worth it,</div>
<div>but in others we should value stability over micro-improvments).</div>
<div><br></div>
<div><br></div>
</div>
Guido van Rossum | 19 May 2013 07:47
Favicon

Ordering keyword dicts

On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger
<raymond.hettinger <at> gmail.com> wrote:
> BTW, I'm +1 on the idea for ordering keyword-args.  It makes
> it easier to debug if the arguments show-up in the order they
> were created.  AFAICT, no purpose is served by scrambling them
> (which is exacerbated by the new randomized hashing security feature).

I'm slow at warming up to the idea. My main concern is speed -- since
most code doesn't need it and function calls are already slow (and
obviously very common :-) it would be a shame if this slowed down
function calls that don't need it noticeably.

An observation is that it's only necessary to preserve order if the
function definition uses **kwds. AFAIK we currently don't know if this
is the case when the call is made though, but perhaps the information
could be made available to the call site somehow.

There are also many special cases to consider; e.g. using **kwds in
the call where kwds is an unordered dict, or calls from C, or calls to
C.

But maybe someone considers this a challenge and comes up with a
patch? The benefits to *some* use cases would be obvious.

--

-- 
--Guido van Rossum (python.org/~guido)
Antoine Pitrou | 18 May 2013 10:59

PEP 442: Safe object finalization


Hello,

I would like to submit the following PEP for discussion and evaluation.

Regards

Antoine.

PEP: 442
Title: Safe object finalization
Version: $Revision$
Last-Modified: $Date$
Author: Antoine Pitrou <solipsis <at> pitrou.net>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2013-05-18
Python-Version: 3.4
Post-History:
Resolution: TBD

Abstract
========

This PEP proposes to deal with the current limitations of object
finalization.  The goal is to be able to define and run finalizers
for any object, regardless of their position in the object graph.

This PEP doesn't call for any change in Python code.  Objects
with existing finalizers will benefit automatically.

Definitions
===========

Reference
    A directional link from an object to another.  The target of the
    reference is kept alive by the reference, as long as the source is
    itself alive and the reference isn't cleared.

Weak reference
    A directional link from an object to another, which doesn't keep
    alive its target.  This PEP focusses on non-weak references.

Reference cycle
    A cyclic subgraph of directional links between objects, which keeps
    those objects from being collected in a pure reference-counting
    scheme.

Cyclic isolate (CI)
    A reference cycle in which no object is referenced from outside the
    cycle *and* whose objects are still in a usable, non-broken state:
    they can access each other from their respective finalizers.

Cyclic garbage collector (GC)
    A device able to detect cyclic isolates and turn them into cyclic
    trash.  Objects in cyclic trash are eventually disposed of by
    the natural effect of the references being cleared and their
    reference counts dropping to zero.

Cyclic trash (CT)
    A reference cycle, or former reference cycle, in which no object
    is referenced from outside the cycle *and* whose objects have
    started being cleared by the GC.  Objects in cyclic trash are
    potential zombies; if they are accessed by Python code, the symptoms
    can vary from weird AttributeErrors to crashes.

Zombie / broken object
    An object part of cyclic trash.  The term stresses that the object
    is not safe: its outgoing references may have been cleared, or one
    of the objects it references may be zombie.  Therefore,
    it should not be accessed by arbitrary code (such as finalizers).

Finalizer
    A function or method called when an object is intended to be
    disposed of.  The finalizer can access the object and release any
    resource held by the object (for example mutexes or file
    descriptors).  An example is a ``__del__`` method.

Resurrection
    The process by which a finalizer creates a new reference to an
    object in a CI.  This can happen as a quirky but supported
    side-effect of ``__del__`` methods.

Impact
======

While this PEP discusses CPython-specific implementation details, the
change in finalization semantics is expected to affect the Python
ecosystem as a whole.  In particular, this PEP obsoletes the current
guideline that "objects with a ``__del__`` method should not be part of
a reference cycle".

Benefits
========

The primary benefits of this PEP regard objects with finalizers, such
as objects with a ``__del__`` method and generators with a ``finally``
block.  Those objects can now be reclaimed when they are part of a
reference cycle.

The PEP also paves the way for further benefits:

* The module shutdown procedure may not need to set global variables to
  None anymore.  This could solve a well-known class of irritating
  issues.

The PEP doesn't change the semantics of:

* Weak references caught in reference cycles.

* C extension types with a custom ``tp_dealloc`` function.

Description
===========

Reference-counted disposal
--------------------------

In normal reference-counted disposal, an object's finalizer is called
just before the object is deallocated.  If the finalizer resurrects
the object, deallocation is aborted.

*However*, if the object was already finalized, then the finalizer isn't
called.  This prevents us from finalizing zombies (see below).

Disposal of cyclic isolates
---------------------------

Cyclic isolates are first detected by the garbage collector, and then
disposed of.  The detection phase doesn't change and won't be described
here.  Disposal of a CI traditionally works in the following order:

1. Weakrefs to CI objects are cleared, and their callbacks called. At
   this point, the objects are still safe to use.

2. The CI becomes a CT as the GC systematically breaks all
   known references inside it (using the ``tp_clear`` function).

3. Nothing.  All CT objects should have been disposed of in step 2
   (as a side-effect of clearing references); this collection is
   finished.

This PEP proposes to turn CI disposal into the following sequence (new
steps are in bold):

1. Weakrefs to CI objects are cleared, and their callbacks called. At
   this point, the objects are still safe to use.

2. **The finalizers of all CI objects are called.**

3. **The CI is traversed again to determine if it is still isolated.
   If it is determined that at least one object in CI is now reachable
   from outside the CI, this collection is aborted and the whole CI
   is resurrected.  Otherwise, proceed.**

4. The CI becomes a CT as the GC systematically breaks all
   known references inside it (using the ``tp_clear`` function).

5. Nothing.  All CT objects should have been disposed of in step 4
   (as a side-effect of clearing references); this collection is
   finished.

C-level changes
===============

Type objects get a new ``tp_finalize`` slot to which ``__del__`` methods
are bound.  Generators are also modified to use this slot, rather than
``tp_del``.  At the C level, a ``tp_finalize`` function is a normal
function which will be called with a regular, alive object as its only
argument.  It should not attempt to revive or collect the object.

For compatibility, ``tp_del`` is kept in the type structure.  Handling
of objects with a non-NULL ``tp_del`` is unchanged: when part of a CI,
they are not finalized and end up in ``gc.garbage``.  However, a
non-NULL ``tp_del`` is not encountered anymore in the CPython source
tree (except for testing purposes).

On the internal side, a bit is reserved in the GC header for GC-managed
objects to signal that they were finalized.  This helps avoid finalizing
an object twice (and, especially, finalizing a CT object after it was
broken by the GC).

Discussion
==========

Predictability
--------------

Following this scheme, an object's finalizer is always called exactly
once.  The only exception is if an object is resurrected: the finalizer
will be called again later.

For CI objects, the order in which finalizers are called (step 2 above)
is undefined.

Safety
------

It is important to explain why the proposed change is safe.  There
are two aspects to be discussed:

* Can a finalizer access zombie objects (including the object being
  finalized)?

* What happens if a finalizer mutates the object graph so as to impact
  the CI?

Let's discuss the first issue.  We will divide possible cases in two
categories:

* If the object being finalized is part of the CI: by construction, no
  objects in CI are zombies yet, since CI finalizers are called before
  any reference breaking is done.  Therefore, the finalizer cannot
  access zombie objects, which don't exist.

* If the object being finalized is not part of the CI/CT: by definition,
  objects in the CI/CT don't have any references pointing to them from
  outside the CI/CT.  Therefore, the finalizer cannot reach any zombie
  object (that is, even if the object being finalized was itself
  referenced from a zombie object).

Now for the second issue.  There are three potential cases:

* The finalizer clears an existing reference to a CI object.  The CI
  object may be disposed of before the GC tries to break it, which
  is fine (the GC simply has to be aware of this possibility).

* The finalizer creates a new reference to a CI object.  This can only
  happen from a CI object's finalizer (see above why).  Therefore, the
  new reference will be detected by the GC after all CI finalizers are
  called (step 3 above), and collection will be aborted without any
  objects being broken.

* The finalizer clears or creates a reference to a non-CI object.  By
  construction, this is not a problem.

Implementation
==============

An implementation is available in branch ``finalize`` of the repository
at http://hg.python.org/features/finalize/.

Validation
==========

Besides running the normal Python test suite, the implementation adds
test cases for various finalization possibilities including reference
cycles, object resurrection and legacy ``tp_del`` slots.

The implementation has also been checked to not produce any regressions
on the following test suites:

* `Tulip <http://code.google.com/p/tulip/>`_, which makes an extensive
  use of generators

* `Tornado <http://www.tornadoweb.org>`_

* `SQLAlchemy <http://www.sqlalchemy.org/>`_

* `Django <https://www.djangoproject.com/>`_

* `zope.interface <http://pypi.python.org/pypi/zope.interface>`_

References
==========

Notes about reference cycle collection and weak reference callbacks:
http://hg.python.org/cpython/file/4e687d53b645/Modules/gc_weakref.txt

Generator memory leak: http://bugs.python.org/issue17468

Allow objects to decide if they can be collected by GC:
http://bugs.python.org/issue9141

Module shutdown procedure based on GC
http://bugs.python.org/issue812369

Copyright
=========

This document has been placed in the public domain.

..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:

Python tracker | 17 May 2013 18:07
Favicon

Summary of Python tracker Issues


ACTIVITY SUMMARY (2013-05-10 - 2013-05-17)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    3966 ( +3)
  closed 25805 (+47)
  total  29771 (+50)

Open issues with patches: 1776 

Issues opened (32)
==================

#17487: wave.Wave_read.getparams should be more user friendly
http://bugs.python.org/issue17487  reopened by Claudiu.Popa

#17807: Generator cleanup without tp_del
http://bugs.python.org/issue17807  reopened by pitrou

#17905: Add check for locale.h
http://bugs.python.org/issue17905  reopened by pitrou

#17951: TypeError during gdb backtracing
http://bugs.python.org/issue17951  opened by Catalin.Patulea

#17953: sys.modules cannot be reassigned
http://bugs.python.org/issue17953  opened by Valentin.Lorentz

#17955: Minor updates to Functional HOWTO
http://bugs.python.org/issue17955  opened by akuchling

#17956: add ScheduledExecutor
http://bugs.python.org/issue17956  opened by neologix

#17957: remove outdated (and unexcellent) paragraph in whatsnew
http://bugs.python.org/issue17957  opened by tshepang

#17960: Clarify the required behaviour of locals()
http://bugs.python.org/issue17960  opened by ncoghlan

#17961: Use enum names as values in enum.Enum convenience API
http://bugs.python.org/issue17961  opened by ncoghlan

#17963: Deprecate the frame hack for implicitly getting module details
http://bugs.python.org/issue17963  opened by ncoghlan

#17967: urllib2.open failed to access a url when a perent directory of
http://bugs.python.org/issue17967  opened by foxkiller

#17969: multiprocessing crash on exit
http://bugs.python.org/issue17969  opened by kristjan.jonsson

#17970: Mutlithread XML parsing cause segfault
http://bugs.python.org/issue17970  opened by mrDoctorWho0..

#17972: inspect module docs omits many functions
http://bugs.python.org/issue17972  opened by s7v7nislands <at> gmail.com

#17974: Migrate unittest to argparse
http://bugs.python.org/issue17974  opened by pitrou

#17975: libpython3.so conflicts between $VERSIONs
http://bugs.python.org/issue17975  opened by prlw1

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976  opened by jasujm

#17978: Python crashes if Py_Initialize/Py_Finalize are called multipl
http://bugs.python.org/issue17978  opened by romuloceccon

#17979: Cannot build 2.7 with --enable-unicode=no
http://bugs.python.org/issue17979  opened by amaury.forgeotdarc

#17980: CVE-2013-2099 ssl.match_hostname() trips over crafted	wildcard
http://bugs.python.org/issue17980  opened by fweimer

#17984: io and _pyio modules require the _io module
http://bugs.python.org/issue17984  opened by serhiy.storchaka

#17985: multiprocessing Queue.qsize() and Queue.empty() with different
http://bugs.python.org/issue17985  opened by aod

#17986: Alternative async subprocesses (pep 3145)
http://bugs.python.org/issue17986  opened by sbt

#17987: test.support.captured_stderr, captured_stdin not documented
http://bugs.python.org/issue17987  opened by fdrake

#17988: ElementTree.Element != ElementTree._ElementInterface
http://bugs.python.org/issue17988  opened by jwilk

#17989: ElementTree.Element broken attribute setting
http://bugs.python.org/issue17989  opened by jwilk

#17991: ctypes.c_char gives a misleading error when passed a one-chara
http://bugs.python.org/issue17991  opened by Steven.Barker

#17994: Change necessary in platform.py to support IronPython
http://bugs.python.org/issue17994  opened by icordasc

#17996: socket module should expose AF_LINK
http://bugs.python.org/issue17996  opened by giampaolo.rodola

#17997: ssl.match_hostname(): sub string wildcard should not match IDN
http://bugs.python.org/issue17997  opened by christian.heimes

#17998: internal error in regular expression engine
http://bugs.python.org/issue17998  opened by jdemeyer

Most recent 15 issues with no replies (15)
==========================================

#17998: internal error in regular expression engine
http://bugs.python.org/issue17998

#17997: ssl.match_hostname(): sub string wildcard should not match IDN
http://bugs.python.org/issue17997

#17996: socket module should expose AF_LINK
http://bugs.python.org/issue17996

#17994: Change necessary in platform.py to support IronPython
http://bugs.python.org/issue17994

#17991: ctypes.c_char gives a misleading error when passed a one-chara
http://bugs.python.org/issue17991

#17987: test.support.captured_stderr, captured_stdin not documented
http://bugs.python.org/issue17987

#17986: Alternative async subprocesses (pep 3145)
http://bugs.python.org/issue17986

#17975: libpython3.so conflicts between $VERSIONs
http://bugs.python.org/issue17975

#17942: IDLE Debugger: names, values misaligned
http://bugs.python.org/issue17942

#17933: test_ftp failure / ftplib error formatting issue
http://bugs.python.org/issue17933

#17924: Deprecate stat.S_IF* integer constants
http://bugs.python.org/issue17924

#17923: test glob with trailing slash fail
http://bugs.python.org/issue17923

#17916: Provide dis.Bytecode based equivalent of dis.distb
http://bugs.python.org/issue17916

#17909: Autodetecting JSON encoding
http://bugs.python.org/issue17909

#17902: Document that _elementtree C API cannot use custom TreeBuilder
http://bugs.python.org/issue17902

Most recent 15 issues waiting for review (15)
=============================================

#17988: ElementTree.Element != ElementTree._ElementInterface
http://bugs.python.org/issue17988

#17980: CVE-2013-2099 ssl.match_hostname() trips over crafted	wildcard
http://bugs.python.org/issue17980

#17979: Cannot build 2.7 with --enable-unicode=no
http://bugs.python.org/issue17979

#17978: Python crashes if Py_Initialize/Py_Finalize are called multipl
http://bugs.python.org/issue17978

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976

#17974: Migrate unittest to argparse
http://bugs.python.org/issue17974

#17956: add ScheduledExecutor
http://bugs.python.org/issue17956

#17951: TypeError during gdb backtracing
http://bugs.python.org/issue17951

#17947: Code, test, and doc review for PEP-0435 Enum
http://bugs.python.org/issue17947

#17945: tkinter/Python 3.3.0: peer_create doesn't instantiate Text
http://bugs.python.org/issue17945

#17944: Refactor test_zipfile
http://bugs.python.org/issue17944

#17941: namedtuple should support fully qualified name for more portab
http://bugs.python.org/issue17941

#17940: extra code in argparse.py
http://bugs.python.org/issue17940

#17937: Collect garbage harder at shutdown
http://bugs.python.org/issue17937

#17936: O(n**2) behaviour when adding/removing classes
http://bugs.python.org/issue17936

Top 10 most discussed issues (10)
=================================

#17914: add os.cpu_count()
http://bugs.python.org/issue17914  36 msgs

#17980: CVE-2013-2099 ssl.match_hostname() trips over crafted	wildcard
http://bugs.python.org/issue17980  31 msgs

#17947: Code, test, and doc review for PEP-0435 Enum
http://bugs.python.org/issue17947  27 msgs

#15392: Create a unittest framework for IDLE
http://bugs.python.org/issue15392  16 msgs

#17961: Use enum names as values in enum.Enum convenience API
http://bugs.python.org/issue17961  15 msgs

#17936: O(n**2) behaviour when adding/removing classes
http://bugs.python.org/issue17936  14 msgs

#17969: multiprocessing crash on exit
http://bugs.python.org/issue17969  13 msgs

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976  10 msgs

#8604: Adding an atomic FS write API
http://bugs.python.org/issue8604   9 msgs

#17974: Migrate unittest to argparse
http://bugs.python.org/issue17974   9 msgs

Issues closed (41)
==================

#6208: path separator output ignores shell's path separator: /	instea
http://bugs.python.org/issue6208  closed by terry.reedy

#14596: struct.unpack memory leak
http://bugs.python.org/issue14596  closed by pitrou

#17237: m68k aligns on 16bit boundaries.
http://bugs.python.org/issue17237  closed by pitrou

#17468: Generator memory leak
http://bugs.python.org/issue17468  closed by pitrou

#17547: "checking whether gcc supports ParseTuple __format__... " erro
http://bugs.python.org/issue17547  closed by python-dev

#17563: Excessive resizing of dicts when used as a cache
http://bugs.python.org/issue17563  closed by rhettinger

#17606: xml.sax.saxutils.XMLGenerator doesn't support byte strings
http://bugs.python.org/issue17606  closed by serhiy.storchaka

#17732: distutils.cfg Can Break venv
http://bugs.python.org/issue17732  closed by georg.brandl

#17742: Add _PyBytesWriter API
http://bugs.python.org/issue17742  closed by haypo

#17754: test_ctypes assumes LANG=C LC_ALL=C
http://bugs.python.org/issue17754  closed by doko

#17843: Lib/test/testbz2_bigmem.bz2 trigger virus warnings
http://bugs.python.org/issue17843  closed by georg.brandl

#17895: TemporaryFile name returns an integer in python3
http://bugs.python.org/issue17895  closed by terry.reedy

#17906: JSON should accept lone surrogates
http://bugs.python.org/issue17906  closed by serhiy.storchaka

#17915: Encoding error with sax and codecs
http://bugs.python.org/issue17915  closed by georg.brandl

#17920: Documentation: "complete ordering" should be "total ordering"
http://bugs.python.org/issue17920  closed by rhettinger

#17927: Argument copied into cell still referenced by frame
http://bugs.python.org/issue17927  closed by benjamin.peterson

#17943: AttributeError: 'long' object has no attribute 'release' in Qu
http://bugs.python.org/issue17943  closed by georg.brandl

#17948: HTTPS and sending a big file size hangs.
http://bugs.python.org/issue17948  closed by pitrou

#17949: operator documentation mixup
http://bugs.python.org/issue17949  closed by ezio.melotti

#17950: Dynamic classes contain non-breakable reference cycles
http://bugs.python.org/issue17950  closed by gvanrossum

#17952: editors-and-tools section of devguide does not appear to be ac
http://bugs.python.org/issue17952  closed by ned.deily

#17954: Support creation of extensible enums through metaclass subclas
http://bugs.python.org/issue17954  closed by ncoghlan

#17958: int(math.log(2**i, 2))
http://bugs.python.org/issue17958  closed by mark.dickinson

#17959: Alternate approach to aliasing for PEP 435
http://bugs.python.org/issue17959  closed by ncoghlan

#17962: Broken OpenSSL version in Windows builds
http://bugs.python.org/issue17962  closed by python-dev

#17964: os.sysconf(): return type of the C function sysconf() is long,
http://bugs.python.org/issue17964  closed by haypo

#17965: argparse does not dest.replace('-', '_')  for positionals
http://bugs.python.org/issue17965  closed by r.david.murray

#17966: Lack of consistency in PEP 8 -- Style Guide for Python Code
http://bugs.python.org/issue17966  closed by gvanrossum

#17968: memory leak in listxattr()
http://bugs.python.org/issue17968  closed by pitrou

#17971: Weird interaction between Komodo Python debugger C module & Py
http://bugs.python.org/issue17971  closed by benjamin.peterson

#17973: '+=' on a list inside tuple both succeeds and raises an except
http://bugs.python.org/issue17973  closed by ronaldoussoren

#17977: urllib.request.urlopen() cadefault argument is documented with
http://bugs.python.org/issue17977  closed by barry

#17981: SysLogHandler closes connection before using it
http://bugs.python.org/issue17981  closed by vinay.sajip

#17982: Syntax Error in IDLE3 not in IDLE
http://bugs.python.org/issue17982  closed by terry.reedy

#17983: global __class__ statement in class declaration
http://bugs.python.org/issue17983  closed by python-dev

#17990: 2.7 builds can fail due to unconditional inclusion of include 
http://bugs.python.org/issue17990  closed by benjamin.peterson

#17992: test_asynchat hangs
http://bugs.python.org/issue17992  closed by neologix

#17993: Missed comma causes unintentional implicit string literal conc
http://bugs.python.org/issue17993  closed by serhiy.storchaka

#17995: report,中 高 层 管 理 技 能158766
http://bugs.python.org/issue17995  closed by fdrake

#995907: memory leak with threads and enhancement of the timer class
http://bugs.python.org/issue995907  closed by neologix

#1662581: the re module can perform poorly: O(2**n) versus O(n**2)
http://bugs.python.org/issue1662581  closed by gregory.p.smith

ACTIVITY SUMMARY (2013-05-10 - 2013-05-17)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    3966 ( +3)
  closed 25805 (+47)
  total  29771 (+50)

Open issues with patches: 1776 

Issues opened (32)
==================

#17487: wave.Wave_read.getparams should be more user friendly
http://bugs.python.org/issue17487  reopened by Claudiu.Popa

#17807: Generator cleanup without tp_del
http://bugs.python.org/issue17807  reopened by pitrou

#17905: Add check for locale.h
http://bugs.python.org/issue17905  reopened by pitrou

#17951: TypeError during gdb backtracing
http://bugs.python.org/issue17951  opened by Catalin.Patulea

#17953: sys.modules cannot be reassigned
http://bugs.python.org/issue17953  opened by Valentin.Lorentz

#17955: Minor updates to Functional HOWTO
http://bugs.python.org/issue17955  opened by akuchling

#17956: add ScheduledExecutor
http://bugs.python.org/issue17956  opened by neologix

#17957: remove outdated (and unexcellent) paragraph in whatsnew
http://bugs.python.org/issue17957  opened by tshepang

#17960: Clarify the required behaviour of locals()
http://bugs.python.org/issue17960  opened by ncoghlan

#17961: Use enum names as values in enum.Enum convenience API
http://bugs.python.org/issue17961  opened by ncoghlan

#17963: Deprecate the frame hack for implicitly getting module details
http://bugs.python.org/issue17963  opened by ncoghlan

#17967: urllib2.open failed to access a url when a perent directory of
http://bugs.python.org/issue17967  opened by foxkiller

#17969: multiprocessing crash on exit
http://bugs.python.org/issue17969  opened by kristjan.jonsson

#17970: Mutlithread XML parsing cause segfault
http://bugs.python.org/issue17970  opened by mrDoctorWho0..

#17972: inspect module docs omits many functions
http://bugs.python.org/issue17972  opened by s7v7nislands <at> gmail.com

#17974: Migrate unittest to argparse
http://bugs.python.org/issue17974  opened by pitrou

#17975: libpython3.so conflicts between $VERSIONs
http://bugs.python.org/issue17975  opened by prlw1

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976  opened by jasujm

#17978: Python crashes if Py_Initialize/Py_Finalize are called multipl
http://bugs.python.org/issue17978  opened by romuloceccon

#17979: Cannot build 2.7 with --enable-unicode=no
http://bugs.python.org/issue17979  opened by amaury.forgeotdarc

#17980: CVE-2013-2099 ssl.match_hostname() trips over crafted	wildcard
http://bugs.python.org/issue17980  opened by fweimer

#17984: io and _pyio modules require the _io module
http://bugs.python.org/issue17984  opened by serhiy.storchaka

#17985: multiprocessing Queue.qsize() and Queue.empty() with different
http://bugs.python.org/issue17985  opened by aod

#17986: Alternative async subprocesses (pep 3145)
http://bugs.python.org/issue17986  opened by sbt

#17987: test.support.captured_stderr, captured_stdin not documented
http://bugs.python.org/issue17987  opened by fdrake

#17988: ElementTree.Element != ElementTree._ElementInterface
http://bugs.python.org/issue17988  opened by jwilk

#17989: ElementTree.Element broken attribute setting
http://bugs.python.org/issue17989  opened by jwilk

#17991: ctypes.c_char gives a misleading error when passed a one-chara
http://bugs.python.org/issue17991  opened by Steven.Barker

#17994: Change necessary in platform.py to support IronPython
http://bugs.python.org/issue17994  opened by icordasc

#17996: socket module should expose AF_LINK
http://bugs.python.org/issue17996  opened by giampaolo.rodola

#17997: ssl.match_hostname(): sub string wildcard should not match IDN
http://bugs.python.org/issue17997  opened by christian.heimes

#17998: internal error in regular expression engine
http://bugs.python.org/issue17998  opened by jdemeyer

Most recent 15 issues with no replies (15)
==========================================

#17998: internal error in regular expression engine
http://bugs.python.org/issue17998

#17997: ssl.match_hostname(): sub string wildcard should not match IDN
http://bugs.python.org/issue17997

#17996: socket module should expose AF_LINK
http://bugs.python.org/issue17996

#17994: Change necessary in platform.py to support IronPython
http://bugs.python.org/issue17994

#17991: ctypes.c_char gives a misleading error when passed a one-chara
http://bugs.python.org/issue17991

#17987: test.support.captured_stderr, captured_stdin not documented
http://bugs.python.org/issue17987

#17986: Alternative async subprocesses (pep 3145)
http://bugs.python.org/issue17986

#17975: libpython3.so conflicts between $VERSIONs
http://bugs.python.org/issue17975

#17942: IDLE Debugger: names, values misaligned
http://bugs.python.org/issue17942

#17933: test_ftp failure / ftplib error formatting issue
http://bugs.python.org/issue17933

#17924: Deprecate stat.S_IF* integer constants
http://bugs.python.org/issue17924

#17923: test glob with trailing slash fail
http://bugs.python.org/issue17923

#17916: Provide dis.Bytecode based equivalent of dis.distb
http://bugs.python.org/issue17916

#17909: Autodetecting JSON encoding
http://bugs.python.org/issue17909

#17902: Document that _elementtree C API cannot use custom TreeBuilder
http://bugs.python.org/issue17902

Most recent 15 issues waiting for review (15)
=============================================

#17988: ElementTree.Element != ElementTree._ElementInterface
http://bugs.python.org/issue17988

#17980: CVE-2013-2099 ssl.match_hostname() trips over crafted	wildcard
http://bugs.python.org/issue17980

#17979: Cannot build 2.7 with --enable-unicode=no
http://bugs.python.org/issue17979

#17978: Python crashes if Py_Initialize/Py_Finalize are called multipl
http://bugs.python.org/issue17978

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976

#17974: Migrate unittest to argparse
http://bugs.python.org/issue17974

#17956: add ScheduledExecutor
http://bugs.python.org/issue17956

#17951: TypeError during gdb backtracing
http://bugs.python.org/issue17951

#17947: Code, test, and doc review for PEP-0435 Enum
http://bugs.python.org/issue17947

#17945: tkinter/Python 3.3.0: peer_create doesn't instantiate Text
http://bugs.python.org/issue17945

#17944: Refactor test_zipfile
http://bugs.python.org/issue17944

#17941: namedtuple should support fully qualified name for more portab
http://bugs.python.org/issue17941

#17940: extra code in argparse.py
http://bugs.python.org/issue17940

#17937: Collect garbage harder at shutdown
http://bugs.python.org/issue17937

#17936: O(n**2) behaviour when adding/removing classes
http://bugs.python.org/issue17936

Top 10 most discussed issues (10)
=================================

#17914: add os.cpu_count()
http://bugs.python.org/issue17914  36 msgs

#17980: CVE-2013-2099 ssl.match_hostname() trips over crafted	wildcard
http://bugs.python.org/issue17980  31 msgs

#17947: Code, test, and doc review for PEP-0435 Enum
http://bugs.python.org/issue17947  27 msgs

#15392: Create a unittest framework for IDLE
http://bugs.python.org/issue15392  16 msgs

#17961: Use enum names as values in enum.Enum convenience API
http://bugs.python.org/issue17961  15 msgs

#17936: O(n**2) behaviour when adding/removing classes
http://bugs.python.org/issue17936  14 msgs

#17969: multiprocessing crash on exit
http://bugs.python.org/issue17969  13 msgs

#17976: file.write doesn't raise IOError when it should
http://bugs.python.org/issue17976  10 msgs

#8604: Adding an atomic FS write API
http://bugs.python.org/issue8604   9 msgs

#17974: Migrate unittest to argparse
http://bugs.python.org/issue17974   9 msgs

Issues closed (41)
==================

#6208: path separator output ignores shell's path separator: /	instea
http://bugs.python.org/issue6208  closed by terry.reedy

#14596: struct.unpack memory leak
http://bugs.python.org/issue14596  closed by pitrou

#17237: m68k aligns on 16bit boundaries.
http://bugs.python.org/issue17237  closed by pitrou

#17468: Generator memory leak
http://bugs.python.org/issue17468  closed by pitrou

#17547: "checking whether gcc supports ParseTuple __format__... " erro
http://bugs.python.org/issue17547  closed by python-dev

#17563: Excessive resizing of dicts when used as a cache
http://bugs.python.org/issue17563  closed by rhettinger

#17606: xml.sax.saxutils.XMLGenerator doesn't support byte strings
http://bugs.python.org/issue17606  closed by serhiy.storchaka

#17732: distutils.cfg Can Break venv
http://bugs.python.org/issue17732  closed by georg.brandl

#17742: Add _PyBytesWriter API
http://bugs.python.org/issue17742  closed by haypo

#17754: test_ctypes assumes LANG=C LC_ALL=C
http://bugs.python.org/issue17754  closed by doko

#17843: Lib/test/testbz2_bigmem.bz2 trigger virus warnings
http://bugs.python.org/issue17843  closed by georg.brandl

#17895: TemporaryFile name returns an integer in python3
http://bugs.python.org/issue17895  closed by terry.reedy

#17906: JSON should accept lone surrogates
http://bugs.python.org/issue17906  closed by serhiy.storchaka

#17915: Encoding error with sax and codecs
http://bugs.python.org/issue17915  closed by georg.brandl

#17920: Documentation: "complete ordering" should be "total ordering"
http://bugs.python.org/issue17920  closed by rhettinger

#17927: Argument copied into cell still referenced by frame
http://bugs.python.org/issue17927  closed by benjamin.peterson

#17943: AttributeError: 'long' object has no attribute 'release' in Qu
http://bugs.python.org/issue17943  closed by georg.brandl

#17948: HTTPS and sending a big file size hangs.
http://bugs.python.org/issue17948  closed by pitrou

#17949: operator documentation mixup
http://bugs.python.org/issue17949  closed by ezio.melotti

#17950: Dynamic classes contain non-breakable reference cycles
http://bugs.python.org/issue17950  closed by gvanrossum

#17952: editors-and-tools section of devguide does not appear to be ac
http://bugs.python.org/issue17952  closed by ned.deily

#17954: Support creation of extensible enums through metaclass subclas
http://bugs.python.org/issue17954  closed by ncoghlan

#17958: int(math.log(2**i, 2))
http://bugs.python.org/issue17958  closed by mark.dickinson

#17959: Alternate approach to aliasing for PEP 435
http://bugs.python.org/issue17959  closed by ncoghlan

#17962: Broken OpenSSL version in Windows builds
http://bugs.python.org/issue17962  closed by python-dev

#17964: os.sysconf(): return type of the C function sysconf() is long,
http://bugs.python.org/issue17964  closed by haypo

#17965: argparse does not dest.replace('-', '_')  for positionals
http://bugs.python.org/issue17965  closed by r.david.murray

#17966: Lack of consistency in PEP 8 -- Style Guide for Python Code
http://bugs.python.org/issue17966  closed by gvanrossum

#17968: memory leak in listxattr()
http://bugs.python.org/issue17968  closed by pitrou

#17971: Weird interaction between Komodo Python debugger C module & Py
http://bugs.python.org/issue17971  closed by benjamin.peterson

#17973: '+=' on a list inside tuple both succeeds and raises an except
http://bugs.python.org/issue17973  closed by ronaldoussoren

#17977: urllib.request.urlopen() cadefault argument is documented with
http://bugs.python.org/issue17977  closed by barry

#17981: SysLogHandler closes connection before using it
http://bugs.python.org/issue17981  closed by vinay.sajip

#17982: Syntax Error in IDLE3 not in IDLE
http://bugs.python.org/issue17982  closed by terry.reedy

#17983: global __class__ statement in class declaration
http://bugs.python.org/issue17983  closed by python-dev

#17990: 2.7 builds can fail due to unconditional inclusion of include 
http://bugs.python.org/issue17990  closed by benjamin.peterson

#17992: test_asynchat hangs
http://bugs.python.org/issue17992  closed by neologix

#17993: Missed comma causes unintentional implicit string literal conc
http://bugs.python.org/issue17993  closed by serhiy.storchaka

#17995: report,中 高 层 管 理 技 能158766
http://bugs.python.org/issue17995  closed by fdrake

#995907: memory leak with threads and enhancement of the timer class
http://bugs.python.org/issue995907  closed by neologix

#1662581: the re module can perform poorly: O(2**n) versus O(n**2)
http://bugs.python.org/issue1662581  closed by gregory.p.smith

Gmane