[issue18837] multiprocessing.reduction is undocumented

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +jnoller, sbt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18837] multiprocessing.reduction is undocumented

[Tomi Pieviläinen]

New submission from Tomi Pieviläinen:

In older versions (2.x, 3.2, 3.3) multiprocessing.reduction was only mentioned 
in a one example, with a one comment after it. In the 3.4dev documentation even 
this was dropped.

--
assignee: docs@python
components: Documentation
messages: 196184
nosy: docs@python, tpievila
priority: normal
severity: normal
status: open
title: multiprocessing.reduction is undocumented
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18836] Potential race condition in exceptions

[Sworddragon]

Sworddragon added the comment:

> Are you saying that if the user keeps hitting ctrl+c you would need an 
> endless chain of nested try/except in order to catch them all?

Correct. For example if I want to show the user the message "Aborted" instead 
of a huge exception if he hits CTRL + C another KeyboardInterrupt could appear.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18836] Potential race condition in exceptions

[Ezio Melotti]

Ezio Melotti added the comment:

> The third CTRL + C will cause a KeyboardInterrupt.

This is expected.  The first ctrl+c interrupts the first sleep and goes in the 
second try, executing the second sleep.  The second ctrl+c interrupts the 
second sleep and goes in the second except where it finds the third sleep.  
Here a third ctrl+c will interrupt the sleep and since this line is not in a 
try block nothing will catch the KeyboardInterrupt.

Are you saying that if the user keeps hitting ctrl+c you would need an endless 
chain of nested try/except in order to catch them all?

--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18823] Idle: use pipes instead of sockets to talk with user subprocess

[Andrew Svetlov]

Changes by Andrew Svetlov :


--
nosy: +asvetlov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18836] Potential race condition in exceptions

[Sworddragon]

Changes by Sworddragon :


Added file: http://bugs.python.org/file31470/race_condition_slow.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18836] Potential race condition in exceptions

[Sworddragon]

New submission from Sworddragon:

On a try/except-block if an exception raises (for example KeyboardInterrupt) 
the except block could cause another exception and if this block tries to catch 
it too the nested except block could cause another exception again. This goes 
into an unlimited recursion.

In the attachments is an example of such a problem (race_condition_fast.py). 
But as it is called a "race condition" it is nearly impossible to reproduce it 
by a human. For this case I have adjusted the example (race_condition_slow.py). 
The third CTRL + C will cause a KeyboardInterrupt.

--
components: Interpreter Core
files: race_condition_fast.py
messages: 196181
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Potential race condition in exceptions
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file31469/race_condition_fast.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

Hmm, did you look at my last comment at all? It solves both the technical 
issues and the API issues very nicely and avoids any problems of potential 
future changes. Let me quickly explain why.

The feature in question depends on two existing parts of the API: the event 
generation of the parser, and the return values of the parser target (e.g. a 
tree builder). So there are really only three places where this feature makes 
sense, both technically and API-wise.

1) in the target
2) in the parser
3) between parser and target

Note how a separate class is ruled out right from the start by the fact that 
the feature lives somehwere between parser and target. It's an inherent part of 
the existing design already (and of the implementation, BTW), so I don't see 
how adding a separate thing to control it makes any sense.

1) is impossible because the target is user provided and we do not control it
2) works fine because the parser controls both the call to the target and its 
return value
3) would be nice (and was my original favourite) but is hard to do with the 
current implementation and requires further changes to the API of parser targets

So 2) is the choice that remains.


> It will *not* accept a "parser" argument in the constructor.

Yes, I had also arrived at that point yesterday. However, I then reconsidered 
why there has to be a separate class in the first place. Basically, if you 
can't allow users to control the parser because the feature is already part of 
the parser, then why expose it as something that appears to be independent? 
Adding it to the existing API is very clean and exposes the feature where users 
would look for it.


> EventParser's output-side method will be called "read_events".

Makes sense to me. I had also considered that problem but didn't come up with a 
good name yet. "read_events" reads better than plain "events".


> The class will be named EventParser.

Obviously because it's parsing Events, as opposed to the XMLParser, which 
parses XML, or the HTMLParser, which parses HTML, right?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17410] Generator-based HTMLParser

[Nick Coghlan]

Nick Coghlan added the comment:

The event generation API for ElementTree being discussed in issue 17741 is 
potentially relevant here.

I think that style of API is preferable, as it doesn't alter how data is fed 
into the parser, just how it is extracted.

--
nosy: +ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Nick Coghlan]

Nick Coghlan added the comment:

Sounds good to me :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

I had a chat with Nick about this, and a variation of the proposal in 
http://bugs.python.org/msg196133 seems acceptable to us both. To summarize, 
here's what goes into 3.4.

* The class will be named EventParser.
Rationale: The Incremental in IncrementalParser is ambiguous, because it's not 
clear which side is incremental - input or output. In addition, XMLParser is 
already "incremental" in the sense that it has a feed() method. EventParser is 
(although not a perfect name) clearer w.r.t what it does - produces events from 
the parsing. Another (milder) reason is to avoid confusing duplication with 
xml.sax.xmlreader.IncrementalParser, which is somewhat different. Yet another 
is that if we eventually figure out how to implement this in a parser target, a 
great name for that target would be EventBuilder, which is a logical building 
block for EventParser.

* It will *not* accept a "parser" argument in the constructor.
Rationale: the parser argument of iterparse is broken anyway. This will make it 
much easier to modify the implementation of EventParser in the future when the 
C internals are fixed w.r.t problems mentioned in this issue.

* iterparse's "parser" argument will be deprecated, and the documentation will 
be more detailed w.r.t to the limitations on its current "parser" argument (the 
limitations are there in the code, but they're not fully documented).

* EventParser's input-side methods will be named feed and close, to be more 
consistent with existing XML APIs (both XMLParser and 
xml.sax.xmlreader.IncrementalParser).

* EventParser's output-side method will be called "read_events".
Rationale: "read_" helps convey that the consumption of events is destructive. 
A possible future addition of a complementary, non-destructive API - 
"peek_events" will be considered.

* Documentation will be modified to clarify exactly how EventParser differs 
from XMLParser and iterparse.

Also, new issue(s) will be created to address fixing specific implementation 
problems.



Nick, feel free to add/correct if I misunderstood or forgot something.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18835] Add aligned memroy variants to the suite of PyMem functions/macros

[Raymond Hettinger]

Raymond Hettinger added the comment:

I should also mention posix_memalign() for Unix/Linux systems.

On systems without a clean way to provide aligned memory, we can always fall 
back to regular malloc().   The API wouldn't guarantee alignment but would 
comply when possible.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13397] Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions

[Donald Stufft]

Donald Stufft added the comment:

Well you could possibly whitelist some exceptions although I still think that's 
ultimately a bad idea because it means to prevent the remote server (or someone 
in the middle of the connection) from being able to crash your program with an 
arbitrary exception it means you'd need to catch _all_ the whitelisted 
exceptions.

You could possibly make exception subclasses that subclass the Fault exception 
_and_ whatever exception the remote server threw so you could get the 
advantages of both sides.

One flaw in this though is that the remote server doesn't need to be in Python, 
so trying to map errors from the remote server into python exceptions is only 
going to work *if* the remote server is in Python (and even then only if the 
exception is a built in one and not any other exception). Yanking the text out 
of the error message and trying to turn that into an exception is fundamentally 
wrong I believe. It's a bit like reading the response body of a HTTP request 
and doing simple string searching to raise arbitrary exceptions (In fact that's 
basically exactly what it is).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18835] Add aligned memroy variants to the suite of PyMem functions/macros

[Raymond Hettinger]

New submission from Raymond Hettinger:

Currently, we have little to no control over the alignment of memory returned 
by the PyMem functions.   

I suggest variants such as PyMem_Alloc32(n) and PyMem_Alloc64(n) to return 
suitably aligned data blocks.

GNU C provides memalign() for this purpose:  
http://www.delorie.com/gnu/docs/glibc/libc_31.html
and the Microsoft C compiler has _aligned_malloc() for the same purpose: 
http://msdn.microsoft.com/en-us/library/8z34s9c6%28VS.80%29.aspx

A principal use case would be PyObject pointers where we want to keep all or 
most of the data fields in the same cache line (i.e. the fields for list, 
tuple, dict, and set objects).

Deques would benefit from having the deque blocks aligned to 64byte boundaries 
and never crossing page boundaries.  Set entries would benefit from 32byte 
alignment.

--
components: Interpreter Core
messages: 196174
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add aligned memroy variants to the suite of PyMem functions/macros
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18720] Switch suitable constants in the socket module to IntEnum

[Eli Bendersky]

Eli Bendersky added the comment:

Serhiy, patch 5 addresses your latest review. Thanks. As for _family_converter, 
let's see how common this really becomes. Based on one use-case I wouldn't add 
it to Enum itself. But if we see it gets repeated in many places, we can.

--
Added file: http://bugs.python.org/file31468/socket-intenum-af.5.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13397] Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions

[Raymond Hettinger]

Raymond Hettinger added the comment:

Do you have a suggestion for white-listing or a fault-to-exception mapper?

The current API makes faults difficult to use in Python.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message when passed a non-string delimiter

[Vajrasky Kok]

Vajrasky Kok added the comment:

I realized there was a test that was similar with my test. I merged them into 
one test.

I think the alternative is better than the original patch so I updated the 
alternative patch only.

--
Added file: 
http://bugs.python.org/file31467/fix_error_message_reader_csv_alternative_1_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18803] Fix more typos in .py files

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

--
assignee: docs@python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18803] Fix more typos in .py files

[Roundup Robot]

Roundup Robot added the comment:

New changeset 33b156e118c0 by Ezio Melotti in branch '2.7':
#18803: fix more typos.  Patch by Févry Thibault.
http://hg.python.org/cpython/rev/33b156e118c0

New changeset c57d99a8fc42 by Ezio Melotti in branch '3.3':
#18803: fix more typos.  Patch by Févry Thibault.
http://hg.python.org/cpython/rev/c57d99a8fc42

New changeset 6b28bfff9204 by Ezio Melotti in branch 'default':
#18803: merge with 3.3.
http://hg.python.org/cpython/rev/6b28bfff9204

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

I actually have another idea. Since we all agree that passing a custom "parser" 
to iterparse is dubious, IncrementalParser does not have to do that at all. 
This will make it a much more future-proof API. So its signature can be:

  class xml.etree.ElementTree.IncrementalParser(events=None)

The only remaining question is how will iterparse then work based on 
IncrementalParser (since iterparse does accept a parser). iterparse can just 
set the parser on IncrementalParser after creating it - it's an internal 
contract that does not have to be exposed.

This will be better than the current approach in terms of future-proofing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8713] multiprocessing needs option to eschew fork() under Linux

[Ezio Melotti]

Ezio Melotti added the comment:

The new tests produce a few warnings:
$ ./python -m test -uall test_multiprocessing_spawn
[1/1] test_multiprocessing_spawn
Using start method 'spawn'
Warning -- threading._dangling was modified by test_multiprocessing_spawn
Warning -- multiprocessing.process._dangling was modified by 
test_multiprocessing_spawn

$ ./python -m test -uall -v -j2 test_multiprocessing_fork
OK (skipped=4)
Warning -- threading._dangling was modified by test_multiprocessing_fork
Warning -- multiprocessing.process._dangling was modified by 
test_multiprocessing_fork
1 test altered the execution environment:
test_multiprocessing_fork

I've seen test_multiprocessing_forkserver giving warnings too, while running 
the whole test suite, but can't reproduce them while running it alone.  The 
warnings seems quite similar though, so a single fix might resolve the problem 
with all the tests.


The "Using start method '...'" should also be displayed only when the tests are 
run in verbose mode.

--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Jeremy Kloth]

Changes by Jeremy Kloth :


--
nosy: +jkloth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04

[Ezio Melotti]

Ezio Melotti added the comment:

FTR this got "fixed" (i.e. the timeout is ignored) in 3.3 (b17662fc41af) and 
default (6f8fef208958), but on 2.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18833] Increased test coverage for telnetlib

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

Could you also sign the contributor agreement?
http://www.python.org/psf/contrib/contrib-form/

--
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18833] Increased test coverage for telnetlib

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6b33d786b46d by Ezio Melotti in branch '2.7':
#18833: add a test for test_telnetlib.  Patch by Alex Volkov.
http://hg.python.org/cpython/rev/6b33d786b46d

New changeset 1b42e483e520 by Ezio Melotti in branch '3.3':
#18833: add a test for test_telnetlib.  Patch by Alex Volkov.
http://hg.python.org/cpython/rev/1b42e483e520

New changeset a4ec11e0fb87 by Ezio Melotti in branch 'default':
#18833: merge with 3.3.
http://hg.python.org/cpython/rev/a4ec11e0fb87

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04

[Yavor]

Yavor added the comment:

Within this note https://sourceware.org/glibc/wiki/NameResolver about 
getaddrinfo():
"In case there was a *negative* answer it's unclear what should be returned."

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04

[Antoine Pitrou]

Antoine Pitrou added the comment:

Works here on 13.04.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17759] test_urllibnet.test_bad_address() fails on Ubuntu 13.04

[Ezio Melotti]

Ezio Melotti added the comment:

Apparently this has been fixed upstream in glibc:
http://sourceware.org/bugzilla/show_bug.cgi?id=15339
There's also a related discussion at 
http://sourceware.org/bugzilla/show_bug.cgi?id=15726

Barry, can this be closed?

--
nosy: +ezio.melotti
type:  -> behavior
versions: +Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18834] Add Clang to distutils to build C/C++ extensions

[Ryan Gonzalez]

New submission from Ryan Gonzalez:

A have created to patches(for ccompiler.py and cygwinccompiler.py) to add Clang 
as a compiler in distutils. The patches are here:

ccompiler.py: http://pastebin.com/yMGYys0P
cygwinccompiler.py: http://pastebin.com/a49qNP6n

I used the distutils version from Mercurial.

--
assignee: eric.araujo
components: Distutils
messages: 196160
nosy: Ryan.Gonzalez, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Add Clang to distutils to build C/C++ extensions
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18832] New regex module degrades re performance

[Ned Deily]

Changes by Ned Deily :


--
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18832] New regex module degrades re performance

[Matthew Barnett]

Matthew Barnett added the comment:

The 'regex' module is not part of the CPython distribution, so it's not covered 
by this tracker.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

[Charles-François Natali]

Changes by Charles-François Natali :


--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18833] Increased test coverage for telnetlib

[Alex Volkov]

New submission from Alex Volkov:

This issue splits up an unrelated patch from issue 18731
http://bugs.python.org/issue18731

Added a test for telnetlib increasing test coverage.

Updated with the changes from code review of issue 18731
http://bugs.python.org/review/18731/patch/8923/33000

--
components: Tests
files: test_telnetlib_getter.patch
keywords: patch
messages: 196158
nosy: Alex.Volkov
priority: normal
severity: normal
status: open
title: Increased test coverage for telnetlib
versions: Python 3.4
Added file: http://bugs.python.org/file31466/test_telnetlib_getter.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18728] Increased test coverage for filecmp.py

[Alex Volkov]

Alex Volkov added the comment:

HI Vajrasky,

I fixed the typo in a comment and removed WIN32 constant definition from the 
code.

I looked at the existing tearDown method, on line 79, it calls shutil.rmtree on 
a directory above the files/directories I'm writing my test files, so the 
statements and the end of each function or combining these statements in a 
cleanup function is redundant, so I removed them.

Alex.

--
Added file: http://bugs.python.org/file31465/test_filecmp_v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18808] Thread.join returns before PyThreadState is destroyed

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, I've committed the first patch.

--
versions:  -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

> Also, even if the new approach is implemented in the next release,
IncrementalParser can stay as a simple synonym to
XMLParser(target=EventBuilder(...)).

No it can't. According to your signature, it accepts a parser instance as 
input. So it can't just create a new one internally.


"""
This is an existing API within ET:

  xml.etree.ElementTree.iterparse(source, events=None, parser=None)

The parser argument is limited: it can't use a custom TreeBuilder. It also
must provide _setevents, so either inherit from XMLParser or just provide
that method in another way [I'll try to improve the documentation to make
all of this explicit]. Whatever we say in this issue, iterparse is here to
stay.
"""

I agree. However, I can't see why this should constrain us when adding a new 
API. Sure, the current implementation puts certain restrictions on the input. 
But I see that as an advantage, not as a constraint. It's currently broken in 
what it accepts as input, so we are free to change that aspect later on. And we 
can now try to get it right for the new API that we add.

Also, AFAICT, passing a parser into iterparse() is a very rare thing to do, if 
only because it doesn't really work, so the likelyhood of breaking code is very 
limited (I'm not saying we should, just thinking about the impact). Note that 
lxml.etree doesn't currently support this at all.


Just to throw some more ideas into the wild, what do you think about making 
this an inherent feature of the XMLParser class itself? That can be done now, 
without major changes to the underlying code. It could be enabled by a new 
keyword argument "collect_events=None" that you could pass into the constructor 
in order to define the set of events. The "events()" method would always be 
available, but would only yield events if there actually are any. Otherwise, it 
would just terminate and be done. So, unless you pass it a set of event names 
at init time, the parser wouldn't collect events and you wouldn't get any out 
of it. Sounds like a clean interface to me.

Collecting the events would work in the same way as it currently works, i.e. it 
would call the target's start() method, and whatever that returns will be added 
as value to the events as a tuple ("start", target_return_value). That means 
that it's up to the parser target to determine what the event iteration 
returns. Can be elements, can be None, can be something else.

As for backwards compatibility with iterparse(), I don't see a problem with 
officially documenting iterparse() as requiring an XMLParser if a parser is 
provided, and as reconfiguring that parser to its needs. It already does that 
anyway and it currently doesn't work for anything but an XMLParser.


Also, on a related note, we might (!) consider the addition of the _setevents() 
method a bug in CPython 3.3. It didn't exist in ElementTree before it was 
merged with cElementTree. Instead, the expected interface was (apparently) that 
the parser that is passed in has a "_parser" attribute that holds an Expat 
parser, and that iterparse() could reconfigure according for itself. Both are 
not public APIs and even differed between ET and cET, so I don't see any harm 
being done, but it would be good to have one way to do it. OTOH, if that way is 
_setevents(), then be it. The advantage would be that this interface is at 
least independent of Expat and could potentially be implemented by other types 
of parsers.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18808] Thread.join returns before PyThreadState is destroyed

[Roundup Robot]

Roundup Robot added the comment:

New changeset becbb65074e1 by Antoine Pitrou in branch 'default':
Issue #18808: Non-daemon threads are now automatically joined when a 
sub-interpreter is shutdown (it would previously dump a fatal error).
http://hg.python.org/cpython/rev/becbb65074e1

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18832] New regex module degrades re performance

[Tal Weiss]

New submission from Tal Weiss:

All tests I ran comparing timing of the new regex module relative to the old re 
module showed significant slower performance.
I'm attaching test code with regular expressions from our production server.
Tested on Python 2.7, 64 bit Linux + 64 bit Windows 7.
regex #0 match success = 0.16530585289 seconds
re#0 match success = 0.0977821350098 seconds
regex #0 match failure = 0.460994958878 seconds
re#0 match failure = 0.249558925629 seconds
regex #1 match success = 0.0802597999573 seconds
re#1 match success = 0.0348429679871 seconds
regex #1 match failure = 0.224385023117 seconds
re#1 match failure = 0.104065895081 seconds
regex #2 match success = 0.0307199954987 seconds
re#2 match success = 0.0200390815735 seconds
regex #2 match failure = 0.0253899097443 seconds
re#2 match failure = 0.0161480903625 seconds

--
components: Regular Expressions
files: play_regex.py
messages: 196153
nosy: Tal.Weiss, ezio.melotti, haypo, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: New regex module degrades re performance
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31464/play_regex.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18685] Restore re performance to pre-PEP393 level

[Tal Weiss]

Changes by Tal Weiss :


--
nosy: +Tal.Weiss

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18763] subprocess: file descriptors should be closed after preexec_fn is called

[Roundup Robot]

Roundup Robot added the comment:

New changeset f2b023135b1b by Charles-François Natali in branch '2.7':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/f2b023135b1b

New changeset 4c52d4bac03c by Charles-François Natali in branch '3.3':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/4c52d4bac03c

New changeset 748a5d39e7ce by Charles-François Natali in branch 'default':
Issue #18763: subprocess: The file descriptors are now closed after calling the
http://hg.python.org/cpython/rev/748a5d39e7ce

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18817] Got resource warning when running Lib/aifc.py

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your patch Vajrasky.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18817] Got resource warning when running Lib/aifc.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset e3eec06aa12e by Serhiy Storchaka in branch '2.7':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.
http://hg.python.org/cpython/rev/e3eec06aa12e

New changeset e0c33e0c0483 by Serhiy Storchaka in branch '3.3':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.
http://hg.python.org/cpython/rev/e0c33e0c0483

New changeset 1da223c1b7ed by Serhiy Storchaka in branch 'default':
Issue #18817: Fix a resource warning in Lib/aifc.py demo.  Patch by
http://hg.python.org/cpython/rev/1da223c1b7ed

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

> > As for faking the new API, I don't know if that's a good idea because
> we're not yet sure what that new API is.
>
> If that's your concern, then I suggest not adding the feature at all, as
> long as we don't know if we can (or should) keep up the IncrementalParser
> facade with the revised implementation.
>
> For example, can it accept a user defined parser instance as input or not?
> Can it accept a user defined parser target as input? Can it wrap it or
> would it maybe have to inherit from a TreeBuilder? Should it be a class or
> a helper function? I don't see how the interface you proposed leaves less
> questions open than what I am proposing.
>

This is an existing API within ET:

  xml.etree.ElementTree.iterparse(source, events=None, parser=None)

The parser argument is limited: it can't use a custom TreeBuilder. It also
must provide _setevents, so either inherit from XMLParser or just provide
that method in another way [I'll try to improve the documentation to make
all of this explicit]. Whatever we say in this issue, iterparse is here to
stay.

  class xml.etree.ElementTree.IncrementalParser(events=None, parser=None)

Is the new class. Its interface combines iterparse and XMLParser - so it is
subject to the same constraints. It also serves as a basis of iterparse's
implementation.

If the internals are changed, the constrains we'll be subject to with
iterparse will be the same for IncrementalParse; no more. For example, the
solution can be substituting the target of the given parser to the "event
builder" target. Since we force the target to be TreeBuilder now, it should
not really break user code because that part isn't custom. But whatever the
solution is, it will be the same solution for both IncrementalParser and
iterparse.

Also, even if the new approach is implemented in the next release,
IncrementalParser can stay as a simple synonym to
XMLParser(target=EventBuilder(...)).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18647] re.error: nothing to repeat

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

> fully working patches will be considered

Let me remind you that it's not me who wants this feature so badly.


> As for faking the new API, I don't know if that's a good idea because we're 
> not yet sure what that new API is.

If that's your concern, then I suggest not adding the feature at all, as long 
as we don't know if we can (or should) keep up the IncrementalParser facade 
with the revised implementation.

For example, can it accept a user defined parser instance as input or not? Can 
it accept a user defined parser target as input? Can it wrap it or would it 
maybe have to inherit from a TreeBuilder? Should it be a class or a helper 
function? I don't see how the interface you proposed leaves less questions open 
than what I am proposing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message when passed a non-string delimiter

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18323] 'GzipFile' object has no attribute 'extrastart'

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

We can add in readline() the check that GzipFile is opened in read mode. 
However it will slowdown readline(). See alse issue18003.

Note that the original example is not correct. zlib.compress() doesn't produce 
legal Gzip file.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

Stefan, I don't mind looking at a working patch; however, it's not clear to me 
how you intend to solve the iterparse-accepting-a-custom-XMLParser problem. As 
for faking the new API, I don't know if that's a good idea because we're not 
yet sure what that new API is. I agree with your earlier observation that we 
must begin by refactoring the internals (in the C implementation) and defining 
cleaner APIs for existing objects. Once we do that, we may have better ideas 
about the ideal API for incremental parsing / event building. But that's a 
large job.

Again, fully working patches will be considered. Lacking those, I'm inclined to 
go with the interim solution proposed in 
http://bugs.python.org/issue17741#msg196133

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message when passed a non-string delimiter

[Vajrasky Kok]

Vajrasky Kok added the comment:

This is the second alternative of the patch to fix the error message using 
different approach. I am not sure which one is better.

--
Added file: 
http://bugs.python.org/file31463/fix_error_message_reader_csv_alternative_1.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18831] importlib.import_module() bypasses builtins.__import__

[Brett Cannon]

New submission from Brett Cannon:

Not sure if anyone really cares about this (I don't, but I figured I should at 
least let it be known), but I realized that importlib.import_module() bypasses 
builtins.__import__ by calling directly into the innards of importlib 
(specifically _gcd_import() which skips all the extra setup that __import__ 
entails and which is unnecessary for programmatic imports).

The docs for importlib.import_module() clearly state it uses 
importlib.__import__, but I'm not sure if anyone would be surprised if they 
replaced builtins.__import__ and found that importlib.import_module() was doing 
an end-run around their custom import system, especially since we are promoting 
importlib.import_module() over calling builtins.__import__ directly.

--
components: Library (Lib)
messages: 196144
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: importlib.import_module() bypasses builtins.__import__
type: behavior
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

Actually, let me revise my rpevious comment. I think we should fake the new 
interface for now by adding a TreeEventBuilder that requires having its own 
TreeBuilder internally, instead of wrapping an arbitrary target. That way, we 
can avoid having to clean up the existing dependency of the C parser on the 
C-level TreeBuilder implementation.

Once this cleanup gets done, we can add the support for wrapping user defined 
targets as a feature.

So, basically, I propose to take the route that my TreeEventBuilder patch went, 
just with a simplified implementation. I'll see if I can cut down the patch to 
those essentials.

Would you be ok with something that uses the isinstance() hack in the parser?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16611] Cookie.py does not parse httponly or secure cookie flags

[R. David Murray]

R. David Murray added the comment:

Fix committed.  Thanks, Julien.

If you want to propose a new patch the makes the behavior more 
consistent/useful with respect to what browsers and servers actually do, feel 
free to propose one.  I'm going to close this issue, though.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message when passed a non-string delimiter

[Vajrasky Kok]

Vajrasky Kok added the comment:

This is the preliminary patch to fix the error message.

--
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file31462/fix_error_message_reader_csv.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16611] Cookie.py does not parse httponly or secure cookie flags

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0dbe45697efc by R David Murray in branch '3.3':
#16611: BaseCookie now parses 'secure' and 'httponly' flags.
http://hg.python.org/cpython/rev/0dbe45697efc

New changeset f81846c2b746 by R David Murray in branch 'default':
Merge #16611: BaseCookie now parses 'secure' and 'httponly' flags.
http://hg.python.org/cpython/rev/f81846c2b746

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

> Stefan Behnel added the comment:
>
> > I still think IncrementalParser is worth keeping.
>
> If you want to keep it at all cost, I think we should at least hide it
> behind a function (as with iterparse()). If it's implemented as a class,
> chances are that people will start relying on internals by inheriting from
> it. And we already know that those internals should eventually be removed
> completely. Eventually, that function should become a two-liner or so.
>

I'm not sure I see how this is different from any class exposed by the
stdlib. Users can inherit it, rely on internals and then we can never
change its implementation? Surely this isn't true. We don't make guarantees
w.r.t. implementation and internals, only interfaces. Yes, Python lets you
monkey-patch anything, but this doesn't mean we can't build stable APIs in
Python and change implementation in the future.

So the only thing we should focus on is the *external* API of this class.
With only feed/close/events exposed, it seems logical that these can be
maintained even when the implementation changes.

Besides, such an incremental parser is a natural match for a class because
it has state and several methods that collectively act on that state.
Redesigning it as a function would be awkward. That said, if you have a
specific suggestion in mind that would be as natural to use in user code,
feel free to offer it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18830] Remove duplicates from a result of getclasstree()

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

inspect.getclasstree() produces duplicated entities when it's argument contains 
duplicated classes. This happened when a module contains class aliases. For 
example `pydoc zipfile` outputs three entities for BadZipFile (BadZipfile and 
error are aliases of BadZipFile):

CLASSES
builtins.Exception(builtins.BaseException)
BadZipFile
BadZipFile
BadZipFile
LargeZipFile
builtins.object
ZipFile
PyZipFile
ZipInfo

The proposed patch removes duplicates from a result of getclasstree().

--
components: Library (Lib)
files: getclasstree_no_dups.patch
keywords: patch
messages: 196138
nosy: eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove duplicates from a result of getclasstree()
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31461/getclasstree_no_dups.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

> I still think IncrementalParser is worth keeping.

If you want to keep it at all cost, I think we should at least hide it behind a 
function (as with iterparse()). If it's implemented as a class, chances are 
that people will start relying on internals by inheriting from it. And we 
already know that those internals should eventually be removed completely. 
Eventually, that function should become a two-liner or so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

"""
TreeBuilder has to support an explicit API for collecting and reporting events. 
XMLParser has to call into this API and either not have _setevents at all or 
have something public and documented. Note also that event hookup in the parser 
makes sense in a way, because we don't want events to be fired when not needed 
(for performance). So we don't want any parser to hook up all events for 
firing, and only incremental tree builders to collect them.
"""

That's why I wanted to introduce the wrapper class. The idea was to extend the 
supported methods on the target object by those needed for iterparse(), 
specifically start_ns() and end_ns(). That way, the event callback setup would 
be just natural.


"""
In addition, since iterparse (an existing, stable API of the module) expects a 
parser argument, it won't be easy creating an IncrementalTreeBuilder, because 
how would we let people using custom parsers with iterparse not change any code 
and yet keep things working?
"""

Yep, that's a problem in the original design.

One way to fix it would be to allow changing the parser target after the 
creation of the parser, but before it actually started parsing. That could be 
an entirely internal feature that would then allow injecting the wrapper 
between the parser and the target after the fact. 

Given that the current support for using different parsers in iterparse() is 
pretty much non-existant, requiring the applicable parsers to support this 
feature would not be a regression, IMHO.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

Thanks for the effort, Stefan, but I still think IncrementalParser is worth 
keeping. It provides functionality that doesn't currently exist in ET, and IMHO 
this functionality is both important and useful.

Renaming its methods to feed & close kills the API naming inconsistency vs. 
XMLParser and SAX's IncrementalParser. As for future directions, having it does 
not add additional constrains to those that already exist because of iterparse 
accepting a "custom" XMLParser creates compatibility problems already.

For the latter, I think I can also beef up the documentation a bit to be more 
explicit (such as requiring the XMLParser provided to iterparse to derive from 
ET.XMLParser; otherwise, it just won't have the required _setevents).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

I attached a patch that removes the IncrementalParser class and merges its 
functionality into the _IterParseIterator. It thus retains most of the 
refactoring without adding new functionality and/or APIs.

I did not take a look if anything else from later changes needs to be reverted, 
neither did I update the documentation. I guess the newly added doc sections 
can just be deleted.

One thing that is still dubious is the requirement for the _setevents() method 
on the parser instance. That was already a flaw before Antoine's change, 
although it only hit if the C parser was used. It now affects both the Python 
parser and the C parser. It's not a regression because code that relies on it 
not being used is broken when it is being used. However, we should be aware 
that we are promoting a quirk to a visible API here. I don't see it as a real 
problem, given that it's an internal API (and thus an implementation detail), 
that's why I left it in. It should eventually be replaced by a proper setup 
based on the parser target.

--
Added file: http://bugs.python.org/file31460/remove_IncrementalParser.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Eli Bendersky]

Eli Bendersky added the comment:

Looking at this more, the Parser/Builder abstraction in ET leaks badly, 
especially when it comes to incremental parsing. This manifests in (at least) 
two ways:

1. The parser accepted by iterparse has to use the ET-provided TreeBuilder, 
because the C implementation of TreeBuilder has undocumented fields and hooks 
used directly by the parser.
2. Even though iterparse & IncrementalParser accept a "parser" argument, it 
cannot be just any parser. This parser (in addition to using the ET 
TreeBuilder) must implement an undocumented and obscure _setevents method; this 
makes the original intent of the abstraction - hooking up arbitrary parsers to 
the interface, hard to follow.

To *really* fix this, all these capabilities have to be exposed as APIs. 
TreeBuilder has to support an explicit API for collecting and reporting events. 
XMLParser has to call into this API and either not have _setevents at all or 
have something public and documented. Note also that event hookup in the parser 
makes sense in a way, because we don't want events to be fired when not needed 
(for performance). So we don't want any parser to hook up all events for 
firing, and only incremental tree builders to collect them. So things aren't 
quite *so* simple. In addition, since iterparse (an existing, stable API of the 
module) expects a parser argument, it won't be easy creating an 
IncrementalTreeBuilder, because how would we let people using custom parsers 
with iterparse not change any code and yet keep things working?

--

Since the above presents considerable changes in the internals, to get *really* 
right - we do have a problem for the upcoming release because I'm not sure if 
anyone has the time or will to do it. However, the feature is interesting and 
useful, and the code is cleaner than it used to be. So I propose the following 
compromise that can serve us for the 3.4 release:

IncrementalParser stays, but its methods will be renamed to feed & close, which 
is consistent with the current XML parsing APIs (including 
xml.sax.xmlreader.IncrementalParser). In a future release, we may decide to 
create a IncrementalTreeBuilder anyway but then IncrementalParser can be 
layered on top of it and offered as a convenience.

--

To conclude, I don't think that when looked at as exposing an implementation 
detail of iterparse, IncrementalParser is so horrible. iterparse is already its 
own kind of thing somewhat alien to ET, but it's very useful and important. 
IncrementalParser is just replacing iterparse's "parse whole source" behavior 
with incremental feeds followed by a close. This is similar to the APIs 
xml.sax.xmlreader is exposing, so there is a consistency here. Solving "all the 
implementation problems" would certainly be great, but unfortunately no one 
seems to have time for this at the moment.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message when passed a non-string delimiter

[R. David Murray]

R. David Murray added the comment:

I forgot to address the comment about accepting bytes in python3: the delimiter 
really is a unicode character.  In python3, non-ASCII delimiters are handled 
correctly.  So no, it isn't a byte anymore, it really is a string.  Terry's 
comment about 'char' in the other issue does not apply to Python3.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message when passed a non-string delimiter

[R. David Murray]

R. David Murray added the comment:

I agree that the 2.7 message is somewhat confusing, but I'm not sure it is 
worth changing at this point in 2.7's life cycle.  

For Python3, the message is correct and unambiguous: a bytes object is not a 
string.

However, in 3.3, we have a regression:

rdmurray@hey:~/python/p34>python3.3 -c 'import csv; reader = csv.reader("foo", 
delimiter=b",")'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: delimiter must be set

So that needs to be tracked down and fixed.

--
keywords: +3.3regression, easy
nosy: +r.david.murray
stage:  -> needs patch
title: csv produces confusing error message for unexpected string encoding -> 
csv produces confusing error message when passed a non-string delimiter
versions: +Python 3.3, Python 3.4 -Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13397] Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions

[Donald Stufft]

Donald Stufft added the comment:

-1

This essentially gives the ability for an XMLRPC server to crash any python 
code that interfaces with them unless you catch _every_ single exception 
including ones like SystemExit, KeyboardInterupt, SyntaxError, StopIteration 
etc.

An XMLRPC server is not a trusted resources and providing this option is akin 
to providing an option to unpickle arbitrary data received over the wire as 
well.

--
nosy: +dstufft

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13397] Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions

[Claudiu.Popa]

Claudiu.Popa added the comment:

Here's a basic patch. I have two issues with it: the flag name used for 
enabling the exceptions seems too verbose (use_python_exceptions, I'm opened to 
new suggestions) and I don't know if the fallback to Fault exception if the 
remote exception is not known is the best way.

--
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file31459/xmlrpc_builtin.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18323] 'GzipFile' object has no attribute 'extrastart'

[Gökcen Eraslan]

Changes by Gökcen Eraslan :


--
nosy: +gkcn

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)

[Christian Heimes]

Christian Heimes added the comment:

Does somebody want to write a test for the issue, too?

--
resolution:  -> fixed
stage: patch review -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)

[Roundup Robot]

Roundup Robot added the comment:

New changeset d5334d8907dc by Christian Heimes in branch '3.3':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/d5334d8907dc

New changeset 8345fb616cbd by Christian Heimes in branch 'default':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/8345fb616cbd

New changeset 8eac75276e5b by Christian Heimes in branch '2.7':
Issue #11973: Fix a problem in kevent. The flags and fflags fields are now
http://hg.python.org/cpython/rev/8eac75276e5b

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18829] csv produces confusing error message for unexpected string encoding

[Thibault Kruse]

New submission from Thibault Kruse:

To reproduce

$ python --version
Python 2.7.3
$ python -c 'from __future__ import unicode_literals; import csv; reader = 
csv.reader("foo", delimiter=",")'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: "delimiter" must be an 1-character string

This is confusing because "," is like a 1-character (unicode) string, while csv 
requires a 1-character (byte) string. In python3, it's the inverse problem, 
using bytestring b','

$ python3 --version
Python 3.2.3
$ python3 -c 'import csv; reader = csv.reader("foo", delimiter=b",")'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: "delimiter" must be an 1-character string


So I believe csv should state more clearly what went wrong here in each case, 
or what kind of string csv is willing to accept in the respective python 
version.

Whether the python3 refusal to use a bytestring is even reasonable I don't know.

This might or might not be related to the issue of multichar delimiters: 
http://bugs.python.org/issue15158  (just sayin)

--
components: Library (Lib)
messages: 196126
nosy: Thibault.Kruse
priority: normal
severity: normal
status: open
title: csv produces confusing error message for unexpected string encoding
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18828] urljoin behaves differently with custom and standard schemas

[Mher Movsisyan]

New submission from Mher Movsisyan:

>>> urljoin('redis://localhost:6379/0', '/1')
'/1'
>>> urljoin('http://localhost:6379/0', '/1')
'http://localhost:6379/1'

--
messages: 196125
nosy: mher.movsisyan
priority: normal
severity: normal
status: open
title: urljoin behaves differently with custom and standard schemas
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11973] kevent does not accept KQ_NOTE_EXIT (and other (f)flags)

[Christian Heimes]

Christian Heimes added the comment:

The patch looks good to me.

--
nosy: +christian.heimes
versions: +Python 3.4 -Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18747] Re-seed OpenSSL's PRNG after fork

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8b962e831ff0 by Christian Heimes in branch '3.3':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/8b962e831ff0

New changeset 7b1da249ab6d by Christian Heimes in branch 'default':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/7b1da249ab6d

New changeset 3f30c281eb1c by Christian Heimes in branch '2.7':
Issue #18747: Fix spelling errors in my commit message and comments,
http://hg.python.org/cpython/rev/3f30c281eb1c

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Christian Heimes]

Christian Heimes added the comment:

Tiger has OpenSSL 0.9.7 which doesn't support IPv6 addresses. I have added a 
workaround.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 004743d210e4 by Christian Heimes in branch '3.3':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/004743d210e4

New changeset 577e9402cadd by Christian Heimes in branch 'default':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/577e9402cadd

New changeset 1cd24ea5abeb by Christian Heimes in branch '2.7':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/1cd24ea5abeb

New changeset 50803d881a92 by Christian Heimes in branch '2.6':
Issue #18709: Fix issue with IPv6 address in subjectAltName on Mac OS X Tiger
http://hg.python.org/cpython/rev/50803d881a92

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly

[Drekin]

Drekin added the comment:

Why are there actually more codepaths which may raise this issue? My naive idea 
would be that input() is just thin wrapper around sys.stdout.write() (for 
prompt) and sys.stdin.readline() which leads to sys.stdin.buffer.raw.read* 
where is the place where some low level OS-dependent function to actually get 
input from user is called (unistd.read or GNU readline or whatever). And also 
there is the place where the waiting for KeyboardInterrupt on Windows should 
occur.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17234] python-2.7.3-r3: crash in visit_decref()

[Ramchandra Apte]

Ramchandra Apte added the comment:

> Here is one stacktrace I just got with the faulthandler installed. It does 
> not show in the trace any 3rd-party module so can I conclude it is a core 
> python bug? Just recompiling with "-ggdb" so eventually will have better 
> stacktraces.

I'm a C noob but I think one can't conclude that it is a core python bug as the 
ref count could have been messed with, then sometime later the error may occur 
and GDB's stacktrace will show the latter.
Or in pseudo-code:

mess_with_ref_count() # In 3rd party code
non_3rd_party_code() #the error may occur here, after the refcount was messed 
with, and gdb will show this function in the stack trace

BTW, run ./configure with the --with-pydebug option, that makes Python perform 
extra checks on refcounts and other things [0]

^0 http://docs.python.org/devguide/setup.html#compiling-for-debugging

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17234] python-2.7.3-r3: crash in visit_decref()

[Martin Mokrejs]

Martin Mokrejs added the comment:

Hi Ramchandra and Christian,
  I am using numpy, matplotlib, expat/cElementTree, doing a lot of os.Popen 
calls. But I think the problem is taht I have huge lists and when I do not need 
them I do del(_mylist) in the code ASAP. That probably causes a lot of churn.

  Here is one stacktrace I just got with the faulthandler installed. It does 
not show in the trace any 3rd-party module so can I conclude it is a core 
python bug? Just recompiling with "-ggdb" so eventually will have better 
stacktraces.




  Does this help? I don't have the gdb stacktrace as I recompiled the binary 
now again ... :(

Fatal Python error: 
/mnt/1TB/var/tmp/portage/dev-lang/python-2.7.5-r2/work/Python-2.7.5/Objects/dictobject.c:1009
 object at 0x40c0a60 has negative ref count -1
Fatal Python error: Aborted

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18819] tarfile fills devmajor and devminor fields even for non-devices

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +lars.gustaebel
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18643] implement socketpair() on Windows

[Charles-François Natali]

Changes by Charles-François Natali :


Added file: http://bugs.python.org/file31458/sendall_write.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18643] implement socketpair() on Windows

[Charles-François Natali]

Charles-François Natali added the comment:

Alright, I think I know what's happening.

The Python implementation uses a TCP socket, whereas the native
implementation uses AF_UNIX socket.
The maximum size of data that can be written to a socket without
blocking is given by its send/receive buffers.
On Linux, the default buffer sizes are set by:
net.core.(r|w)mem_default

but for TCP sockets, its set by:
net.ipv4.tcp_(r|w)mem

So on your machine, you probably have tcp_(r|w)mem quite larger than
(r|w)mem, so the sendall test doesn't write enough data to the socket
to block.

The solution is simply to increase the amount of data written.
Could you try the attached patch?

If it works I'll commit it, because the test isn't really reliable
(i.e. it could fail on a machine with a large (r|w)mem_default).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

"""
1. Why have the "event builder" wrap a tree builder? Can't it just be a 
separate target?
"""

You need a TreeBuilder in order to build the tree for the events.

If you want to use a different target than a TreeBuilder, you're free to do so. 
That's the idea of wrapping.


"""
2. Instead of the stock XMLParser recognizing the event builder via isinstance 
and giving it special treatment, would it not be better to still have a 
separate class that implements the XMLParser interface (it can derive from it 
or just use duck typing)?
"""

Why would you want to restrict it to an XMLParser? If there was an HTMLParser 
(which exists in lxml.etree), then how would you make the two interact?

The isinstance() check was only a quick way to get the API working without 
changing the implementation in the back too much. The actual functionality 
should (eventually) be moved into the target itself. Currently, it is 
implemented internally in the parser inside of the C module. That's the main 
problem with the current implementation that needs fixing. See issue #17902 
(which is not a documentation issue but a real issue, BTW).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Donald Stufft]

Changes by Donald Stufft :


--
nosy: +dstufft

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18808] Thread.join returns before PyThreadState is destroyed

[Charles-François Natali]

Charles-François Natali added the comment:

The first patch looks good, as for the second one, it'll take some time :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12869] PyOS_StdioReadline is printing the prompt on stderr

[Drekin]

Drekin added the comment:

Related stackoverflow question: 
http://stackoverflow.com/questions/18419787/where-does-pythons-interactive-prompt-output-to
 .

--
nosy: +Drekin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18709] SSL module fails to handle NULL bytes inside subjectAltNames general names (CVE-2013-4238)

[Charles-François Natali]

Charles-François Natali added the comment:

The test is failing on Tiger buildbots:

"""
==
FAIL: test_parse_cert_CVE_2013_4238 (test.test_ssl.BasicSocketTests)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_ssl.py", line 
230, in test_parse_cert_CVE_2013_4238
('IP Address', '2001:DB8:0:0:0:0:0:1\n'))
AssertionError: Tuples differ: (('DNS', 'altnull.python.org\x... != (('DNS', 
'altnull.python.org\x...

First differing element 4:
('IP Address', '')
('IP Address', '2001:DB8:0:0:0:0:0:1\n')

  (('DNS', 'altnull.python.org\x00example.com'),
   ('email', 'n...@python.org\x00u...@example.org'),
   ('URI', 'http://null.python.org\x00http://example.org'),
   ('IP Address', '192.0.2.1'),
-  ('IP Address', ''))
+  ('IP Address', '2001:DB8:0:0:0:0:0:1\n'))

--
"""

http://buildbot.python.org/all/builders/x86 Tiger 
3.x/builds/6829/steps/test/logs/stdio

--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com