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
<ht
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#L9
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.pyt
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:
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
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
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
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 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:
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 Ronacher added the comment:
Reviewed and applied. Looks good.
--
nosy: +aronacher
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16148
Changes by Armin Ronacher armin.ronac...@active-4.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16148
___
___
Python
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
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
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
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
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
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
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
Changes by Armin Ronacher armin.ronac...@active-4.com:
--
assignee: - loewis
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11574
Changes by Armin Ronacher armin.ronac...@active-4.com:
--
nosy: +aronacher
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6210
___
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Armin Ronacher armin.ronac...@active-4.com:
--
nosy: +aronacher
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3976
___
___
Python-bugs
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
Changes by Armin Ronacher armin.ronac...@active-4.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6945
___
___
Python
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
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
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
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
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
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
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
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
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
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
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
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__
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 130 matches
Mail list logo