[issue34475] functools.partial objects have no __qualname__ attribute
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 <https://bugs.python.org/issue34475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34475] functools.partial objects have no __qualname__ attribute
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.python.org/issue34475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34475] functools.partial objects have no __qualname__ attribute
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/issue34475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34475] functools.partial objects have no __qualname__ attribute
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 >>> int.__qualname__ 'int' >>> p = functools.partial(int) >>> p.__qualname__ Traceback (most recent call last): File "", line 1, in AttributeError: 'functools.partial' object has no attribute '__qualname__' -- components: Library (Lib) messages: 323947 nosy: chris.jerdonek priority: normal severity: normal status: open title: functools.partial objects have no __qualname__ attribute type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22852] urllib.parse wrongly strips empty #fragment, ?query, //netloc
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_none" to parallel "allow_fragments")? It seems like this would be more elegant, IMO, because it would lead to the API we really want. For example, the ParseResult(), etc. signatures and repr() values would be simpler. Changing the default value of the new keyword arguments would also provide a clean and simple deprecation pathway in the future, if desired. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue22852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes
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(scheme='file', netloc='', path='/foo', query='', fragment='')
>>> urllib.parse.urlsplit('file:///foo')
SplitResult(scheme='file', netloc='', path='/foo', query='', fragment='')
>>> urllib.parse.urlsplit('file:/foo') == \
urllib.parse.urlsplit('file:///foo')
True
Both have authority / netloc equal to the empty string, even though in the
first example the authority isn't present per your comment.
--
___
Python tracker
<https://bugs.python.org/issue34276>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes
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 form "file:root" (with four or more leading slashes) are
perhaps not valid URI's technically. See Section 3. "Syntax Components" of RFC
3986, where it says, "When authority [i.e. netloc] is not present, the path
cannot begin with two slash characters ('//')":
https://tools.ietf.org/html/rfc3986#section-3
However, I don't think that means Python shouldn't try to roundtrip it
successfully. Also, git-clone is apparently okay with URLs of this form, and
does the right thing with them.
--
___
Python tracker
<https://bugs.python.org/issue34276>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes
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)
print(f'{url} [{parsed}]\n{new_url}')
print('ROUNDTRIP: {}\n'.format(url == new_url))
for i in range(4):
round_trip('file://{}root/a'.format(i * '/'))
results in--
file://root/a [SplitResult(scheme='file', netloc='root', path='/a',
query='', fragment='')]
file://root/a
ROUNDTRIP: True
file:///root/a [SplitResult(scheme='file', netloc='', path='/root/a',
query='', fragment='')]
file:///root/a
ROUNDTRIP: True
file:root/a [SplitResult(scheme='file', netloc='', path='//root/a',
query='', fragment='')]
file://root/a
ROUNDTRIP: False
file:/root/a [SplitResult(scheme='file', netloc='', path='///root/a',
query='', fragment='')]
file:///root/a
ROUNDTRIP: False
URI's of the form file:// occur, for example, when one
wants to git-clone a UNC path on Windows:
https://stackoverflow.com/a/2520121/262819
Here is where CPython defines urlunsplit():
https://github.com/python/cpython/blob/4e11c461ed39085b8495a35c9367b46d8a0d306d/Lib/urllib/parse.py#L465-L482
(The '//' special-casing seems to occur in this line here:
https://github.com/python/cpython/blob/4e11c461ed39085b8495a35c9367b46d8a0d306d/Lib/urllib/parse.py#L473
)
And here is where the round-tripping is tested:
https://github.com/python/cpython/blob/4e11c461ed39085b8495a35c9367b46d8a0d306d/Lib/test/test_urlparse.py#L156
(Three initial leading slashes is tested, but not the problem case of four or
more.)
--
components: Library (Lib)
messages: 322652
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: urllib.parse doesn't round-trip file URI's with multiple leading slashes
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34276>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows
Change by Chris Jerdonek : -- assignee: chris.jerdonek -> ___ Python tracker <https://bugs.python.org/issue15533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15767] add ModuleNotFoundError
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 want to use a fallback module if a package isn't installed: try: from fancy_parser import NewParser as HTMLParser except ModuleNotFoundError: from html.parser import HTMLParser But you might still want an error if the package is installed, though incorrectly (e.g. fancy_parser is installed, but an old version that doesn't have NewParser). Catching ImportError would swallow this error, whereas ModuleNotFoundError would let it bubble up. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32643] Make Task._step, Task._wakeup and Future._schedule_callback methods private
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32642] add support for path-like objects in sys.path
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, even though sys.path showed the path as being present. Eventually I tracked this down to the path being a pathlib.Path object rather than a string. This wasn't obvious because Path objects appear as strings in normal debug output, etc. The sys.path docs currently say this: > Only strings and bytes should be added to sys.path; all other data types are > ignored during import. -- components: Library (Lib) messages: 310560 nosy: brett.cannon, chris.jerdonek priority: normal severity: normal status: open title: add support for path-like objects in sys.path type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23859] asyncio: document behaviour of wait() cancellation
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23859] asyncio: document behaviour of wait() cancellation
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue23859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25612] nested try..excepts don't work correctly for generators
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25683] __context__ for yields inside except clause
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18861] Problems with recursive automatic exception chaining
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad
Change by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31033] Add argument to .cancel() of Task and Future
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 is
raised would cause the exception to display:
https://github.com/python/cpython/blob/733d0f63c562090a2b840859b96028d6ec0a4803/Lib/asyncio/futures.py#L153
https://github.com/python/cpython/blob/733d0f63c562090a2b840859b96028d6ec0a4803/Lib/asyncio/futures.py#L173
The "raise CancelledError" could be changed to "raise CancelledError('future is
cancelled')", a bit like how InvalidStateError is handled a couple lines later:
if self._state == _CANCELLED:
raise CancelledError
if self._state != _FINISHED:
raise InvalidStateError('Result is not ready.')
Second, in terms of making cancellations easier to debug, is it a deliberate
design decision that the CancelledError traceback "swallows" / doesn't show the
point at which the coroutine was cancelled?
For example, running the following code--
async def run():
await asyncio.sleep(100)
loop = asyncio.new_event_loop()
task = asyncio.ensure_future(run(), loop=loop)
loop.call_later(2, task.cancel)
loop.run_until_complete(task)
Results in the following output:
Traceback (most recent call last):
File "test-cancel.py", line 46, in
loop.run_until_complete(task)
File "/Users/.../python3.6/asyncio/base_events.py", line 466,
in run_until_complete
return future.result()
concurrent.futures._base.CancelledError
In particular, it doesn't show that the task was waiting on
asyncio.sleep(100) when the task was cancelled. It would be very useful to
see full tracebacks in these cases. (Sorry in advance if this second point is
off-topic for this issue.)
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31033>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31033] Add argument to .cancel() of Task and Future
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29432] wait_for(gather(...)) logs weird error message
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> <http://bugs.python.org/issue29432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29432] wait_for(gather(...)) logs weird error message
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.sleep(0.2)
future = asyncio.gather(sleep)
try:
yield from asyncio.wait_for(future, timeout=0.1)
except asyncio.TimeoutError:
print(f'future: {future}')
try:
yield from future
except asyncio.CancelledError:
print(f'future: {future}')
yield from asyncio.sleep(0.1)
asyncio.get_event_loop().run_until_complete(main())
Outputs:
future: <_GatheringFuture pending>
future: <_GatheringFuture finished exception=CancelledError()>
Another option is to pass return_exceptions=True to gather(). This appears to
make the log messages you were concerned about go away:
future: <_GatheringFuture pending>
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29432>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31131] asyncio.wait_for() TimeoutError doesn't provide full traceback
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 the following code:
import asyncio
async def run():
print('running...')
await asyncio.sleep(100)
def main(coro):
loop = asyncio.new_event_loop()
future = asyncio.wait_for(coro, timeout=1)
loop.run_until_complete(future)
main(run())
It gives the following output (notice that the sleep() line is missing):
$ python test-timeouterror.py
running...
Traceback (most recent call last):
File "test-timeouterror.py", line 12, in
main(run())
File "test-timeouterror.py", line 10, in main
loop.run_until_complete(future)
File "/Users/.../python3.6/asyncio/base_events.py", line 466,
in run_until_complete
return future.result()
File "/Users/.../python3.6/asyncio/tasks.py", line 356, in wait_for
raise futures.TimeoutError()
concurrent.futures._base.TimeoutError
It seems like it should be possible to show the full traceback because, for
example, if I register a signal handler with loop.add_signal_handler() as
described here:
https://mail.python.org/pipermail/async-sig/2017-August/000374.html
and press Control-C before the timeout occurs, I do get a full traceback
showing the line:
await asyncio.sleep(100)
--
components: Library (Lib), asyncio
messages: 299845
nosy: chris.jerdonek, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.wait_for() TimeoutError doesn't provide full traceback
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31131>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28600] asyncio: Optimize loop.call_soon
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- title: shutdown_asyncgens -> asyncio: Optimize loop.call_soon ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28600] shutdown_asyncgens
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- title: asyncio: Optimize loop.call_soon -> shutdown_asyncgens ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28777] Add asyncio.Queue __aiter__, __anext__ methods
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://bugs.python.org/issue28777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28777] Add asyncio.Queue __aiter__, __anext__ methods
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30935] document the new behavior of get_event_loop() in Python 3.6
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- components: +asyncio nosy: +yselivanov ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30935] document the new behavior of get_event_loop() in Python 3.6
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.python.org> <http://bugs.python.org/issue30935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30935] document the new behavior of get_event_loop() Python 3.6
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://docs.python.org/3/library/asyncio-eventloops.html#asyncio.AbstractEventLoopPolicy.get_event_loop This is new behavior that was introduced in Python 3.6 in this issue: https://github.com/python/asyncio/pull/452 Without this, the docs make it seem like get_event_loop() should return the loop that was last passed to set_event_loop(). This could be added with a "Changed in version 3.6" note. -- assignee: docs@python components: Documentation messages: 298380 nosy: chris.jerdonek, docs@python priority: normal severity: normal status: open title: document the new behavior of get_event_loop() Python 3.6 versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29930] Waiting for asyncio.StreamWriter.drain() twice in parallel raises an AssertionError when the transport stopped writing
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30773] async generator receives wrong value when shared between coroutines
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: hello
received None
received None
--
nosy: +chris.jerdonek
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30773>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29985] make install doesn't seem to support --quiet
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 altinstall", etc). I tried a number of variations like: $ make --quiet install $ make install --quiet etc. The install output is quite verbose, so it would be useful to support --quiet. This should still allow warnings, etc, through like it does for configure and bare make. -- components: Installation messages: 291143 nosy: chris.jerdonek priority: normal severity: normal status: open title: make install doesn't seem to support --quiet type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16288] TextTestResult uses TestCase.__str__() which isn't customisable (vs id() or shortDescription())
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, customizing the test name would simply be a matter of subclassing TextTestResult and overriding TextTestResult.getName() (which unittest makes easy). This is much easier than trying to modify the test cases themselves (which unittest doesn't make easy). It's also more natural as the responsibility for formatting should lie with the test result classes rather than with the test case classes themselves (e.g. as discussed in #22431). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes
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 the mentioned commit on my macOS Sierra public beta with a fresh 3.5.2 python environment. No problems there." (https://code.djangoproject.com/ticket/27086#comment:4 ) In other words, the issue that affected me on Mac OS X El Capitan (whose root cause is this issue I believe) wasn't present in Sierra. Do you think this means Apple has addressed the issue in the next version of its OS? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes
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 there: https://code.djangoproject.com/ticket/27086 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27713] Spurious "platform dependent libraries" warnings when running make
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 background, these warnings are apparently harmless: https://mail.python.org/pipermail/python-dev/2016-August/145783.html -DHGBRANCH="\"`LC_ALL=C `\"" \ -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-Werror=declaration-after-statement -I. -IInclude -I./Include-DPy_BUILD_CORE -o Programs/_freeze_importlib.o Programs/_freeze_importlib.c gcc -pthread -o Programs/_freeze_importlib Programs/_freeze_importlib.o Modules/getbuildinfo.o Parser/acceler.o [**snipped for brevity**] Modules/xxsubtype.o -lpthread -ldl -lutil -lm if test "no" != "yes"; then \ ./Programs/_freeze_importlib \ ./Lib/importlib/_bootstrap.py Python/importlib.h; \ fi ***: Could not find platform dependent libraries ***: Consider setting $PYTHONHOME to [:] if test "no" != "yes"; then \ ./Programs/_freeze_importlib \ ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h; \ fi ***: Could not find platform dependent libraries ***: Consider setting $PYTHONHOME to [:] gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-Werror=declaration-after-statement -I. -IInclude -I./Include-DPy_BUILD_CORE -o Python/frozen.o Python/frozen.c rm -f libpython3.5m.a ar rc libpython3.5m.a Modules/getbuildinfo.o -- components: Installation messages: 272186 nosy: chris.jerdonek priority: normal severity: normal status: open title: Spurious "platform dependent libraries" warnings when running make versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25077] Compiler warnings: initialization from incompatible pointer type
Changes by Chris Jerdonek <chris.jerdo...@gmail.com>: -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23085] update internal libffi copy to 3.2.1
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.python.org/issue25077#msg266068 -- nosy: +chris.jerdonek ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase
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/issue24959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15693] expose glossary link on hover
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 <rep...@bugs.python.org> <http://bugs.python.org/issue15693> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs with SIGINT when os.waitpid() does not
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:
process = None
def handle_signal(signalnum, frame):
print("Handling: {0}".format(signalnum))
p = State.process
# The following line hangs:
p.wait()
# However, this line does not hang:
# os.waitpid(p.pid, 1)
print("Done waiting")
signal.signal(signal.SIGINT, handle_signal)
p = subprocess.Popen("while true; do echo sleeping; sleep 2; done",
shell=True)
State.process = p
p.wait()
Then run the following, hit Control-C, and it will hang:
$ python demo.py
sleeping
sleeping
^CHandling: 2
It will still hang if you insert "p.terminate()" right before p.wait().
However, calling "os.waitpid(p.pid, ...)" instead of p.wait() exits immediately
and does not hang. The behavior also occurs without shell=True.
--
components: Library (Lib)
messages: 257071
nosy: chris.jerdonek
priority: normal
severity: normal
status: open
title: Popen.wait() hangs with SIGINT when os.waitpid() does not
type: behavior
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25960>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs with SIGINT when os.waitpid() does not
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 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid(pid, os.WNOHANG) does not
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 time. Does your point still hold? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25960] Popen.wait() hangs when called from a signal handler when os.waitpid() does not
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.waitpid() does not ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase
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 raising AssertionError in a TestCase ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24780] unittest assertEqual difference output foiled by newlines
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 correctly. The second shows a newline case with the confusing display. == FAIL: test1 -- Traceback (most recent call last): File /Users/chris/***/test.py, line 66, in test1 self.assertEqual(abc, abd) AssertionError: 'abc' != 'abd' - abc ? ^ + abd ? ^ == FAIL: test2 -- Traceback (most recent call last): File /Users/chris/***/test.py, line 69, in test2 self.assertEqual(\nabcx, \nabdx) AssertionError: '\nabcx' != '\nabdx' - abcx? ^ + abdx? ^ -- components: Library (Lib) messages: 247883 nosy: chris.jerdonek priority: normal severity: normal status: open title: unittest assertEqual difference output foiled by newlines type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24780 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23097] unittest can unnecessarily modify sys.path (and with the wrong case)
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 of the wrong case. This occurs for me on Mac OS X with the default case-insensitive file system. If the path-- '/Users/chris/Dev/python/my_package' is already in sys.path, running unittest's test discovery will prepend sys.path with the following: '/Users/chris/dev/python/my_package' Aside from causing unnecessary modifications of sys.path, this also causes an issue in coverage, for example: https://bitbucket.org/ned/coveragepy/issue/348 The relevant code is here in unittest/loader.py (with `top_level_dir` starting out as os.curdir): top_level_dir = os.path.abspath(top_level_dir) if not top_level_dir in sys.path: # all test modules must be importable from the top level directory # should we *unconditionally* put the start directory in first # in sys.path to minimise likelihood of conflicts between installed # modules and development versions? sys.path.insert(0, top_level_dir) self._top_level_dir = top_level_dir (from https://hg.python.org/cpython/file/75ede5bec8db/Lib/unittest/loader.py#l259 ) The issue occurs when os.path.abspath(top_level_dir) is already in sys.path but with a different case. (Note that if os.path.abspath() returned a path with the right case, then the unittest code would be okay.) See also these two threads regarding obtaining the correct case for a path: 1. https://mail.python.org/pipermail/python-dev/2010-September/103823.html 2. https://mail.python.org/pipermail/python-ideas/2010-September/008153.html -- components: Library (Lib) messages: 232993 nosy: chris.jerdonek priority: normal severity: normal status: open title: unittest can unnecessarily modify sys.path (and with the wrong case) type: behavior versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23097 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23079] os.path.normcase documentation confusing
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 to lowercase. However, with a case-insensitive file system on Mac OS X (e.g. File System Personality: Journaled HFS+), normcase() does not convert paths to lowercase. As it stands, it seems like the clause on case-insensitive filesystems, it converts the path to lowercase should be removed or further qualified. I don't know what the qualification is though. -- assignee: docs@python components: Documentation, Library (Lib) messages: 232871 nosy: chris.jerdonek, docs@python priority: normal severity: normal status: open title: os.path.normcase documentation confusing type: behavior versions: Python 2.7, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23082] pathlib relative_to() can give confusing error message
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 or license for more information. import os from pathlib import Path Path(/foo).relative_to(os.curdir) Traceback (most recent call last): File stdin, line 1, in module File /opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/pathlib.py, line 806, in relative_to .format(str(self), str(formatted))) ValueError: '/foo' does not start with '' I guess the error here is that the path must be relative when other is relative. -- components: Library (Lib) messages: 232876 nosy: chris.jerdonek priority: normal severity: normal status: open title: pathlib relative_to() can give confusing error message type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23082] pathlib relative_to() can give confusing error message
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/pathlib.py, line 806, in relative_to .format(str(self), str(formatted))) ValueError: 'foo' does not start with 'fo' Without knowing that foo is a path, the message seems wrong. If it said something like Path 'foo' does not start with part 'fo', it would be clearer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23082 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19918] PureWindowsPath.relative_to() is not case insensitive
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/Python.framework/Versions/3.4/lib/python3.4/pathlib.py, line 806, in relative_to .format(str(self), str(formatted))) ValueError: 'Foo' does not start with 'foo' -- nosy: +chris.jerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17325] improve organization of the PyPI distutils docs
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 register and upload. Previously, this information was confined to the upload section, even though the information was applicable to both commands. (2) Separating general information about PyPI (e.g. PyPI user permissions and the web interface) from the information about Distutils command usage. (3) Consolidating information about the .pypirc file in the .pypirc section. Previously, some of the .pypirc information was spread throughout the upload section, even though the information is equally applicable to the register command. -- assignee: eric.araujo components: Distutils, Documentation files: issue-pypi-docs.patch keywords: patch messages: 183252 nosy: chris.jerdonek, eric.araujo, tarek priority: normal severity: normal stage: patch review status: open title: improve organization of the PyPI distutils docs type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file29281/issue-pypi-docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17323] Disable [X refs, Y blocks] ouput in debug builds
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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17323 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17315] test_posixpath doesn't clean up after itself
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 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17312] test_aifc doesn't clean up after itself
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. ./python.exe -m unittest test.test_aifc.AIFCLowLevelTest.test_write_aiff_by_extension -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17312] test_aifc doesn't clean up after itself
Chris Jerdonek added the comment: Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17315] test_posixpath doesn't clean up after itself
Chris Jerdonek added the comment: Thanks, I confirmed the fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16930] mention limitations and/or alternatives to hg graft
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 (version 2.2.1+20120504) and get the error. (Mercurial's web site is down right now so I can't tell if it's the newest released version still.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10967] move regrtest over to using more unittest infrastructure
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 test module). -- dependencies: +Make CPython test package discoverable ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17284] create mercurial section in devguide's committing.rst
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 skip over the section. I'm not wedded to the title I initially suggested. Mercurial Guide for Committers is another possibility. Mercurial information common to both committers and non-committers can go in a more generally titled section like Working with Mercurial. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16930] mention limitations and/or alternatives to hg graft
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 documenting quirks, or responding to e-mails or tracker issues saying our recommended steps don't work. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16931] mention work-around to create diffs in default/non-git mode
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. Good observation. Personally, I think it makes sense to keep Mercurial information for both committers and non-committers (like configuring to use the git format) outside of the Mercurial section specific to committers. This can be in a general Mercurial section before the section specific to committers, or else spread throughout (e.g. in the FAQ). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17284] create mercurial section in devguide's committing.rst
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 Mercurial section before the Mercurial section specific to committers. I can propose a patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16930] mention limitations and/or alternatives to hg graft
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 have a patch that is known to apply cleanly to 3.x. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16930] mention limitations and/or alternatives to hg graft
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 in having to undo 2.7-specific changes and/or add back 3.x-specific changes, and even more so when skipping 3.2. But this is all secondary to my point that we shouldn't include in our basic instructions things that we know won't work for some people when there is a straightforward alternative (and one that uses no new concepts). At the very least, we should provide a working alternative alongside. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16930 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17283] Lib/test/__main__.py should share code with regrtest.py
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15305] Test harness unnecessarily disambiguating twice
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16406] move the Uploading Packages section to distutils/packageindex.rst
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17311] use distutils terminology in PyPI package display section
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 instead of following the naming conventions used in the rest of the distutils docs (see glossary). Here I don’t know when “package” and “home page” mean pypi.python.org/project or pypi.python.org/project/release (the former being a shortcut to the latest release page). -- assignee: eric.araujo components: Distutils, Documentation keywords: easy messages: 183169 nosy: chris.jerdonek, eric.araujo, tarek priority: normal severity: normal stage: needs patch status: open title: use distutils terminology in PyPI package display section type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16406] move the Uploading Packages section to distutils/packageindex.rst
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15305] Test harness unnecessarily disambiguating twice
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 http://bugs.python.org/issue15305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15305] Test harness unnecessarily disambiguating twice
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17312] test_aifc doesn't clean up after itself
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: needs patch status: open title: test_aifc doesn't clean up after itself type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17312] test_aifc doesn't clean up after itself
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- components: +Tests ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17313] test_logging doesn't clean up after itself
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, vinay.sajip priority: normal severity: normal stage: needs patch status: open title: test_logging doesn't clean up after itself type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17315] test_posixpath doesn't clean up after itself
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 priority: normal severity: normal stage: needs patch status: open title: test_posixpath doesn't clean up after itself type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17311] use distutils terminology in PyPI package display section
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17313] test_logging doesn't clean up after itself
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-based approach (there is an issue about this). Currently, test_logging seems to be one of only a few test modules that don't do this. It's probably okay to make the fix only in 3.4 since we won't be making progress on moving away from regrtest in maintenance releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
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 from raising most of my comments, because I'm fairly certain my comments will lead to back-and-forth discussion which will make the thread even longer. That's why I want to break things up. I want to be clear that I'm not against the goals of the patch, so I'm not trying to block or stalemate anything. I just have concerns I would like to discuss which is what the review process is supposed to allow. Needless to say, I know what it feels like to have a patch reviewed in detail (which I'm not necessarily planning to do). On the plus side, it's much better than comments being against the patch outright in any form. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
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. I hope there isn't a double standard when it comes to proposing subsequent changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
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 and committed individually, so that the whole set of patches doesn't have to be redone after each round of comments: http://bugs.python.org/issue14468#msg179849 But the bulk of the discussion wound up being about this request rather than on the content of the patches themselves. I've never had a problem breaking up my own issues/patches when asked. For various reasons, there is a phenomenon that the larger the patch, the less relative scrutiny it tends to undergo (with the exception of PEP's where the process is different), which is the opposite of what it should be. I'd like for us to try to avoid that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17284] create mercurial section in devguide's committing.rst
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. -- components: Devguide files: mercurial-section-1.patch keywords: easy, patch messages: 182859 nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan, pitrou, sandro.tosi, terry.reedy, tshepang priority: normal severity: normal stage: patch review status: open title: create mercurial section in devguide's committing.rst type: enhancement Added file: http://bugs.python.org/file29217/mercurial-section-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17284 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
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 smaller patches. I will copy the nosy list unless I hear otherwise from anyone. Patch 2 could indeed committed separately, I created issue 17284 for this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15305] Test harness unnecessarily disambiguating twice
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 behave the same with respect to creating the temp dir, etc. since both invocations should work from the command-line: http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17283] Lib/test/__main__.py should share code with regrtest.py
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 -- keywords: +patch Added file: http://bugs.python.org/file29226/issue-17283-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17283 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17283] Lib/test/__main__.py should share code with regrtest.py
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17283 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16406] move the Uploading Packages section to distutils/packageindex.rst
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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16406 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17283] Lib/test/__main__.py should share code with regrtest.py
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15132] Let unittest.TestProgram()'s defaultTest argument be a list
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 appears only in the documentation signature), though this part of my comment need not be done as part of this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15132] Let unittest.TestProgram()'s defaultTest argument be a list
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-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17282] document the defaultTest parameter to unittest.main()
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. The documentation should also say when *defaultTest* is used based on the value of the *module* and *argv* arguments, etc. This issue is an offshoot of issue 15132. -- assignee: docs@python components: Documentation keywords: easy messages: 182839 nosy: chris.jerdonek, docs@python, ezio.melotti, michael.foord priority: normal severity: normal stage: needs patch status: open title: document the defaultTest parameter to unittest.main() type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17282 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15132] Let unittest.TestProgram()'s defaultTest argument be a list
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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16401] mention PKG-INFO in the documentation
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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16401 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15305] Test harness unnecessarily disambiguating twice
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, path=TESTCWD): But the corresponding change wasn't made in Lib/test/__main__.py (which I believe is the code path used by Geoff's `./python.exe -m test -j3` invocation): http://hg.python.org/cpython/file/96f08a22f562/Lib/test/__main__.py#l12 Those two code chunks should really share code by the way (even the code comment is copied verbatim), which would help in not needing to update code in two places as in this issue/patch. Perhaps that should even be done first as part of a separate issue (to separate this into smaller changes). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17283] Lib/test/__main__.py should share code with regrtest.py
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://hg.python.org/cpython/file/96f08a22f562/Lib/test/__main__.py#l12 -- components: Tests keywords: easy messages: 182854 nosy: chris.jerdonek, ezio.melotti, gmwils, michael.foord, petri.lehtinen, pitrou priority: normal severity: normal stage: needs patch status: open title: Lib/test/__main__.py should share code with regrtest.py type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17283 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15305] Test harness unnecessarily disambiguating twice
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/issue15305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
