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
&
Armin Ronacher 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
Armin Ronacher 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
Armin Ronacher added the comment:
2.7 does not suffer from this since 2.7 does not support unicode in headers.
--
___
Python tracker
<http://bugs.python.org/issue10
Armin Ronacher added the comment:
I see what you did there :P
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue12575>
___
___
Python-bug
New submission from Armin Ronacher :
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 whe
Changes by Armin Ronacher :
--
keywords: +patch
Added file: http://bugs.python.org/file18746/9775-fix.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Armin Ronacher :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue9775>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Ronacher 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
> destructo
Armin Ronacher 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
New submission from Armin Ronacher :
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
Changes by Armin Ronacher :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue9867>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Ronacher 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 ins
Armin Ronacher added the comment:
Interestingly even PHP handles that properly.
--
___
Python tracker
<http://bugs.python.org/issue9867>
___
___
Python-bug
Armin Ronacher 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 loo
Armin Ronacher added the comment:
The following minimal C code shows how EINTR can be handled:
#include
#include
#include
#include
#define BUFFER_SIZE 1024
int
main()
{
char buffer[BUFFER_SIZE];
printf("PID = %d\n", getpid());
while (1) {
int rv = f
Armin Ronacher 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
Armin Ronacher 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
Armin Ronacher 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.
--
versio
Armin Ronacher 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 (r
New submission from Armin Ronacher :
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
New submission from Armin Ronacher :
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
New submission from Armin Ronacher :
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 agains
Changes by Armin Ronacher :
Added file: http://bugs.python.org/file19009/find-caller.patch
___
Python tracker
<http://bugs.python.org/issue9948>
___
___
Python-bugs-list m
Changes by Armin Ronacher :
Removed file: http://bugs.python.org/file19008/find-caller.patch
___
Python tracker
<http://bugs.python.org/issue9948>
___
___
Python-bug
Armin Ronacher 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 l
New submission from Armin Ronacher :
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
New submission from Armin Ronacher :
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 fa
Changes by Armin Ronacher :
--
assignee: -> loewis
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11574>
___
___
Python-bugs-list mai
Changes by Armin Ronacher :
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue6210>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Armin Ronacher :
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
Armin Ronacher added the comment:
Georg Brandl signed off the commit and Python 3.2 will ship with the HTTP
server accepting latin1 bytes.
--
___
Python tracker
<http://bugs.python.org/issue10
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
This is actually not a bug. copy_location does not work recursively.
For this example it's more useful to use the "fix_missing_locations"
function which traverses the tree and copies the locations from the
parent no
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
Just for the record. This original discussion for this bug is here:
http://article.gmane.org/gmane.comp.python.devel/96925
--
nosy: +aronacher
___
Python tracker <[EMAIL PROTECTE
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
The root of the problem is that ast.AST doesn't have _fields or
_attributes. I think the better solution is to add these attributes to
the root class which makes it easier to work with these objects.
I attached a diff for asdl
Changes by Armin Ronacher:
--
components: Library (Lib)
nosy: aronacher
severity: normal
status: open
title: Small _abcoll Bugs / Oddities
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
New submission from Armin Ronacher:
_abcoll.py references intertools.chain but doesn't import it. This
breaks Set subclasses. Additionally the abstract base classes don't
provide the right hand operator callbacks or how you want to call them.
So __add__ is there but __radd__ not
Changes by Armin Ronacher:
--
nosy: +aronacher
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2246>
__
___
Python-bugs-list mailing list
Unsubs
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
nosy: +aronacher
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2321>
__
___
Python-bugs
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
nosy: +aronacher
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1810>
__
___
Python-bugs
New submission from Armin Ronacher <[EMAIL PROTECTED]>:
Currently python raises an exception if one tries to copy or deepcopy
Ellpisis. The former is usually no problem but if an ellipsis ends up
on an object and becomes deepcopied this is pretty annoying.
The patch provided adds Ellip
New submission from Armin Ronacher <[EMAIL PROTECTED]>:
#2505 adds a new init to the ast nodes that allows initialization of the
fields directory from the constructor. Unfortunately there are nodes
where fields is None (_ast.Store and others) and the constructor didn't
take care of
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
Fixed in changeset 66973 for trunk.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4067>
___
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
Fixed in changeset 66984.
--
resolution: -> fixed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
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
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
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
This could probably be fixed by adding a `is_builtin` helper function to
the fixer_util module that checks if the name is not overriden in the
module. I would use something like a weak dictionary for the
`find_binding` function becaus
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
Since yesterday there is a handy little helper that adds imports to
files which is already used for the reduce() / intern() fixers. This
makes this fix a lot easier.
I attached a version that does that.
However the import adder is n
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
nosy: +aronacher
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2899>
___
__
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
nosy: +aronacher
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2454>
___
__
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
nosy: +aronacher
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2805>
___
__
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
2to3 could handle it, but it would be a lot of work for something
unnecessary. You can use "s.replace(a, b)" instead of string.replace(s,
a, b) since at least 2.0.
___
Python tracker &
Armin Ronacher <[EMAIL PROTECTED]> added the comment:
Patch applied in [67679].
The tests were nearly the same, even with the same numbers :)
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PR
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
stage: patch review -> committed/rejected
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Armin Ronacher :
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_
Armin Ronacher added the comment:
fixed patch :)
Added file: http://bugs.python.org/file12675/literal-eval.patch
___
Python tracker
<http://bugs.python.org/issue4
Armin Ronacher 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
Armin Ronacher 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&q
Armin Ronacher 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
Armin Ronacher added the comment:
Fixed in rev68571.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue4907>
___
___
Python-bugs-lis
Armin Ronacher 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
> thes
New submission from Armin Ronacher :
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
Armin Ronacher added the comment:
Yes, I'm definitely still interested in this. I still carry this hack around.
--
status: pending -> open
___
Python tracker
<https://bugs.python.org
Armin Ronacher 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
New submission from Armin Ronacher :
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
sev
Armin Ronacher added the comment:
Reviewed and applied. Looks good.
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue16148>
___
___
Python-bug
Changes by Armin Ronacher :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16148>
___
___
Python-bugs-list mailing list
Unsubscri
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
<http://bugs.python.org/is
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 a
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
conf
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
<http://bugs.python.org/issue21
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 som
Armin Ronacher added the comment:
I should add that we still support non OpenSSL hashers, but we go a different
path.
--
___
Python tracker
<http://bugs.python.org/issue21
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
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.e
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:
>>&g
Armin Ronacher added the comment:
Is there any chance this will be fixed for 2.7 as well?
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue13
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/ma
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
<http://bugs.py
Armin Ronacher added the comment:
I can confirm that calling detach() in __del__ within an except block solves
the issue.
--
___
Python tracker
<http://bugs.python.org/issue21
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:
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 librar
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
<http://bugs.python.o
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
<h
Changes by Armin Ronacher :
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14714>
___
___
Python-bugs-
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:
>
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 cann
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',
...
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
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 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
<http://bugs.python.org/issue20
Armin Ronacher 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
<http://bugs.python.org/issue6
Armin Ronacher 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
Armin Ronacher 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
Armin Ronacher 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 a
New submission from Armin Ronacher :
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
1 - 100 of 121 matches
Mail list logo
