[issue14228] SIGINT (Ctrl-C) not caught at startup

[telmich]

New submission from telmich :

Hello,

pressing ctrl-c or having sigint delivered to the python process in its startup 
phase results in random tracebacks displayed.

This is related to issue3137, but actually happening in Python 3.2.2 on 
archlinux.

We noticed this during development of the cdist project 
(http://www.nico.schottelius.org/software/cdist/), where we call a shell via 
subprocess.check_call() which calls us again (under a different name and thus 
different behaviour.

So the call chain is like this:

cdist => /bin/sh -e script => cdist_as_different_name (i.e. __file)

A simple test case to reproduce the problem needs the two files caller.py and 
shellpart.sh in a directory:

% ln -s caller.py __testpython
% chmod a+x *
% ./caller.py 
Indirect child being called
Indirect child being called
Indirect child being called
Indirect child being called
^Ccaught signint in parent
Traceback (most recent call last):
  File "/usr/lib/python3.2/site.py", line 58, in 
import traceback
  File "/usr/lib/python3.2/traceback.py", line 3, in 
import linecache
  File "/usr/lib/python3.2/linecache.py", line 10, in 
import tokenize
  File "/usr/lib/python3.2/tokenize.py", line 28, in 
import re   
  
  File "/usr/lib/python3.2/re.py", line 121, in 
[10:02] brief:python-traceback-test% import functools
  File "/usr/lib/python3.2/functools.py", line 2, in 
"""
KeyboardInterrupt


Pressing Ctrl-C results in various different tracebacks and I don't see any way 
to catch the SIGINT reliably currently, as the code executed seems to be 
*before* my code is being executed.

There is another related bug at debian that references the same problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926

--
files: shellpart.sh
messages: 155152
nosy: telmich
priority: normal
severity: normal
status: open
title: SIGINT (Ctrl-C) not caught at startup
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file24755/shellpart.sh

___
Python tracker 

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

[issue14228] SIGINT (Ctrl-C) not caught at startup

[telmich]

telmich  added the comment:

And here's the actual python code

--
Added file: http://bugs.python.org/file24756/caller.py

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Tshepang Lekhonkhobe]

Tshepang Lekhonkhobe  added the comment:

> Éric Araujo  added the comment:
>> For devguide/documenting, If you show me markup, also show me what output it 
>> gives me.
> Would this really be useful?  If you’re looking at that page, you want to 
> know what markup to use for what situation; why do you care about output?

I want to see how it looks like.

>> It's kinda tedious to keep building the markup just to verify how it's 
>> rendered.
> I’m not sure I understand; if there were example output in the doc, you’d 
> only have to build the devguide once to see how markup is rendered, wouldn’t 
> you?

Yes you didn't understand, sorry for my inadequate explanation.

I want to see how the output of the markup looks like, without having
to do the rendering (running sphinx-build) myself.

--

___
Python tracker 

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

[issue14216] ImportError: No module named binascii

[Ramchandra Apte]

Ramchandra Apte  added the comment:

See http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3.
What it says might be the cause of the problem.

--
nosy: +ramchandra.apte

___
Python tracker 

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

[issue14217] text output pretends to be code

[Tshepang Lekhonkhobe]

Tshepang Lekhonkhobe  added the comment:

> Éric Araujo  added the comment:
>
> Use this:
>
> .. code-block:: none
>
>   output etc.

Thanks much. I've attached a patch.

--
Added file: http://bugs.python.org/file24757/tis-not-code-2.patch

___
Python tracker 

___diff -r b8be6ac4395d Doc/tutorial/classes.rst
--- a/Doc/tutorial/classes.rst  Wed Mar 07 08:55:52 2012 +0100
+++ b/Doc/tutorial/classes.rst  Thu Mar 08 12:03:20 2012 +0200
@@ -180,7 +180,9 @@
scope_test()
print("In global scope:", spam)
 
-The output of the example code is::
+The output of the example code is:
+
+.. code-block:: none
 
After local assignment: test spam
After nonlocal assignment: nonlocal spam
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

[Steven Bethard]

Steven Bethard  added the comment:

> Hence, I conclude that, unless this was spelled out in the PEP and I 
> missed it, that having such boundaries is a bug

Practically speaking, we just can't change this because it will break existing 
argparse scripts. Argparse has had this behavior since 2006 when it was first 
released, and I guarantee you that many scripts expect and rely on this 
behavior.

As I said earlier, the only reasonable solution is to document the current 
behavior more explicitly, and then add a new constructor parameter or method or 
something to enable the behavior you want.

I looked a bit a guilherme's patch, and I think it's not really the right 
direction. We definitely shouldn't be modifying the action classes like 
_StoreAction. All changes should be within _parse_known_args. The parsing 
algorithm is so different for the proposed behavior, that I wonder if it 
wouldn't be easier to just create a new ArgumentParser subclass, 
ArgumentParserAllowingOptionalsInsidePositionals (or whatever), that just 
overrides _parse_known_args and rewrites it entirely.

--

___
Python tracker 

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

[issue14227] console w/ cp65001 displays extra characters for non-ascii strings.

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +haypo, loewis

___
Python tracker 

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

[issue14217] text output pretends to be code

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue14227] console w/ cp65001 displays extra characters for non-ascii strings.

[STINNER Victor]

STINNER Victor  added the comment:

See the issue #1602.

--

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6c218b9c5c4c by Jason R. Coombs in branch '2.7':
Extracted Windows directory detection from NullImporter.__init__. This greatly 
simplifies the code and fixes issue6727.
http://hg.python.org/cpython/rev/6c218b9c5c4c

New changeset 92f4d4eebed1 by Jason R. Coombs in branch '2.7':
Adding regression test for issue6727
http://hg.python.org/cpython/rev/92f4d4eebed1

--
nosy: +python-dev

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Jason R. Coombs]

Changes by Jason R. Coombs :


--
hgrepos:  -104

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I've gone ahead and pushed the changesets for Python 2.7. I'll continue to hold 
off on Python 3.2/3.3 until I can review. Perhaps Brian and I can review these 
changes at PyCon.

--

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Florent Xicluna]

Florent Xicluna  added the comment:

It breaks the compilation on few buildbots.


  Python/import.c:130:14: error: #if with no expression

--
nosy: +flox

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I see that. Thanks. I'm on it.

--

___
Python tracker 

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

[issue6333] logging: ValueError: I/O operation on closed file

[Pekka Klärck]

Pekka Klärck  added the comment:

The same problem that caused problems to py.test caused problems also to Robot 
Framework:
http://code.google.com/p/robotframework/issues/detail?id=1079

I was surprised to notice this issue was closed as invalid although the problem 
didn't occur with Python 2.7 anymore. After a little more digging I noticed 
that the proposed fix has actually been done in r84282 as part of fixing issue 
9051. The fix doesn't check for `closed` attribute but instead silences 
possible ValueError.

We also noticed a variation of the problem: If the registered handler ever 
tries to write anything to its stream you also get an exception. We decided to 
silence all these errors with this code:

import logging
logging.raiseExceptions = False

Finally, I consider it a separate bug that logging.StreamHandler uses 
sys.stderr by default. It should use sys.__stderr__ instead.

--
nosy: +pekka.klarck

___
Python tracker 

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

[issue9408] curses: Link against libncursesw instead of libncurses

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue14228] SIGINT (Ctrl-C) not caught at startup

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Try to enclose the whole code (including the imports) in the try...except 
block. I'm not sure why this matters, though.
If you want Python to have a different return code when terminated by a 
KeyboardInterrupt, then I agree it is a valid feature request.

--
nosy: +pitrou

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Éric Araujo]

Éric Araujo  added the comment:

I don’t understand why you don’t want to build the doc if you want to see what 
the output looks like.  You should build the doc anyway before making a patch 
to make sure there are no errors, and it does not take that long.  As I don’t 
understand your problem, I disagree to making the doc longer for this.

--

___
Python tracker 

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

[issue6333] logging: ValueError: I/O operation on closed file

[Vinay Sajip]

Vinay Sajip  added the comment:

Re. the fix to #9501, the swallowing of exceptions was done for specific 
reasons noted in the comments in the exception clause which does the 
swallowing. This only happens during application shutdown - not all ValueErrors 
on flush() or close() are swallowed. In general, swallowing these will mask 
logic errors which close a stream prematurely.

If you pass a stream to a logging.StreamHandler, make sure you remove the 
handler from any loggers you attached it to, then close it. Otherwise (if you 
just close the underlying stream) the StreamHandler might still try to use it, 
leading to the error. Unattaching the handler and closing it tells logging 
you're done with writing to that stream, so subsequent logging calls won't try 
to write to that stream.

I'm not aware that every file-like object (including duck-typed ones) will have 
a 'closed' attribute, so checking for that may not help.

If you want to set sys.stderr to a StringIO() and then create a StreamHandler 
from it, that's fine. The sequence should be:

set sys.stderr to StringIO instance
create a StreamHandler with sys.stderr
add that handler to a logger

when finished, 

remove that handler from a logger
close the handler (StreamHandler does not close the underlying stream)
restore sys.stderr
close the StringIO instance
access the contents of the StringIO instance using getvalue()

If things are not done in that order, it's possible for arbitrary code (e.g. in 
a 3rd-party library) to log an event, because of which logging then tries to 
write to the stream. If that stream is closed, you get the ValueError - that's 
a warning that something isn't being done correctly, and the answer is not to 
just swallow that exception.

Re. your proposed fix - it may be fine in your specific scenario, but I 
wouldn't recommend it in general because it may mask logic errors in a program.

Regarding your preference for sys.__stderr__ rather than sys.stderr, that's all 
it is - a preference. You can easily pass the exact stream that you want to 
StreamHandler, including sys.__stderr__, so the fact that it picks sys.stderr 
by default shouldn't bother you - just be explicit.

Of course, that default - whatever the rights and wrongs of it - cannot be 
changed without breaking existing code, so it has to stay that way.

--

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Jason R. Coombs]

Jason R. Coombs  added the comment:

The Unix tests are now passing again. Some Windows buildbots are failing 
because they do not have the symlink privilege. I'll add a guard in the test to 
not run it if it doesn't have privilege to symlink.

--

___
Python tracker 

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

[issue14144] urllib2 HTTPRedirectHandler not forwarding POST data in redirect

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I am closing this issue as I feel that the requirement may not be addressed by 
a change. If there is patch for HowTo, we can tackle that in another issue. 
Thank you for contribution.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue6727] ImportError when package is symlinked on Windows

[Brian Curtin]

Brian Curtin  added the comment:

The @support.skip_unless_symlink decorator could be helpful there.

--

___
Python tracker 

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

[issue14228] SIGINT (Ctrl-C) not caught at startup

[telmich]

telmich  added the comment:

This does not change a thing:

Indirect child being called
^CTraceback (most recent call last):
  File "/usr/lib/python3.2/functools.py", line 176, in wrapper
caught signint in parent
result = cache[key]
KeyError: (, '[ 
\\f\\t]*((\\r?\\n|#[^\\r\\n]*|([bB]?[rR]?\'\'\'|[bB]?[rR]?"""))|(([0-9]+[jJ]|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)[jJ])|(([0-9]+\\.[0-9]*|\\.[0-9]+)([eE][-+]?[0-9]+)?|[0-9]+[eE][-+]?[0-9]+)|(0[xX][0-9a-fA-F]+|0[bB][01]+|0[oO][0-7]+|(?:0+|[1-9][0-9]*)))|((\\*\\*=?|>>=?|<<=?|!=|//=?|->|[+\\-*/%&|^=<>]=?|~)|[][(){}]|(\\r?\\n|\\.\\.\\.|[:;.,@]))|([bB]?[rR]?\'[^\\n\']*(?:.[^\\n\']*)*(\'|\\r?\\n)|[bB]?[rR]?"[^\\n"]*(?:.[^\\n"]*)*("|\\r?\\n))|\\w+)',
 32)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.2/site.py", line 58, in 
import traceback
  File "/usr/lib/python3.2/traceback.py", line 3, in 
import linecache
  File "/usr/lib/python3.2/linecache.py", line 10, in 
import tokenize
  File "/usr/lib/python3.2/tokenize.py", line 118, in 
[19:02] brief:python-traceback-test% _compile, (Token, PseudoToken, 
Single3, Double3))
  File "/usr/lib/python3.2/tokenize.py", line 115, in _compile
return re.compile(expr, re.UNICODE)
  File "/usr/lib/python3.2/re.py", line 206, in compile
return _compile(pattern, flags)
  File "/usr/lib/python3.2/re.py", line 255, in _compile
return _compile_typed(type(pattern), pattern, flags)
  File "/usr/lib/python3.2/functools.py", line 180, in wrapper
result = user_function(*args, **kwds)
  File "/usr/lib/python3.2/re.py", line 267, in _compile_typed
return sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 495, in compile
code = _code(p, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 480, in _code
_compile(code, p.data, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 101, in _compile
_compile(code, av[1], flags)
  File "/usr/lib/python3.2/sre_compile.py", line 142, in _compile
_compile(code, av, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 101, in _compile
_compile(code, av[1], flags)
  File "/usr/lib/python3.2/sre_compile.py", line 142, in _compile
_compile(code, av, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 101, in _compile
_compile(code, av[1], flags)
  File "/usr/lib/python3.2/sre_compile.py", line 142, in _compile
_compile(code, av, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 57, in _compile
_compile_charset(av, flags, code, fixup)
  File "/usr/lib/python3.2/sre_compile.py", line 183, in _compile_charset
for op, av in _optimize_charset(charset, fixup):
  File "/usr/lib/python3.2/sre_compile.py", line 253, in _optimize_charset
data = _mk_bitmap(charmap)
  File "/usr/lib/python3.2/sre_compile.py", line 270, in _mk_bitmap
if m > MAXCODE:
KeyboardInterrupt

[19:03] brief:python-trace

--
Added file: http://bugs.python.org/file24758/caller.py

___
Python tracker 

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

[issue14228] SIGINT (Ctrl-C) not caught at startup

[telmich]

telmich  added the comment:

Regarding "feature request": I think this is a *bug*, not a feature request: 
For me, it is impossible to handle SIGINT correctly with my code, because it is 
half-handled (exception raised, but impossible to catch) by python itself.

Imho this behaviour should not be possible. Instead python could do the 
standard sigint behaviour, before reading python code (= exit).

When starting to read "python shipped code" (i.e. stuff that comes with python 
and is always loaded), it should either implement a handler for sigint OR have 
sigint signal handler set to ignore.

As soon as control flow is passed over to user code, raising KeyboardInterrupt 
is fine and I can catch that by enclosing all parts (including import 
statements) into a try: ... block that does what I want.

--

___
Python tracker 

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

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

[Glenn Linderman]

Glenn Linderman  added the comment:

Ah yes, argparse had a life outside the stdlib, so now I understand your 
compatibility concerns.

Mind you, I think the overall technology of argparse is superior to optparse, 
which is why, together with the optparse deprecation, I am trying to port to 
use it... so consider me a fan, not an enemy.  But...

However, it seems that while the esoteric extensions required in optparse were 
a known incompatibility at the time the PEP was written, the incompatibility 
with intermixed positional and optional parameters slipped under the radar... 
but is actually a more serious compatibility problem for general use.

I see three possible ways forward, maybe there are others.

1) un-deprecate optparse, explaining and documenting this functional difference 
between optparse and argparse.  The deprecation of optparse is what makes this 
missing capability a bug, rather than a feature enhancement.

2) add features to argparse to make it capable of parsing all the same command 
lines as unextended optparse. (I'm of the opinion that folks that extended 
optparse can learn to extend argparse in similar or more capable manners; not 
having such extensions, I'm not qualified to state whether there are optparse 
extensions that cannot be ported to use standard or extended argparse 
capabilities.)  The documentation for such features should clearly state that 
former users of argparse may be interested in using this feature, and should 
state why; further, the deprecation notice in optparse should be updated to 
point out that porting to argparse may need to use this particular argparse 
capability to achieve command line compatibility with optparse, and that the 
capability is not available until (specified release).

3) If there is an already existing way (my t14.py is a half-hearted attempt to 
find it) to parse scattered positional parameters, it could be explicitly 
documented rather than writing new capabilities per #2.  However, since you as 
author jumped to the new capabilities option straightway, I suspect this is not 
really a possibility.


The rest of this is concerned option #2, which seems the best way forward to 
me, with my current knowledge.

You mention ArgumentParserAllowingOptionalsInsidePositionals and that is 
extremely lengthy, might I suggest something like  ArgumentParserIntermixed ?

What would be the scope of the effort, and what release(s) might be a possible 
target? (since it is a bug, it can be backported, but since the cure will be 
implemented as a new capability, that might be problematical for point 
releases, somehow? I'm not the expert in that area.)

--

___
Python tracker 

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

[issue14228] SIGINT (Ctrl-C) not caught at startup

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Regarding "feature request": I think this is a *bug*, not a feature
> request: For me, it is impossible to handle SIGINT correctly with my
> code, because it is half-handled (exception raised, but impossible to
> catch) by python itself.

In the trace you just posted, I see "caught signint in parent" (at the
beginning), so the exception was indeed caught.

> When starting to read "python shipped code" (i.e. stuff that comes
> with python and is always loaded), it should either implement a
> handler for sigint OR have sigint signal handler set to ignore.

Well, it does implement a SIGINT handler, and that handler raises
KeyboardInterrupt. QED. You can override that behaviour and register
your own handler using the standard "signal" module.
http://docs.python.org/dev/library/signal.html

--

___
Python tracker 

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

[issue14229] On KeyboardInterrupt, the exit code should mirror the signal number

[Antoine Pitrou]

New submission from Antoine Pitrou :

Compare:

$ ./python -c "import subprocess, signal, time; p = subprocess.Popen(['cat']); 
time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())"
-2

with:

$ ./python -c "import subprocess, signal, time; p = subprocess.Popen(['python', 
'-c', 'input()']); time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())"
Traceback (most recent call last):
  File "", line 1, in 
KeyboardInterrupt
1

Python's behaviour apparently breaks a common assumption towards Unix processes 
(see bug reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926). 
A solution would be to add a signal number attribute to KeyboardInterrupt, and 
use that value when computing the process exit code.

--
components: Interpreter Core
messages: 155174
nosy: loewis, neologix, pitrou
priority: normal
severity: normal
status: open
title: On KeyboardInterrupt, the exit code should mirror the signal number
type: enhancement
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

[issue14228] SIGINT (Ctrl-C) not caught at startup

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Opened issue14229 for the "signal number as exit code" enhancement as mentioned 
on the Debian issue tracker.

--

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Tshepang Lekhonkhobe]

Tshepang Lekhonkhobe  added the comment:

Okay, let me try again:

I want the documentation tutorial to tell me, for example, (1) here is the 
markup for a code block, and (2) here is what it looks like. At the moment, I 
only get (1)... point is I do not want to have to rebuild a reST file each time 
I want to see what some specific markup (e.g. a code block) would look like.

--

___
Python tracker 

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

[issue14229] On KeyboardInterrupt, the exit code should mirror the signal number

[Nadeem Vawda]

Changes by Nadeem Vawda :


--
nosy: +nadeem.vawda

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Éric Araujo]

Éric Araujo  added the comment:

I don’t get why you want to know what it looks like, and then, I don’t get why 
you can’t build the doc or look at docs.python.org.  Also, not getting what you 
talk about re-building: building the devguide or docs once should be enough.

--

___
Python tracker 

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

[issue14220] "yield from" kills generator on re-entry

[Benjamin Peterson]

Changes by Benjamin Peterson :


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

[issue14218] include rendered output in addition to markup

[Éric Araujo]

Éric Araujo  added the comment:

It looks like I have a hard time putting myself in your shoes and seeing what 
you want, so I’m going to shut up for a while and let Ezio and Sandro state 
their opinion on your original request.  :)

--

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Sandro Tosi]

Sandro Tosi  added the comment:

eheh yeah it seems so :)

What I think Tshepang wants is this:

- the devguide contains the description of how to document python
- that documentation is about a set of ReST coding commands that
generate the desired output
- currently the devguide reports only the ReST code block without,
right below to that block, the resulting highlitening.
-> add the resulting "visual" output right below the description of
the code to use.

so something like

blablabla you have to use ``word`` to have the word in bold (or
whatever it generates, I'm too lazy to check :) ) for example:



Tshepang: did I get it correctly? Éric: is it (at least a bit) clearer?

--

___
Python tracker 

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

[issue14218] include rendered output in addition to markup

[Tshepang Lekhonkhobe]

Tshepang Lekhonkhobe  added the comment:

> Sandro Tosi  added the comment:
> Tshepang: did I get it correctly? Éric: is it (at least a bit) clearer?

that's exactly what I tried to convey

--

___
Python tracker 

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

[issue6333] logging: ValueError: I/O operation on closed file

[Pekka Klärck]

Pekka Klärck  added the comment:

@vinay.sajip the problem is that many tools that don't do anything with logging 
module intercept sys.stdout and sys.stderr. Such tools typically aren't even 
aware of libraries they use (or test) using logging and much less about them 
registering StreamHandler using sys.stderr.

It's great that nowadays you don't always get ValueError at exit anymore. Now 
you only get them if the StreamHandler itself tries to use the stream after 
sys.stderr is restored and the intercepting stream closed. Typically this only 
happens in error situations so the problem isn't so severe.

IMHO nobody should ever register StreamHandler with sys.stderr because you 
cannot be sure has someone intercepted it or not. There's a strong convention 
that sys.__stderr__ should not be intercepted so using it is safe.

I strongly believe StreamHandler should be changed to use sys.__stderr__ by 
default. That shouldn't cause problems because a) if sys.stderr isn't 
intercepted sys.stderr is sys.__stderr__, and b) if sys.stderr is intercepted 
you most likely already have problems. I know stuff like this cannot be changed 
other than in major releases and there should perhaps even be a deprecation 
period. I also acknowledge that it might be too much work to be worth the 
effort. Mentioning this issue in the docs might be a good idea nevertheless.

--

___
Python tracker 

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

[issue14230] Delegating generator is not always visible to debugging tools such as inspect & pdb

[Mark Shannon]

New submission from Mark Shannon :

Delegating generators do not show always up in stack traces, such as 
inspect.stack().
The show up during the first delegation, but not thereafter.

I have attached a patch. It alters the way the YIELD_FROM bytecode works; it 
loops back on itself. This ensures the delegator's frame is always in the trace.

Unfortunately I started working on it before Benjamin fixed issue 14220
(rev 3357eac1ba62). By the nature of it, this patch necessarily fixes most of 
issue  14220, so I have just included the tests for issue 14220
in this patch as well.
So in order to apply this, 3357eac1ba62 will have to be backed out.
Sorry for the overlap.

--
components: Interpreter Core
files: yieldfrom.patch
keywords: patch
messages: 155182
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Delegating generator is not always visible to debugging tools such as 
inspect & pdb
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file24759/yieldfrom.patch

___
Python tracker 

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

[issue14220] "yield from" kills generator on re-entry

[Mark Shannon]

Mark Shannon  added the comment:

I've just added issue 14230 which overlaps with this issue somewhat.

--

___
Python tracker 

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

[issue13842] Cannot pickle Ellipsis or NotImplemented

[Łukasz Langa]

Changes by Łukasz Langa :


--
assignee:  -> lukasz.langa
nosy: +lukasz.langa

___
Python tracker 

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

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

[Łukasz Langa]

Changes by Łukasz Langa :


--
assignee:  -> lukasz.langa
nosy: +lukasz.langa

___
Python tracker 

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

[issue8754] quote bad module name in ImportError-like messages

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue6333] logging: ValueError: I/O operation on closed file

[Vinay Sajip]

Vinay Sajip  added the comment:

> IMHO nobody should ever register StreamHandler with sys.stderr because you 

> cannot be sure has someone intercepted it or not. There's a strong 
> convention that sys.__stderr__ should not be intercepted so using it is safe.

Actually, I believe it is reasonable to intercept sys.stderr, even with logging 
in use, because you might be testing that logging actually works in a common 
scenario (use of StreamHandler in the default configuration). To do that, you 
would need to capture sys.stderr and check that its contents contain logged 
messages. For example, the Python test suite contains specific tests which 
intercept (and restore) sys.stderr, for this very purpose.

If one is careful to follow the sequence of events I mentioned in my last 
response, it should be safe to intercept sys.stderr. You only have to remember 
that if you have passed it to logging to use for I/O, logging may try to use it 
at times you don't expect (e.g. because of logging by third-party code). Just 
remove it from logging before you close it, and all will be well. This, of 
course, applies to any stream you pass to logging - not just sys.stderr or a 
replacement for it like a StringIO.

Using sys.__stderr__ is of course doable right now by your code; as you are the 
first one to mention this as desirable, I think it quite likely that people are 
working with the existing default without any problems. So it's unlikely that 
this default will change (as it doesn't need to - you can be explicit about the 
stream you want to use). If there is a lot of adverse feedback about the 
default (unlikely, since it's been there ever since logging was added to Python 
- about 10 years ago) then I will of course reconsider.

--

___
Python tracker 

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

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

[Steven Bethard]

Steven Bethard  added the comment:

Thinking about it a bit more, it strikes me that maybe you could get the 
behavior you want by declaring two parsers, one with just optionals, and one 
with just positionals. Then:

optional_args, remaining_args = optionals.parse_known_args()
args = positionals.parse_args(remaining_args)
vars(args).update(vars(optional_args))

Basically, you first parse out all the optional arguments, then you parse out 
the positional arguments from what's left after the optional arguments are 
stripped out. This approach seems to work for your t14.py.

--

___
Python tracker 

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

[issue14199] Keep a refence to mro in _PyType_Lookup() and super_getattro()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 21e245ed3747 by Victor Stinner in branch 'default':
Close #14199: _PyType_Lookup() and super_getattro() keep a strong reference to
http://hg.python.org/cpython/rev/21e245ed3747

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

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

[Steven Bethard]

Steven Bethard  added the comment:

Actually, that could be even simpler:

args, remaining_args = optionals.parse_known_args()
args = positionals.parse_args(remaining_args, args)

--

___
Python tracker 

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

[issue14211] Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 579f845ac396 by Victor Stinner in branch 'default':
Issue #14211: _PyObject_GenericSetAttrWithDict() keeps a strong reference to
http://hg.python.org/cpython/rev/579f845ac396

--
nosy: +python-dev

___
Python tracker 

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

[issue14211] Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 2cc44cd8098e by Victor Stinner in branch 'default':
Issue #14211: Oops, I removed the wrong file :-)
http://hg.python.org/cpython/rev/2cc44cd8098e

--

___
Python tracker 

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

[issue14231] Fix or drop Lib/test/crashers/borrowed_ref_1.py

[STINNER Victor]

New submission from STINNER Victor :

Lib/test/crashers/borrowed_ref_1.py contains the docstring:
"_PyType_Lookup() returns a borrowed reference.
This attacks the call in dictobject.c."
The file was added by Armin in 2006 by the changeset 4dd1a9383e47.

I just fixed #14211 which was a similar bug 
(Lib/test/crashers/borrowed_ref_2.py), but I'm unable to reproduce this one.

Extract of dict_subscript():

missing = _PyObject_LookupSpecial((PyObject *)mp, 
&PyId___missing__);
if (missing != NULL) {
res = PyObject_CallFunctionObjArgs(missing,
   key, NULL);
Py_DECREF(missing);
return res;
}

I fail to see how missing can be destroyed before being used. Is it a problem 
that missing is destroyed while we are calling it?

How can I trigger the crash in gdb?

--
components: Interpreter Core
messages: 155190
nosy: arigo, haypo
priority: normal
severity: normal
status: open
title: Fix or drop Lib/test/crashers/borrowed_ref_1.py
type: crash
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

[issue14211] Don't rely on borrowed _PyType_Lookup() reference in PyObject_GenericSetAttr()

[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

[issue14231] Fix or drop Lib/test/crashers/borrowed_ref_1.py

[Armin Rigo]

Armin Rigo  added the comment:

Crashes for me on Python 2.5 and 2.6, but no longer on Python 2.7.  The problem 
may have been fixed in the meantime.

--

___
Python tracker 

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

[issue14232] obmalloc: mmap() returns MAP_FAILED on error, not 0

[STINNER Victor]

New submission from STINNER Victor :

Python fails to catch memory allocation error in its memory allocator when 
mmap() is used. Attached patch fixes the issue.

--
components: Interpreter Core
files: obmalloc_map_failed.patch
keywords: patch
messages: 155192
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: obmalloc: mmap() returns MAP_FAILED on error, not 0
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24760/obmalloc_map_failed.patch

___
Python tracker 

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

[issue14231] Fix or drop Lib/test/crashers/borrowed_ref_1.py

[STINNER Victor]

STINNER Victor  added the comment:

Oh, it looks like the following commit fixed the issue without touching to the 
crasher test: ba6376dff6c4. Armin, Benjamin: can you confirm?

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[STINNER Victor]

STINNER Victor  added the comment:

Guido: So, what do you think? Do you like the new behaviour, or would you 
prefer a softer solution like retrying N times? Python < 3.3 retries the lookup 
an unlimited number of times which lead to a crash, that's the issue fixed by 
my change.

--

___
Python tracker 

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

[issue14233] argparse: "append" action fails to override default values

[guilherme-pg]

New submission from guilherme-pg :

Trying to set a default value to arguments whose action is "append" causes 
argparse to raise AttributeError when such arguments are provided in the 
command line (see attached test case t1.py).

This happens because _AppendAction doesn't expect the presence of a default 
value for the argument: when the command line is parsed and the argument is 
found, _AppendAction attempts to append the new value to the list of old 
values, if any, or the old list. In case there is already a non-list default 
value, it attempts to append the new value to it, which raises the exception.

Is this intended behavior? If so, shouldn't ArgumentError be raised instead? It 
should also be easy to fix this issue otherwise, making _StoreAction ensure the 
old values are stored in a list before appending.

--
components: Library (Lib)
files: t1.py
messages: 155195
nosy: bethard, guilherme-pg
priority: normal
severity: normal
status: open
title: argparse: "append" action fails to override default values
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file24761/t1.py

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[Guido van Rossum]

Guido van Rossum  added the comment:

I'm still torn.  Can you implement the counter without adding an extra field to 
the dict object?  I worry that we'll get the same objection we had when MAL 
proposed collision counting as a solution to the hash DoS attack.

The numbers 0, 1 and infinity are special; all others are to be treated with 
skepticism.

I'm prepared to make the current semantic change a 3.3 feature, but I'm not 
sure it's safe to backport.

--

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[STINNER Victor]

STINNER Victor  added the comment:

> Can you implement the counter without adding an extra field to the dict 
> object?

Add a counter requires to change the prototype of the C lookup function:
PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, Py_hash_t hash);

I don't know if it is a problem for ABI compatibility or extension
modules. I suppose that it is safer and simpler to not change it :-)

> I worry that we'll get the same objection we had when MAL proposed collision 
>counting as a solution to the hash DoS attack.
>
> The numbers 0, 1 and infinity are special; all others are to be treated with 
> skepticism.

Is it really useful to only retry once? Retrying once means that it
would work in most cases, but not in some corner cases. For example,
retrying once may hide the problem if you have only 1 client (1
thread), but you get the exception when you have more clients (more
threads).

Or do I misunderstand the problem?

--

___
Python tracker 

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

[issue14234] CVE-2012-0876 (hash table collisions CPU usage DoS) for embedded copy of expat

[Dave Malcolm]

New submission from Dave Malcolm :

Expat 2.1.0 Beta was recently announced:
  http://mail.libexpat.org/pipermail/expat-discuss/2012-March/002768.html
which contains (among other things) a fix for a hash-collision 
denial-of-service attack (CVE-2012-0876)

I'm attaching a patch which minimally backports the hash-collision fix part of 
expat 2.1.0 to the embedded copy of expat in the CPython source tree, and which 
adds a call to XML_SetHashSalt() to pyexpat when creating parsers.  It reuses 
part of the hash secret from Py_HashSecret.

--
components: XML
files: expat-hash-randomization.patch
keywords: patch
messages: 155198
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: CVE-2012-0876 (hash table collisions CPU usage DoS) for embedded copy of 
expat
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24762/expat-hash-randomization.patch

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[Guido van Rossum]

Guido van Rossum  added the comment:

On Thu, Mar 8, 2012 at 4:56 PM, STINNER Victor  wrote:
>
> STINNER Victor  added the comment:
>
>> Can you implement the counter without adding an extra field to the dict 
>> object?
>
> Add a counter requires to change the prototype of the C lookup function:
> PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, Py_hash_t hash);
>
> I don't know if it is a problem for ABI compatibility or extension
> modules. I suppose that it is safer and simpler to not change it :-)

Agreed.

>> I worry that we'll get the same objection we had when MAL proposed collision 
>>counting as a solution to the hash DoS attack.
>>
>> The numbers 0, 1 and infinity are special; all others are to be treated with 
>> skepticism.
>
> Is it really useful to only retry once? Retrying once means that it
> would work in most cases, but not in some corner cases. For example,
> retrying once may hide the problem if you have only 1 client (1
> thread), but you get the exception when you have more clients (more
> threads).
>
> Or do I misunderstand the problem?

Sorry, I was joking; anyway, 1 in this context would mean do the
lookup exactly once (so 0 would mean not to do it at all). One retry
would effectively mean try it twice, which would have to be treated
skeptically. :-)

Given all this I think we should keep it as you have committed and add
it to the docs and whatsnew.

--

___
Python tracker 

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

[issue14234] CVE-2012-0876 (hash table collisions CPU usage DoS) for embedded copy of expat

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +barry

___
Python tracker 

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

[issue14235] test_cmd.py does not correctly call reload()

[Josh Watson]

New submission from Josh Watson :

The test_coverage function in test_cmd.py calls reload(cmd)

--
components: Tests
messages: 155200
nosy: Josh.Watson
priority: normal
severity: normal
status: open
title: test_cmd.py does not correctly call reload()
type: crash
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

[issue14235] test_cmd.py does not correctly call reload()

[Josh Watson]

Josh Watson  added the comment:

Accidentally submitted before finishing typing. Anyways, it calls "reload(cmd)" 
in the test_coverage function in test_cmd.py, which does not work anymore given 
that reload has been moved to imp.

I've uploaded a patch that fixes this.

--
keywords: +patch
Added file: http://bugs.python.org/file24763/test_cmd-reload.patch

___
Python tracker 

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

[issue14235] test_cmd.py does not correctly call reload()

[Josh Watson]

Changes by Josh Watson :


--
type: crash -> behavior

___
Python tracker 

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

[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters

[Glenn Linderman]

Glenn Linderman  added the comment:

*Very* interesting, Steven.

Looking again at section 15.4.6, and recognizing that positional arguments were 
never parsed by optparse, then we discover that with two minor tweaks, removing 
"and add additional ArgumentParser.add_argument() calls for the positional 
arguments." from step two, and calling parse_known_args instead of parse_args, 
we actually achieve greater compatibility with optparse, for those that need it.

However, the above would allow undefined arguments to slip through into the 
positional arguments.

So to prevent that, the second parser you suggest, defining only the positional 
arguments, will tighten up the error checks.

So this issue could be resolved simply by updating section 15.4.6 of the 
documentation to explain all this.  On the other hand, the explanation gets 
long and perhaps confusing.


Looking at the 15.4.4, I see:

ArgumentParser.parse_args(args=None, namespace=None)

Convert argument strings to objects and assign them as attributes of the 
namespace. Return the populated namespace.

Previous calls to add_argument() determine exactly what objects are created 
and how they are assigned. See the documentation for add_argument() for details.

By default, the argument strings are taken from sys.argv, and a new empty 
Namespace object is created for the attributes.


However, nowhere is the args= parameter explained.  One example is given at the 
end of 15.4.4.6 showing the use of args= which apparently accepts a list of 
parameters, similar to the positional list of parameters that are used in all 
the other examples.  It might be nice to clarify that.


This leads into a suggestion: a new keyword parameter for  parse_args: 
intermixed=False.

When False, the default, new_parse_args would act exactly as it does today, 
possibly by calling old_parse_args.  When True, parse_args would implement your 
suggestion probably in the following way: filter out the positional parameters, 
call parse_known_args, then filter out the optional parameters, call 
old_parse_args, and return the combination.

t16.py implements this, external to the class, and using two parsers as you 
suggested.

One thing I notice in playing with my optparse function, is that error messages 
contain an improper usage message.  This would seem to be most easily fixed if 
the logic were built in to argparse, rather than attempting to do it externally.

Adding this parameter would also make it is much easier to write section 15.4.7 
accurately, and would reduce the porting burden on each implementer, as well.  
The technique has merit in achieving compatibility with optparse, to allow it 
to remain deprecated, and looks straightforward to implement.

--
Added file: http://bugs.python.org/file24764/t16.py

___
Python tracker 

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

[issue14233] argparse: "append" action fails to override default values

[guilherme-pg]

Changes by guilherme-pg :


--
type: crash -> behavior

___
Python tracker 

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

[issue14233] argparse: "append" action fails to override default values

[Eric V. Smith]

Eric V. Smith  added the comment:

I don't think it's worth checking that you've passed in the correct type for 
the default parameter. That's not something that Python code typically does.

The error you get:
AttributeError: 'tuple' object has no attribute 'append'
seem pretty clear. Pass in a list instead of a tuple, and it works as expected.

--
nosy: +eric.smith

___
Python tracker 

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

[issue14036] urlparse insufficient port property validation

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Couple of points:

1. On your last example, which webserver treats 'L' as part of port number? I 
can't of anything.

2. Can you write a "real application" which is listening to beyond 65535? Which 
platform would it be?

Current way of handling invalid port like, int('foo') by raising ValueError 
seems to be a better than returning a None.  A better error message could be 
desirable, but that does not make it a security issue.

Additionally, for the example of int changing long integer to 'L' appended one 
would a 2.x case as it is no longer the behavior in 3.x

Also, I would advice to look at getPort function in a C library or a Java 
library and see what it does. The only difference I see is, they return -1 
where Python returns None.

I am changing the request type to an enhancement, because there is not a valid 
argument to support that it is a security issue.

--
status: open -> pending
type: security -> enhancement

___
Python tracker 

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

[issue14205] Raise an error if a dict is modified during a lookup

[Jim Jewett]

Jim Jewett  added the comment:

On Thu, Mar 8, 2012 at 7:43 PM, STINNER Victor wrote:
> Python < 3.3 retries the lookup an unlimited number of times which
> lead to a crash, that's the issue fixed by my change.

How does it lead to a crash?  I think it just leads to an infinite
loop (which is worse) if the data is actually malicious, but
eventually fixes itself if the data is merely unlucky or even
ill-behaved.

Guido van Rossume:
>> Can you implement the counter without adding an extra field to the dict 
>> object?

Yes.  The logic does add complexity, but there is no per-dict charge,
and the extra logic can be isolated to a function that will normally
not be paged in.

> Add a counter requires to change the prototype of the C lookup
> function:
>PyDictEntry *(*ma_lookup)(PyDictObject *mp, PyObject *key, Py_hash_t hash);

> I don't know if it is a problem for ABI compatibility or extension
> modules. I suppose that it is safer and simpler to not change it :-)

That should still be the signature for the primary lookup; it can do
its own delegation to a private function with an extra parameter
if/when needed.

> The numbers 0, 1 and infinity are special; all others are to be
> treated with skepticism.

Yes; it isn't clear whether to cut off after 1 retry or 3 or 10...

> Is it really useful to only retry once? Retrying once means that it
> would work in most cases, but not in some corner cases. For example,
> retrying once may hide the problem if you have only 1 client (1
> thread), but you get the exception when you have more clients (more
> threads).

Without threads, there shouldn't be any problems for innocent code.
Even with threads, the number of resets is not (for innocent code)
tied to the number of alternative threads; only to the fact that they
can run mid-lookup.

-jJ

--

___
Python tracker 

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

[issue14217] text output pretends to be code

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I reviewed the patch, built the docs and found it good.
Fixed it in 3d877dee1bde and aaf45928899c 

Thanks!

--
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed
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

[issue14236] In help(re) are insufficient details

[py.user]

New submission from py.user :

1)
help(re)

"\s   Matches any whitespace character; equivalent to [ \t\n\r\f\v].
\S   Matches any non-whitespace character; equiv. to [^ 
\t\n\r\f\v]."


no info about unicode spaces

2)
help(re.split)

"split(pattern, string, maxsplit=0, flags=0)
Split the source string by the occurrences of the pattern,
returning a list containing the resulting substrings."


no info about behaviour with groups in pattern

--
assignee: docs@python
components: Documentation, Regular Expressions
messages: 155207
nosy: docs@python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In help(re) are insufficient details
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

[issue14237] Special sequences \A and \Z don't work in character set []

[py.user]

New submission from py.user :

>>> import re
>>> re.search(r'\Ac\Z', 'c')
<_sre.SRE_Match object at 0xb74cff38>
>>> re.search(r'[\A]c[\Z]', 'c')
>>> re.purge()
>>> re.search(r'[\A]c[\Z]', 'c', re.DEBUG)
in 
  at at_beginning_string
literal 99 
in 
  at at_end_string
>>>

--
components: Regular Expressions
messages: 155208
nosy: ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: Special sequences \A and \Z don't work in character set []
type: behavior
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

[issue14229] On KeyboardInterrupt, the exit code should mirror the signal number

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I'm not so sure that Python is in violation of the convention here. The exit 
code should report *unhandled* signals, indicating that the process didn't 
provide an exit code at all (as it didn't call exit(2)). You are supposed to 
use WIFEXITED/WIFSIGNALED/WIFSTOPPED on the status code, and interpret it as an 
exit code only if WIFEXITED.

Since Python *does* handle the signal, and exits "regularly", we shouldn't (and 
probably even can't) claim that we didn't exit (unless we raise the signal 
again instead of exiting).

--

___
Python tracker 

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

[issue14237] Special sequences \A and \Z don't work in character set []

[Martin v . Löwis]

Martin v. Löwis  added the comment:

What behavior would you expect?

--
nosy: +loewis

___
Python tracker 

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