Chris Angelico added the comment:
This still happens in current CPython, and doesn't even require a package:
rosuav@sikorsky:~$ echo 'from . import x' >syserr.py
rosuav@sikorsky:~$ python3 syserr.py
Traceback (most recent call last):
File "syserr.py", lin
Chris Angelico added the comment:
Linking this issue with #18018 - same problem, same situation.
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue24
Chris Angelico added the comment:
If someone made a new way of importing and had it raise ValueError on some
issue or other, I think there'd be complete consensus that that's the wrong
exception. Yes, this is incompatible with Python 2 - but there are a lot of
corner cases in the 3
Chris Hogan added the comment:
Zach,
3.x had the desired behavior. We didn't have to make any changes.
--
___
Python tracker
<http://bugs.python.org/is
Chris Hogan added the comment:
I should be able to try it out today or tomorrow. I'll let you know.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Chris Torek:
The pty.spawn() code assumes that when the process on the slave side of the pty
quits, the master side starts raising OSError when read-from or written-to.
That used to be true in FBSD, but then someone fixed (?) it, and now the master
side simply returns EOF
Changes by Chris Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue26252>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris AtLee added the comment:
Switching this to unified_diff allows the test case to finish nearly instantly.
The downside is that the output is changed in the case of a difference found:
FF
==
FAIL: test_compare (__main__
Changes by Chris AtLee :
Added file: http://bugs.python.org/file41824/cpython-issue19217.diff
___
Python tracker
<http://bugs.python.org/issue19217>
___
___
Python-bug
Chris Angelico added the comment:
Ultimately, it's the exact same thing that PEP 479 is meant to deal with -
raising StopIteration is functionally identical to returning. I don't use
asyncio enough to be certain, but I'm not aware of any good reason to inject a
StopIteration in
Chris Angelico added the comment:
POC patch, no tests. Is TypeError right? Should it be ValueError, since the
notional type is "Exception"?
--
keywords: +patch
Added file: http://bugs.python.org/file41980/no_stop_iter.patch
___
Python trac
Chris Angelico added the comment:
How about "StopException interacts badly with generators and cannot be raised
into a Future"?
--
___
Python tracker
<http://bugs.python.o
Chris Angelico added the comment:
Wording changed, and a simple test added. I'm currently seeing failures in
test_site, but that probably means I've messed something up on my system.
--
Added file: http://bugs.python.org/file41986/no_stop_
Chris Angelico added the comment:
Opened https://github.com/python/asyncio/pull/322
--
___
Python tracker
<http://bugs.python.org/issue26221>
___
___
Python-bug
Chris Jerdonek added the comment:
It looks like the issue I previously filed on the Sphinx tracker was migrated
here: https://github.com/sphinx-doc/sphinx/issues/996 . But the patch I
submitted seems to have been dropped.
--
___
Python tracker
Chris Jerdonek added the comment:
This is simply a reduced test case to illustrate the issue more clearly. There
was more to it in how I was using it in practice.
--
___
Python tracker
<http://bugs.python.org/issue24
Chris Angelico added the comment:
Question: Is it worth having an explanation somewhere of exactly what *does*
happen? To what extent is it guaranteed by the language?
--
___
Python tracker
<http://bugs.python.org/issue26
Chris Angelico added the comment:
Sounds good to me. Replacement patch.
--
Added file: http://bugs.python.org/file42182/deco-docos.patch
___
Python tracker
<http://bugs.python.org/issue26
Chris Angelico added the comment:
Sure - changing it to "roughly". I started with that wording, and then changed
to "broadly", for reasons which I now can't remember - so they can't have been
too important. Consistency wins.
--
Added file: http://
New submission from Chris Angelico:
The official documentation declares an unambiguous equivalence which is not
true in some corner cases:
@deco
def f(x): pass
is not quite the same as
def f(x): pass
f = deco(f)
as the name is never bound to the undecorated function. This is
Chris Angelico added the comment:
I may be a committer, but I don't push to cpython - just to the peps. But sure,
pretty little logo :)
--
___
Python tracker
<http://bugs.python.org/is
Chris Angelico added the comment:
The remaining difference that's actually of use, perhaps. But the decoration
itself happens before the name is bound. It's impossible to describe in Python
code; but it can be probed - you can monkeypatch a class using a decorator:
def monke
New submission from Chris Mitchell:
assertRaises has callableObj listed as a keyword, though it is not possible to
use it as a keyword when the callableObj takes arguments.
The function definition is:
def assertRaises(self, excClass, callableObj=None, *args, **kwargs):
Therefore, using
Changes by Chris Angelico :
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue26763>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Angelico added the comment:
Typo fixed in peps repo.
--
___
Python tracker
<http://bugs.python.org/issue26763>
___
___
Python-bugs-list mailing list
Unsub
Changes by Chris Angelico :
--
nosy: +Rosuav
___
Python tracker
<http://bugs.python.org/issue26805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Angelico added the comment:
By "doesn't keep track of call chains", you mean that it can't handle
mutually-recursive functions, right?
Still useful.
--
nosy: +Rosuav
___
Python tracker
<http://bug
New submission from Chris Beaumont:
http://bugs.python.org/issue16270 identified an issue with
ftpwrapper.endtransfer that causes ftp fetches to hang in certain situations. A
fix was applied to python 3. I see the same issue on python 2.7, and the patch
from 16270 fixes it. Is there a reason
Changes by Chris Beaumont :
--
keywords: +patch
Added file: http://bugs.python.org/file42728/urllib.patch
___
Python tracker
<http://bugs.python.org/issue26
Changes by Chris Kaynor :
--
nosy: +DragonFireCK
___
Python tracker
<http://bugs.python.org/issue23515>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue23622>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Chris Abiad added the comment:
Running through each of the demos, it seems as though only 'penrose' and 'tree'
have console/shell output.
'penrose' output is a list of information about the current rendering and has a
format like:
Calculation:0.0009 s
Drawing
Chris Abiad added the comment:
The original problem was described as:
"the character is printed at the start of the current line rather than the
start of the next line."
I haven't gotten too far investigating the cause, but adding a single line to
the sample code makes this
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:
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:
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
Changes by Chris Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue24064>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Angelico added the comment:
Stinner, not sure what you mean by first part / second part. Is there a way for
me to withdraw the first two versions of the patch and just keep #37646?
--
___
Python tracker
<http://bugs.python.org/issue22
Chris Angelico added the comment:
You sure can! Take it, deploy it, run the test suite, and then start writing
real code that uses it. When you find a problem, that's what needs help! :)
--
___
Python tracker
<http://bugs.python.org/is
Chris Angelico added the comment:
The comment was general because I honestly had no idea what was needed still.
All I knew was that the patch seemed to work for me, all tests passing
(including the new one). Thanks for uploading the new patch; it compiles
happily, and I'm running test
Chris Angelico added the comment:
Thanks everyone for all the help getting this to land! This is going to be a
part of my active python3 binary from now on :)
--
___
Python tracker
<http://bugs.python.org/issue22
Chris Angelico added the comment:
Weird. Tests ran fine on my machine too. Interestingly, that number is
0xdbdbdbdbdbdbdbda - does that mean anything? (It's negative
0x2424242424242426, for what that's worth.)
--
___
Python trac
Chris Angelico added the comment:
Another couple of tests, per comments.
--
Added file: http://bugs.python.org/file44425/moar-tests.patch
___
Python tracker
<http://bugs.python.org/issue27
Chris Angelico added the comment:
Just ran into the same issue, but in a slightly different way, and with
slightly different consequences. You can actually eliminate this failure by
manually running compileall on the affected directory:
sudo python3 -m compileall /usr/local/lib/python3.6/site
Chris Angelico added the comment:
Thanks Brett! Sounds like a plan.
--
___
Python tracker
<http://bugs.python.org/issue27080>
___
___
Python-bugs-list mailin
New submission from Chris Nyland:
I have recently developed a action for the argparse module that allows
arguments to be read in from configuration files. It is different in
functionality than the convert_arg_line_to_args in that the file path(s) is
passed to the action and then opened. This
Chris Angelico added the comment:
Huh. Yeah, that would work really nicely. Thanks Christian!
Does this count as a bugfix? I think we've missed 3.6 feature freeze.
--
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
An idea occurred to me on this recently. Instead of changing TextTestResult to
call test.id() everywhere instead of str(test), what about making
TextTestResult DRY by having it call a new method called something like
self.getName(test)?
With this approach
New submission from Chris Angelico:
Discussion on python-ideas led to a firm ruling by Guido that enum members are
functionally equivalent to constants, and should thus be named in upper-case.
This is contrary to the current documentation. Solution? Change the docs.
--
assignee: docs
New submission from Chris Rao:
In the second code block in the section on autospeccing in
https://docs.python.org/3/library/unittest.mock.html#auto-speccing, assert is
spelled as "assret"
>>> mock = Mock(name='Thing', return_value=None)
>>> mock(1, 2, 3)
Chris Angelico added the comment:
I'm not sure. The patch got backed out with little explanation, so presumably
it broke something somewhere, but I don't know what.
--
___
Python tracker
<http://bugs.python.o
Chris Angelico added the comment:
Also working for me. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue27322>
___
___
Python-bugs-list mailin
New submission from Chris Meyer:
BaseEventLoop.close shuts down the executor associated with the event loop.
It should do that BEFORE it sets self._closed = True, otherwise any pending
executor futures will attempt to 'call_soon' on the event loop when they
finish, resulting in a
New submission from Chris Byers:
The configure.ac file adds the "-g" debug compiler option to both debug and
non-debug builds, so debug information is built for production builds. This
seems likely a bug, unless there was a specific reason to do this.
Around line 1480 of co
Changes by Chris Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue28537>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Barker added the comment:
Agreed:
the custom dict type would be nice for a recipe or blog post or...
but not for the docs.
I'll note that the other trick to this recipe is that you need to know to use
lambda to make a "None factory" for defaultdict -- though maybe tha
2701 - 2758 of 2758 matches
Mail list logo
