[issue5322] object.__new__ argument calling autodetection faulty
Armin Ronacher added the comment: The bug is still there, just that it's now not just a warning but an error. The auto detection is incorrect here. It should allow the instantiation of the object with arguments. -- ___ Python tracker <https://bugs.python.org/issue5322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
Armin Ronacher <armin.ronac...@active-4.com> added the comment: I have no good solution. What I do so far is pretty much exactly what was originally reported here: https://github.com/pallets/werkzeug/blob/6922d883ba61c6884fa6cab5bfd280c5a60399af/werkzeug/security.py#L96-L104 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
Armin Ronacher <armin.ronac...@active-4.com> added the comment: Yes, I'm definitely still interested in this. I still carry this hack around. -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27589] asyncio doc: issue in as_completed() doc
Armin Ronacher added the comment: I am not even sure what the function is supposed to tell me. The documentation is very unclear and the example code does not help. What is "fs" for instance? And why would it return things that are not from fs? -- nosy: +aronacher ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14714] PEP 414 tokenizing hook does not preserve tabs
Armin Ronacher added the comment: I hereby close this issue which is two years old. The only point of the tokenizer thing was to support Python 3.2 which many libraries already have stopped supporting anyways. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14714 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14714] PEP 414 tokenizing hook does not preserve tabs
Changes by Armin Ronacher armin.ronac...@active-4.com: -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14714 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21364] Documentation Recommends Broken Pattern
Armin Ronacher added the comment: To avoid further problems may I also recommend documenting how exactly people are supposed to wrap sys.stdout and so forth. Clearly putting a StringIO there is insufficient as StringIO does not have a buffer. Something like this maybe? import io buf = io.BytesIO() sys.stdout = io.TextIOWrapper(buf, encoding='utf-8', errors='strict', # or surrogate-escape as this is the default for stdout now? not sure line_buffering=True ) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21364 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21364] Documentation Recommends Broken Pattern
Armin Ronacher added the comment: I would like to know of some situations where you want to write some code that accesses standard streams as binary *and* don't control the application setup (i.e. library code rather than application code). It seems to me that a library should take the binary streams as parameters rather than force the use of stdin/stdout. The same situations people wrapped streams before on python 2: * code.py users. Werkzeug's traceback system implements a remote python shell through it. * any system that wants to unittest shell scripts on a high level. * any system that wants to execute arbitrary python code and then capture whatever output it did. This is for instance what I see Sphinx users frequently do (or doctests) In fact, the reasons people wrap sys.stdout/sys.stderr on 2.x are the same reasons why people would do it on 3.x: they have arbitrary code they did not write and they want to capture what it does. Since you do not know if that is binary or text you need a stream object that behaves the same way as the default one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21364 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21364] Documentation Recommends Broken Pattern
Armin Ronacher added the comment: Pretty much, yes. Just that you probably want 'replace' instead. surrogate-escape does not do anything useful here I think. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21364 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21363] io.TextIOWrapper always closes wrapped files
Armin Ronacher added the comment: Detach destroys the stream, so it's not a solution. I can't just randomly destroy global state just because it's convenient. This is what I am doing now which seems borderline insane: https://github.com/mitsuhiko/click/blob/master/click/_compat.py#L31 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21363] io.TextIOWrapper always closes wrapped files
Armin Ronacher added the comment: Ah. Misread. This is about detaching the underlying stream from TextIOWrapper. I assume this could be done in the __del__ so that would work. I'm checking this now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21363] io.TextIOWrapper always closes wrapped files
Armin Ronacher added the comment: I can confirm that calling detach() in __del__ within an except block solves the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21364] Documentation Recommends Broken Pattern
Armin Ronacher added the comment: Sidestepping: The shutdown message is a related issue. TextIOWrapper tends to internally log errors apparently which is super annoying and probably should be fixed. I encountered the same problem with sockets disconnecting wrapped in TextIOWrapper always writing some dummy traceback to stderr which I can't silence. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21364 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13598] string.Formatter doesn't support empty curly braces {}
Armin Ronacher added the comment: Is there any chance this will be fixed for 2.7 as well? -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21363] io.TextIOWrapper always closes wrapped files
New submission from Armin Ronacher: I'm trying to write some code that fixes a misconfigured sys.stdin on a case by case bases but unfortunately I cannot use TextIOWrapper for this because it always closes the underlying file: Python import io sys.stdin.encoding 'ANSI_X3.4-1968' stdin = sys.stdin correct_stdin = io.TextIOWrapper(stdin.buffer, 'utf-8') correct_stdin.readline() foobar 'foobar\n' del correct_stdin stdin.readline() Traceback (most recent call last): File stdin, line 1, in module ValueError: I/O operation on closed file. Ideally there would be a way to disable this behavior. -- messages: 217260 nosy: aronacher priority: normal severity: normal status: open title: io.TextIOWrapper always closes wrapped files ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21364] Documentation Recommends Broken Pattern
New submission from Armin Ronacher:
The documentation recommends replacing sys.stdin with a binary stream
currently: https://docs.python.org/3/library/sys.html#sys.stdin
This sounds like a bad idea because it will break pretty much everything in
Python in the process.
As example:
import sys
sys.stdin = sys.stdin.detach()
input('Test: ')
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: '_io.BufferedReader' object has no attribute 'errors'
sys.stdout = sys.stdout.detach()
print('Hello World!')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'str' does not support the buffer interface
--
messages: 217270
nosy: aronacher
priority: normal
severity: normal
status: open
title: Documentation Recommends Broken Pattern
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21364
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
New submission from Armin Ronacher: Is there a specific reason why hashlib.pbkdf2_hmac now has a completely inconsistent API with the rest of the stdlib? So far the concept in both hashlib and hmac has been to accept hash constructors as parameters. As such you would expect the API to look like this: hashlib.pbkdf2_hmac(hashlib.sha256, b'password', b'salt', 10) Instead the API now is string based. This is annoying because a lot of code already in the past exposed a pbkdf2 implementation that allows passing in a hashlib constructor by passing it to HMAC. If such code now wants to use the stdlib pbkdf2_hmac implementation it has to special case known implementations. If a non known implementation is found it needs to dispatch to a separate implementation of PBKDF2. In addition to that there is no nice way to detect if a algorithm is not supported as the exception raised for an invalid algorithm is the same as an invalid parameter for the iteration count (ValueError). I would propose to change the API to allow hash constructors to be passed in in addition to strings. -- messages: 216728 nosy: aronacher priority: normal severity: normal status: open title: hashlib.pbkdf2_hmac Hash Constructor versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
Armin Ronacher added the comment: This commit shows why the API is problematic: https://github.com/mitsuhiko/werkzeug/commit/c527dcbfb0ee621e9faa0a3a2873118438965800 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
Armin Ronacher added the comment: We can accept only hashlib functions, and continue passing their names to the OpenSSL backend. A bit ugly and limited solution (no user-defined hash functions) for a better looking API. What I'm doing at the code for my employer is something similar. There is a PBKDF2 implementation on top of the hmac module. If a hashlib constructor is detected that OpenSSL implements it dispatches that to the PBKDF2 path in OpenSSL via ctypes. Ultimately it's the same situation but it does not expose the implementation detail. -- versions: +Python 3.4 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
Armin Ronacher added the comment: I should add that we still support non OpenSSL hashers, but we go a different path. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21288] hashlib.pbkdf2_hmac Hash Constructor
Armin Ronacher added the comment: I understand that, but given that this API might be backported to 2.7 I think it should get further review. Also, this would only be a change to the error case. Non string arguments are currently being responded to with a TypeError. I am not proposing to remove the string API, just also allow a hash constructor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21288 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21235] importlib's spec module create algorithm is not exposed
New submission from Armin Ronacher:
3.4 deprecates load_module on the loaders and now proposes to use create_module
(optionally) and exec_module. Unfortunately for external callers these
interfaces are not useful because you need to reimplement _SpecMethods.create
and a whole bunch of other stuff for it.
Right now a caller can get hold of _SpecMethods by importing from
_frozen_importlib but that seems very unsupported and is obviously entirely not
exposed.
Is there a reason those methods are not on the ModuleSpec directly but on a
private wrapper?
Example usage:
from types import ModuleType
from importlib.machinery import ModuleSpec, SourceFileLoader
from _frozen_importlib import _SpecMethods
loader = SourceFileLoader('plugin_base', 'my_file.py')
spec = ModuleSpec(name=loader.name, loader=loader)
mod = _SpecMethods(spec).create()
In the absence of _SpecMethods a caller needs to do this:
from importlib.machinery import ModuleSpec, SourceFileLoader
loader = SourceFileLoader('plugin_base', 'my_file.py')
spec = ModuleSpec(name=loader.name, loader=loader)
if not hasattr(loader, 'create_module'):
module = types.ModuleType(loader.name)
else:
module = loader.create_module(spec)
module.__loader__ = loader
module.__spec__ = spec
try:
module.__package__ = spec.parent
except AttributeError:
pass
loader.exec_module(module)
(And that is not the whole logic yet)
--
keywords: 3.4regression
messages: 216295
nosy: aronacher
priority: normal
severity: normal
status: open
title: importlib's spec module create algorithm is not exposed
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21235
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21235] importlib's spec module create algorithm is not exposed
Armin Ronacher added the comment: On further investigation that is not even enough yet due to the new locking mechanism. I'm not even sure if exposing _SpecMethods would be enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21235] importlib's spec module create algorithm is not exposed
Armin Ronacher added the comment: I'm not sure myself what I need right now. I personally have avoided importlib/imp entirely for my code and I roll with manual module creation because it is most stable between 2.6 - 3.4 but it's getting more complicated to work because of all the new attributes (__package__, __spec__ etc.). This particular case came from SQLAlchemy I believe (I tried to help Mike Bayer transition his code). It's true that create() is the wrong function, load() is actually what should have been used there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21235] importlib's spec module create algorithm is not exposed
Armin Ronacher added the comment: Also mostly unrelated importlib now does something I have never seen an ABC do: the ABC has create_module but concrete implementations mostly have that function entirely absent. That should probably be reconsidered as it's super confusing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21235 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20839] pkgutil.get_loader throws deprecation warning due to internal deprecation
Armin Ronacher added the comment: This also happens with the latest hg version. I could not make an isolated test case unfortunately but it happens on the flask testsuite if run on 3.4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20839] pkgutil.get_loader throws deprecation warning due to internal deprecation
New submission from Armin Ronacher: pkgutil.get_loader calls pkgutil.find_loader which calls importlib.find_loader The latter logs a deprecation warning about it being replaced by importlib.util.find_spec. This is a regression in 3.4 as far as I can see. -- keywords: 3.4regression messages: 212615 nosy: aronacher priority: normal severity: normal status: open title: pkgutil.get_loader throws deprecation warning due to internal deprecation type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20839 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode
Armin Ronacher added the comment: Two things wrong with your example: a) PATH_INFO on Python 3 must not be bytes b) PATH_INFO on Python 3 must be latin1 transfer encoded. See unicode_to_wsgi and wsgi_to_bytes functions in PEP . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode
Armin Ronacher added the comment: Which version and bugfix release are you using? You can reproduce it against the current development version of Python 3. What is werkzeug and what does it have to do with stdlib urllib? Werkzeug is a WSGI implementation. An stdlib test cannot depend on 3rd party code. That's why the output values are in the clear so you can remove the werkzeug specific parts. url_unquote can be replaced with urllib.parse.unquote. None of that is relevant to the issue here though. It was just to show that the standard library is currently in violation to PEP . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20138 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode
Armin Ronacher added the comment:
What it currently returns:
from wsgiref.util import request_uri
request_uri({
... 'wsgi.url_scheme': 'http',
... 'SCRIPT_NAME': '',
... 'PATH_INFO': '/\xe2\x98\x83',
... 'SERVER_PORT': '80',
... 'SERVER_NAME': 'localhost'
... })
'http://localhost/%C3%A2%C2%98%C2%83'
What it should return:
'http://localhost/%E2%98%83'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20138
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20138] wsgiref on Python 3.x incorrectly implements URL handling causing mangled Unicode
New submission from Armin Ronacher:
I just noticed through looking through someone else's WSGI framework that
wsgiref is incorrectly handling URL handling. It does not go through the WSGI
coding dance in the wsgiref.utils.request_uri function.
Testcase through werkzeug:
from wsgiref.util import request_uri
from werkzeug.test import create_environ
from werkzeug.urls import url_parse, url_unquote
env = create_environ('/\N{SNOWMAN}')
url_parse(request_uri(env)).path
'/%C3%A2%C2%98%C2%83'
url_unquote(url_parse(request_uri(env)).path)
'/รข\x98\x83'
_ == '/\N{SNOWMAN}'
False
If this passes tests then I'm assuming that wsgiref is doing the inverse bug
somewhere else. I will look into it later, but this behavior is definitely
broken.
--
messages: 207418
nosy: aronacher
priority: normal
severity: normal
status: open
title: wsgiref on Python 3.x incorrectly implements URL handling causing
mangled Unicode
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20138
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16148] Implement PEP 424
Armin Ronacher added the comment: Reviewed and applied. Looks good. -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16148 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16148] Implement PEP 424
Changes by Armin Ronacher armin.ronac...@active-4.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16148 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14711] Remove os.stat_float_times
New submission from Armin Ronacher armin.ronac...@active-4.com: Is there a specific reason this is still around? Originally that was to make it possible to upgrade to Python 2.3 or whenever that was introduced. I don't think anyone still uses that. -- messages: 159859 nosy: aronacher priority: normal severity: normal status: open title: Remove os.stat_float_times versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10980] http.server Header Unicode Bug
Armin Ronacher armin.ronac...@active-4.com added the comment: 2.7 does not suffer from this since 2.7 does not support unicode in headers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue415492] Compiler generates relative filenames
Armin Ronacher armin.ronac...@active-4.com added the comment:
The reason why this is a problem:
$ cat test.py
def foo():
pass
import test, os, inspect
os.chdir('/')
inspect.getsource(test)
'def foo():\npass\n'
But
import test, os, inspect
os.chdir('/')
inspect.getsource(test)
Traceback (most recent call last):
File stdin, line 1, in module
IOError: source code not available
--
nosy: +aronacher
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue415492
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Armin Ronacher armin.ronac...@active-4.com added the comment: A little bit of input on this issue. Considering that exceptions are now getting keyword arguments for things like import errors and other things for attributes I would find it much better if StopIteration would follow that as well (StopIteration(value=42) instead of StopIteration(42)). -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12575] add a AST validator
Armin Ronacher armin.ronac...@active-4.com added the comment: I see what you did there :P -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12575 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11573] Improve Unicode Documentation with Known Caveats
New submission from Armin Ronacher armin.ronac...@active-4.com: The documentation should explain some of the common problems with Unicode on Python 3. * locale's affect the text default encoding * SSH clients can set the locale on a remote server * filesystem encoding is set by the SSH client as well -- components: Unicode messages: 131143 nosy: aronacher priority: normal severity: normal stage: needs patch status: open title: Improve Unicode Documentation with Known Caveats versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11573 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11574] Unicode Fallback Encoding on Python 3.3
New submission from Armin Ronacher armin.ronac...@active-4.com: Right now Python happily falls back to ASCII if it can not parse your LC_CTYPE or something similar happens. Instead of falling back to ASCII it would be better if it falls back to UTF-8. Alternatively it should at least give a warning that it's falling back to ASCII. This issue was discussed at PyCon and the consensus so far was that falling back to UTF-8 in 3.3 might be a good idea and should not break much code as UTF-8 is a superset of ASCII. -- components: Unicode messages: 131144 nosy: aronacher priority: normal severity: normal status: open title: Unicode Fallback Encoding on Python 3.3 versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11574] Unicode Fallback Encoding on Python 3.3
Changes by Armin Ronacher armin.ronac...@active-4.com: -- assignee: - loewis nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11574 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Changes by Armin Ronacher armin.ronac...@active-4.com: -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10980] http.server Header Unicode Bug
New submission from Armin Ronacher armin.ronac...@active-4.com: I have a critical bugfix that should make it into Python 3.2 even when it's in release candidate state. Currently http.server.BaseHTTPServer encodes headers with ASCII charset. This is at least in violation with PEP which demands that latin1 is used. Because HTTP itself suggests latin1 (iso-8859-1) I strongly recommend changing this in BaseHTTPServer and not wsgiref. The attached patch fixes that in a backwards compatible fashion. -- assignee: georg.brandl components: Library (Lib) files: http-server-unicode.patch keywords: patch messages: 126832 nosy: aronacher, georg.brandl priority: normal severity: normal stage: patch review status: open title: http.server Header Unicode Bug type: behavior Added file: http://bugs.python.org/file20486/http-server-unicode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10980] http.server Header Unicode Bug
Armin Ronacher armin.ronac...@active-4.com added the comment: Georg Brandl signed off the commit and Python 3.2 will ship with the HTTP server accepting latin1 bytes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
Armin Ronacher armin.ronac...@active-4.com added the comment: 1. Users can use _srcFile = None to avoid calling findCaller() altogether, so I can't do away with the _srcFile altogether as it may cause some issues with existing code. That is very undocumented behaviour and relying on that sounds like a terrible idea. 2. If using e.g. a LoggerAdapter derived class, there needs to be some way in which you can skip (in addition to the logging package itself) other user-defined modules until you get to the appropriate stack frame. First of all that should not be a global setting, secondly this is currently not possible in logging either. A better solution would be to do what warnings does and making it possible provide a stacklevel to the caller finder. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9945] Improper locking in logging
New submission from Armin Ronacher armin.ronac...@active-4.com: I found a a useless lock acquiring in the 27 maintenance branch in logging and a missing one as well: Logger.removeHandler() locks around a handler lock, however the code executed in this lock is not depending on anything of that lock. However there is a race condition when two pieces of code try to remove the same handler at the same time because between the if and the remove() no locking takes place. I would recommend this instead (and also add locking to the addHandler): def addHandler(self, hdlr): Add the specified handler to this logger. _acquireLock() try: if hdlr not in self.handlers: self.handlers.append(hdlr) finally: _releaseLock() def removeHandler(self, hdlr): Remove the specified handler from this logger. _acquireLock() try: if hdlr in self.handlers: self.handlers.remove(hdlr) finally: _releaseLock() I suppose in 3.x there might be something similar. -- assignee: vinay.sajip components: Library (Lib) messages: 117364 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: Improper locking in logging type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9947] Weird locking in logging config system
New submission from Armin Ronacher armin.ronac...@active-4.com: Another case of improper locking in logging. The stopListening() method of the logging config acquires the logging lock, but it doesn't do it early enough. In order for this function to be thread safe it would have to lock before the if. Currently that lock used is useless because it locks assigning to a single attribute assignment and a global assignment that is never checked to existence besides the stopListening() function. The attached patch proposes moving the lock before the if to make it threadsafe, but in all fairness sake that method is probably never executed from more than one thread. -- assignee: vinay.sajip files: logging-config-threadsafety.patch keywords: patch messages: 117370 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: Weird locking in logging config system versions: Python 2.7 Added file: http://bugs.python.org/file19007/logging-config-threadsafety.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
New submission from Armin Ronacher armin.ronac...@active-4.com: findCaller() on loses case information on the files on Windows and has in general a really bad performance. The attached patch does not depend on filename comparisions and instead compares the object identity of the caller's global namespace against the one from the logging module. -- assignee: vinay.sajip components: Library (Lib) files: find-caller.patch keywords: patch messages: 117373 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: findCaller is slow and loses case information on Windows versions: Python 2.7 Added file: http://bugs.python.org/file19008/find-caller.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
Changes by Armin Ronacher armin.ronac...@active-4.com: Added file: http://bugs.python.org/file19009/find-caller.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
Changes by Armin Ronacher armin.ronac...@active-4.com: Removed file: http://bugs.python.org/file19008/find-caller.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Changes by Armin Ronacher armin.ronac...@active-4.com: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment: One could argue of course that every user of Python should handle EINTR, but that's something I think should be solved in the IO library because very few people know that one is supposed to restart syscalls on EINTR on POSIX systems. Ruby for instance handles EINTR properly: mitsuh...@nausicaa:~$ ruby -e 'puts $stdin.read.inspect' ^Z [1]+ Stopped mitsuh...@nausicaa:~$ fg ruby -e 'puts $stdin.read.inspect' test test\n So does perl: mitsuh...@nausicaa:~$ perl -e 'chomp($x = STDIN); print $x' ^Z [1]+ Stopped mitsuh...@nausicaa:~$ fg perl -e 'chomp($x = STDIN); print $x' test test -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment: Interestingly even PHP handles that properly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment:
Hmm. So under what conditions should it continue, and under what
conditions should it raise an exception (when errno is EINTR)?
EINTR indicates a temporary failure. In that case it should always retry.
A common macro for handling that might look like this:
#define RETRY_ON_EINTR(x) ({ \
typeof(x) rv; \
do { rv = x; } while (rv 0 errno == EINTR); \
rv;\
})
But from what I understand, braces in parentheses are a GCC extension.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9867
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment:
The following minimal C code shows how EINTR can be handled:
#include stdlib.h
#include stdio.h
#include errno.h
#include signal.h
#define BUFFER_SIZE 1024
int
main()
{
char buffer[BUFFER_SIZE];
printf(PID = %d\n, getpid());
while (1) {
int rv = fgetc(stdin);
if (rv 0) {
if (feof(stdin))
break;
if (errno == EINTR)
continue;
printf(Call failed with %d\n, errno);
return 1;
}
else
fputc(rv, stdout);
}
return 0;
}
Test application:
mitsuh...@nausicaa:/tmp$ ./a.out
PID = 22806
Terminated
mitsuh...@nausicaa:/tmp$ ./a.out
PID = 22809
mitsuh...@nausicaa:/tmp$ ./a.out
PID = 22812
^Z
[2]+ Stopped ./a.out
mitsuh...@nausicaa:/tmp$ fg
./a.out
test
test
foo
foo
First signal sent was TERM, second was INT. Last case was sending to
background, receiving the ignored SIGCONT signal, fgetc returning -1 and fgetc
being called again because of errno being EINTR.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9867
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment: Wouldn't retrying on EINTR cause havoc when you try to interrupt a process? All your C applications are doing it, why should Python cause havok there? Check the POSIX specification on that if you don't trust me. That is: what would happen with the proposed patch when a python script does a read that takes a very long time and the user tries to interrupt the script (by using Ctrl+C to send a SIGTERM)? EINTR is only returned if nothing was read so far and the call was interrupted in case of fread. Here a quick explanation from the GNU's libc manual: http://www.gnu.org/s/libc/manual/html_node/Interrupted-Primitives.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment: There is a funny story related to that though :) BSD avoids EINTR entirely and provides a more convenient approach: to restart the interrupted primitive, instead of making it fail. BSD does, but the Mach/XNU kernel combo on OS X is not. Which is why all the shipped BSD tools have that bug, but if you run their GNU equivalents on OS X everything work as expected. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment: setting the SA_RESTART in the call to sigaction should work (on OSX HAVE_SIGACTION is defined), unless the manpage is lying. It should work, haven't tried. From what I understand on a BSD system, retrying is the default. -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried
Armin Ronacher armin.ronac...@active-4.com added the comment: You conveniently didn't quote the part of my message where I explained why I think there may be a problem. I understand that, but there are already cases in Python where EINTR is handled properly. In fact, quoting socketmodule.c: if (res == EINTR PyErr_CheckSignals()) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9867] Interrupted system calls are not retried on OS X
New submission from Armin Ronacher armin.ronac...@active-4.com: Currently Python does not check fread and other IO calls for EINTR. This usually is not an issue, but on OS X a continued program will be sent an SIGCONT signal which causes fread to be interrupted. Testcase: mitsuh...@nausicaa:~$ python2.7 Python 2.7 (r27:82508, Jul 3 2010, 21:12:11) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type help, copyright, credits or license for more information. from signal import SIGCONT, signal def show_signal(*args): ... print 'Got SIGCONT' ... signal(SIGCONT, show_signal) 0 import sys sys.stdin.read() ^Z [1]+ Stopped python2.7 mitsuh...@nausicaa:~$ fg python2.7 Got SIGCONT Traceback (most recent call last): File stdin, line 1, in module IOError: [Errno 4] Interrupted system call Expected behavior: on fg it should continue to read. The solution would be to loop all calls to fread and friends until errno is no longer EINTR. Now the question is how to best do that. I can't think of a portable way to define a macro that continues to run an expression until errno is EINTR, maybe someone else has an idea. Otherwise it would be possible to just put the loops by hand around each fread/fgetc etc. call, but that would make the code quite a bit more ugly. Technically I suppose the problem applies to all platforms, on OS X it's just easier to trigger. -- messages: 116504 nosy: aronacher priority: normal severity: normal status: open title: Interrupted system calls are not retried on OS X type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9775] Multiprocessing, logging and atexit play not well together
New submission from Armin Ronacher armin.ronac...@active-4.com:
It's hard to say what exactly is to blame here, but I will try to outline the
problem as good as I can and try to track it down:
A library of mine is using a Thread that is getting entries from a
multiprocessing.Queue periodically. What I find when the python interpreter is
shutting down is this on stderr:
Error in sys.exitfunc:
Traceback (most recent call last):
File python2.6/atexit.py, line 24, in _run_exitfuncs
func(*targs, **kargs)
File python2.6/multiprocessing/util.py, line 270, in _exit_function
info('process shutting down')
TypeError: 'NoneType' object is not callable
Tracking down the issue shows that something has a __del__ [i have not found
the object, i was under the impression the ProcessAwareLogger monkeypatch was,
but apprently it's not the culprit] and clears out the module. When the exit
handler is running info is already set to None. It can be easily checked if
that is the issue when a weird monkepatch is added:
def fix_logging_in_multiprocesing():
from multiprocessing import util, process
import logging
util._check_logger_class()
old_class = logging.getLoggerClass()
def __del__(self):
util.info = util.debug = lambda *a, **kw: None
process._cleanup = lambda *a, **kw: None
old_class.__del__ = __del__
I originally thought that the destructor of the ProcessAwareLogger class was
the issue, but apparently not so because it does not have one.
Interestingly if one looks into the util.py module the following comment can be
found:
def _check_logger_class():
'''
Make sure process name is recorded when loggers are used
'''
# XXX This function is unnecessary once logging is patched
import logging
if hasattr(logging, 'multiprocessing'):
return
...
This is interesting because the logging monkeypatch is unused if logging is
multiprocessing aware (which it should be in 2.6 at least). However apparently
at one point the toplevel multiprocessing import was removed which makes this
test fall all the time. Looking at the current 26 branch it appears that the
monkeypatch was removed by jesse noller in [68737] over a year ago.
With the current development version (and I suppose a later release than 2.6.1
which I am currently testing) the error disappears as well.
However the core issue would come back as soon as the atexit call moves past a
destructor again I suppose. Because of that I would recommend aliasing info to
_info and debug to _debug and then calling the underscored methods in the
atexit handler.
Any reasons for not doing that? Otherwise I would like to propose committing
that patch.
--
components: Library (Lib)
messages: 115578
nosy: aronacher
priority: normal
severity: normal
status: open
title: Multiprocessing, logging and atexit play not well together
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9775
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9775] Multiprocessing, logging and atexit play not well together
Changes by Armin Ronacher armin.ronac...@active-4.com: -- keywords: +patch Added file: http://bugs.python.org/file18746/9775-fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9775] Multiprocessing, logging and atexit play not well together
Changes by Armin Ronacher armin.ronac...@active-4.com: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9775] Multiprocessing, logging and atexit play not well together
Armin Ronacher armin.ronac...@active-4.com added the comment: This also affects 2.7, I just worked on 2.6 because this is where I encountered the issue. As for 2.7: please try explaining again what specific issue the patch is meant to resolve? What monkey-patching are you referring to? What destructor? Why is aliasing these functions going to solve a problem? As mentioned above I cannot provide more information because I am unable to find the root of the issue. All I know is that if the atexit handler is executed after the module globals were set to None it fails to shutdown properly. The old monkey patch can be found here: http://svn.python.org/view/python/tags/r261/Lib/multiprocessing/util.py?revision=71601view=markup I am pretty sure that this is one way to trigger the issue but by itself not the root of the problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9775] Multiprocessing, logging and atexit play not well together
Armin Ronacher armin.ronac...@active-4.com added the comment: Put the stuff from an older version back in with a monkeypatch and you will see the issue again. There are certainly many more ways to trigger that issue, that was just the easiest. I will try to create a simpler test case. -- resolution: works for me - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9368] Const-Correctness for Method Calls
New submission from Armin Ronacher armin.ronac...@active-4.com: The following patch changes some parts of the public C API for const correctness which would help C++ programmers. The original patch was provided by neXyon on irc.freenode.net. It does not produce any compiler warnings on GCC and I don't expect any compiler warnings on other systems either. -- components: None files: const.patch keywords: patch messages: 111435 nosy: aronacher priority: normal severity: normal stage: patch review status: open title: Const-Correctness for Method Calls type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file18174/const.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9368 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
Armin Ronacher armin.ronac...@active-4.com added the comment: Yes. Appears to be related. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Changes by Armin Ronacher armin.ronac...@active-4.com: -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
Armin Ronacher armin.ronac...@active-4.com added the comment: Duplicate of #3976 -- resolution: - duplicate ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
Changes by Armin Ronacher armin.ronac...@active-4.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Armin Ronacher armin.ronac...@active-4.com added the comment: @Georg: Instead of catching a TypeError i would rather call __gt__ / __lt__ directly and check for NotImplemented. Python 2.x did not catch TypeErrors either. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3976 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Armin Ronacher armin.ronac...@active-4.com added the comment:
Eg, something like this:
class safe_key(object):
__slots__ = ('obj',)
def __init__(self, obj):
self.obj = obj
def __eq__(self, other):
return self.obj.__eq__(other.obj)
def __lt__(self, other):
rv = self.obj.__lt__(other.obj)
if rv is NotImplemented:
rv = id(type(self.obj)) id(type(other.obj))
return rv
ls = [2, 1, 1.0, 1.5, 'a', 'c', 'b']
print(sorted(ls, key=safe_key))
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3976
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6945] pprint.pprint does not pprint unsortable dicts in Python 3
New submission from Armin Ronacher armin.ronac...@active-4.com: Currently pprint does not work on dicts it cannot sort. Because in Python 3 sorted(x.items()) is no longer guaranteed to work a new sorting solution has to be found. -- messages: 92862 nosy: aronacher severity: normal status: open title: pprint.pprint does not pprint unsortable dicts in Python 3 versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com added the comment: Why does this have to go into the standard library? People that want to use it can still install it from PyPI. -sys.maxint from me. -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com added the comment: @Armin: Doesn't that argument apply to *any* library proposed for inclusion in the standard library? By which logic we should never add anything to the standard library ever again. That's what I say. Do not add anything to the stdlib that is not needed to keep applications platform independent. argparse adds zero value to x-platform development. Things I consider good for a stdlib: * portable filesystem notification hooks * stuff like os.path * distutils * socket library Stuff that should not go into the stdlib: * xml parsers * command line parsers (one is enough, and that should be *stable* not replaced later with something like argparse) Fix packaging and do not dump useless stuff into the standard library to make it appear more modern. Decentralization is modern, not replacing modules in the stdlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com added the comment: I can respect that viewpoint. So what do you propose to do with existing modules like optparse that aren't required to make platform independent applications and are out of date and basically unmaintained? One option would be to remove them, but that's probably too drastic. Documentation and a new kind of deprecation warning. It's documentation-deprecated in one version, one later a real deprecation warning appears that sticks around for a couple of versions. The documentation would explain how to hide the deprecation warning and tells the user to better use more modern alternatives. This of course requires packaging to work flawlessly first which I consider to be high priority. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6247] should we include argparse
Armin Ronacher armin.ronac...@active-4.com added the comment: It must be convenient to operate in an environment where you can install new software so easily Armin. Trust me, it is. For others (including me), the actual package installation is the least of our hassles and anything that helps us avoid dealing with the lawyers is a big gain. So you're suggesting Python should suffer because some companies have a weird legal department? @Michael Foord: I totally agree that argument parsing is something that *should* be in the standard library because everybody needs it. However at the same time it's something I could imagine comes from an external source. I would rather maintain optparse myself for python.org than seeing another argument parsing library in the stdlib so that everybody has to switch over because the Python devs did not find someone to maintain it. The stdlib is very often unmaintained for large parts; we can't just replace a module because the developer got bored... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Armin Ronacher armin.ronac...@active-4.com added the comment: Please no. We just decided to *not* extend the API. The PEP originally had a well designed list of dict API extensions that already provided exactly that. If we really want to provide access to that, we can roll back to where we came from. I don't think implementing an LRUCache on an ordered dict is a good idea. Especially because LRU caches are a shared resource and should be thread safe because of that. Which the ordered dict is not. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Armin Ronacher armin.ronac...@active-4.com added the comment: Please no. We just decided to *not* extend the API. The PEP originally had a well designed list of dict API extensions that already provided exactly that. If we really want to provide access to that, we can roll back to where we came from. I don't think implementing an LRUCache on an ordered dict is a good idea. Especially because LRU caches are a shared resource and should be thread safe because of that. Which the ordered dict is not. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Changes by Armin Ronacher armin.ronac...@active-4.com: ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1355826] shutil.move() does not preserve ownership
Armin Ronacher armin.ronac...@active-4.com added the comment: While this is surprising, this is documented behavior: If the destination is on the current filesystem, then simply use rename. Otherwise, copy src (with copy2()) to the dst and then remove src. And copy2() uses copystat() and does not copy contents, owner, and group. -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1355826 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5405] There is no way of determining which ABCs a class is registered against
Armin Ronacher armin.ronac...@active-4.com added the comment: I don't think this can be solved. Not only do registered classes not show up (which could be fixed by providing something like inspect.getfakemro) but ABCs can also perform duck-type checks. For example a class with an __iter__ method is an instance of collections.Iterable or how it's called thanks to the __subclasscheck__ magic method. -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5405] There is no way of determining which ABCs a class is registered against
Armin Ronacher armin.ronac...@active-4.com added the comment: I suppose it would be a good idea to fix part of that problem in Sphinx (and probably also in pydoc) by adding something like :implements: MutableMapping in the docstring. So that this is explicitly added to the docstring and conforming tools can use this documentation hints. Similar things are currently implemented in Sphinx for :param: :return: etc. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Armin Ronacher armin.ronac...@active-4.com added the comment: Maybe premature optimization but maybe it would make sense to implement __eq__ like this: def __eq__(self, other): if isinstance(other, OrderedDict): if not dict.__eq__(self, other): return False return all(p == q for p, q in _zip_longest(self.items(), other.items())) return dict.__eq__(self, other) For the most likely case (that dicts are different) this should give a speedup. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Armin Ronacher armin.ronac...@active-4.com added the comment: @Georg * eval()ing the repr() will not construct the dict in the same order The alternative would be a list of dicts inside the constructor call, but that feels ugly. defaultdict from the same module is not evaluable at all, so I guess it wouldn't be that much of a problem. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5401] mimetypes.MAGIC_FUNCTION implementation clusterfuck
New submission from Armin Ronacher armin.ronac...@active-4.com: Sorry for the harsh words, but when I found that code I nearly freaked out. For all those years I was using from mimetypes import guess_type until today I found out that this has horrendous performance problems due to the fact that the mimetype database is re-parsed on each call. The reason for this is that mimetypes.guess_type is implemented like this: def guess_type(...): global guess_type init() guess_type = new_guess_type return guess_type(...) Obviously if the function was imported from the module and not looked up via standard attribute lookup before each call (by calling it like mimetypes.guess_type(...)) init() would be called over and over again. What's the performance impact? In a small WSGI middleware that serves static files the *total* performance impact (including HTTP header parsing, file serving etc.) was 1000%. Just for guess_type() versus mimetypes.guess_type() which was called just once per request. I attached a workaround for that problem that tries to avoid init() calls after the thing was initialized. If this is intended behaviour it should be documented but I doubt that this is a good idea as people don't read documentation it stuff seems to work. And google tells me I'm not the first one who invoked guess_type that way: http://google.com/codesearch?q=from+mimetypes+import+guess_type; -- components: Library (Lib) files: mimetypes-speedup.diff keywords: easy, needs review, patch, patch messages: 82992 nosy: aronacher priority: critical severity: normal stage: patch review status: open title: mimetypes.MAGIC_FUNCTION implementation clusterfuck versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file13225/mimetypes-speedup.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5401 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5401] mimetypes.MAGIC_FUNCTION performance problems
Changes by Armin Ronacher armin.ronac...@active-4.com: -- title: mimetypes.MAGIC_FUNCTION implementation clusterfuck - mimetypes.MAGIC_FUNCTION performance problems ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5401 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5381] json need object_pairs_hook
Armin Ronacher armin.ronac...@active-4.com added the comment: Motivation: Yes. JSON says it's unordered. However Hashes in Ruby are ordered since 1.9 and they were since the very beginning in JavaScript and PHP. -- nosy: +aronacher ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5381 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
New submission from Armin Ronacher armin.ronac...@active-4.com:
In 2.6 a deprecation warning was added if `object.__new__` was called
with arguments. Per se this is fine, but the detection seems to be faulty.
The following code shows the problem:
class A(object):
... def __new__(self):
... raise TypeError('i do not exist')
...
class B(A):
... __new__ = object.__new__
... def __init__(self, x):
... self.x = x
...
B(1)
__main__:1: DeprecationWarning: object.__new__() takes no parameters
__main__.B object at 0x88dd0
In the `B` case `__new__` is not overridden (in the sense that it
differs from object.__new__) but `__init__` is. Which is the default
behaviour. Nonetheless a warning is raised.
I used the pattern with the __new__ switch to achieve a
cStringIO.StringIO behavior that supports typechecks: IterIO() returns
either a IterI or IterO object, both instances of IterIO so that
typechecks can be performed.
Real-world use case here:
http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/contrib/iterio.py
--
messages: 82497
nosy: aronacher
severity: normal
status: open
title: Python 2.6 object.__new__ argument calling autodetection faulty
type: behavior
versions: Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5322
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5322] Python 2.6 object.__new__ argument calling autodetection faulty
Armin Ronacher armin.ronac...@active-4.com added the comment: The problem seems to be caused by tp_new being slot_tp_new which then invokes whatever __new__ in the class dict is. I'm not so sure what would be the solution to this. One could of course check if tp_new is either object_new or slot_tp_new and in the latter case check if the class dict's __new__ item is object_new... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5284] platform.linux_distribution() improperly documented
New submission from Armin Ronacher armin.ronac...@active-4.com: platform.linux_distribution() was added in 2.6 as an alias for platform.dist(). However the documentation lists platform.dist() as an alias for platform.linux_distribution() and there is no information that the latter appered in 2.6 whereas the former exists since 2.4 I think. Not sure what the fix is, but it should be documented properly with .. versionadded:: 2.6. -- assignee: lemburg components: Documentation keywords: easy messages: 82273 nosy: aronacher, lemburg priority: normal severity: normal status: open title: platform.linux_distribution() improperly documented type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
Armin Ronacher armin.ronac...@active-4.com added the comment: literal_eval has eval() semantics and not complex() constructor semantics. It accepts what eval() accepts just without arithmetic and unsafe features. For exmaple (2 + 4j) is perfectly fine even though the complex call only supports 2+4j (no parentheses and whitespace). I commit the fix with the ValueError except Georg suggested. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
Armin Ronacher armin.ronac...@active-4.com added the comment: Indeed, it accepts parentheses in 2.6 now, but not in 2.5 or earlier. Why not the other way round? Somewhere there has to be a limit. And if you write down complex numbers you usually have the imaginary part after the real part. But let's try no to make this a bikeshed discussion. If you say that literal_eval can safely evaluate the repr() of builtins (with the notable exception of reprs that eval can't evaluate either [like nan, inf etc.]) and probably a bit more it should be fine :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
Armin Ronacher armin.ronac...@active-4.com added the comment: Fixed in rev68571. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
Armin Ronacher armin.ronac...@active-4.com added the comment: Why didn't you use assertRaises in place of that try/except for a test ? Could be changed. I was somewhat following this issue and just saw it being commited, but the change was being discussed. Aren't you supposed to commit these kind of changes only after entering in agreement with others ? The needs review keyowrd was removed, I was under the impression I can commit now :) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
Armin Ronacher armin.ronac...@active-4.com added the comment: Here a patch with unittests to correctly handle complex numbers. This does not allow the user of arbitrary add/sub expressions on complex numbers. Added file: http://bugs.python.org/file12707/literal-eval.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
New submission from Armin Ronacher armin.ronac...@active-4.com: ast.literal_eval does not properly handle complex numbers: ast.literal_eval(1j) 1j ast.literal_eval(2+1j) Traceback (most recent call last): ... ValueError: malformed string ast.literal_eval((2+1j)) Traceback (most recent call last): ... ValueError: malformed string Expected result: ast.literal_eval(1j) 1j ast.literal_eval(2+1j) (2+1j) ast.literal_eval((2+1j)) (2+1j) I attached a patch that fixes this problem. -- components: Library (Lib) files: literal-eval.patch keywords: needs review, patch, patch messages: 79548 nosy: aronacher priority: normal severity: normal stage: patch review status: open title: ast.literal_eval does not properly handled complex numbers type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file12674/literal-eval.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4907] ast.literal_eval does not properly handled complex numbers
Armin Ronacher armin.ronac...@active-4.com added the comment: fixed patch :) Added file: http://bugs.python.org/file12675/literal-eval.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4590] 2to3 strips trailing L for long iterals in two fixers
New submission from Armin Ronacher [EMAIL PROTECTED]: I noticed that fix_long and fix_numliterals both strip trailing Ls from numbers. That's redudant, one of them should be enough. I attached a patch that removes the literal changing from the fix_long fixer. Because I'm not sure if that may be the correct fixer to modify I didn't commit it but created an issue for review. -- assignee: benjamin.peterson components: 2to3 (2.x to 3.0 conversion tool) files: remove_redundant.diff keywords: needs review, patch messages: 77296 nosy: aronacher, benjamin.peterson priority: normal severity: normal stage: patch review status: open title: 2to3 strips trailing L for long iterals in two fixers type: behavior versions: 3rd party Added file: http://bugs.python.org/file12277/remove_redundant.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4590 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3563] fix_idioms.py generates bad code
Armin Ronacher [EMAIL PROTECTED] added the comment: I would drop the prefix in that case or attach it to the sorted() call. So from this code: x = foo() # perform sorting x.sort() to # perform sorting x = sorted(foo()) Makes more sense than sticking it after the sorted() call like it happens currently. This should also fix the problem with outdented statements such as except/finally. -- nosy: +aronacher ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3563 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
