[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Ross Lagerwall]

Ross Lagerwall added the comment:

It's caused by the following check in _posixsubprocess.c:
if (close_fds && errpipe_write < 3) {  /* precondition */
PyErr_SetString(PyExc_ValueError, "errpipe_write must be >= 3");
return NULL;
}

which was written by Gregory P. Smith in 2010 (adding to nosy list).

I'm not entirely sure why this check is here, presumably its due to the way 
close_fds=True is handled.

The close fds logic is also hardcoded to close fds from 3 upwards,.

--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue15804] Feature request, implicit "except : pass"

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage:  -> committed/rejected

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
nosy: +cjerdonek

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Nick Coghlan]

Nick Coghlan added the comment:

I'd just write it with @contextmanager. Making it easier to cleanly factor out 
exception handling is one of the main reasons that exists.

  @contextmanager
  def ignored(*exceptions):
"""Context manager to ignore particular exceptions"""
try:
yield
except exceptions:
pass

While the class based version would likely be fractionally faster, the 
generator based version is more obviously correct.

--

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Raymond Hettinger]

Raymond Hettinger added the comment:

Yes, something along those lines would be *much* better:

class Ignore:
''' Context manager to ignore particular exceptions'''

def __init__(self, *ignored_exceptions):
self.ignored_exceptions = ignored_exceptions

def __enter__(self):
return self

def __exit__(self, exctype, excinst, exctb):
return exctype and issubclass(exctype, self.ignored_exceptions)

--

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Alex Gaynor]

Alex Gaynor added the comment:

Why not just: issubclass(exctype, self.exception_types)?

--

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Raymond Hettinger]

Raymond Hettinger added the comment:

Hmm, the __exit__ method was doing exact matches by exception type, so KeyError 
wouldn't match LookupError or Exception.

There are probably a number of ways to fix this, but it may be easiest to use 
the builtin exception catching mechanisms:

class Ignore:
''' Context manager to ignore particular exceptions'''

def __init__(self, *ignored_exceptions):
self.ignored_exceptions = ignored_exceptions

def __enter__(self):
return self

def __exit__(self, exctype, excinst, exctb):
if exctype is not None:
try:
raise
except self.ignored_exceptions:
return True

--

___
Python tracker 

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

[issue15805] Add stdout redirection tool to contextlib

[Nick Coghlan]

Nick Coghlan added the comment:

Sure, but by targeting a specific use case you can make it really trivial to 
use.

--

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex

___
Python tracker 

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

[issue15805] Add stdout redirection tool to contextlib

[Alex Gaynor]

Alex Gaynor added the comment:

Sounds like a special case of a small part of mock. Not sure that this 
observation is significant though.

--
nosy: +alex

___
Python tracker 

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

[issue15806] Add context manager for the "try: ... except: pass" pattern

[Raymond Hettinger]

New submission from Raymond Hettinger:

It is a somewhat common pattern to write:

   try:
   do_something()
   except SomeException:
   pass

To search examples in the standard library (or any other code base) use:

$ egrep -C2 "except( [A-Za-z]+)?:" *py  | grep -C2 "pass"

In the Python2.7 Lib directory alone, we find 213 examples.

I suggest a context manager be added that can ignore specifie exceptions.  
Here's a possible implementation:

class Ignore:
''' Context manager to ignore particular exceptions'''

def __init__(self, *ignored_exceptions):
self.ignored_exceptions = ignored_exceptions

def __enter__(self):
return self

def __exit__(self, exctype, excinst, exctb):
return exctype in self.ignored_exceptions

The usage would be something like this:

with Ignore(IndexError, KeyError):
print(s[t])

Here's a real-world example taken from zipfile.py:

def _check_zipfile(fp):
try:
if _EndRecData(fp):
return True # file has correct magic number 
   
except IOError:
pass
return False

With Ignore() context manager, the code cleans-up nicely:

def _check_zipfile(fp):
with Ignore(IOError):
return bool(EndRecData(fp))  # file has correct magic number

return False

I think this would make a nice addition to contextlib.

--
assignee: ncoghlan
messages: 169337
nosy: ncoghlan, rhettinger
priority: low
severity: normal
status: open
title: Add context manager for the "try: ... except: pass" pattern
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

[issue15805] Add stdout redirection tool to contextlib

[Nick Coghlan]

Nick Coghlan added the comment:

We actually use a variant of this idea in the test suite 
(http://docs.python.org/dev/library/test#test.support.captured_stdout)

It would be pretty easy to combine the two concepts by defaulting the 
redirection to a new StringIO instance if no other destination is given:

print('This goes to stdout')
with redirect_stdout(sys.stderr):
 print('This goes to stderr')
 print('So does this')
print('This goes to stdout')
with redirect_stdout() as s:
 print('This goes to the io.StringIO instance "s"')
 print('So does this')
print('This goes to stdout')

--

___
Python tracker 

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

[issue15805] Add stdout redirection tool to contextlib

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> ncoghlan
nosy: +ncoghlan
priority: normal -> low

___
Python tracker 

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

[issue15805] Add stdout redirection tool to contextlib

[Raymond Hettinger]

New submission from Raymond Hettinger:

The technique of temporarily redirecting stdout could be encapsulated in a 
context manager.

print('This goes to stdout')
with RedirectStdout(sys.stderr):
 print('This goes to stderr')
 print('So does this')
print('This goes to stdout')

The print function already supports redirection but it much be done for every 
single call to print().  The context manager let's the redirection apply to a 
batch of statements.

The context manager is also useful with existing tools that don't currently 
provide output redirection hooks:

   from collections import namedtuple
   with open('model.py', 'w') as module:
   with RedirectStdout(module):
namedtuple('Person', ['name', 'age', 'email'], verbose=True)


   import dis
   with open('disassembly.txt', 'w') as f:
   with RedirectStdout(f):
dis.dis(myfunc)


A possible implementation is:

class RedirectStdout:
''' Create a context manager for redirecting sys.stdout
to another file.
'''
def __init__(self, new_target):
self.new_target = new_target

def __enter__(self):
self.old_target = sys.stdout
sys.stdout = self.new_target
return self

def __exit__(self, exctype, excinst, exctb):
sys.stdout = self.old_target

--
components: Library (Lib)
messages: 169335
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add stdout redirection tool to contextlib
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

[issue15751] Support subinterpreters in the GIL state API

[Nick Coghlan]

Nick Coghlan added the comment:

Currently, both PyGILState_Ensure and PyGILState_Release just call 
PyFatal_Error if anything goes wrong. With the *Ex versions, it would be 
possible to replace those fatal errors with more conventional error handling.

For Ensure, the likely error is failing to create the thread state.

For Release, the likely error is calling it with the system in the wrong state.

I think the current API reflects a difference between an extension mindset and 
an embedding mindset. If those calls go wrong in an extension context, killing 
the entire application is likely the only thing you can reasonably do. In an 
embedded context, though, the embedding application likely has other options 
(such as reinitialising the entire Python interpreter).

--

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Graham Dumpleton]

Graham Dumpleton added the comment:

So you are saying that as user of this I am meant to call it as:

PyGILState_INFO info;

PyGILState_EnsureEx(interp, &info);
...
PyGILState_ReleaseEx(&info);

What is the potential error code from PyGILState_EnsureEx() considering that 
right now for PyGILState_Ensure() it is a value passed back into 
PyGILState_Release().

--

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Nick Coghlan]

Nick Coghlan added the comment:

No, those wouldn't change at all. However, after thinking about it further, I'm 
leaning back towards the option of an EnsureEx/ReleaseEx pair that allows the 
previous interpreter to be reported and restored along with the GIL state. I'd 
also like to make the state an opaque structure that isn't exposed in the 
limited API. Something along the lines of:

typedef struct _gilinfo {
PyGILState_STATE  lock_state;
PyInterpreter *active;
} PyGILState_INFO;

int /* Allow returning an error code */
PyGILState_EnsureEx(PyInterpreterState *target,
PyGILState_INFO*prev);

void
PyGILState_ReleaseEx(PyGILState_INFO *prev);

This allows various issues related to implicitly creating thread states to be 
handled the same way they are now, where PyThreadState_New will create a 
persistent thread state, while PyGILState_EnsureEx will either use a 
preexisting thread state for the requested interpreter (if it exists), or 
implicitly create one. Implicitly created thread states would be destroyed by 
the corresponding call to ReleaseEx.

To make this work, I believe all that should be needed is for:

1. PyInterpreterState updated to include a per-interpreter TLS key
2. _PyGILState_NoteThreadState would update both the autoTLSkey entry and the 
per-interpreter key entry
3. PyGILState_EnsureEx added to support switching the autoTLSkey entry to point 
to a different thread state (creating it if needed)
4. PyGILState_Ensure updated to map to PyGILState_EnsureEx(NULL) and to extract 
the lock state from the info structure
5. PyGILState_Release updated to populate the info structure with the active 
interpreter and the passed in previous GIL state before calling 
PyGILState_ReleaseEx
5. PyThreadState_Delete and PyThreadState_DeleteCurrent updated to also clobber 
the per-interpreter TLS key entry

PyThreadState_New already calls _PyGILState_NoteThreadState implicitly, so 
Python created threads (and embedded threads with an explicitly created thread 
state) should do the right thing automatically.

Making the INFO struct an opaque token also means it can be expanded to cover 
any future needs that arise.

--

___
Python tracker 

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

[issue15804] Feature request, implicit "except : pass"

[Benjamin Peterson]

Benjamin Peterson added the comment:

Please submit your idea to the python-ideas list.

--
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Graham Dumpleton]

Graham Dumpleton added the comment:

Nick. Valid point.

I guess I hadn't been thinking about case of one thread calling out of one 
interpreter and then into another, as I don't do it in mod_wsgi and even I 
regard doing that as partly evil.

Does that mean this switch interpreter call somehow gets used in the 
Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS.

--

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Nick Coghlan]

Nick Coghlan added the comment:

The reason I'm proposing going back to the original SwitchInterpreter idea is 
because the EnsureEx idea doesn't nest cleanly - if your thread is already 
associated with "interpreter A", you can't readily call into "interpeter B", 
because the API provides no way to correctly restore the associated interpreter 
back to interpreter A when you're done.

EnsureEx works fine if extension modules are not aware of multiple interpreters:

   /* Embedding application (GIL always unlocked) */
   gilstate = PyGILState_EnsureEx(interp_A);
 /* Python code and extension code happens */
   /* Callback needs to reach back into Python */
   cb_gilstate = PyGILState_Ensure();
 /* Callback runs */
   PyGILState_Release(cb_gilstate);
 /* Python code and extension code unwinds */
   PyGILState_Release(gilstate);

However, it *doesn't* work (at least, not easily) if the extension itself wants 
to call back into an interpreter other than the one already associated with the 
current thread:

   /* Embedding application (GIL always unlocked) */
   gilstate = PyGILState_EnsureEx(interp_A);
 /* Python code and extension code happens */
   /* Callback needs to reach back into a specific interpreter */
   cb_gilstate = PyGILState_EnsureEx(interp_B);
 /* Callback runs */
   PyGILState_Release(cb_gilstate);
 /* Python code and extension code unwinds */
   PyGILState_Release(gilstate);

Does that second call to EnsureEx fail? If it succeeds, how does the client 
know which interpreter to use for the PyGILState_Release call? It could be made 
to work if PyGILState_STATE was changed from an enum to a struct that included 
in interpreter state pointer, or if EnsureEx returned a different type and was 
paired up with a new ReleaseEx pointer.

However, that's starting to get very messy compared to a separate 
SwitchInterpreter call:

   /* Embedding application (GIL always unlocked) */
   old_interp = PyGILState_SwitchInterpreter(interp_A);
   /* "autoTLSkey" now refers to a thread state for interpreter A */
   gilstate = PyGILState_Ensure();
 /* Python code and extension code happens */
   /* Callback needs to reach back into Python */
   pre_cb_interp = PyGILState_SwitchInterpreter(interp_B);
   /* "autoTLSkey" now refers to a thread state for interpreter B */
   cb_gilstate = PyGILState_Ensure();
 /* Callback runs */
   PyGILState_Release(cb_gilstate);
   PyGILState_SwitchInterpreter(pre_cb_interp);
   /* "autoTLSkey" again refers to a thread state for interpreter A */
 /* Python code and extension code unwinds */
   PyGILState_Release(gilstate);
   PyGILState_SwitchInterpreter(old_interp);

And yes, I'm pondering ways that this could be used to implement Rust-style 
"channels" for communication between interpreters without needing to copy data, 
by using this API to create proxy interfaces for accessing an object owned by 
another subinterpreter.

--

___
Python tracker 

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

[issue15804] Feature request, implicit "except : pass"

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

No way this is going to be in 2.7.

--
nosy: +jcea
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

[issue15804] Feature request, implicit "except : pass"

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, this is already easy to do with decorators:

>>> class Pass:
def __init__(self, exc):
self.exc = exc
def __enter__(self):
return self
def __exit__(self, exctype, excinst, exctb):
return exctype == self.exc


>>> with Pass(IndexError):
'hello'[10]

--
nosy: +rhettinger
priority: normal -> low

___
Python tracker 

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

[issue15804] Feature request, implicit "except : pass"

[gd2shoe]

New submission from gd2shoe:

I'm constantly finding myself writing itty-bitty try blocks like such:

process stuff
try : someSubProcess.kill()
except : pass
process stuff

I realize this isn't a rigorous use of except, but it's good enough for a vast 
majority of what I need it for.  Still, it adds excess verbiage and makes code 
slightly harder to read.

All I need except to do most of the time is suppress exceptions.  I think the 
language could be enhanced by making the except clause implicit.

the above would become:

process stuff
try : someSubProcess.kill()
process stuff

The intent remains clear.  The code is cleaner and easier to read.

This does not happen often in rigorous code, but grep does find 3 counts in 
standard modules and 9 counts in numpy.  I'm certain most prototype code (like 
mine) would greatly benefit.  (My current 300 line project uses 4 so far.)

--
components: Interpreter Core
messages: 169326
nosy: gd2shoe
priority: normal
severity: normal
status: open
title: Feature request, implicit "except : pass"
type: enhancement
versions: Python 2.7, Python 3.4

___
Python tracker 

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

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

[Nick Coghlan]

Nick Coghlan added the comment:

I agree it's an acceptable risk for 3.3.0. Most third party decimal operations 
simply won't accept an explicit context argument at all - avoiding the need to 
pass the current context around explicitly is the whole point of it being 
stored in the thread locals.

However, I still think it would be better if consistency with the Python API 
could be restored for 3.3.1. If that's done via a more general "this value 
means the arg is actually missing" C API that can be made public in 3.4, so 
much the better.

--

___
Python tracker 

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

[issue15803] Incorrect docstring on ConfigParser.items()

[Nathan Trapuzzano]

New submission from Nathan Trapuzzano:

The docstring on ConfigParser.items() is self-evidently bass ackwards. Fix is 
in attached patch.

--
components: Library (Lib)
files: cpython.patch
keywords: patch
messages: 169324
nosy: nbtrap
priority: normal
severity: normal
status: open
title: Incorrect docstring on ConfigParser.items()
type: enhancement
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27041/cpython.patch

___
Python tracker 

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

[issue15802] Illegal test for mailbox

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15800] Closing of sys.std* files in gzip test.

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

[Chris Jerdonek]

Chris Jerdonek added the comment:

I updated the patch to fix the test_zipimport_support tests.  All tests now 
pass.  The only changes were to Lib/test/test_zipimport_support.py.

I'll make a note about test_pyclbr and test_zipimport_support when I create the 
issue to move the supporting doctest files into a subdirectory.  Thanks again 
for the catch, David.

--
Added file: http://bugs.python.org/file27040/issue-14649-6.patch

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[Roundup Robot]

Roundup Robot added the comment:

New changeset c58789634d22 by Victor Stinner in branch 'default':
Issue #15785: Modify window.get_wch() API of the curses module: return a
http://hg.python.org/cpython/rev/c58789634d22

--

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

bitdancer proposes (on IRC) a better doc for get_wch():

"Get a wide character. Return a character for most keys, or an integer for 
function keys, keypad keys, and other special keys."

We may also replace "and so on" by "and other special keys" in getkey() 
definition.

--

___
Python tracker 

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

[issue15801] Weird string interpolation behaviour

[Erik Allik]

Erik Allik added the comment:

Respectable reaction time.

--

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

@simpkins: can you please try my patch?

--

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

bitdancer tested the patch version 3 for me and it fails: unget_wch(KEY_UP) 
inserts the character U+0103 (259, à) instead of KEY_UP in get_wch() buffer. 
unget_wch() cannot be used to insert key codes, only classic keys like letters.

So I removed the patch version 3 and restored patch version 2 which only 
changes the get_wch() API and adapts the existing unit test.

--

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file27039/curses_get_wch-3.patch

___
Python tracker 

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

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

[Chris Jerdonek]

Chris Jerdonek added the comment:

> With your patch 5 applied, test_zipimport_support fails.

You're right.  It looks like test_zipimport_support is tightly coupled to 
test_doctest.  For example--

http://hg.python.org/cpython/file/786d9516663e/Lib/test/test_zipimport_support.py#l94

My apologies for not running the full test suite before uploading those 
patches.  I'll take a closer look.

--

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

Changes by STINNER Victor :


Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

> Perhaps you should simply remove the new function, and re-add it in 3.4 when 
> you've thought it out a bit more.

Python 3 forces somehow to use Unicode, and the Unicode support of the curses 
module in Python 3.2 is incomplete or broken (see . Many issues have been fixed 
in Python 3.3. It would be a regression to remove get_wch(), it's an important 
function to use the curses module with Python 3.

Changes between Python 3.2 and 3.3:
http://docs.python.org/dev/whatsnew/3.3.html#curses

--

___
Python tracker 

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

[issue14649] doctest.DocTestSuite error misleading when module has no docstrings

[R. David Murray]

R. David Murray added the comment:

With your patch 5 applied, test_zipimport_support fails.  I took a quick look 
at this and it looks like it is because we've added a dependency on an external 
data file to the test for DocTestSuite.

Note that with patch 4 applied, test_pyclbr fails...I found that out by 
accident.  Not sure why test_zipimport_support didn't fail with that one.  But 
regardless we'll have to deal with pyclbr if/when we isolate the doctest test 
files.

--

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

New patch with a test for this specific issue.

(It's not easy to me to write a patch because my version of libncurses doesn't 
work with integers bigger than 128...)

--
Added file: http://bugs.python.org/file27039/curses_get_wch-3.patch

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file27038/curses_get_wch-2.patch

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

window.get_wch() has been added by the issue #6755, and curses.unget_wch() by 
#12567. Copy the nosy of the issue #6755.

--
nosy: +Nicholas.Cole, akuchling, cben, gpolo, inigoserna, jcea, phep, 
python-dev, r.david.murray, schodet, zeha

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[Antoine Pitrou]

Antoine Pitrou added the comment:

Perhaps you should simply remove the new function, and re-add it in 3.4 when 
you've thought it out a bit more.

--
nosy: +pitrou

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

Changes by STINNER Victor :


Removed file: http://bugs.python.org/file27007/curses_get_wch.patch

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

New patch fixing the issue with a better API: window.get_wch()->int or str 
depending on the key (int for key codes, str for other keys).

Oh, I realized that test_curses does also fail on my laptop without the patch. 
My laptop is running Fedora 11 which uses libncurses 5.7. This version is old 
and has known bugs. So the "unget_wch" issue is maybe unrelated.

--
Added file: http://bugs.python.org/file27038/curses_get_wch-2.patch

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Graham Dumpleton]

Graham Dumpleton added the comment:

Sorry, Mark. Is not for associating thread state specified by embedding 
application. In simple terms it is exactly like existing PyGILState_Ensure() in 
that caller doesn't have a thread state, whether it has already been created. 
Only difference is to allow that simplified API to work against a sub 
interpreter.

Nick, I previously said:

"""In the case of the latter, if a Python thread is created in a specific sub 
interpreter, it should automatically designate for that thread that that is its 
interpreter context, so if it calls out and does the Release/Ensure dance, that 
it goes back into the same sub interpreter."""

So yes to your:

"""Thinking about it, I believe there still needs to be a concept of an "active 
thread state" TLS key in order to deal with Graham's original problem. 
Specifically, if PyGILState_EnsureEx is used to associate the thread with a 
particular interpreter, then subsequent calls to PyGILState_Ensure from *that 
thread* should get the explicitly associated interpreter, rather than the main 
interpreter."""

My example was more to do with a thread created in Python then calling out and 
back in, but same deal as foreign thread calling in, out and back in.

Antoine, yes, can possibly can be simplified to that. The original idea of a 
switch interpreter function was suggested on basis that PyGILState_Ensure would 
not be modified or extended version of function created. Rolling an implicit 
switch interpreter into PyGILState_EnsureEx when argument is different to the 
current may serve same purpose.

--

___
Python tracker 

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

[issue15801] Weird string interpolation behaviour

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2801bf875a24 by Benjamin Peterson in branch '2.7':
use the stricter PyMapping_Check (closes #15801)
http://hg.python.org/cpython/rev/2801bf875a24

New changeset 4d431e719646 by Benjamin Peterson in branch '3.2':
use the stricter PyMapping_Check (closes #15801)
http://hg.python.org/cpython/rev/4d431e719646

New changeset 263d09ce3e9e by Benjamin Peterson in branch 'default':
merge 3.2 (#15801)
http://hg.python.org/cpython/rev/263d09ce3e9e

--
nosy: +python-dev
resolution:  -> fixed
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

[issue15802] Illegal test for mailbox

[A.M. Kuchling]

Changes by A.M. Kuchling :


--
nosy:  -akuchling

___
Python tracker 

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

[issue15802] Illegal test for mailbox

[R. David Murray]

R. David Murray added the comment:

Looks right to me on a quick scan, but I'm not familiar with that test.

--
nosy: +petri.lehtinen

___
Python tracker 

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

[issue15802] Illegal test for mailbox

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file27037/test_mailbox_create_tmp-2.7.patch

___
Python tracker 

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

[issue15802] Illegal test for mailbox

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Test for mailbox contains meaningless asserts. Here is a patch that corrects 
testing, if I correctly understand it.

--
components: Tests
files: test_mailbox_create_tmp.patch
keywords: patch
messages: 169307
nosy: akuchling, barry, r.david.murray, storchaka
priority: normal
severity: normal
status: open
title: Illegal test for mailbox
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27036/test_mailbox_create_tmp.patch

___
Python tracker 

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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

[Benjamin Peterson]

Benjamin Peterson added the comment:

This seems to have broken parallel building of modules.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue15799] httplib client and statusline

[karl]

karl added the comment:

Fair enough, it could be a warning when

* more than one space in between http version and status code
* if there is a missing space after the status code


I'm not advocating for being strict only. I'm advocating for giving the tools 
to developer to assess that things are right and choose or not to ignore and 
having to avoid to patch the libraries or rewrite modules when you create code 
which needs to be strict for specifically validating responses and requests. :)

ps: I haven't checked yet if the server counter part of httplib was strict in 
the production rule.

--

___
Python tracker 

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

[issue15801] Weird string interpolation behaviour

[Mike Graham]

Mike Graham added the comment:

Line 13464 of unicodeobject.c is

if (Py_TYPE(args)->tp_as_mapping && !PyTuple_Check(args) &&
!PyUnicode_Check(args))

Too lazy to check, but don't user-created types have a tp_as_mapping? If so, I 
think it mistakes Foo() for a dict.

--
nosy: +Mike.Graham

___
Python tracker 

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

[issue15801] Weird string interpolation behaviour

[R. David Murray]

R. David Murray added the comment:

Didn't get an error in 2.7, either, with Message().

--

___
Python tracker 

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

[issue15801] Weird string interpolation behaviour

[R. David Murray]

R. David Murray added the comment:

That doesn't appear to be true in 3.2.  I happened to test this on 
email.message.Message, and it also did not raise an error, but it defines an 
__str__.

I suspect this is some oddball result of the coercion rules.

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

[issue15801] Weird string interpolation behaviour

[Alex Gaynor]

Alex Gaynor added the comment:

Additional detail, if and only if Foo defines an __str__ method, this raises an 
exception.

--
nosy: +alex

___
Python tracker 

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

[issue15801] Weird string interpolation behaviour

[Erik Allik]

New submission from Erik Allik:

>>> class Foo(object):
... pass
... 
>>> "asdads" % Foo()
'asdads'


Doesn't look like it's supposed to be this way.

As per the documentation:

"If format requires a single argument, values may be a single non-tuple object. 
[5] Otherwise, values must be a tuple with exactly the number of items 
specified by the format string, or a single mapping object (for example, a 
dictionary)."

Tested and confirmed on 2.5, 2.6, 2.7 (both old and new style classes) and 3.2.

--
messages: 169300
nosy: eallik
priority: normal
severity: normal
status: open
title: Weird string interpolation behaviour
type: behavior
versions: Python 2.6, 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

[issue15799] httplib client and statusline

[Antoine Pitrou]

Antoine Pitrou added the comment:

I would point out that the goal of the http module is to provide 
interoperability with real-life servers, rather than be a strict implementation 
of RFCs. So, starting to raise errors for "HTTP/1.1 200" while "HTTP/1.1 200 " 
remains ok might not be the best idea.

--
nosy: +orsenthil, pitrou

___
Python tracker 

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

[issue15799] httplib client and statusline

[R. David Murray]

R. David Murray added the comment:

Why should it raise an error?  The postel principle suggests that we should 
treat it as equivalent to the second line.

--

___
Python tracker 

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

[issue15799] httplib client and statusline

[karl]

karl added the comment:

ok.

status lines 1 and 2 are valid. 
the third one is invalid and should trigger a 

raise BadStatusLine(line)

The code at line 318 is bogus as it will parse happily the third line without 
raising an exception.
http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l318

--

___
Python tracker 

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

[issue15800] Closing of sys.std* files in gzip test.

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

When porting gzip module from Python 2 to Python 3, binary files 
sys.std(in|out) was replaced by sys.std(in|out).buffer in gzip module internal 
testing code (when gzip used as executable). But in one place the replacement 
was skipped. As the result the condition now always true and standard files are 
closed after use.

Here is a patch that fixes this error.

--
components: Library (Lib)
files: gzip_main_close.patch
keywords: patch
messages: 169296
nosy: pitrou, storchaka
priority: low
severity: normal
status: open
title: Closing of sys.std* files in gzip test.
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27035/gzip_main_close.patch

___
Python tracker 

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

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

[Mark Dickinson]

Mark Dickinson added the comment:

I don't really feel that strongly either way, either.  I understand Nick's 
arguments, but can't help feeling that we're letting a doc mistake dictate the 
API here.  (And my inner type-system has an aversion to APIs where arguments 
are expected to be *either* None or of type/interface XXX.)

So colour me -0 on changing cdecimal to allow the 'None' argument.

--

___
Python tracker 

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

[issue15799] httplib client and statusline

[R. David Murray]

R. David Murray added the comment:

Could you explain the error you are seeing in more detail first?  You are talk 
about parsing and fixes here, but I'm not clear on what the actual bug is you 
are reporting.

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

[issue15799] httplib client and statusline

[karl]

New submission from karl:

The current parsing of HTTP status line seems strange with regards to its 
definition in HTTP.

http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l307

Currently the code is 
version, status, reason = line.split(None, 2)

>>> status1 = "HTTP/1.1 200 OK"
>>> status2 = "HTTP/1.1 200 "
>>> status3 = "HTTP/1.1 200"
>>> status1.split(None, 2)
['HTTP/1.1', '200', 'OK']
>>> status2.split(None, 2)
['HTTP/1.1', '200']
>>> status3.split(None, 2)
['HTTP/1.1', '200']

According to the production rules of HTTP/1.1 bis only status1 and status2 are 
valid.

  status-line = HTTP-version SP status-code SP reason-phrase CRLF
  — http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.1.2

with reason-phrase  = *( HTAB / SP / VCHAR / obs-text ) aka 0 or more 
characters.

I'm also not sure what are the expected ValueError with additional parsing 
rules which seems even more bogus.

First modification should be

>>> status1.split(' ', 2)
['HTTP/1.1', '200', 'OK']
>>> status2.split(' ', 2)
['HTTP/1.1', '200', '']

Which would be correct for the first two, with an empty reason-phrase
The third one is still no good.

>>> status3.split(' ', 2)
['HTTP/1.1', '200']

An additional check could be done with 

len(status.split(' ', 2)) == 3

Will return False in the third case.

Do you want me to create a patch and a test for it?

--
messages: 169293
nosy: karlcow
priority: normal
severity: normal
status: open
title: httplib client and statusline
type: enhancement
versions: Python 3.2

___
Python tracker 

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

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

[Stefan Krah]

Stefan Krah added the comment:

I don't want to block this, BTW. Personally I'm +-0 on the issue.

If more people think this is needed for backwards compatibility, I'll
write a patch for localcontext. But I'd rather do that *very* soon.

FWIW, none of the cdecimal users has ever complained about this.

So we have a tie here: Mark thinks it can wait, Nick thinks it's
better to do something.

--

___
Python tracker 

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

[issue15784] OSError.__str__() should distinguish between errno and winerror

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2e587b9bae35 by Richard Oudkerk in branch 'default':
Issue #15784: Modify OSError.__str__() to better distinguish between
http://hg.python.org/cpython/rev/2e587b9bae35

--
nosy: +python-dev

___
Python tracker 

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

[issue14468] Update cloning guidelines in devguide

[Mike Hoy]

Changes by Mike Hoy :


--
nosy: +mikehoy

___
Python tracker 

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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue15794] test_importlib: test_locks failure

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution:  -> fixed
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

[issue15794] test_importlib: test_locks failure

[Roundup Robot]

Roundup Robot added the comment:

New changeset 454dceb5fd56 by Antoine Pitrou in branch 'default':
Issue #15794: Relax a test case due to the deadlock detection's 
conservativeness.
http://hg.python.org/cpython/rev/454dceb5fd56

--
nosy: +python-dev

___
Python tracker 

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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

[Matthias Klose]

Matthias Klose added the comment:

fixed.

--
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

___
Python tracker 

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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1a1d097b17e2 by Matthias Klose in branch '2.7':
- Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target.
http://hg.python.org/cpython/rev/1a1d097b17e2

New changeset 763d188a96bb by Matthias Klose in branch '3.2':
- Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target.
http://hg.python.org/cpython/rev/763d188a96bb

New changeset 3a3fd48a6ef7 by Matthias Klose in branch 'default':
- Issue #15591: Fix parsing MAKEFLAGS in the sharedmods target.
http://hg.python.org/cpython/rev/3a3fd48a6ef7

--
nosy: +python-dev

___
Python tracker 

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

[issue13592] repr(regex) doesn't include actual regex

[Ezio Melotti]

Changes by Ezio Melotti :


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

[issue15591] when building the extensions, stdout is lost when stdout is redirected

[Matthias Klose]

Matthias Klose added the comment:

bah, this happens when you do a parallel build. --jobserver-fds is passed in 
MAKEFLAGS, and the test for sharedmods turns on the quiet mode, because it 
matches just *s* in MAKEFLAGS :-/

The patch tries to parse MAKEFLAGS using getopt, and if getopt is not 
available, falls back to MAKEFLAGS, and then tries to match -s.

The only downside is that you won't get a quiet build, if you don't have 
getopt, and pass MAKEFLAGS options as a combined option (e.g. -fs).

--
keywords: +patch
Added file: http://bugs.python.org/file27034/makeflags.diff

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Antoine Pitrou]

Antoine Pitrou added the comment:

Le mardi 28 août 2012 à 14:12 +, Nick Coghlan a écrit :
> old_interp = PyGILState_SwitchInterpreter(target_interp);
> old_gil = PyGILState_Ensure();
> /* Call into Python using target_interp */
> PyGILState_Release(old_gil);
> PyGILState_SwitchInterpreter(old_interp); /* May not be needed in the 
> mod_wsgi case, since it knows it is making the outermost call into the 
> PyGILState_* APIs */

Why wouldn't it be simply written:

old_gil = PyGILState_EnsureEx(target_interp);
/* Call into Python using target_interp */
PyGILState_Release(old_gil);

--

___
Python tracker 

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

[issue15797] bdist_msi does not pass -install/remove flags to install_script

[B Maqueira]

Changes by B Maqueira :


Added file: http://bugs.python.org/file27033/patch1.diff

___
Python tracker 

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

[issue15775] Add StopParser() to expat

[Nemeskey Dávid]

Nemeskey Dávid added the comment:

loewis: I don't think it would be difficult to fix, so theoretically I'd be in. 
However, I don't really have the time to work on this right now.

--

___
Python tracker 

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

[issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains

[Éric Araujo]

Changes by Éric Araujo :


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

[issue15751] Support subinterpreters in the GIL state API

[Nick Coghlan]

Nick Coghlan added the comment:

Thinking about it, I believe there still needs to be a concept of an "active 
thread state" TLS key in order to deal with Graham's original problem. 
Specifically, if PyGILState_EnsureEx is used to associate the thread with a 
particular interpreter, then subsequent calls to PyGILState_Ensure from *that 
thread* should get the explicitly associated interpreter, rather than the main 
interpreter.

Then, the lookup sequence for "interpreter=NULL" would be:

1. Check the active TLS key, if set, use that thread state
2. If not set, look up the main interpreter's TLS key. If set, also set that on 
the active TLS key and use that thread state.
3. If still not set, create a new thread state on the main interpreter, set it 
for both the active TLS and the main interpreter's TLS key and use that thread 
state

A similar approach almost works when requesting a specific interpreter, but 
where that goes wrong is when the active TLS key is *already set*. You can't 
just overwrite it, because that will cause problems for subsequent 
PyGIL_Release calls. You could just make it an error, but I think Graham's 
original idea makes it possible to do better than that.

Specifically, a PyGILState_SwitchInterpreter API could focus solely on the 
manipulation of the "active thread state" TLS key entry. The sequence of 
commands in mod_wsgi would then look like:

old_interp = PyGILState_SwitchInterpreter(target_interp);
old_gil = PyGILState_Ensure();
/* Call into Python using target_interp */
PyGILState_Release(old_gil);
PyGILState_SwitchInterpreter(old_interp); /* May not be needed in the mod_wsgi 
case, since it knows it is making the outermost call into the PyGILState_* APIs 
*/

All of the other elements of Antoine's proposal (i.e. the per-interpreter TLS 
key entries) would still be needed, it's just that the API for associating a 
thread with an interpreter would remain separated from that of associating the 
thread with a particular thread state.

The big advantage of doing it this way is that it will nest properly, whereas 
PyGILState_EnsureEx would need a more complicated API to correctly report both 
the old interpreter state and the old GIL state within that interpreter.

--

___
Python tracker 

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

[issue11489] json.dumps not parsable by json.loads (on Linux only)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> It's Unicode that considers unpaired surrogates invalid, not UTF-8 by itself.

It's UTF-8 too. See RFC 3629:

   The definition of UTF-8 prohibits encoding character numbers between
   U+D800 and U+DFFF, which are reserved for use with the UTF-16
   encoding form (as surrogate pairs) and do not directly represent
   characters.  When encoding in UTF-8 from UTF-16 data, it is necessary
   to first decode the UTF-16 data to obtain character numbers, which
   are then encoded in UTF-8 as described above.

--
nosy: +storchaka

___
Python tracker 

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

[issue15762] Windows 8 certification

[Martin v . Löwis]

Martin v. Löwis added the comment:

The change you proposed cannot be applied to Python 2.7, or any distutils code 
bases, for a number of reasons:

- it's not clear (and probably not the case) that the proposed command line 
flags are correct for all distutils code. It may well be that some code breaks 
if you use the flags - if they were 100% backwards compatible, Microsoft 
wouldn't have made them separate options.

- distutils is essentially frozen, any change to it requires considerable 
negotiation.

- for Python 2.7 to 3.3, making such a change would be a new feature (to pass 
the Windows 8 certification), which cannot be added to a bug fix release.

So if you insist that this is a distutils bug, I'll re-close the issue as 
"won't fix".

Instead, I suggest to find a way to solve this within py2exe's setup.py, e.g. 
by monkey-patching distutils.msvccompiler.MSVCCompiler with a subclass of 
msvc9compiler.MSVCCompiler.

--
resolution: invalid -> wont fix

___
Python tracker 

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

[issue15775] Add StopParser() to expat

[Martin v . Löwis]

Martin v. Löwis added the comment:

nemeskeyd: would you like to work on a patch (for Python 3.4)?

--
nosy: +loewis

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Mark Hammond]

Mark Hammond added the comment:

To clarify, I wrote:

> can be associated with a thread-state specified by the 
> embedding application 

Where I meant to say:

Can be associated with an interpreter state and corresponding thread-state ...

Or something like that - it's been a while since I've looked at that code.

--

___
Python tracker 

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

[issue14783] Update int() docstring from manual

[Ezio Melotti]

Ezio Melotti added the comment:

.. function:: int(n=0)
  int(s, base=10)

should do the trick.
+1 on using this instead of int([number | string[, base]])

--

___
Python tracker 

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

[issue15751] Support subinterpreters in the GIL state API

[Mark Hammond]

Mark Hammond added the comment:

The GIL state api was mainly interested in the case of a thread which has 
(possibly) never been seen before calling into Python.  IIUC, the proposal here 
is so that a thread that *has* been seen before can be associated with a 
thread-state specified by the embedding application (and the degenerate case 
would be to assume the thread hasn't been seen, and as such should get the 
default interpreter)

If that isn't too wide of the mark, I agree it sounds workable and worthwhile.

--
nosy: +mhammond

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Ezio Melotti]

Ezio Melotti added the comment:

#10806 seems related.

--
components: +Library (Lib)
nosy: +ezio.melotti, pitrou, rosslagerwall
type:  -> behavior

___
Python tracker 

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

[issue15798] subprocess.Popen() fails if 0, 1 or 2 descriptor is closed

[Aleksey Filippov]

New submission from Aleksey Filippov:

System info:
kernel: 3.4.8-1-ARCH
dist: Arch linux
python: 3.2.3

subprocess.Popen() fails if python interpreter is started with closed 0, 1 or 2 
descriptor.

Traceback (most recent call last):
  File "", line 14, in 
  File "/usr/lib/python3.2/subprocess.py", line 745, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.2/subprocess.py", line 1197, in _execute_child
restore_signals, start_new_session, preexec_fn)
ValueError: errpipe_write must be >= 3

--
messages: 169276
nosy: sarum9in
priority: normal
severity: normal
status: open
title: subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
versions: Python 3.2

___
Python tracker 

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

[issue1185124] pydoc doesn't find all module doc strings

[Nick Coghlan]

Nick Coghlan added the comment:

Oops, I somehow ended up looking at an old revision of pydoc.py

The current version *is* using tokenize.open and importlib in synopsis(), so 
those aspects of my comments are incorrect.

However, the point that pydoc should probably be using the tokenize module to 
do the parsing inside source_synopsis remains valid. There's no good reason to 
continue duplicating a subset of that text processing logic within pydoc.

--

___
Python tracker 

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

[issue1185124] pydoc doesn't find all module doc strings

[Nick Coghlan]

Nick Coghlan added the comment:

The standard library has moved on quite a bit since this patch was written...

1. source_synopsis() should be using the tokeniser module when reading the 
docstring. The current implementation is broken in more ways than just those 
noted here (e.g. it completely ignores the declared encoding)

(The reason for not using full compilation is that you would then have to 
either *run* the compiled code or else compile to the AST and interrogate that, 
which is technically implementation dependent)

2. For 3.3+, synopsis should be using importlib to get the source code rather 
than assuming filesystem imports. That's probably better handled in a separate 
issue, though.

--
assignee: ping -> 
nosy: +ncoghlan
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

[Petri Lehtinen]

Changes by Petri Lehtinen :


--
nosy: +pitrou

___
Python tracker 

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

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

[Petri Lehtinen]

Petri Lehtinen added the comment:

Attached a patch for 2.7 that updates docs and docstrings.

--
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file27032/issue13769.patch

___
Python tracker 

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

[issue15785] curses.get_wch() returns keypad codes incorrectly

[STINNER Victor]

STINNER Victor added the comment:

> If the function returned either a single-character unicode string or an
integer
> keycode, this would also make it possible to completely drop the
is_key_code
> part of the return value.  (Callers could simply check the type of the
return
> value to see if it is a keycode.)

I tried to mimic the getkey() function, but I like your idea. In many cases
you don't have to check explicitly the type. Example: if key == "q":
quit(), or if key == curses.KEY_UP: move(1). It works also if the key is
used as a key of a dictionary: key => callback. And yes, keyname() can be
used to mimic manually getkey()  behaviour.

It does not solve unget_wch() issue, but I propose to drop the
unget_wch()+get_wch() test on non-ASCII keys because it looks like a bug in
the curses library.

--

___
Python tracker 

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

[issue14042] json.dumps() documentation is slightly incorrect.

[Petri Lehtinen]

Petri Lehtinen added the comment:

This is a documentation bug for 2.7. Setting as duplicate of #13769.

--
nosy: +petri.lehtinen
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> json.dump(ensure_ascii=False) return str instead of unicode
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue13769] json.dump(ensure_ascii=False) return str instead of unicode

[Petri Lehtinen]

Petri Lehtinen added the comment:

It may also be unicode if the encoding parameter is used even if there are no 
unicode objects in the input.

>>> json.dumps([u'Ş'.encode('iso-8859-9')], encoding='iso-8859-9', 
>>> ensure_ascii=False)
u'["\u015e"]'

--

___
Python tracker 

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

[issue13405] Add DTrace probes

[Samuel John]

Samuel John added the comment:

I did your test. Thank you! 
You are absolutely right, it seems, dtrace does not honor "CPP" or "PATH" or 
any other flags and bluntly looks in a hard-coded location. It's not up to you 
to patch that.

--

___
Python tracker 

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

[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs

[Hynek Schlawack]

Hynek Schlawack added the comment:

Thank you for your contribution Chris!

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

[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs

[Roundup Robot]

Roundup Robot added the comment:

New changeset dc080e19f7aa by Hynek Schlawack in branch '2.7':
#14880: Fix kwargs notation in csv.reader, .writer & .register_dialect
http://hg.python.org/cpython/rev/dc080e19f7aa

--
nosy: +python-dev

___
Python tracker 

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

[issue15783] decimal.localcontext(None) fails when using the C accelerator module

[Stefan Krah]

Stefan Krah added the comment:

Nick Coghlan  wrote:
> Any third party Decimal manipulating function that accepts an
> optional context and passes it down to the standard Decimal API
> will be confronted with the same problem in 3.3: passing None
> as the context no longer means the same thing as omitting the
> context argument entirely.

I agree, but for me the issue is: What is the standard API?

If you look at the Context methods in decimal.py, you see this pattern:

def add(self, a, b):
...
r = a.__add__(b, context=self)


So I think it's reasonably safe to say that all Decimal methods only
take a context=None argument because it happens to be a convenient way
of implementing the Context methods.

With that reasoning, most of the list in msg169144 would be eliminated
already. I sort of regret that the Decimal methods of the C version take
a context argument at all, but the arguments are documented.

Now to localcontext(ctx=None). Yes, code might exist that does the
following:

def f(a, b, context=None):
with localcontext(context):
return a / b


It is, however, a strange function: If I explicitly pass a context to
a function, I'd expect that it is also used for recording any status
that accumulates in the function (or that the function actually *can*
accumulate status at all).


If I'm only interested in the precision, I'd write:

def f(a, b, prec=None):
with localcontext() as c:
c.prec = 9 if prec is None else prec
return Decimal(a) / b


[This is along the lines of Raymond's original suggestion in #15136.]


But there are other examples of unexpected behavior, such as
Decimal.to_eng_string(context) taking a context purely to determine
the value of context.capitals, i.e. no status flags can possibly be
set. Here I'd also prefer:

to_eng_string(capitals=1)

--

___
Python tracker 

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

[issue14880] csv.reader and .writer use wrong kwargs notation in 2.7 docs

[Hynek Schlawack]

Hynek Schlawack added the comment:

It seems correct like that:

static PyObject *
csv_register_dialect(PyObject *module, PyObject *args, PyObject *kwargs)
{
PyObject *name_obj, *dialect_obj = NULL;
PyObject *dialect;

if (!PyArg_UnpackTuple(args, "", 1, 2, &name_obj, &dialect_obj))
return NULL;

Therefore going to commit.

--

___
Python tracker 

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

[issue11489] json.dumps not parsable by json.loads (on Linux only)

[Petri Lehtinen]

Petri Lehtinen added the comment:

Bear in mind that Douglas Crockford thinks a JSON document is valid even if it 
contains unpaired surrogates:

http://tech.groups.yahoo.com/group/json/message/1603
http://tech.groups.yahoo.com/group/json/message/1583

It's Unicode that considers unpaired surrogates invalid, not UTF-8 by itself.

--
nosy: +petri.lehtinen

___
Python tracker 

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