Change by Ben Spiller :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue40687>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Ben Spiller :
The py.exe launcher doc states "If no relevant options are set, the commands
python and python2 will use the latest Python 2.x version installed" ... which
was indeed working reliably until Microsoft added their weird python.exe shim
(which either
Ben Spiller added the comment:
Looks like on WSL the errno is errno.EACCES rather than EPERM, so we just need
to change the shutil._copyxattr error handler to also cope with that error code:
except OSError as e:
- if e.errno not in (errno.EPERM, errno.ENOTSUP
New submission from Ben Spiller :
The built-in profiling modules only provide information about the main thread
(at least when invoked as documented).
To avoid user confusion we should state this in the documentation at
https://docs.python.org/3/library/profile.html.
Potentially we could
Ben Spiller added the comment:
Thanks... yep I realise method calls are slower than operators, am hoping we
can still find a cunning way to speed up this use case nonetheless. :D For
example by having a configuration option on dict (or making a new subclass)
that gives the (speedy
New submission from Ben Spiller :
In performance-critical python code, it's quite common to need to get an item
from a dictionary, falling back on a default (e.g. None, 0 etc) if it doesn't
yet exist. The obvious way to do this based on the documentation is to call the
dict.get() method
Ben Spiller added the comment:
Interesting conversation. :)
Yes I agree correctness is definitely top priority. :) I'd go further and say
I'd prefer correctness to be always there automatically, rather than something
the user must remember to enable by setting a flag
Ben Spiller added the comment:
I'd definitely suggest we go for a solution that doesn't hit performance of
normal logging when you're not adding/removing things, being as that's the more
common case. I guess that's the reason why callHandlers was originally
implemented without grabbing
Ben Spiller added the comment:
Running this command:
time python -c "import re; re.compile('y.*x').search('y'*(N))"
It's clearly quadratic:
N=100,000 time=7s
N=200,000 time=18s
N=400,000 time=110s
N=1,000,000 time=690s
This illustrates how a simple program that's working cor
Ben Spiller added the comment:
Correction to original report - it doesn't hang indefinitely, it just takes a
really long time. Specifically, looks like it's quadratic in the length of the
input string. Increase the size of the input string to 1000*1000 and it's
really really slow.
I don't
New submission from Ben Spiller :
These work fine and return instantly:
python -c "import re; re.compile('.*x').match('y'*(1000*100))"
python -c "import re; re.compile('x').search('y'*(1000*100))"
python -c "import re; re.compile('.*x').search('y'*(1000*10
New submission from Ben Spiller :
I just came across a fairly serious thread-safety / race condition bug in the
logging.Loggers class, which causes random log lines to be lost i.e. not get
passed to some of the registered handlers, if (other, unrelated) handlers are
being added/removed using
Change by Ben Spiller :
--
nosy: +Ben Spiller
___
Python tracker
<https://bugs.python.org/issue5166>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ben Spiller added the comment:
To help anyone else struggling with this bug, based on
https://lsimons.wordpress.com/2011/03/17/stripping-illegal-characters-out-of-xml-in-python/
the best workaround I've currently found is to define this:
def escape_xml_illegal_chars(unicodeString
Ben Spiller added the comment:
Hi it's been a few years now since this was reported and it's still a problem,
any chance of a fix for this? The API gives the impression that if you pass
python strings to the XML API then the library will generate valid XML. It
takes care of the charset
Ben Spiller added the comment:
Thanks for considering this, anyway. I'll admit I'm disappointed we couldn't
fix this on the 2.7 train, as to me fixing a method that takes an
errors='ignore' argument and then throws an exception anyway seems a little
more like a bug than a feature
Ben Spiller added the comment:
btw If anyone can find the place in the code (sorry I tried and failed!) where
str.encode('utf-8', error=X) is resulting in an implicit call to the equivalent
of decode(defaultencoding, errors=strict) (as suggested by the exception
message) I think it'll
Ben Spiller added the comment:
I'm proposing that str.encode() should _not_ throw a 'decode' exception for
non-ascii characters and be effectively a no-op, to match what it already does
for ascii characters - which therefore shouldn't break behavior anyone will be
depending on. This could
Ben Spiller added the comment:
yes the situation is loads better in python 3, this issue is specific to 2.x,
but like many people sadly we're not able to move to 3 for the time being.
Since making this mistake is quite common and there's some sensible behaviour
that would make it disappear
Ben Spiller added the comment:
Thanks that's really helpful
Having thought about it some more, I think if possible it'd be really so much
better to actually 'fix' the behaviour for the unicode<->str standard codecs
(i.e. not base64) rather than just documenting around it. The c
New submission from Ben Spiller:
It's well known that lots of people struggle writing correct programs using
non-ascii strings in python 2.x, but I think one of the main reasons for this
could be very easily fixed with a small addition to the documentation for
str.encode and unicode.decode
21 matches
Mail list logo
