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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
New submission from Armin Rigo:
The docs still say that the default __hash__() is equal to id(), but that's not
the case since Python 2.7.
--
assignee: docs@python
components: Documentation
files: lang-ref-fix.diff
keywords: patch
messages: 215517
nosy: arigo, docs@python
priority
Changes by Armin Rigo ar...@users.sourceforge.net:
--
assignee: arigo -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1617161
___
___
Python-bugs
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
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
Armin Rigo added the comment:
Sorry to hijack CPython's bug tracker for that, but can you check if this makes
sense to you? I added a function 'locals_to_fast()' to the __pypy__ built-in
module which just calls the PyPy equivalent to PyFrame_LocalsToFast(). Your
tests are passing, so I
Armin Rigo added the comment:
CPython 2.7 is in feature-freeze, so we need to add it to __pypy__. If people
here decide to add it more officially to CPython 3.x, then we'll also add it
into pypy3, obviously. I'm sure a debugger can cope with a few extra ifs to
check on which platform
Armin Rigo added the comment:
Hi Fabio! This is admittedly a corner-case use case, but if you think it would
be worth it, we can very easily add this as a feature to PyPy (by making
frame.f_locals writeable). Then we can add the write inside pdb, and you could
do the same for PyDev when
Armin Rigo added the comment:
Also, can you provide a concrete case? Trying around in CPython 2.7, it seems
that locals of the current frame can always be modified from a pdb.set_trace().
--
___
Python tracker rep...@bugs.python.org
http
Armin Rigo added the comment:
Instances of 'staticmethod' or 'classmethod' are not callable. I'm unsure why
not, but it's good enough, as you need to go through various unexpected hops in
order to try to call one.
'dict.fromkeys' is not a classmethod, as seen by dict.__dict__['fromkeys
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
Armin Rigo added the comment:
PyPy 2.x accepts null characters in all of import, exec and eval, and complains
if they occur in non-comment.
PyPy 3.x refuses them in import, which is where this bug report originally
comes from (someone complained that CPython 3.x accepts them but not PyPy
3.x
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
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
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
Armin Rigo added the comment:
Fwiw, both exec and eval() ban NUL bytes, which means that there is a strange
case in which some files can be imported, but not loaded and exec'ed. So I
agree with Benjamin.
--
___
Python tracker rep
New submission from Armin Rigo:
This is probably the smallest example of a .py file that behaves differently in
CPython vs PyPy, and for once, I'd argue that the CPython behavior is
unexpected:
# make the file:
open('x.py', 'wb').write('#\x00\na')
# run it:
python x.py
Expected
New submission from Armin Rigo:
This is a repeat of the old issue 532860: NameError assigning to class in a
func. It is about class statements' variable lookups, which has different
behavior at module level or in a nested scope:
def f(n):
class A:
n = n # doesn't work, tries
Armin Rigo added the comment:
As you can see in x.py, the underlying question is rather: are weakdicts usable
in a single thread of a multithreaded program? I believe that this question
cannot reasonably be answered No, independently on the answer you want to give
to your own question
Armin Rigo added the comment:
Am I correct in thinking that you're simply replacing the OSError(EINTR) with
returning empty lists? This is bound to subtly break code, e.g. the code that
expects reasonably that a return value of three empty lists means the timeout
really ran out (i.e
Armin Rigo added the comment:
Modules/socketmodule.c is using a simple style to implement socket timeouts
using select(). If I were to naively copy this style over to pure Python, it
would work in current Pythons; I'd get occasionally an OSError(EINTR), which I
would have presumably been
(hopefully) all the missing ``os.xxx()`` functions,
including ``os.startfile()`` on Windows and a handful of rare ones
on Posix.
* numpy has a rudimentary C API that cooperates with ``cpyext``
Cheers,
Armin Rigo and Maciej Fijalkowski
--
https://mail.python.org/mailman/listinfo/python-announce
New submission from Armin Rigo:
WeakValueDictionary.setdefault() contains a bug that shows up in multithreaded
situations using reference cycles. Attached a test case: it is possible for
'setdefault(key, default)' to return None, although None is never put as a
value in the dictionary
Changes by Armin Rigo ar...@users.sourceforge.net:
Added file: http://bugs.python.org/file32557/x.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19542
Changes by Armin Rigo ar...@users.sourceforge.net:
Added file: http://bugs.python.org/file32558/weakref.slice
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19542
Armin Rigo added the comment:
'list' doesn't, precisely.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19414
___
___
Python-bugs-list mailing
Armin Rigo added the comment:
Hi Raymond! Yes, I had the same reaction at first, but then it seemed to be
possible to implement a reasonably good behavior with almost no performance hit.
Plainly undefined behaviors are a mess for other implementations because in
half of the big projects
Armin Rigo added the comment:
Another option for the try harder to raise RuntimeError category (which I
tend to like, because otherwise people are bound to write programs that rely on
undocumented details):
In __delitem__() set link.next = None. In the various iterators check
explicitly
Armin Rigo added the comment:
Modifying an ordered dict while iterating over it can be officially classified
as an ok think to do, but then the precise behavior must described in the
documentation in some details, with of course matching implementation(s) and
tests. I mean
Armin Rigo added the comment:
Better remove this field if its value is now useless anyway. If someone needs
it again for a similar reason, he can contribute a patch like I did in 2002 :-)
--
___
Python tracker rep...@bugs.python.org
http
New submission from Armin Rigo:
The attached patch (which can be applied on both trunk and 2.7) gives a huge
speed improvement for the case 'pow(huge_number, smallish_number,
smallish_number)'. The improvement is unbounded: I get 20x with 'pow(x, y, z)'
with the arguments 'x = 3 ** 1, y
New submission from Armin Rigo:
It is possible to get the working copy of Python 2.7 in a state such that any
attempt to do make ends with the error shown in the title. The working copy
is perfectly valid; it is a matter of getting the wrong timestamps on the files.
(Despite the error
Armin Rigo added the comment:
The patch looks good to me. It may break existing code, though, as reported on
https://bugs.pypy.org/issue1595. I would say that it should only go to trunk.
We can always fix PyPy (at Python 2.7) in a custom manner, in a bug-to-bug
compatibility mode
Armin Rigo added the comment:
Fwiw I agree with you :-) I'm just relaying a bug report that originates on
PyPy (https://bugs.pypy.org/issue1595).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18943
Armin Rigo added the comment:
Getting consistently one behavior or the other would be much better imho; I
think it's wrong-ish to have the behavior depend uncontrollably on
implementation details. But I agree that it's slightly messy to declare which
of the two possible fixes is the right
New submission from Armin Rigo:
In argparse, default arguments have a strange behavior that shows up in
mutually exclusive groups: specifying explicitly on the command-line an
argument, but giving it its default value, is sometimes equivalent to not
specifying the argument at all
Changes by Armin Rigo ar...@users.sourceforge.net:
--
keywords: -patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18943
___
___
Python-bugs
Changes by Armin Rigo ar...@users.sourceforge.net:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18943
New submission from Armin Rigo:
Found a minor mistake in test_set.py. Patch attached.
--
components: Interpreter Core
files: test_set.diff
keywords: patch
messages: 197060
nosy: arigo
priority: normal
severity: normal
status: open
title: Minor mistake in test_set.py
versions: Python
Armin Rigo added the comment:
I believe that this describes a problem more general than the problem of Enums
from Issue18693: help(x) shouldn't crash in the presence of a __dir__() method
that returns unexpected names.
--
nosy: +arigo
___
Python
Changes by Armin Rigo ar...@users.sourceforge.net:
--
assignee: - tim.peters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18944
___
___
Python
Armin Rigo added the comment:
The __objclass__ is a workaround. I don't understand your point. I think the
original poster is saying that simply putting a __dir__() method on a class can
confuse help() more than would be necessary, and if he's correct I agree with
him
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: +arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18885
___
___
Python-bugs-list
Armin Rigo added the comment:
@Serhiy: it's a behavior change and as such not an option for a micro release.
For example, the following legal code would behave differently: it would
compute s = '\\u1234' instead of s = 'UTF8:\xe1\x88\xb4'.
try:
s = repr(x)
except
Armin Rigo added the comment:
@Serhiy: it would certainly break a program that tries to call the repr() and
catches the UnicodeEncodeError to do something else, like encode the data
differently.
--
___
Python tracker rep...@bugs.python.org
http
Armin Rigo added the comment:
For completeness, can you post one line saying why the much simpler solution
range(a).stop is not accepted?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18712
Armin Rigo added the comment:
Ah. If that's the only reason, then that seems a bit like misguided effort...
For alternative implementations like PyPy and Jython, the _operator module is
definitely one of the simplest ones to reimplement in RPython or Java. Every
function
Armin Rigo added the comment:
...but yes, it's very obvious that exposing _PyType_Lookup() to pure Python is
the right thing to do here. This is a central part of the way Python works
internally, after all.
Moreover, sorry about my previous note: if we started today to write PyPy
Armin Rigo added the comment:
Just mentioning it here again, but type(a).__index__(a) is still not
perfectly correct. Attached is a case where it differs.
I think you get always the correct answer by evaluating range(a).stop. It's
admittedly obscure... For example:
class
Armin Rigo added the comment:
The difference doesn't look significant. In all cases the TypeError is raised.
Ok, so here is another case. (I won't go to great lengths trying to convince
you that there is a problem, because the discussion already occurred several
times; google for example
Armin Rigo added the comment:
This may have been the most recent discussion of this idea (as far as I can
tell):
http://mail.python.org/pipermail//python-ideas/2012-August/016036.html
Basically, it seems to be still unresolved in the trunk Python; sorry, I
thought by now it would have been
Armin Rigo added the comment:
Sorry, realized that my pure Python algorithm isn't equivalent to
_PyType_Lookup() --- it fails the staticmethod example of Serhiy. A closer one
would be:
for t in type(a).__mro__:
if '__index__' in t.__dict__:
return t.__dict__
Armin Rigo added the comment:
Just a side note for 2.7: could I recommend people to be really extra, extra
careful when changing what kind of regexps are accepted and what kind of
regexps are outright rejected? I believe the risk of making long-existing and
working 2.7 programs suddenly
Armin Rigo added the comment:
A slightly more complete example that I tested:
http://stackoverflow.com/a/16077568/1556290
--
nosy: +arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18033
Armin Rigo added the comment:
Brett: I don't really have a constructive opinion on this matter. I could
suggest putting a bit more logic in py_compile.compile(cfile=...) to revert to
the old behavior if we specify an already-existing target, in order to fix the
other reported issue
Armin Rigo added the comment:
That's not really what I'm after, but that's a workaround I proposed to avoid
the worst breakage. I don't have an opinion about what to do with symlinks.
--
___
Python tracker rep...@bugs.python.org
http
Armin Rigo added the comment:
The bug is different, because it doesn't depend on details of the platform.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18122
Armin Rigo added the comment:
Indeed, no clue: it seems I don't get the error only on my system-installed
2.7.3 on Linux 32. I do get it on any other Python I tried, like 2.6.x, or the
system-installed 2.7.1 on Linux 64. So it's not actually a new bug
New submission from Armin Rigo:
A new bug, introduced in recent Python 2.7 (2.7.3 passes, 2.7 trunk fails):
With the attached x.py, running python -c 'import x' fails with RuntimeError:
not holding the import lock.
It occurs when doing a fork() while holding the import lock, if the child
New submission from Armin Rigo:
If you have in x some very large number, like 3**20, then the computation
for 'str(x)' is sub-efficient. Nathan Hurst posted to the pypy-dev mailing
list a pure Python algo that gives the same result in 2/3rd of the time (in
either CPython or PyPy). We
Armin Rigo added the comment:
Thanks, I missed it. Sorry for the noise.
--
resolution: - duplicate
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18107
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18004
___
___
Python-bugs-list
Armin Rigo added the comment:
Can someone confirm the answer to Arfrever's original question: a seemingly
innocent use case of py_compile.compile(), which works fine until Python 3.3,
when executed as root, can in Python 3.4 fundamentally break down a complete
Posix system in a non-obvious
Armin Rigo added the comment:
My point is that in five years' time some existing well-tested sysadmin-like
program will be run with Python 3.4 for the first time, and suddenly whole
systems will break. I don't want to sound negative but this is the worst
behavior ever (with the possible
Armin Rigo added the comment:
Well, adding weak references left and right to break cycles is going to subtly
change or break people's code and hasn't been done so far, but that's only my
opinion. Anyway, I want to correct what you say about tp_subclasses: yes,
tp_subclasses is a list
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1545463
___
___
Python-bugs-list
New submission from Armin Rigo:
In Python 2, a buffered file opened for writing is flushed by the C library
when the process exit. In Python 3, the _pyio and _io modules don't do it
reliably. They rely on __del__ being called, which is not neccesarily the
case. The attached example ends
Armin Rigo added the comment:
It used to be a consistently reliable behavior in Python 2 (and we made it so
in PyPy too), provided of course that the process exits normally; but it no
longer is in Python 3. Well I can see the reasons for not flushing files, if
it's clearly documented
Armin Rigo added the comment:
Grrr, ok, I have an alias ls='/bin/ls'. It seems that both PATH= and
unset PATH are equivalent to PATH=.. This is behavior that we cannot add
to PYTHONPATH, I fear, because so far . is not implicitly included if
PYTHONPATH is not set. Or if we do it's a big
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16273
___
___
Python-bugs-list
Armin Rigo added the comment:
Uh, confusion. Indeed, PATH= foo finds foo in the current directory on bash.
I'm not sure how I ran the original example. It seems that a default PATH is
used, which includes at least /bin and ..
The point I was making in the original post is still valid: PATH
Armin Rigo added the comment:
You may want to add a test. This might help notice that comparing an integer
of type Py_ssize_t to check if it's greater than PY_SSIZE_T_MAX is bogus in C
:-(
--
resolution: fixed -
stage: committed/rejected - test needed
New submission from Armin Rigo:
Run this example on a 32-bit machine with more than 2GB of addressable RAM
(e.g. by default, more or less anything but Windows).
On Python 2.7 it raises SystemError: Negative size passed to
PyString_FromStringAndSize. On a debug version, it causes an assert
Changes by Armin Rigo ar...@users.sourceforge.net:
--
components: +Interpreter Core
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17645
Armin Rigo added the comment:
Modified the example to run in only 1+GB of RAM, so that it crashes also on
32-bit versions of the Python 2.7 interpreter in Windows (the most common
around, I suppose).
--
Added file: http://bugs.python.org/file29689/mem2x.py
Changes by Armin Rigo ar...@users.sourceforge.net:
--
nosy: -arigo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1173475
___
___
Python-bugs-list
Armin Rigo added the comment:
See also http://bugs.python.org/issue16576.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16575
___
___
Python
hope you have a solution for me, because it is quite urgent and
important.
I am looking forward to a quick answer!
Yours faithfully
Armin Karner--
http://mail.python.org/mailman/listinfo/python-list
New submission from Armin Rigo:
The docstring of thread.lock.acquire() (or _thread on Python 3) is bogus: it
says that if called without argument, the return value is None; it is only if
called with a blocking argument that it returns True or False. But since a
long time it was always
Armin Rigo added the comment:
FWIW, on Windows only, open('foo', 'a').tell() always returns 0, which I
think is broken too. It usually works anyway, because it updates the position
before the first .write(). But it does not work in case the writing occurs in
another process, like described
New submission from Armin Rigo:
ctypes pretends to support passing arguments to C functions that are unions
(not pointers to unions), but that's a lie. In fact, the underlying libffi
does not support it. The attached example misbehaves on Linux x86-64.
--
components: ctypes
files
Changes by Armin Rigo ar...@users.sourceforge.net:
--
type: - crash
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16575
___
___
Python-bugs-list
201 - 300 of 582 matches
Mail list logo
