Chris Jerdonek added the comment:
> It shouldn't be the __qualname__ of the wrapped function
Yes, I agree with you. I was thinking it should be similar to what it would be
for a function defined at the same location.
--
___
Python tracker
<
Chris Jerdonek added the comment:
Okay, I thought a partial object was supposed to "look" like a function.
I'm okay with closing this.
--
resolution: -> rejected
___
Python tracker
<https://bugs.pytho
Chris Jerdonek added the comment:
Using p.func would name the function passed to functools.partial() rather than
the partial object itself.
--
___
Python tracker
<https://bugs.python.org/issue34
New submission from Chris Jerdonek :
functools.partial objects have no __qualname__ attribute. This means, for
example, that code expecting a callable that logs the __qualname__ attribute
can break when passed a functools.partial object.
Example:
>>> import functools
>>>
Chris Jerdonek added the comment:
I just learned of this issue. Rather than adding has_netloc, etc. attributes,
why not use None to distinguish missing values as is preferred above, but add a
new boolean keyword argument to urlparse(), etc. to get the new behavior (e.g.
"allow
Chris Jerdonek added the comment:
> The RFC treats empty authority and no authority as different cases.
I'm not well-versed on this. But I guess this means urllib.parse doesn't
support this distinction. For example:
>>> urllib.parse.urlsplit('file:/foo')
SplitResult(
Chris Jerdonek added the comment:
Thanks for all the extra info. A couple more comments:
1. I came across this issue when diagnosing the following pip issue ("pip
install git+file://" not working for Windows UNC paths):
https://github.com/pypa/pip/issues/3783
2. URLs of the
New submission from Chris Jerdonek :
urllib.parse doesn't seem to round-trip file URI's containing multiple leading
slashes. For example, this--
import urllib.parse
def round_trip(url):
parsed = urllib.parse.urlsplit(url)
new_url = urllib.parse.urlunsplit(parsed
Change by Chris Jerdonek :
--
assignee: chris.jerdonek ->
___
Python tracker
<https://bugs.python.org/issue15533>
___
___
Python-bugs-list mailing list
Un
Chris Jerdonek <chris.jerdo...@gmail.com> added the comment:
Eric touched on the use when he said the following above:
> It's nice to be able to distinguish between the failure to *find* the module
> during import from other uses of ImportError.
To make up one example, you might
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Chris Jerdonek <chris.jerdo...@gmail.com>:
This issue is to suggest enhancing sys.path to recognize path-like objects, per
PEP 519.
I recently ran into an issue where a path was getting added to sys.path, but
the corresponding imports weren't working as they should
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
versions: +Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Chris Jerdonek added the comment:
A couple thoughts on this issue:
First, I think the OP's original issue could perhaps largely be addressed
without having to change cancel()'s signature. Namely, simply passing a
hard-coded string to CancelledError in the couple spots that CancelledError
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Chris Jerdonek added the comment:
By the way, I see this exact issue was also raised and discussed here, with a
couple responses by Guido, too:
https://github.com/python/asyncio/issues/253
--
___
Python tracker <rep...@bugs.python.org>
Chris Jerdonek added the comment:
I noticed that the future defined by asyncio.gather(sleep) is in a "pending"
state immediately after the asyncio.TimeoutError.
One workaround is to wait for the cancellation to finish:
@asyncio.coroutine
def main():
sleep = asyncio
New submission from Chris Jerdonek:
In Python 3.6.1, if asyncio.wait_for() times out with a TimeoutError, the
traceback doesn't show what line the code was waiting on when the timeout
occurred. This makes it more difficult to diagnose the cause of a timeout.
To reproduce, you can use
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
title: shutdown_asyncgens -> asyncio: Optimize loop.call_soon
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
title: asyncio: Optimize loop.call_soon -> shutdown_asyncgens
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Chris Jerdonek added the comment:
> there's no way to end the loop on the producing side.
I might be missing something, but can't something similar be said of
queue.get()?
--
___
Python tracker <rep...@bugs.python.org>
<http://bug
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
components: +asyncio
nosy: +yselivanov
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
title: document the new behavior of get_event_loop() Python 3.6 -> document the
new behavior of get_event_loop() in Python 3.6
___
Python tracker <rep...@bugs.pytho
New submission from Chris Jerdonek:
Currently, the Python asyncio.get_event_loop() docs don't say that
get_event_loop() returns the currently running event loop when it is called
from a coroutine:
https://docs.python.org/3/library/asyncio-eventloops.html#asyncio.get_event_loop
https
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Chris Jerdonek added the comment:
Note that the example can be further simplified by replacing user() with:
async def send_hello(g):
print("sending: hello")
await g.asend("hello")
Then the output is:
sending: hello
received hello
sending: hello
sending:
New submission from Chris Jerdonek:
When installing from source, the --quiet option works with "configure" and a
bare "make":
$ ./configure --quiet
$ make --quiet
However, it doesn't seem to work when passed to "make install" (and "make
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
Chris Jerdonek added the comment:
> We can't solve that problem; only Apple can;
> So, if we don't change _scproxy or urllib*'s use of it, only Apple can fix
> the problem.
In the Django ticket I mentioned in my comment above, one of the commenters
said, "Just ran the tests at
Chris Jerdonek added the comment:
FWIW, I just came across an issue in Django's test suite that I believe is
caused by the issue reported here. Some of Django's unit tests were hanging for
me when run in "parallel" mode (which uses multiprocessing). Here is the ticket
I filed th
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Chris Jerdonek:
When installing Python 3.5.2 from source on Ubuntu 14.04 and running
make, I get the below "Could not find platform dependent libraries"
warnings (which I prefixed with "***" for better visibility).
>From this message which has more bac
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Chris Jerdonek added the comment:
> Are there any issue *we* have with libffi which an update to 3.2.1 would
> solve ?
There are these Ubuntu-specific compiler warnings:
https://bugs.python.org/issue25077
which Berker says have been fixed in upstream libffi:
https://bugs.pyth
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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 <
New submission from Chris Jerdonek:
I came across a situation where Popen.wait() hangs and os.waitpid() doesn't
hang. It seems like a bug, but I don't know for sure. This is with Python
3.5.1.
To reproduce, save the following to demo.py:
import os, signal, subprocess
class State
Chris Jerdonek added the comment:
More information:
No hang: 2.7.11, 3.3.6, 3.4.0
Hang: 3.4.1 3.4.3, 3.5.0, 3.5.1
Is this a regression or a bug fix? Maybe issue #21291 is related which was
fixed in 3.4.1. Also, this is on Mac OS X 10.11 for me.
--
nosy: +gregory.p.smith
Chris Jerdonek added the comment:
Thanks for looking into this so quickly.
> os.waitpid(p.pid, 1) is os.waitpid(p.pid, os.WNOHANG) which is a non-blocking
> operation so it works.
For the record, it also works with "os.waitpid(p.pid, 0)." I should have
written 0 the first
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>:
--
title: Popen.wait() hangs when called from a signal handler when
os.waitpid(pid, os.WNOHANG) does not -> Popen.wait() hangs when called from a
signal handler when os.waitp
Chris Jerdonek added the comment:
I guess this isn't limited just to the raise from syntax. It also occurs if
from exc is removed from the example above.
--
title: unittest swallows part of stack trace using raise from with
AssertionError - unittest swallows part of stack trace when
New submission from Chris Jerdonek:
When newlines are present, the error message displayed by unittest's
self.assertEqual() to show where strings differ can be nonsensical. For
example, the caret symbol can show up in a strange location.
The first example below shows a case where things work
New submission from Chris Jerdonek:
I have observed that when running unit tests using unittest's test discovery,
unittest can simultaneously (1) modify sys.path unnecessarily (by adding a path
that is already in sys.path with a different case), and (2) modify sys.path by
adding a path
New submission from Chris Jerdonek:
The documentation for os.path.normcase(path) is currently confusing or
self-contradictory.
Currently, it reads--
Normalize the case of a pathname. On Unix and Mac OS X, this returns the path
unchanged; on case-insensitive filesystems, it converts the path
New submission from Chris Jerdonek:
pathlib's relative_to(other) can give a confusing message when other is
os.curdir.
For example--
Python 3.4.2 (default, Nov 12 2014, 18:23:59)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin
Type help, copyright, credits
Chris Jerdonek added the comment:
By the way, here is another (less) confusing error message:
Path(foo).relative_to(fo)
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4
Chris Jerdonek added the comment:
Was this also fixed for Mac OS X? Mac OS X is also case-insensitive by
default, and on Python 3.4.2 I'm getting:
Path(Foo).relative_to(foo)
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/local/Library/Frameworks
New submission from Chris Jerdonek:
This issue is to improve the organization of the PyPI section of the Distutils
documentation, now that the information has been combined into one page.
A patch is attached.
Improvements include:
(1) Creating a section for command options common to both
Chris Jerdonek added the comment:
The refs output also complicates testing in some cases, e.g.
http://hg.python.org/cpython/file/bc4458493024/Lib/test/test_subprocess.py#l61
http://hg.python.org/cpython/file/bc4458493024/Lib/test/test_subprocess.py#l786
--
nosy: +chris.jerdonek
Chris Jerdonek added the comment:
The file gets created in the current working directory. You won't see it when
using regrtest since regrtest creates and then deletes a temp working directory.
To see it easier, try running instead:
./python.exe -m unittest test.test_posixpath
Chris Jerdonek added the comment:
Similar to as I stated in issue 17315, you won't see it when using regrtest
since regrtest creates and then deletes a temp working directory.
The file gets created and is left behind in the current working directory. Try
running using unittest, e.g
Chris Jerdonek added the comment:
Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17312
___
___
Python-bugs-list mailing list
Unsubscribe
Chris Jerdonek added the comment:
Thanks, I confirmed the fix.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17315
___
___
Python-bugs-list
Chris Jerdonek added the comment:
The first and/or main place that recommends hg graft should link to the
section with more detail for cases where users experience problems with graft.
I also agree that the section should mention the case-folding error. I'm using
a pretty new version of hg
Chris Jerdonek added the comment:
Extending regrtest to support unittest test discovery directly is also a
worthwhile specific proposal.
Updating the tests to support discovery in all cases is discussed in (meta)
issue 16748. There are also many individual issues in the tracker (one per
Chris Jerdonek added the comment:
Ezio, did you delete the section on null-merging in your commits? I don't see
it in the devguide anymore.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
Chris Jerdonek added the comment:
Currently the section covers all the fundamental Mercurial-related operations
that a committers needs to know (set up, commit, merge, push), not just
committing.
The point of the change in section title is to have a title so non-committers
know they can
Chris Jerdonek added the comment:
Why must we mention graft at all? I've never had a need for it. It seems
simpler and just as effective to run `hg import` on the original patch.
I think it's preferable that the steps we recommend to work on all systems.
Then we won't have to worry about
Chris Jerdonek added the comment:
AFAICT, the recommendation to use hg git format is currently only mentioned
in the Committing section
(http://docs.python.org/devguide/committing.html#minimal-configuration) but
not elsewhere, in particular, not http://docs.python.org/devguide/patch.html
Chris Jerdonek added the comment:
I think making the sections more focused helps because sections are the
linkable units, and sections can be freely moved around once they are more
stand-alone (e.g. into or out of the FAQ).
In issue 16931 in response to Ned, I suggested adding a general
Chris Jerdonek added the comment:
If you start with a patch against 3.x, which is the normal case, why go to the
trouble of grafting from the patch modified for 2.7? It seems you're just
creating more trouble for yourself (introducing more conflicts you have to
resolve, etc) when you already
Chris Jerdonek added the comment:
Reapplying the patch means that I have to do import + commit at least, and
possibly reapply manually changes that I've already done on 2.7.
Since 2.7 is more different from 3.2 than is 3.4, it seems more likely that
grafting from 2.7 to 3.x will result
Chris Jerdonek added the comment:
Thanks a lot for the review, Petri.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17283
Chris Jerdonek added the comment:
The fix for issue 17283 has been committed now, which should make this slightly
easier to fix (e.g. change one place instead of two).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15305
Chris Jerdonek added the comment:
Thanks a lot for taking the time to review, guys.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16406
New submission from Chris Jerdonek:
As suggested by Éric in a Rietveld comment to issue 16406, this issue is to
make the PyPI package display section of the distutils docs use the right
terminology:
It’s too bad this part of the documentation use “package” with the meaning
used on PyPI
Chris Jerdonek added the comment:
I created issue 17311 for a suggestion Éric made on Rietveld.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16406
Chris Jerdonek added the comment:
Here is a patch that updates Geoff's patch to the latest code, and addresses
the directory creation issue.
--
Added file: http://bugs.python.org/file29269/issue15305-3.patch
___
Python tracker rep...@bugs.python.org
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
stage: - patch review
type: - enhancement
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15305
New submission from Chris Jerdonek:
test_aifc's AIFCLowLevelTest.test_write_aiff_by_extension() leaves a test file
behind. I'm not sure what other versions are affected.
--
keywords: easy
messages: 183175
nosy: chris.jerdonek, r.david.murray
priority: normal
severity: normal
stage
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
components: +Tests
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17312
___
___
Python-bugs
New submission from Chris Jerdonek:
test_logging leaves behind a file called test.log in the current working
directory. I haven't narrowed down to the specific test, and I'm not sure what
other versions are affected.
--
components: Tests
messages: 183176
nosy: chris.jerdonek
New submission from Chris Jerdonek:
test_posixpath leaves behind a file of the following form when running on Mac
OS X:
lrwxr-xr-x @test_17700_tmpa - @test_17700_tmpa/b
I'm not sure which test it is or which other versions are affected.
--
components: Tests
messages: 183178
nosy
Chris Jerdonek added the comment:
The link for convenience:
http://docs.python.org/dev/distutils/packageindex.html#pypi-package-display
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17311
Chris Jerdonek added the comment:
Thanks for investigating.
Yes, currently regrtest.py deletes the containing directory. But this doesn't
happen when running with plain unittest. If each test cleans up after itself,
this will give us more flexibility in moving from regrtest to a unittest
Chris Jerdonek added the comment:
I still fail to understand what are you trying to achieve.
My goal is to reach consensus on changes and have them committed. In its
current form, I don't agree with the patch. The length of the comment thread
and the length of the patch has discouraged me
Chris Jerdonek added the comment:
For the record, I don't recall *any* changes being made to any of the patches
in response to mine or others' comments, other than dividing them up. So we're
not talking about perfection. If they're going to be committed as is, it might
as well be one patch
Chris Jerdonek added the comment:
But, surely at this point, it would be easier to get meaningful additional
review after the current set of changes are committed rather than continually
redoing a large set of patches.
This was my reason for asking early on that the changes be proposed
New submission from Chris Jerdonek:
As discussed in issue 14468, this issue is to reorder the sections in the
devguide's committing.rst to create a section dedicated to using Mercurial when
committing. The attached patch is adapted from the 2-move_two_sections.diff
patch of that issue
Chris Jerdonek added the comment:
As discussed above and because this comment thread is getting very long, I'm
going to start proposing smaller issues off of this one. In this way we can
start committing as we reach agreement, and hash out any disagreements in more
focused contexts around
Chris Jerdonek added the comment:
I don't think support.temp_cwd() should be changed for this issue (or needs to
be). Also, changing it in the proposed way could mask errors in the test suite
since tests were written against the current behavior.
regrtest.py and __main__.py should both
Chris Jerdonek added the comment:
Attaching patch.
The use of global TEMPDIR isn't ideal. Alternatively, TEMPDIR's value when
sysconfig.is_python_build() is true can be set when initially setting TEMPDIR:
http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l203
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17283
Chris Jerdonek added the comment:
Attaching an improved patch.
This patch improves the introductory wording, adds some additional hyperlinks,
and changes the order of one of the inserted sections.
--
Added file: http://bugs.python.org/file29227/issue-16406-4.patch
Chris Jerdonek added the comment:
Here is a new patch which does not use the global keyword.
--
Added file: http://bugs.python.org/file29228/issue-17283-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17283
Chris Jerdonek added the comment:
Thanks, Jyrki and Petri. I just noticed that a Changed in version should
probably be added at the end of this section:
http://docs.python.org/dev/library/unittest.html#unittest.main
*defaultTest* should probably also be documented in the text (it currently
Chris Jerdonek added the comment:
I can take care of the Changed in version.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15132
___
___
Python
New submission from Chris Jerdonek:
This issue is to document the defaultTest parameter to unittest.main():
http://docs.python.org/dev/library/unittest.html#unittest.main
Note that it is not enough simply to say that *defaultTest* is a default test
name or iterable of test names
Chris Jerdonek added the comment:
*defaultTest* should probably also be documented in the text
I created issue 17282 for this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15132
Chris Jerdonek added the comment:
FYI, the fix for issue 16403 adds I believe the first mention of PKG-INFO to
the docs (as an aside when discussing the maintainer field). However, a
description of PKG-INFO, etc. should still be added somewhere
Chris Jerdonek added the comment:
I would be happy to commit and watch the buildbots, once I have confidence in
the patch though. Question: I noticed that the following was changed in
Lib/test/regrtest.py:
-with support.temp_cwd(TESTCWD, quiet=True):
+with support.temp_cwd(quiet=True
New submission from Chris Jerdonek:
As discussed here:
http://bugs.python.org/issue15305#msg182853
this issue is for Lib/test/__main__.py to share code with Lib/test/regrtest.py
to minimize duplication of code:
http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l1594
http
Chris Jerdonek added the comment:
Those two code chunks should really share code by the way
I created issue 17283 for this (it's okay to fix the current issue before this
one).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
201 - 300 of 1573 matches
Mail list logo
