Chris Angelico added the comment:
Got around to tracking down where this is actually being done. It's in
Objects/stringlib/codecs.h and it looks to be a hot area for optimization. I
don't want to fiddle with it without knowing a lot about the performance
implications (UTF-8 enc
Chris Angelico added the comment:
Had a peek at the 2.7 branch in the web
(https://hg.python.org/cpython/file/4234b0dd2a54/Lib/test) and all the tests
appear to be testing the behaviour *with* the future directive, not bothering
to test the old behaviour. It makes sense - that way, when the
Chris Angelico added the comment:
Simple test case for the future directive. Needs expansion.
--
Added file: http://bugs.python.org/file39079/test_pep479.py
___
Python tracker
<http://bugs.python.org/issue22
Chris Angelico added the comment:
Nice document. Is that actually how Python's decoder checks things? Does the
decoder have different definitions of "valid continuation byte" based on the
lead byte? If that's the case... well, ten out of ten for complying with the
s
New submission from Chris Angelico:
>>> b"\xed\xb4\x80".decode("utf-8")
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position
0: invalid continuation byte
The actual p
Changes by Chris Angelico :
--
nosy: -Rosuav
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Angelico added the comment:
*facepalm* Of course I am. I don't know how I missed that in there, but maybe I
was focusing too much on the abort that followed it to actually read the
exception text. Duh.
But with the latest version of the patch, I'm seeing something that I'
Chris Angelico added the comment:
The third version of the patch is huge compared to the other two. Is it all
important?
I'm seeing a different build failure, and with the size of patch, I'm not sure
I'm well placed to figure out what's going on.
-- cut --
Traceback (m
Chris Angelico added the comment:
I'm not sure what to look for in the code generation. In compile.c lines 3456
and following, there's a LOAD_CONST None coming through, in the else branch of
"if (e->v.Yield.value)", but nothing talking about lambda function
Chris Angelico added the comment:
Okay! I think I have something here. DEFINITELY needs more eyeballs, but all
tests pass, including a new one that tests StopIteration leakage both with and
without the __future__ directive. Some docs changes have been made (I grepped
for 'stopiteration
Changes by Chris Angelico :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue23192>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Chris Angelico:
As yield is an expression, it's legal in a lambda function, which then
means you have a generator function. But it's not quite the same as
the equivalent function made with def:
$ python3
Python 3.5.0a0 (default:1c51f1650c42+, Dec 29 2014, 02:2
Chris Angelico added the comment:
Nick, any particular reason for pointing to
https://hg.python.org/cpython/annotate/bbf16fd024df/Lib/__future__.py rather
than https://hg.python.org/cpython/annotate/tip/Lib/__future__.py ? I'm looking
at both, a
Changes by Chris Angelico :
Added file: http://bugs.python.org/file37641/stopiter.py
___
Python tracker
<http://bugs.python.org/issue22906>
___
___
Python-bugs-list mailin
Chris Angelico added the comment:
PyErr_Restore doesn't seem to trigger exception chaining. But thanks for the
tip about explicitly setting the traceback; not sure how I missed that, but now
the StopIteration traceback is visible.
Minor point: The previous patch was setting the __context
Chris Angelico added the comment:
I can have a poke at the __future__ import tonight, but my main concern is
memory management - I'm not sufficiently familiar with the exception handling
calls to be sure that I'm neither leaking nor over-freeing anything. There's
also a seconda
New submission from Chris Angelico:
Creating an issue to keep track of a patch, but this probably wants to be
discussed on python-ideas.
The attached patch allows a Python function to be put into sys.__getglobal__,
which then works like __getattr__ but for global names. This allows
Chris Angelico added the comment:
Yeah, I saw that. Since that function begins with an underscore, I thought it
best to replicate its behaviour rather than to call it. Either way ought to
work though.
--
___
Python tracker
<http://bugs.python.
Chris Angelico added the comment:
Stefan, I'm not sure - I don't know the details of the C API here. But I tried
commenting out everything but that one line, and while it does result in
RuntimeError, it doesn't do the exception chaining. Currently, I believe the
exception isn
Chris Angelico added the comment:
Known issues with the current patch, if anyone feels like playing with this who
better knows the code:
1) Needs a __future__ directive to control behaviour
2) test_generators needs to be heavily reworked
3) The test of what exception was thrown needs to also
Chris Angelico added the comment:
Sadly, I don't know of a way to check if that's the case, other than by
manually going through and eyeballing the code - if there's "raise
StopIteration", see if there's also "yield" in the same function. The three
cite
Chris Angelico added the comment:
Yep, the question is whether any of the "raise StopIteration" lines are
actually non-local flow control. If they're local, then it's easy: mechanical
replacement with "return" and it becomes compatible with all versions (unless
Chris Angelico added the comment:
Marc, are those all cases where the "raise StopIteration" is actually inside a
generator? If so, it can be trivially replaced with "return". Yes, it'll break
that way of spelling it, but it's a completely mechanical transformation
New submission from Chris Angelico:
See PEP for full details. Attached is POC patch: behaviour is altered globally
(rather than respecting a __future__ directive), and minimal changes are made
elsewhere to make the test suite mostly pass (test_generators does not - it'll
need
Chris Angelico added the comment:
Patch applies nicely to current default, and works for me on amd64 Linux. I'm
liking how this is looking.
--
___
Python tracker
<http://bugs.python.org/is
Changes by Chris Angelico :
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue21667>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Angelico added the comment:
I agree that current behaviour is a bit confusing; also, the implication is
that deleting from the dictionary while you have an iterator may leave some
hanging references around the place, which raises a red flag in my mind (maybe
something else might find
Chris Angelico added the comment:
Presumably this is not an issue in 3.x. Is this considered a bug fix (in which
case the patch should almost certainly be applied - it looks perfectly safe),
or a feature enhancement (in which case this should get closed wontfix)? Looks
like low-hanging fruit
Chris Angelico added the comment:
Patch doesn't apply to current Python trunk (18 months later). Do you know what
version you wrote this against? The current wording is different.
--
nosy: +Rosuav
___
Python tracker
<http://bugs.py
Chris Angelico added the comment:
Python doesn't currently have any sort of function for fetching all a
computer's IPs, as far as I know, but if there is one (either now or in the
future), it would be good to link to that from there. "Here's how to get your
host name. And
Changes by Chris Angelico :
Added file: http://bugs.python.org/file34252/broken.diff
___
Python tracker
<http://bugs.python.org/issue20739>
___
___
Python-bugs-list mailin
Changes by Chris Angelico :
Added file: http://bugs.python.org/file34251/churn2.diff
___
Python tracker
<http://bugs.python.org/issue20739>
___
___
Python-bugs-list mailin
Changes by Chris Angelico :
Added file: http://bugs.python.org/file34250/churn1.diff
___
Python tracker
<http://bugs.python.org/issue20739>
___
___
Python-bugs-list mailin
Chris Angelico added the comment:
I've applied all the changes my script can find, including ones that are
actually quite inappropriate, like:
try:
some_function_call()
except some_exception:
some_other_function_call()
All tests pass except for one, which I don&#x
Chris Angelico added the comment:
Thanks for the fast turn-around, guys! Not that it matters hugely - I happened
to have bytecode writing disabled to test something unrelated and noticed the
test failure.
--
___
Python tracker
<h
Chris Angelico added the comment:
One test failing, due to Tools/parser/unparse.py not knowing how to unparse an
except expression. Otherwise, test suite passes (with most of the stdlib
unchanged). I'm about to try writing an actual conversion script which will
rewrite the stdlib, and
New submission from Chris Angelico:
$ find . -name \*.pyc -delete
$ PYTHONDONTWRITEBYTECODE=1 make test
Three test failures, which all seem to be duplicates of:
==
FAIL: test_timestamp_overflow
Changes by Chris Angelico :
--
components: +Tests
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue20796>
___
___
Python-bugs-list mailin
Changes by Chris Angelico :
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue20739>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Chris Angelico:
Only noticed because I was searching the stdlib for hasattr calls, but in
mailbox.Mailbox.update(), a check is done thus:
if hasattr(arg, 'iteritems'):
source = arg.items()
elif hasattr(arg, 'items')
Chris Angelico added the comment:
Yeah. I first thought "Hey, I could just change the file names in the patch and
apply it", but then when it failed, I went looking, found the wrong piece of
code, and thought it was completely different. Turned out to be not so
different after all
Changes by Chris Angelico :
Added file:
http://bugs.python.org/file34042/0001-Add-an-authorization-header-to-the-initial-request.patch
___
Python tracker
<http://bugs.python.org/issue19
Chris Angelico added the comment:
Oops, I was reading off the wrong piece of code. It's not "distinctly
different", actually; it's just different enough that the patch fails. The only
difference is that in 3.4 the headers are Unicode strings (so the content gets
encoded
Changes by Chris Angelico :
Added file:
http://bugs.python.org/file34041/0001-Add-an-authorization-header-to-the-initial-request.patch
___
Python tracker
<http://bugs.python.org/issue19
Chris Angelico added the comment:
Patch doesn't apply to 3.4. Apart from the obvious filename change
(Lib/urllib2.py -> Lib/urllib/request.py), retry_http_basic_auth is distinctly
different in the current version. I think this will need a completely separate
patch, separately done an
Changes by Chris Angelico :
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Angelico added the comment:
Small quibble: The last sentence capitalizes a Python built-in, which is
confusing ("Len(seq_dict) must match..."). Tweak of grammar to have it not at
the beginning of the sentence: "Either way, len(seq_dict) must match...".
New submission from Chris Angelico:
When tests are run from an Upstart job in a minimal environment,
test_posix.test_initgroups fails as it attempts to find the max() of an empty
list of supplementary groups.
Problem sighted with 2.7, 3.3, and 3.x branches. Patch derived from 3.x
(default
New submission from Chris Angelico:
In an interactive session, typing 'import this' a second time doesn't produce
output (as the module's already imported). Peeking into the module shows a
string and what looks like a translation dictionary, but doing the obvious
thing:
New submission from Chris Angelico:
IDLE tries to be helpful, but it errors on something that isn't yet an error.
Pasting in this code works fine:
>>> def a():
def b():
nonlocal q
q+=1
q=1
b()
return q
>>&g
Chris Angelico added the comment:
CPython also knows the length of a string, which means that len(s) is a fast
operation. I wouldn't expect anyone to rewrite len() as:
def get_string_length(s):
length=0
for ch in s:
length+=1
return length
even though that works. No, we have a
Chris Angelico added the comment:
And of course, I make a copy/paste error in a trivial piece of example code.
def str_width(s):
width=1
for ch in map(ord,s):
if ch > 0x: return 4
if ch > 0xFF: width=2
return width
--
___
New submission from Chris Angelico:
As of PEP 393, a string's width is recorded in its header - effectively, a
marker that says whether the highest codepoint in the string is >0x, >0xFF,
or <=0xFF. This is, on some occasions, useful to know; for instance, when
testing stri
Changes by Chris Angelico :
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue17575>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Chris Angelico:
The timeit module is commonly used via the convenience function timeit.timeit,
which is listed in the documentation as the recommended "Python Interface":
http://docs.python.org/3/library/timeit.html
However, this function is not listed in __all_
Chris Angelico added the comment:
I'm experiencing a similar issue. Fresh install of 3.3 today from the .msi
installer on the web site, identifies itself as:
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
(Intel)] on win32
To reproduce: Copy and paste
New submission from Chris Angelico :
An anomaly in the argument types of similar functions:
PyImport_ImportModuleLevel takes char *, while the related functions
PyImport_AddModule, PyImport_ImportModule, and PyImport_ImportModuleNoBlock all
take const char *. This made a nuisance of itself
101 - 157 of 157 matches
Mail list logo
