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:
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
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 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:
Changes by Armin Ronacher :
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14714>
___
___
Python-bugs-
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
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 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:
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:
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:
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:
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:
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:
Is there any chance this will be fixed for 2.7 as well?
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue13
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
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
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
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:
> 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:
This commit shows why the API is problematic:
https://github.com/mitsuhiko/werkzeug/commit/c527dcbfb0ee621e9faa0a3a2873118438965800
--
___
Python tracker
<http://bugs.python.org/issue21
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:
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
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:
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
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:
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
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:
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 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:
> 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
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:
>
Changes by Armin Ronacher :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue16148>
___
___
Python-bugs-list mailing list
Unsubscri
Armin Ronacher added the comment:
Reviewed and applied. Looks good.
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue16148>
___
___
Python-bug
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:
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:
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:
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:
I see what you did there :P
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue12575>
___
___
Python-bug
Changes by Armin Ronacher :
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue6210>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Ronacher :
--
assignee: -> loewis
nosy: +loewis
___
Python tracker
<http://bugs.python.org/issue11574>
___
___
Python-bugs-list mai
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
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
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
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:
> 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
Changes by Armin Ronacher :
Removed file: http://bugs.python.org/file19008/find-caller.patch
___
Python tracker
<http://bugs.python.org/issue9948>
___
___
Python-bug
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
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
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 :
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
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
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:
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:
> 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:
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:
> 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:
Interestingly even PHP handles that properly.
--
___
Python tracker
<http://bugs.python.org/issue9867>
___
___
Python-bug
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
Changes by Armin Ronacher :
--
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue9867>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
Changes by Armin Ronacher :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue9775>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Armin Ronacher :
--
keywords: +patch
Added file: http://bugs.python.org/file18746/9775-fix.patch
___
Python tracker
<http://bugs.python.org/issue9
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
New submission from Armin Ronacher :
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 expec
Armin Ronacher 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.
Armin Ronacher 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
<http://bugs.python.
Changes by Armin Ronacher :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue6945>
___
___
Python-bugs-list mailing list
Unsubscri
Armin Ronacher added the comment:
Duplicate of #3976
--
resolution: -> duplicate
___
Python tracker
<http://bugs.python.org/issue6945>
___
___
Python-bugs-lis
Changes by Armin Ronacher :
--
nosy: +aronacher
___
Python tracker
<http://bugs.python.org/issue3976>
___
___
Python-bugs-list mailing list
Unsubscribe:
Armin Ronacher added the comment:
Yes. Appears to be related.
--
___
Python tracker
<http://bugs.python.org/issue6945>
___
___
Python-bugs-list mailin
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
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
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:
> @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:
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
Changes by Armin Ronacher :
___
Python tracker
<http://bugs.python.org/issue5397>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/o
Armin Ronacher 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
Armin Ronacher 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
Armin Ronacher 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
Armin Ronacher 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
ca
Armin Ronacher 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 instan
Armin Ronacher 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 "
Changes by Armin Ronacher :
--
title: mimetypes.MAGIC_FUNCTION implementation clusterfuck ->
mimetypes.MAGIC_FUNCTION performance problems
___
Python tracker
<http://bugs.python.org/iss
New submission from Armin Ronacher :
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 d
Armin Ronacher 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
Armin Ronacher 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
Armin Ronacher 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 l
New submission from Armin Ronacher :
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):
...
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:
> 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
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:
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:
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:
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:
fixed patch :)
Added file: http://bugs.python.org/file12675/literal-eval.patch
___
Python tracker
<http://bugs.python.org/issue4
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_
Changes by Armin Ronacher <[EMAIL PROTECTED]>:
--
stage: patch review -> committed/rejected
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
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
1 - 100 of 121 matches
Mail list logo
