[issue17741] event-driven XML parser

[Stefan Behnel]

Stefan Behnel added the comment:

> Putting _setevents aside for the moment,

Agreed, obviously.


> XMLParser is a clean and simple API. Its output is only "push" (by calling 
> callbacks on the target). It doesn't deal with Elements at all.

We already agreed on that, too. Keep things simple.


> It decomposes the input XML and produces push events. That's it. It doesn't 
> even have to interact with the target to a larger extent than pushing 
> callback calls to it.

It does, though. That's essentially how iterparse works. I.e. the API between 
parser and target that I'm using here is already there. And has been for years. 
And I think that the feature in question shows that this was a particularly 
good design. Thank you Fredrik!


> You propose to add a completely different mode of operation to it, controlled 
> by a constructor flag. In "collect_events mode", XMLParser undergoes a 
> transformation.

We clearly disagree here.


> Coupled with "weird" targets, its semantics become totally unclear.

Try to come up with a patch for your own proposal that avoids that. You will 
notice that you will be using the existing protocol, thus the target will 
continue to be able to do what it wants. If it's a weird target, then it's a 
weird target because the user said so. But it's the target's very own concern 
to do expected things (build a tree) or do weird things (whatever an example 
for this is).

Except when you disallow using user defined targets, but then, that's an 
arbitrary restriction that ignores what is there already.

As long as you want to keep up the existing separation of concern between 
parser and target (and we agreed on that being a good thing), and as long as 
you don't impose arbitrary (and arbitrarily complex) restrictions on user code, 
you will not be able to prevent the target from doing "weird" things that 
impact the events being collected by whatever interface you choose for this. 
And why should you?


> XMLParser is not supposed to be an isolated entity. Users should be able to 
> implement custom parsers that provide its API. When the API is simple - 
> feed/close and some callbacks, replacing/ehnancing/faking it is easy. When 
> the API is complex -- two different modes of operation -- it's considerably 
> more difficult.

That's only true when you use it for incremental event parsing. If you don't, 
that part of the API doesn't have to bother you. If you want to implement a 
custom parser that doesn't support event collection, then simply don't support 
the "collect_events" keyword argument and you're done. Implement read_events() 
by returning an empty iterator, if you like, that's up to you. If you want to 
write a target that prevents parsers from keeping tree fragments alive in 
memory, simply return None from your callback methods and you're done. If you 
want to write a target that changes the Elements that the parser collects, then 
you can do that. Yes, those are actually features. And you could already do 
most of this before.

Remember that it's the users using the parser and providing (or implementing) 
the target. We should let them.


I'm sorry if I sound offensive, but most of what I read as counter arguments in 
this ticket so far was either incomplete or (sometimes) even plain wrong. Some 
seemed pretty close to FUD, but maybe that's just me (and I'm guilty here too, 
I guess - sorry for that). Now, how could this discussion possibly give the me 
impression that everyone has the same level of understanding? Even your comment 
about "weird" targets, right above, after going through all of this discussion, 
makes me wonder if you really know how all of this works.

Please take a closer look at the original code before Antoine changed it. Play 
with the parser targets a bit. That will help you understand this issue better.


Also, if you want to come up with a patch that implements approach 3), i.e. a 
class between parser and target, then please do. I tried it (the incomplete and 
partially fake patch is attached to this ticket), and my take on it is that 
it's too complex and requires some rather non-trivial changes, including user 
visible ones. So, based on that experience, I decided that it would be better 
to keep things simple and integrate the feature more closely with what is there 
anyway. I think it might help if you went through the same experience.

--

___
Python tracker 

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

[issue1565525] tracebacks eat up memory by holding references to locals and globals when they are not wanted

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
keywords: +easy

___
Python tracker 

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

[issue18623] Factor out the _SuppressCoreFiles context manager

[Antoine Pitrou]

Antoine Pitrou added the comment:

> If its a problem with the test I'm guessing it might have to do with how 
> os.WCOREDUMP() decides whether a process has dumped its core or not.

You are right, the status code doesn't seem affected by whether the core file 
was actually dumped or not:

$ ulimit -c
0
$ python -c "import os; os.abort()"; echo $?
Abandon
134
$ ulimit -c unlimited
$ python -c "import os; os.abort()"; echo $?
Abandon (core dumped)
134

And of course:

>>> os.WCOREDUMP(134)
True


I don't think there's any reliable way to test this: modern Linux kernels can 
intercept core file generation and run an executable instead (think Ubuntu's 
apport), so the only thing remaining to do is to just check that the context 
manager "works", i.e. doesn't raise anything.

(see http://linux.die.net/man/5/core "Piping core dumps to a program")

--

___
Python tracker 

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

[issue18849] Failure to try another name for tempfile when directory with chosen name exists on windows

[Vlad Shcherbina]

New submission from Vlad Shcherbina:

When directory exists with a name chosen for new temporary file, OSError with 
EACCESS errno is thrown on windows, while attempts to chose another name only 
happen on EEXIST errors.


To reproduce, run
--- 8< -
import sys
import tempfile
import os

print sys.platform
print sys.version

# Mock random names to ensure collision.
tempfile._RandomNameSequence = lambda: iter(['a', 'a', 'b'])

d = tempfile.mkdtemp()
print d

try:
print tempfile.NamedTemporaryFile().name
finally:
os.rmdir(d)
--- >8 -


Expected result:
win32
2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
...\tmpa
...\tmpb


Actual result:
win32
2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)]
c:\users\shcher~1\appdata\local\temp\tmpa
Traceback (most recent call last):
  File "hz.py", line 13, in 
print tempfile.NamedTemporaryFile().name
  File "C:\python_27_amd64\files\lib\tempfile.py", line 454, in 
NamedTemporaryFile
(fd, name) = _mkstemp_inner(dir, prefix, suffix, flags)
  File "C:\python_27_amd64\files\lib\tempfile.py", line 235, in _mkstemp_inner
fd = _os.open(file, flags, 0600)
OSError: [Errno 13] Permission denied: 
'c:\\users\\shcher~1\\appdata\\local\\temp\\tmpa'

--
components: Library (Lib), Windows
messages: 196269
nosy: Vlad.Shcherbina
priority: normal
severity: normal
status: open
title: Failure to try another name for tempfile when directory with chosen name 
exists on windows
type: behavior

___
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:

The whole point of the new API is not to replace XMLParser, but to
provide a convenience API to set up a particular combination of an
XMLParser with a particular kind of custom target. It just happens
that actually *implementing it* that way doesn't work right with the
current code. It is *not* necessary (or even appropriate) for it to
serve as a new building block, but as a convenience API to compose
*existing* building blocks in a particular way (or should be, except
that composition doesn't currently work right).

Once the underlying deficiencies are fixed, then the event capturing
target can be exposed directly, but in the meantime, the *composed*
version can be exposed by relying on internal APIs.

We could call the new class XMLParserWithEventCapturingTarget, but
that's a little clumsy :)

--

___
Python tracker 

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

[issue17908] Unittest runner needs an option to call gc.collect() after each test

[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

[issue18850] xml.etree.ElementTree accepts control chars.

[Michele Orrù]

New submission from Michele Orrù:

Got from irc; 
 python bug in xml.etree.ElementTree, from version 2.7 to 3.2 
http://www.reddit.com/r/Python/comments/1l6cta/python_bug_in_xmletreeelementtree/

I think we should keep consistency with lxml and forbid control chars in 
advance. 


Attaching the test file proving the issue, slightly modified to work on 2.7 and 
3.x

--
files: test.py
messages: 196271
nosy: maker
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree accepts control chars.
Added file: http://bugs.python.org/file31482/test.py

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Michele Orrù]

Changes by Michele Orrù :


--
components: +Library (Lib), XML
type:  -> behavior

___
Python tracker 

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

[issue18623] Factor out the _SuppressCoreFiles context manager

[Charles-François Natali]

Charles-François Natali added the comment:

The test works for me. The only problem is that faulthandler dumps a
stack: it might be better to use subprocess with stderr=devnull).

As for the status code, it looks like a bash bug:
"""
$ cat /tmp/test_core.py
import os

if os.fork() == 0:
os.abort()
else:
pid, status = os.waitpid(-1, 0)
print("%d: %s" % (status, os.WCOREDUMP(status)))
$ python /tmp/test_core.py
134: True
$ ulimit -c 0
$ python /tmp/test_core.py
6: False
$ python -c "print(0x80 | 6)"
134
"""

And it's funny, because bash does detect the coredump generation, compare:
"""
$ python -c "import os; os.abort()"; echo $?
Abandon
134
"""

to

"""
$ python -c "import os; os.abort()"; echo $?
Abandon (core dumped)
134
"""

I had a quick look at the code, and indeed there's a bug: there's a
function rebuilding the exit status from the exit code:

"""
static int
process_exit_status (status)
 WAIT status;
{
  if (WIFSIGNALED (status))
return (128 + WTERMSIG (status));
  else if (WIFSTOPPED (status) == 0)
return (WEXITSTATUS (status));
  else
return (EXECUTION_SUCCESS);
}
"""

Unfortunately, adding 128 sets the coredump flag every time,
regardless of the actual coredump status.
Never thought I'd encounter such a bug in bash :-)

--

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[Andrew Svetlov]

Andrew Svetlov added the comment:

Looks good but review comments worth to be applied or rejected with reasonable 
note.

--
nosy: +asvetlov

___
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:

> The whole point of the new API is not to replace XMLParser, but to provide a 
> convenience API to set up a particular combination of an XMLParser with a 
> particular kind of custom target.

Ok, but I'm saying that we don't need that. It's all there, it all comes 
together at the interfaces of the parser. The two-way communication between 
parser and target already exists and is used by iterparse().

So, what I'm advocating is that we should not complicate the module interface 
with a new class (and eventually two classes) at all. Instead, we should just 
expose the *existing* interface of the parser in two ways, once as callbacks 
and once as collected events. I find that much easier to explain than any of 
the other proposals I've seen so far.

This is really not about doing it this way because it's technically too 
difficult to do differently. It's about keeping things simple for users and 
well integrated with what's there.

BTW, Eli asked for working code before we discuss. I've provided it. Now I 
would like to see working code for the proposed three-level design in order to 
make sure it actually works and feels right. I've already said that I've tried 
it and it didn't feel right. We can continue to discuss hot air for another 
month or two, or we can stick to discussing real code and real APIs.

--

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[Matt McClure]

Matt McClure added the comment:

Andrew,

I didn't understand your message. Are you asking me to change the patch 
somehow? Or asking Michael to review and apply it?

Best,
Matt

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +eli.bendersky, scoder, serhiy.storchaka
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

[issue18849] Failure to try another name for tempfile when directory with chosen name exists on windows

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +georg.brandl, ncoghlan, serhiy.storchaka

___
Python tracker 

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

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

[Jan-Wijbrand Kolman]

New submission from Jan-Wijbrand Kolman:

An internal library that heavily uses subprocess.Popen() started failing its 
automated tests when we upgraded from Python 2.7.3 to Python 2.7.5. This 
library is used in a threaded environment. After debugging the issue, I was 
able to create a short Python script that demonstrates the error seen as in the 
failing tests.

This is the script (called "threadedsubprocess.py"):

===
import time
import threading
import subprocess

def subprocesscall():
p = subprocess.Popen(
['ls', '-l'],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
)
time.sleep(2) # simulate the Popen call takes some time to complete.
out, err = p.communicate()
print 'succeeding command in thread:', threading.current_thread().ident

def failingsubprocesscall():
try:
p = subprocess.Popen(
['thiscommandsurelydoesnotexist'],
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
)
except Exception as e:
print 'failing command:', e, 'in thread:', 
threading.current_thread().ident

print 'main thread is:', threading.current_thread().ident

subprocesscall_thread = threading.Thread(target=subprocesscall)
subprocesscall_thread.start()
failingsubprocesscall()
subprocesscall_thread.join()
===

Note: this script does not exit with an IOError when ran from Python 2.7.3. It 
does fail at least 50% of the times when ran from Python 2.7.5 (both on the 
same Ubuntu 12.04 64-bit VM).

The error that is raised on Python 2.7.5 is this:

==
/opt/python/2.7.5/bin/python ./threadedsubprocess.py 
main thread is: 139899583563520
failing command: [Errno 2] No such file or directory 139899583563520
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/opt/python/2.7.5/lib/python2.7/threading.py", line 808, in 
__bootstrap_inner
self.run()
  File "/opt/python/2.7.5/lib/python2.7/threading.py", line 761, in run
self.__target(*self.__args, **self.__kwargs)
  File "./threadedsubprocess.py", line 13, in subprocesscall
out, err = p.communicate()
  File "/opt/python/2.7.5/lib/python2.7/subprocess.py", line 806, in communicate
return self._communicate(input)
  File "/opt/python/2.7.5/lib/python2.7/subprocess.py", line 1379, in 
_communicate
self.stdin.close()
IOError: [Errno 9] Bad file descriptor

close failed in file object destructor:
IOError: [Errno 9] Bad file descriptor
==

When comparing the subprocess module from Python 2.7.3 to Python 2.7.5 I see 
the Popen()'s __init__() call indeed now explicitly closes the stdin, stdout 
and stderr file descriptors in case executing the command somehow fails. This 
seems to be an intended fix applied in Python 2.7.4 to prevent leaking file 
descriptors (http://hg.python.org/cpython/file/ab05e7dd2788/Misc/NEWS#l629).

The diff between Python 2.7.3 and Python 2.7.5 that seems to be relevant to 
this issue is in the Popen __init__():

==
@@ -671,12 +702,33 @@
  c2pread, c2pwrite,
  errread, errwrite) = self._get_handles(stdin, stdout, stderr)

-self._execute_child(args, executable, preexec_fn, close_fds,
-cwd, env, universal_newlines,
-startupinfo, creationflags, shell,
-p2cread, p2cwrite,
-c2pread, c2pwrite,
-errread, errwrite)
+try:
+self._execute_child(args, executable, preexec_fn, close_fds,
+cwd, env, universal_newlines,
+startupinfo, creationflags, shell,
+p2cread, p2cwrite,
+c2pread, c2pwrite,
+errread, errwrite)
+except Exception:
+# Preserve original exception in case os.close raises.
+exc_type, exc_value, exc_trace = sys.exc_info()
+
+to_close = []
+# Only close the pipes we created.
+if stdin == PIPE:
+to_close.extend((p2cread, p2cwrite))
+if stdout == PIPE:
+to_close.extend((c2pread, c2pwrite))
+if stderr == PIPE:
+to_close.extend((errread, errwrite))
+
+for fd in to_close:
+try:
+os.close(fd)
+except EnvironmentError:
==

Note: I think to see a similar change in the subprocess.Popen() __init__() from 
Python-3.3.0 to Python-3.3.1.

--
components: Library (Lib)
messages: 196276
nosy: janwijbrand
priority: normal
severity: normal
status: open
title: subprocess's Popen closes stdout/stderr filedescriptors used in another 
thread when Popen errors
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker 

__

[issue18850] xml.etree.ElementTree accepts control chars.

[Stefan Behnel]

Stefan Behnel added the comment:

This is a bit tricky in ET because it generally allows you to stick anything 
into the Element properties (and that's a feature). So catching this at tree 
building time (as lxml.etree does) isn't really possible.

However, at least catching it in the serialiser should be possible and would 
help. Regexes for well-formed tag names and text could do the job.

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Michele Orrù]

Michele Orrù added the comment:

you mind if I try by myself to provide patch and unittest in the next few days?

--

___
Python tracker 

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

[issue18800] Document Fraction's numerator and denominator properties

[Madison May]

Madison May added the comment:

The docs page does mention, however, that Fraction inherits from 
numbers.Rational, and links to that page 
(http://docs.python.org/2/library/numbers.html#numbers.Rational). There the 
properties 'numerator' and 'denominator' are clearly documented.  Perhaps its 
still worth it to mention those properties on the Fraction docs page though, or 
to include them in one of the examples.

--
nosy: +madison.may

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Stefan Behnel]

Stefan Behnel added the comment:

Go for it. That's usually the fastest way to get things done.

--

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[Andrew Svetlov]

Andrew Svetlov added the comment:

Matt, I've added new patch.

Will commit it after tomorrow if nobody object.

--
Added file: http://bugs.python.org/file31483/issue11798.diff

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[Michael Foord]

Michael Foord added the comment:

Go ahead and commit. The functionality and patch are good.

--

___
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

[R. David Murray]

R. David Murray added the comment:

Unless I'm completely misunderstanding (which I don't think I am), this is not 
a race condition, it is how the language is designed to operate.  The change 
you are proposing is a language-design level change that would require a PEP.  
The appropriate place to discuss this the is the python-ideas list.

I'm going to close this issue.  If you get a positive response on python-ideas, 
you can reopen it with a link to the discussion.

--
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

[issue18848] In unittest.TestResult .startTestRun() and .stopTestRun() methods don't work

[R. David Murray]

Changes by R. David Murray :


--
nosy: +michael.foord

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[R. David Murray]

R. David Murray added the comment:

Unless it is a security issue, this seems like the kind of fix that shouldn't 
be applied to maintenance releases.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue18851] subprocess's Popen closes stdout/stderr filedescriptors used in another thread when Popen errors

[R. David Murray]

Changes by R. David Murray :


--
nosy: +gregory.p.smith, pitrou
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

[issue18852] Problem with pyreadline

[Thomas Heller]

New submission from Thomas Heller:

In site.py, line 477, I find this code:

# Reading the initialization (config) file may not be enough to set a
# completion key, so we set one first and then read the file
if 'libedit' in getattr(readline, '__doc__', ''):
readline.parse_and_bind('bind ^I rl_complete')

I am using pyreadline on Windows, where readline.__doc__ is None.

So the above code crashes with this exception:

Python 3.4.0a1 (v3.4.0a1:46535f65e7f3, Aug  3 2013, 22:57:30) [MSC v.1600 64 
bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "C:\Python34-64\lib\site.py", line 477, in register_readline
if 'libedit' in getattr(readline, '__doc__', ''):
TypeError: argument of type 'NoneType' is not iterable

--
components: Library (Lib)
keywords: 3.3regression
messages: 196285
nosy: theller
priority: normal
severity: normal
status: open
title: Problem with pyreadline
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

[issue18850] xml.etree.ElementTree accepts control chars.

[Michele Orrù]

Michele Orrù added the comment:

I suppose it is, David, if in 2 minutes flat I can change your terminal name.

--
Added file: http://bugs.python.org/file31484/inject.py

___
Python tracker 

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

[issue18852] Problem with pyreadline

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +pitrou

___
Python tracker 

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

[issue18848] In unittest.TestResult .startTestRun() and .stopTestRun() methods don't work

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +ezio.melotti, pitrou

___
Python tracker 

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

[issue18848] In unittest.TestResult .startTestRun() and .stopTestRun() methods don't work

[Michael Foord]

Michael Foord added the comment:

It is the TextTestRunner that calls startTestRun and stopTestRun not the suite. 

The documentation could be improved to make that clear *or* the call could be 
moved into the TestSuite as not everybody uses the TextTestRunner. That would 
be a change in behaviour though.

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[R. David Murray]

R. David Murray added the comment:

In that case, the fix needs to be applied to 3.2 and 2.6 as well.  Or at least 
considered for application.  It could be that this will break working (though 
dangerous) programs.  I'll leave it to folks more knowledgeable in this 
particular area than I to decide where the severity/backward compatibility line 
lies in this case.

--
stage:  -> needs patch
type: behavior -> security
versions: +Python 2.6, Python 3.2

___
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:

> Unless I'm completely misunderstanding (which I don't think I am), this is 
> not a race condition, it is how the language is designed to operate.

If it is intended not to be able to catch all exceptions and prevent a 
traceback being showed this should be indeed a PEP.

--

___
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'm sorry if I sound offensive, but most of what I read as counter
> arguments in this ticket so far was either incomplete or (sometimes) even
> plain wrong. Some seemed pretty close to FUD, but maybe that's just me (and
> I'm guilty here too, I guess - sorry for that). Now, how could this
> discussion possibly give the me impression that everyone has the same level
> of understanding? Even your comment about "weird" targets, right above,
> after going through all of this discussion, makes me wonder if you really
> know how all of this works.
>
> Please take a closer look at the original code before Antoine changed it.
> Play with the parser targets a bit. That will help you understand this
> issue better.
>

Ah, awesome. Well, you can't say I didn't warn you, can you?

I am done discussing this issue with you, Stefan.

--

___
Python tracker 

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

[issue18853] Got ResourceWarning unclosed file when running Lib/shlex.py demo

[Vajrasky Kok]

New submission from Vajrasky Kok:

The python is compiled with --with-pydebug flag.

[sky@localhost cpython]$ cat /tmp/quote.txt 
manly "man" likes 'cute "cat"'
[sky@localhost cpython]$ ./python Lib/shlex.py /tmp/quote.txt 
Token: 'manly'
Token: '"man"'
Token: 'likes'
Token: '\'cute "cat"\''
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/tmp/quote.txt' 
mode='r' encoding='UTF-8'>

Attached the patch to close the file when running the demo.

--
components: Library (Lib)
files: fix_resource_warning_shlex_test.patch
keywords: patch
messages: 196291
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got ResourceWarning unclosed file when running Lib/shlex.py demo
type: resource usage
versions: Python 3.4
Added file: 
http://bugs.python.org/file31485/fix_resource_warning_shlex_test.patch

___
Python tracker 

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

[issue18854] is_multipart and walk should document their treatment of 'message' parts.

[R. David Murray]

New submission from R. David Murray:

A 'message' part is not, in fact, a multipart in RFC terms.  (Only 'multipart' 
messages are multiparts.)  The email package models 'message' parts by making 
them single-element "multipart" messages, with the single element being a 
Message object representing the 'message' part's payload.

This is very useful; however, the fact that this is done should be documented 
in at least the is_multipart and walk methods.  As motivation for documenting 
this, consider a program that is looking for "the first part of type X" in a 
Message.  If an attached 'message' object has such a part, it would be 
discovered by a naive algorithm that uses 'walk', even though it is *inside* an 
attachment instead of part of the main message.  As for is_multipart, a naive 
reader of the documentation might expect that is_multipart would be true if and 
only if get_content_maintype == 'multipart', when this is in fact not true.

(I made these mistakes myself while implementing get_body and iter_parts in the 
new API additions.)

--
components: email
messages: 196292
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: is_multipart and walk should document their treatment of 'message' parts.
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

[issue18852] site.py does not handle readline.__doc__ being None

[R. David Murray]

R. David Murray added the comment:

I don't think __doc__ can ever not exist, so that code is just wrong :)

--
keywords: +easy
nosy: +r.david.murray
stage:  -> needs patch
title: Problem with pyreadline -> site.py does not handle readline.__doc__ 
being None

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

See also issue7727. Almost any other XML generation code 
(xml.sax.sautils.XMLGenerator, xml.dom.minidom.Element.writexml(), etc, but not 
plistlib.PlistWriter) has the same problem.

The problem with filtering control characters is that it will significantly 
slowdown XML generation.

--

___
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:

Eli, I agree that we've put way more than enough time into the discussion by 
now. We all know each other's arguments and failed to convince each other.

Please come up with working code that shows that the approach you are 
advocating for the final implementation is doable and also helpful from an API 
user's point of view.

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Stefan Behnel]

Stefan Behnel added the comment:

Michele, could you elaborate how you would exploit this issue as a security 
risk?

I mean, I can easily create a (non-)XML-document with control characters 
manually, and the parser would reject it.

What part of the create-to-serialise process exactly is a problem here?

--

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[Andrew Svetlov]

Andrew Svetlov added the comment:

Matt, would you sign licence agreement http://www.python.org/psf/contrib/ ?
The Python Software Fondation is asking all contributors to sign it.
Thanks.

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Michele Orrù]

Michele Orrù added the comment:

> Michele, could you elaborate how you would exploit this issue as a security 
> risk?
Sure. What I meant in my message is: assume you have a script that simply 
stores each message it receives (from stdin, from a tcp stream, whatever) 
inside an xml tree like 
'{message1}{message2}',
and prints the tree on SIGINT.

What I would expect is the xml document not to allow control chars, as 
"restricted and discouraged", and consistent with lxml. 
What instead happens is that the control chars are not handled, and thus 
anybody can send control chars in my terminal. Changing the terminal title is a 
trivial example of those. 

For sure an echo server may have the same issue, but the premises are 
different, because I expect to print just a byte stream.
Mentioning this fact in the documentation may be a possible solution, but I 
believe more that keeping consistency with lxml is the right way.

> I mean, I can easily create a (non-)XML-document with control characters 
> manually, and the parser would reject it.
False? The parser is *not* rejecting control chars.
 
> What part of the create-to-serialise process exactly is a problem here?
ElementTree.tostring().

--

___
Python tracker 

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

[issue18855] Inconsistent README filenames

[Madison May]

New submission from Madison May:

Is there any reason (other than backwards compatibility) that the names of 
README files are inconsistent?

README: 3 instances - root, /Mac, /Misc, /Tools
readme.txt: 2 instances - /PC, /PCbuild
README.txt: 1 instance - /Doc

--
assignee: docs@python
components: Documentation
messages: 196299
nosy: docs@python, madison.may
priority: normal
severity: normal
status: open
title: Inconsistent README filenames

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[Matt McClure]

Matt McClure added the comment:

Andrew,

I signed the agreement as matthewlmcclure and as matthewlmcclure-gmail. Is 
there any way I can merge those two user accounts?

I believe the original patch was Tom Wardill's. I just updated his patch.

--
nosy: +matthewlmcclure

___
Python tracker 

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

[issue11798] Test cases not garbage collected after run

[R. David Murray]

R. David Murray added the comment:

There is no easy way to merge accounts in roundup.  If you've submitted the 
agreement, your "*" should show up in a bit :)

--

___
Python tracker 

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

[issue18783] No more refer to Python "long"

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4d62a62ba44d by Serhiy Storchaka in branch '3.3':
Issue #18783: Removed existing mentions of Python long type in docstrings,
http://hg.python.org/cpython/rev/4d62a62ba44d

New changeset 0872257752c2 by Serhiy Storchaka in branch 'default':
Issue #18783: Removed existing mentions of Python long type in docstrings,
http://hg.python.org/cpython/rev/0872257752c2

--
nosy: +python-dev

___
Python tracker 

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

[issue18783] No more refer to Python "long"

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Ezio and Terry for reviews.

> I presume you thought about it carefully in context.

Yes. Here can be any different types for which instances can be equal (1 == 1L, 
1.0 == 1.0+0.0j).

> This kind of changes are a bit out of place in a patch like this.  They risk 
> to
> introduce subtle problems and might go unnoticed during commit reviews.

I reverted code back to PyErr_SetString.

The only nontrivial changes are in Lib/pickletools.py, 
Lib/test/test_itertools.py and Lib/test/test_long.py (removed redundant 
handling of 'L' suffix in long representation).

--

___
Python tracker 

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

[issue18783] No more refer to Python "long"

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
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

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

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
keywords: +needs review

___
Python tracker 

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

[issue16201] socket.gethostbyname incorrectly parses ip

[Michele Orrù]

Michele Orrù added the comment:

Ping.

--

___
Python tracker 

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

[issue18564] Integer overflow in socketmodule

[Michele Orrù]

Michele Orrù added the comment:

Ping.

--

___
Python tracker 

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

[issue18564] Integer overflow in socketmodule

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ah, haven't you seen Charles-François' comments on the review tool?
Click on the "review" link next to your patch :-)

--

___
Python tracker 

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

[issue16083] HTTPServer does not correctly handle bad request line

[Michele Orrù]

Michele Orrù added the comment:

Still is an issue, though. Exported on the current tip.

--
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file31486/issue16083.1.patch

___
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()

[Vajrasky Kok]

Vajrasky Kok added the comment:

What about if you extend the test coverage as well? Right now, we don't have 
test to test getclasstree method with unique parameter set to false.

--
nosy: +vajrasky

___
Python tracker 

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

[issue18564] Integer overflow in socketmodule

[Michele Orrù]

Michele Orrù added the comment:

oops, didn't see :) thanks.

--

___
Python tracker 

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

[issue18623] Factor out the _SuppressCoreFiles context manager

[Antoine Pitrou]

Antoine Pitrou added the comment:

> As for the status code, it looks like a bash bug:

Your script gives different results here (on Ubuntu):

$ ulimit -c
0
$ ./python dumpcore.py 
6: False
$ ulimit -c unlimited
$ ./python dumpcore.py 
6: False

That's because Ubuntu overrides the core file pattern:

$ cat /proc/sys/kernel/core_pattern 
|/usr/share/apport/apport %p %s %c

If I ask for a regular core file, the script works:

$ sudo sh -c "echo core.%p > /proc/sys/kernel/core_pattern"
$ ./python dumpcore.py 
134: True

Which means the test really threatens to be unreliable (other systems may 
install similar mechanisms by default).

--

___
Python tracker 

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

[issue18856] Added test coverage for calendar print functions

[Madison May]

New submission from Madison May:

Just redirected stdout to a string io object unittest.mock.patch() to add basic 
test coverage for calendar.py print functions (TextCalendary.prweek(), 
TextCalendar.prmonth(), TextCalendar.pryear(), and format()).

--
components: Tests
files: calendar_print.diff
keywords: patch
messages: 196311
nosy: madison.may
priority: normal
severity: normal
status: open
title: Added test coverage for calendar print functions
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31487/calendar_print.diff

___
Python tracker 

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

[issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix

[Thomas Weißschuh]

Changes by Thomas Weißschuh :


--
nosy: +t-8ch

___
Python tracker 

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

[issue18856] Added test coverage for calendar print functions

[Madison May]

Madison May added the comment:

"...to a string io object USING unittest.mock.patch()..."

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Stefan Behnel]

Stefan Behnel added the comment:

> The parser is *not* rejecting control chars.

The parser *is* rejecting control characters. It's an XML parser. See the 
example in the link you posted.


> assume you have a script that simply stores each message it receives (from 
> stdin, from a tcp stream, whatever) inside an xml tree like 
> '{message1}{message2}',
> and prints the tree on SIGINT.

That's not an XML specific issue. You are printing a byte string here, so 
repr() would be the right thing to use (and is actually being used 
automatically in Py3), instead of plain printing. The fact that you are 
wrapping the content in XML doesn't matter.


>> What part of the create-to-serialise process exactly is a problem here?
> ElementTree.tostring().

What I meant was: at what step of the process from creating an XML tree in 
memory to serialisation is it a problem that the tree contains control 
characters? Because once the data is serialised, it will just be rejected on 
input by any XML parser, and handling bytes data is a thing on its own (e.g. 
you could serialise to UTF16 and the result would contain null bytes - too bad).

It may just be a bad example that you chose here, but I really can't see this 
being a security problem. You are mishandling arbitrary untrusted binary data, 
that's all. Control characters are most likely not the only problem that you 
should guard against.

Unless there is a more dangerous way to exploit this that is actually due to 
XML being used, I'd suggest changing the type from "security" back to 
"behaviour".

--

___
Python tracker 

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

[issue18857] urlencode of a None value uses the string 'None'

[Joshua Johnston]

New submission from Joshua Johnston:

This is strange behavior. When you encode nulls in other languages you don't 
get the string 'null' you usually get an empy string. Shouldn't str(None) == ''?

If not str(None) == 'None' and the string representation of a None value should 
not match a known string

>>> from urllib import urlencode
>>> urlencode({'josh': None})
'josh=None'

--
components: Extension Modules
messages: 196314
nosy: Joshua.Johnston
priority: normal
severity: normal
status: open
title: urlencode of a None value uses the string 'None'
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

[issue18850] xml.etree.ElementTree accepts control chars.

[Stefan Behnel]

Stefan Behnel added the comment:

Or maybe even to "enhancement". The behaviour that it writes out what you give 
it isn't exactly wrong, it's just inconvenient that you have to take care 
yourself that you pass it well-formed XML content.

--

___
Python tracker 

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

[issue18855] Inconsistent README filenames

[Antoine Pitrou]

Antoine Pitrou added the comment:

No reason really. We could standardize all of them on README.txt, perhaps.

--
nosy: +pitrou
priority: normal -> low
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

[issue18857] urlencode of a None value uses the string 'None'

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +orsenthil

___
Python tracker 

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

[issue18857] urlencode of a None value uses the string 'None'

[R. David Murray]

R. David Murray added the comment:

In Python the str of a None value is indeed 'None', just as the str of a True 
value is 'True'.  Unless the protocol to which you are encoding supports null 
values, you shouldn't be using None values in the input to the serialization.  
If you want an empty string in the output, use an empty string in the input.

Now, that said, it seems to me that while it is not (apparently) RFC compliant, 
query strings do have a natural way to support null values: a name without a 
value.  It would therefore be convenient if urlencode supported null values by 
turning something like {'josh': None, 'fred': 'abc'} into:

josh&fred=abc

That is what I would expect it to do, so I'd be in favor of that enhancement.

I note that parse_qs and parse_qsl don't handle this case either, which 
surprises me since I think such value-less query string parameters are fairly 
common.

--
nosy: +r.david.murray
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.4 -Python 2.7

___
Python tracker 

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

[issue18855] Inconsistent README filenames

[Madison May]

Madison May added the comment:

It's obviously low priority, just thought I would mention it.  I found it a bit 
odd that "README" is used, though, since that means users will likely have to 
select the program they want to use to open the file (in Windows, at least).  

It might also be nice to follow the standard distutils idiom. From Éric Araujo 
on issue11913, 

"In packaging/distutils2, the recommended idiom looks like this (in setup.cfg):

[metadata]
description-file = README.whatever"

In other words, README.txt would work nicely.

--

___
Python tracker 

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

[issue18857] urlencode of a None value uses the string 'None'

[Joshua Johnston]

Joshua Johnston added the comment:

Hi David,

That is what I would expect it to do as well. I'm relatively new to Python but 
this is causing all kinds of problems with oauth signing using ims_lti_py as 
well as my own code using urlencode.

--

___
Python tracker 

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

[issue17400] ipaddress should make it easy to identify rfc6598 addresses

[pmoody]

pmoody added the comment:

The problem is that 'shared' describes exactly one network, unless you mean 
that we should try to start 'private' as 'shared'. That's something I really 
don't want to do because it leads to confusion like this.

Do you not think that is_global or is_forwardable (per the iana registry) is 
worthwhile?

--

___
Python tracker 

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

[issue18858] dummy_threading lacks threading.get_ident() equivalent

[Jan Kaliszewski]

New submission from Jan Kaliszewski:

In Python 3.3 threading.get_ident() has been added as a public and documented 
function, but there is no dummy_threading.get_ident():

>>> import threading, dummy_threading
>>> threading.get_ident()
139974728402752
>>> dummy_threading.get_ident()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'get_ident'

By the way: it may be worth to check for other possible inconsistencies between 
avaliable interfaces of threading and dummy_threading.

--
components: Library (Lib)
messages: 196321
nosy: zuo
priority: normal
severity: normal
status: open
title: dummy_threading lacks threading.get_ident() equivalent
type: behavior
versions: 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

[issue17741] event-driven XML parser

[Nick Coghlan]

Nick Coghlan added the comment:

Stefan, your proposed merged design isn't going to happen. Two alternative
ways of using the one class is far more complicated to explain to users
than exposing a helper that composes the existing API components to address
a particular use case (particularly when the helper is hiding the fact that
the theoretical underlying composition doesn't currently work the way it
should according to the public APIs).

As a higher level helper, users that are comfortable with and prefer the
lower level API are then clearly free to ignore. This recasting of the
nature of the API as a composition of the lower level components is a
*direct* response to your concern about it being a capability that the
lower level API should support directly.

You clearly don't like that design choice, but this isn't a democracy.
Arguing further on this point will just be ranting for the sake of ranting,
rather than having any chance of changing Eli's mind as module maintainer.

As far as naming goes, I still think it's better to drop "Parser" from the
name entirely. Call it "XMLEventReader" or something like that. The point
is to use it when you want to get the events out without blocking when no
events have been triggered and don't want to set up your own class to
receive event notifications through the target push API. The docs should
make it clear that this API is "pull only" - if people need callbacks or
other push triggers, then that's still what custom targets are for.

--

___
Python tracker 

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

[issue17400] ipaddress should make it easy to identify rfc6598 addresses

[Nick Coghlan]

Nick Coghlan added the comment:

I'd also be fine with "is_carrier_private", or, as you say, the inverse
"is_global" for "not is_private and not is_carrier_private and not (any of
the other private addresses)" (assuming I understood that suggestion
correctly).

I guess the "is_global" one is the most useful, since that lets you know if
you can send or store that address directly, or if you need to translate it
to a persistent global address somehow.

--

___
Python tracker 

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

[issue18571] Implementation of the PEP 446: non-inheritable file descriptors

[STINNER Victor]

Changes by STINNER Victor :


Added file: http://bugs.python.org/file31488/ca6217fbec85.diff

___
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:

Sorry, Stefan, I missed your last comment before posting mine. It appears
you had already reached the same conclusion I had regarding further high
level design discussion being pointless :)

--

___
Python tracker 

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

[issue18731] Increased test coverage for uu and telnet

[Alex Volkov]

New submission from Alex Volkov:

Okay,

I'm submitting the patch just for uu / test_uu.

I replaced all try/finally statemets with 'with' context, added try..finally 
statement for both test cases.

uu.py, line 61 is exposed by test_encode_osstat_assert -- os.stat is 
duckpunched out of the system, then test case verifies that default 
permissions(666) is written into a file.

I didn't have try...finally statement because I wasn't sure how the test case 
will behave when inner try..finally is triggered, so far the tests seem to 
pass..

--
Added file: http://bugs.python.org/file31489/uu_test_v2.patch

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Martin Mokrejs]

Martin Mokrejs added the comment:

I took a crack from another angle. I converted my application using cython and 
then used gcc. Finally, ran valgrind over the binary. It is not finished yet 
but already spotted plenty of hints.

--
Added file: 
http://bugs.python.org/file31490/python2.7_through_cython_valgrind.txt

___
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:

W.r.t. the summary in http://bugs.python.org/msg196177, after some further chat 
with Nick, a name that sounds good for us for the class is XMLPullParser. It 
has both XML and Parser in it, so the intention is clear. On the other hand, 
Pull works well for analogy with the existing pull API in xml.dom.pulldom, 
*and* suggests that the push API is inactive and gets redirected to a pull API 
(thanks Nick for this insight). 

The method names remain as suggested there.

--

___
Python tracker 

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

[issue18850] xml.etree.ElementTree accepts control chars.

[Martin Mokrejs]

Martin Mokrejs added the comment:

Incidentally I read today 
http://blastedbio.blogspot.co.uk/2012/05/blast-tabular-missing-descriptions.html
 mentioning ^A being used. Maybe that would stop working?

--
nosy: +mmokrejs

___
Python tracker 

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

[issue18571] Implementation of the PEP 446: non-inheritable file descriptors

[Roundup Robot]

Roundup Robot added the comment:

New changeset ef889c3d5dc6 by Victor Stinner in branch 'default':
Issue #18571: Implementation of the PEP 446: file descriptors and file handles
http://hg.python.org/cpython/rev/ef889c3d5dc6

--
nosy: +python-dev

___
Python tracker 

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

[issue18571] Implementation of the PEP 446: non-inheritable file descriptors

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue10115] Support accept4() for atomic setting of flags at socket creation

[STINNER Victor]

STINNER Victor added the comment:

Python 3.4 now uses accept4() internally for socket.socket.accept(), the new 
socket is created non-inheritable. See the PEP 446 for more information (PEP 
implemented in the issue #18571).

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue10115] Support accept4() for atomic setting of flags at socket creation

[STINNER Victor]

Changes by STINNER Victor :


--
versions: +Python 3.4 -Python 3.3

___
Python tracker 

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

[issue12107] TCP listening sockets created without FD_CLOEXEC flag

[STINNER Victor]

STINNER Victor added the comment:

Sockets are now created non-inheritable in Python 3.4. See the PEP 446 for more 
information (PEP implemented in the issue #18571).

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue16946] subprocess: _close_open_fd_range_safe() does not set close-on-exec flag on Linux < 2.6.23 if O_CLOEXEC is defined

[STINNER Victor]

STINNER Victor added the comment:

This issue has been fixed in the implementation of the PEP 446 (issue #18571).

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue17070] PEP 433: Use the new cloexec to improve security and avoid bugs

[STINNER Victor]

STINNER Victor added the comment:

The PEP 446 has been implemented (see issue #18571), this issue can be closed.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Tim Peters]

Tim Peters added the comment:

Did you read Misc/README.valgrind (in the Python tree)?  The warnings you've 
seen so far are probably all nonsense, and README.valgrind explains how to 
avoid getting them.

--

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Martin Mokrejs]

Martin Mokrejs added the comment:

No, I did not know that. Thanks, I did now.


  * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
then rebuild Python
  * Uncomment the lines in Misc/valgrind-python.supp that
suppress the warnings for PyObject_Free and PyObject_Realloc



Why isn't there a configure switch for this? :(

--

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Tim Peters]

Tim Peters added the comment:

I don't know why there isn't a configure switch for this - but then I've never 
used valgrind - LOL ;-)

Other developers use valgrind on Python routinely, though.  So it's unlikely 
you'll find a legitimate problem _in Python_ reported by valgrind.

--

___
Python tracker 

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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Martin Mokrejs]

Martin Mokrejs added the comment:

I was just checking whether configure picked up my --with-pymalloc and 
incidentally saw:

  --with-valgrind Enable Valgrind support

maybe Misc/README.valgrind needs revision and should explain what that does as 
well? ;-)

It should also explain what is one supposed to do with 
Misc/valgrind-python.supp. It becomes clear once one goes to edit that file, 
true. ;-)

--

___
Python tracker 

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

[issue18859] README.valgrind should mention --with-valgrind

[Tim Peters]

New submission from Tim Peters:

In issue 18843 a user noted that Misc/README.valgrind doesn't mention the 
--with-valgrind configure option.  It probably should.  But since I've never 
used valgrind, I'm not the guy to do it ;-)

--
components: Build
messages: 196338
nosy: tim.peters
priority: normal
severity: normal
stage: needs patch
status: open
title: README.valgrind should mention --with-valgrind
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

[issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad byte") at Python-2.7.5/Python/pythonrun.c:1689

[Tim Peters]

Tim Peters added the comment:

I opened issue 18859 about the lack of --with-valgrind info in 
Misc/README.valgrind.  Thanks for noticing!

--

___
Python tracker 

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

[issue18606] Add statistics module to standard library

[janzert]

janzert added the comment:

Seems that the discussion is now down to implementation issues and the PEP is 
at the point of needing to ask python-dev for a PEP dictator?

--
nosy: +janzert

___
Python tracker 

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

[issue18606] Add statistics module to standard library

[Oscar Benjamin]

Oscar Benjamin added the comment:

On Aug 28, 2013 1:43 AM, "janzert"  wrote:
>
> Seems that the discussion is now down to implementation issues and the
PEP is at the point of needing to ask python-dev for a PEP dictator?

I would say so. AFAICT Steven has addressed all of the issues that have
been raised. I've read through the module in full and I'm happy with the
API/specification exactly as it now is (including the sum function since
the last patch).

--

___
Python tracker 

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

[issue18860] Add content manager API to email package

[R. David Murray]

Changes by R. David Murray :


--
dependencies: +Add get_body and iter_attachments to provisional email API

___
Python tracker 

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

[issue18860] Add content manager API to email package

[R. David Murray]

New submission from R. David Murray:

Here is a patch, layered on top of the patch in issue 18785, to add the content 
manager support.  This patch contains only the base ContentManager class, not 
the proposed functional registries.

--
components: email
files: contentmanager.patch
keywords: patch
messages: 196342
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add content manager API to email package
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file31491/contentmanager.patch

___
Python tracker 

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

[issue18780] SystemError when formatting int subclass

[Ethan Furman]

Ethan Furman added the comment:

Okay, simple fix, patch and tests attached.

--
keywords: +patch
nosy: +ncoghlan
stage:  -> patch review
Added file: http://bugs.python.org/file31492/issue18780.stoneleaf.01.patch

___
Python tracker 

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

[issue18861] Problems with recursive automatic exception chaining

[Nikolaus Rath]

New submission from Nikolaus Rath:

Consider this:

$ python3 test_exc.py 
Traceback (most recent call last):
  File "test_exc.py", line 14, in 
fail1()
  File "test_exc.py", line 11, in fail1
fail2()
  File "test_exc.py", line 5, in fail2
raise RuntimeError('Third') from None
RuntimeError: Third

$ cat test_exc.py 
def fail2():
try:
raise RuntimeError('Second')
except RuntimeError:
raise RuntimeError('Third') from None

def fail1():
try:
raise RuntimeError('First')
except:
fail2()
raise

fail1()


Any exception raised in fail2() is the immediate consequence of the 'First' 
exception should thus be chained to the 'First' exception.

However, if somewhere in the call stack under fail2() an exception is caught 
and re-raised from None (to convert between exception types), this also results 
in a loss of the chain to the initial exception.


The correct stacktrace (in my opinion) would be:
Traceback (most recent call last):
  File "test_exc.py", line 9, in fail1
raise RuntimeError('First')
RuntimeError: First

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test_exc.py", line 14, in 
fail1()
  File "test_exc.py", line 11, in fail1
fail2()
  File "test_exc.py", line 5, in fail2
raise RuntimeError('Third')
RuntimeError: Third

--
components: Interpreter Core
messages: 196344
nosy: Nikratio
priority: normal
severity: normal
status: open
title: Problems with recursive automatic exception chaining
type: behavior
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

[issue18861] Problems with recursive automatic exception chaining

[Nikolaus Rath]

Nikolaus Rath added the comment:

The second paragraph should of course read "...consequence of the 'First' 
exception *and* should thus be chained..."

--

___
Python tracker 

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

[issue18862] Implement __subclasshook__() for Finders and Loaders in importlib.abc

[Eric Snow]

New submission from Eric Snow:

It would be helpful to have __subclasshook__() implemented on the finders and 
loaders in importlib.abc, following the approach taken by ABCs in 
collections.abc.  This came up relative to PEP 431, but would be generally 
useful (if only to a limited audience ).

--
components: Library (Lib)
keywords: easy
messages: 196346
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Implement __subclasshook__() for Finders and Loaders in importlib.abc
type: enhancement
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

[issue18859] README.valgrind should mention --with-valgrind

[Tim Peters]

Changes by Tim Peters :


--
keywords: +easy

___
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:

> the push API is inactive and gets redirected to a pull API

Given that this is aimed to become a redundant 'convenience' wrapper around 
something else at a point, I assume that you are aware that the above is just 
an arbitrary restriction due to the fact that the parser does not accept 
arbitrary targets as input.

Also, the refrence to pulldom is a bad one, because pulldom reads data as you 
request it ("pull"). This class creates events based on the data you *push* 
into it. So it's really a push API from the POV of the user, not so much a pull 
API.

Anyway, it should be possible to emulate both this class and the pie-in-the-sky 
three-level API based on what I suggested, so I can't see this addition being a 
problem. I may even end up making the same visual split in lxml.etree 
deliberately, in order to make it clear that this feature only applies to the 
push parser API, i.e. when using feed() and close(), as opposed to what parse() 
and fromstring() use. That would mean that there'd also be a corresponding 
class for the HTMLParser then, and both would inherit from the base parsers and 
thus obviously (and conveniently) accept arbitrary parser targets.

I think I'm ok with adding that class. I liked Greg Ewing's suggestion of 
calling it AsyncParser, though, i.e. AsyncXMLParser. It makes it obvious what 
the use case is and avoids any references to push or pull that will always 
confuse some users, based on what part of the feature they are focussing on in 
their code.

--

___
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

[Charles-François Natali]

Charles-François Natali added the comment:

> If it is intended not to be able to catch all exceptions
> and prevent a traceback being showed this should be indeed a PEP.

You may want to have a look at sys.excepthook.

--
nosy: +neologix

___
Python tracker 

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