[issue4376] Nested ctypes 'BigEndianStructure' fails
Changes by Jake : -- nosy: -Jake.Coffman ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4376] Nested ctypes 'BigEndianStructure' fails
Changes by Jake : -- nosy: +Jake.Coffman ___ Python tracker <http://bugs.python.org/issue4376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4655] setup.py should not use .pydistutils.cfg
New submission from Jake : When installing python 2.6, I used: ./configure --prefix=/home/name/usr Installation was fine and everything was installed to: ~/usr/lib/python2.6 But the .so files were installed to: ~/usr/lib/python As ~/usr/lib/python was (no longer) declared in my PYTHONPATH, I ran into import issues. The problem was due to a forgotten file: ~/.pydistutils.cfg So this is clearly a user error, but I wonder if it is something which should be avoided at the setup.py level. When installing python, the installation locations are derived from the results of ./configure. When setup.py is eventually called, the installation locations can change. This seems undesirable. Would it be better if setup.py instructed distutils to ignore any configuration file so that the installation directories matched what was used by the rest of 'make install'? Related: http://bugs.python.org/issue1180 -- components: Installation messages: 1 nosy: jah severity: normal status: open title: setup.py should not use .pydistutils.cfg type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue4655> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4655] during Python installation, setup.py should not use .pydistutils.cfg
Changes by Jake : -- title: setup.py should not use .pydistutils.cfg -> during Python installation, setup.py should not use .pydistutils.cfg ___ Python tracker <http://bugs.python.org/issue4655> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42063] More options to http.server & SimpleHTTPRequestHandler
New submission from Jake :
I would find it useful to have more options to http.server
SimpleHTTPRequestHandler:
1) The option to get the current directory in not only HTML, but represented in
JSON for example. This could be an added --json flag in the main method of
http.server, and an added corresponding method in SimpleHTTPRequestHandler much
like list_directory but for JSON.
2) Options to add more headers. For example I would find it useful to be able
to add the header 'Access-Control-Allow-Origin'. This could be achieved by
send_head in SimpleHTTPRequestHandler taking more arguments for specifying any
additional headers to be added.
This way a custom class can inherit SimpleHTTPRequestHandler, and in its own
send_head method call e.g.
super().send_head(extra_headers={'Access-Control-Allow-Origin','*'}).
--
components: Library (Lib)
messages: 378823
nosy: jacobsorme
priority: normal
severity: normal
status: open
title: More options to http.server & SimpleHTTPRequestHandler
type: enhancement
___
Python tracker
<https://bugs.python.org/issue42063>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42004] Allow uploading files with SimpleHTTPRequestHandler
Change by Jake : -- nosy: +jacobsorme ___ Python tracker <https://bugs.python.org/issue42004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42004] Allow uploading files with SimpleHTTPRequestHandler
Jake added the comment: I would find this very useful. -- ___ Python tracker <https://bugs.python.org/issue42004> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17196] crash
New submission from jake: I have had python 3.3.0 on my mac and have been successfully using it for the past few weeks. Today in my class I had the program open and it was running fine. Then suddenly it quit working and shut itself down. I have restarted my machine multiple times and reinstalled the program over 5 times and it still will not open at all now. Does anyone know why this might be? I am currently running OSX 10.8.2 and trying to get the python version 3.3.0 to run. I am puzzled as to why it would work fine for so long and then suddenly decide to stop and even not open after reinstallation. I would appreciate it if someone could help me troubleshoot how to get it up and running again. -- assignee: ronaldoussoren components: Macintosh messages: 181976 nosy: flynn11, ronaldoussoren priority: normal severity: normal status: open title: crash type: crash versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue17196> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17196] crash
jake added the comment: Ned, I was starting python from the applications menu and selecting IDLE. I tried both of those commands. Both worked, the first started python in terminal and displayed this message: "Last login: Tue Feb 12 16:32:21 on ttys000 localhost:~ jakeflynn$ /usr/local/bin/python3.3 Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> " , the second started up a python shell. But even though python is now open, the icon on the dock is different and none of my previous python files will open. When i try to open them, the IDLE icon im used to seeing bounces a few times and then disappears while the other python IDLE icon that started up after entering the second command line you gave me is up the whole time. -- ___ Python tracker <http://bugs.python.org/issue17196> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17196] crash
jake added the comment: It is working correctly now. Thank you for the help! -- ___ Python tracker <http://bugs.python.org/issue17196> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
New submission from Jake: In the statistics module documentation, there is a note that states that "The mean is strongly affected by outliers and is not a robust estimator for central location: the mean is not necessarily a typical example of the data points. For more robust, although less efficient, measures of central location, see median() and mode()" https://docs.python.org/3/library/statistics.html While I appreciate the intention, this is quite misleading. The implication is that the mean, median and mode are different ways to estimate one "central location", however, in reality they are very different things (albeit which refer to a similar notion). The sample mean is an unbiased estimator of the true mean but it need not be unbiased as an estimator of the true median or modes and vice versa for the median and mode. To make this clearer I would rephrase to "The mean is strongly affected by outliers and is not necessarily representative of the central tendency of the data. For cases with large outliers or very low sample size, see median() and mode()" Apologies if this is seen as frivolous, but statistics can be hard enough to remain very clear about even when the words are used precisely. -- assignee: docs@python components: Documentation messages: 236612 nosy: Journeyman08, docs@python priority: normal severity: normal status: open title: Misleading note in Statistics module documentation type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
New submission from Jake McGuire : Instance attribute names are normally interned - this is done in PyObject_SetAttr (among other places). Unpickling (in pickle and cPickle) directly updates __dict__ on the instance object. This bypasses the interning so you end up with many copies of the strings representing your attribute names, which wastes a lot of space, both in RAM and in pickles of sequences of objects created from pickles. Note that the native python memcached client uses pickle to serialize objects. >>> import pickle >>> class C(object): ... def __init__(self, x): ... self.long_attribute_name = x ... >>> len(pickle.dumps([pickle.loads(pickle.dumps(C(None), pickle.HIGHEST_PROTOCOL)) for i in range(100)], pickle.HIGHEST_PROTOCOL)) 3658 >>> len(pickle.dumps([C(None) for i in range(100)], pickle.HIGHEST_PROTOCOL)) 1441 >>> Interning the strings on unpickling makes the pickles smaller, and at least for cPickle actually makes unpickling sequences of many objects slightly faster. I have included proposed patches to cPickle.c and pickle.py, and would appreciate any feedback. -- components: Library (Lib) files: cPickle.c.diff keywords: patch messages: 80670 nosy: jakemcguire severity: normal status: open title: unpickling does not intern attribute names type: resource usage Added file: http://bugs.python.org/file12879/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Changes by Jake McGuire : Added file: http://bugs.python.org/file12880/pickle.py.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Changes by Jake McGuire : Removed file: http://bugs.python.org/file12879/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Changes by Jake McGuire : Added file: http://bugs.python.org/file12882/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Jake McGuire added the comment: Are you sure? I may not have enough context in my diff, which I should have done against an anonymous svn checkout, but it looks like the slot attributes get set several lines after my diff. "while (PyDict_Next(slotstate, ...))" as opposed to the "while (PyDict_Next(state, ...))" in my change... -jake On Jan 27, 2009, at 6:54 PM, Alexandre Vassalotti wrote: > > Alexandre Vassalotti added the comment: > > The patch for cPickle doesn't do the same thing as the pickle one. In > the cPickle one, you are only interning slot attributes, which, I > believe, is not what you intended. :-) > > -- > assignee: -> alexandre.vassalotti > nosy: +alexandre.vassalotti > > ___ > Python tracker > <http://bugs.python.org/issue5084> > ___ ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment:
I have encountered a minor bug with this new feature. The bug occurs when
creating a new multiprocessing.Process object on Unix (or on any platform where
the multiprocessing start_method is 'fork' or 'forkserver').
When creating a new process via fork, the Native ID in the new MainThread is
incorrect. The new forked process' threading.MainThread object inherits the
Native ID from the parent process' MainThread instead of capturing/updating its
own (new) Native ID.
See the following snippet:
>>> import threading, multiprocessing
>>> multiprocessing.set_start_method('fork') # or 'forkserver'
>>> def proc(): print(threading.get_native_id(),
>>> threading.main_thread().native_id) # get_native_id(), mainthread.native_id
>>> proc()
22605 22605 # get_native_id(), mainthread.native_id
>>> p = multiprocessing.Process(target=proc)
>>> p.start()
22648 22605 # get_native_id(), mainthread.native_id
>>>
>>> def update(): threading.main_thread()._set_native_id()
>>> def print_and_update(): proc(); update(); proc()
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605
>>> p2=multiprocessing.Process(target=print_and_update); p2.start()
22724 22605 # get_native_id(), mainthread.native_id
22724 22724
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605
As you can see, the new Process object's MainThread.native_id attribute matches
that of the MainThread of its parent process.
Unfortunately, I'm not too familiar with the underlying mechanisms that
Multiprocessing uses to create forked processes.
I believe this behavior occurs because (AFAIK) a forked multiprocessing.Process
copies the MainThread object from its parent process, rather than
reinitializing a new one. Looking further into the multiprocessing code, it
appears the right spot to fix this would be in the
multiprocessing.Process.bootstrap() function.
I've created a branch containing a working fix - I'm also open to suggestions
of how a fix might otherwise be implemented.
If it looks correct I'll create a PR against the CPython 3.8 branch.
See the branch here: https://github.com/jaketesler/cpython/tree/fix-mp-native-id
Thanks all!
-Jake
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue36084>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Change by Jake Tesler : -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()
New submission from Jake Tesler :
I have encountered a minor bug with the new `threading.get_native_id()`
featureset in Python 3.8. The bug occurs when creating a new
multiprocessing.Process object on Unix (or on any platform where the
multiprocessing start_method is 'fork' or 'forkserver').
When creating a new process via fork, the Native ID in the new MainThread is
incorrect. The new forked process' threading.MainThread object inherits the
Native ID from the parent process' MainThread instead of capturing/updating its
own (new) Native ID.
See the following snippet:
>>> import threading, multiprocessing
>>> multiprocessing.set_start_method('fork') # or 'forkserver'
>>> def proc(): print(threading.get_native_id(),
>>> threading.main_thread().native_id) # get_native_id(), mainthread.native_id
>>> proc()
22605 22605 # get_native_id(), mainthread.native_id
>>> p = multiprocessing.Process(target=proc)
>>> p.start()
22648 22605 # get_native_id(), mainthread.native_id
>>>
>>> def update(): threading.main_thread()._set_native_id()
>>> def print_and_update(): proc(); update(); proc()
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605
>>> p2=multiprocessing.Process(target=print_and_update); p2.start()
22724 22605 # get_native_id(), mainthread.native_id
22724 22724
>>> print_and_update()
22605 22605 # get_native_id(), mainthread.native_id
22605 22605
As you can see, the new Process object's MainThread.native_id attribute matches
that of the MainThread of its parent process.
Unfortunately, I'm not too familiar with the underlying mechanisms that
Multiprocessing uses to create forked processes.
I believe this behavior occurs because (AFAIK) a forked multiprocessing.Process
copies the MainThread object from its parent process, rather than
reinitializing a new one. Looking further into the multiprocessing code, it
appears the right spot to fix this would be in the
multiprocessing.Process.bootstrap() function.
I've created a branch containing a working fix - I'm also open to suggestions
of how a fix might otherwise be implemented.
If it looks correct I'll create a PR against the CPython 3.8 branch.
See the branch here: https://github.com/jaketesler/cpython/tree/fix-mp-native-id
Thanks all!
-Jake
--
components: Library (Lib)
messages: 356070
nosy: jaketesler, vstinner
priority: normal
severity: normal
status: open
title: Multiprocessing: bug with Native ID for threading.mainthread()
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38707>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()
Change by Jake Tesler : -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue38707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()
Change by Jake Tesler : -- keywords: +patch pull_requests: +16596 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17088 ___ Python tracker <https://bugs.python.org/issue38707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()
Jake Tesler added the comment: @vstinner PR created :) https://github.com/python/cpython/pull/17088 -- ___ Python tracker <https://bugs.python.org/issue38707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35183] os.path.splitext documentation needs typical example
Jake Stockwin added the comment: Hello, I would like to submit a PR for this. It'll be my first contribution to cPython and I am slightly unclear if this suggestion has been "accepted" in some sense (i.e. do the Devs agree it should be fixed as suggested)? If so, I will go ahead and create PR (and credit shaungriffith for his provided examples). -- nosy: +jstockwin ___ Python tracker <https://bugs.python.org/issue35183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35183] os.path.splitext documentation needs typical example
Change by Jake Stockwin : -- keywords: +patch pull_requests: +25828 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27286 ___ Python tracker <https://bugs.python.org/issue35183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35183] os.path.splitext documentation needs typical example
Jake Stockwin added the comment: Thanks for the info, @jack__d - very helpful. I have now submitted a PR for this and will await a review. Let me know if anything else is needed. -- ___ Python tracker <https://bugs.python.org/issue35183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38707] Multiprocessing: bug with Native ID for threading.mainthread()
Jake Tesler added the comment: PR was updated with tests and is ready for core developer review and then the merge to cpython:master. After that (if I understand correctly) a backport will automatically get picked into the 3.8 branch if there aren't any conflicts. -- ___ Python tracker <https://bugs.python.org/issue38707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38891] ShareableList read and write access is O(N), should be O(1)
New submission from Jake Northey : For an illustration of the performance implications of the __getitem__ and __setitem__ implementation, see the article below. https://medium.com/@rvprasad/performance-of-system-v-style-shared-memory-support-in-python-3-8-d7a7d1b1fb96 The issue appears to be due to the summing of ShareableList item sizes to generate an offset for the requested item. Perhaps an offset-based index could be created in which the allocation sizes could be constructed by comparing two offets. -- components: Library (Lib) messages: 357239 nosy: Jake Northey, davin priority: normal severity: normal status: open title: ShareableList read and write access is O(N), should be O(1) type: performance versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)
New submission from Jake Gustafson :
Steps to reproduce the issue:
- Run Python 3.7.3 (or later, possibly) with the following code:
import subprocess
import inspect
with open("subprocess-py3.py", 'w') as outs:
outs.write(inspect.getsource(subprocess).replace("\\n","\n"))
The resulting ./subprocess-py3.py contains the source code for subprocess
including:
# Copyright (c) 2003-2005 by Peter Astrand
#
# Licensed to PSF under a Contributor Agreement.
# See http://www.python.org/2.4/license for licensing details.
However, the URL is broken, and whatever code Peter Astrand developed may be
long gone--I'll leave it up to the devs to determine the correct license, but
the link is broken and the code is significantly different even than Python
2.4's.
--
assignee: docs@python
components: Documentation
messages: 388049
nosy: docs@python, poikilos
priority: normal
severity: normal
status: open
title: The comments have invalid license information (broken Python 2.4 URL for
Python 3)
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue43391>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43391] The comments have invalid license information (broken Python 2.4 URL for Python 3)
Jake Gustafson added the comment: *significantly different even than Python 2.7.16's. -- ___ Python tracker <https://bugs.python.org/issue43391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42297] [argparse] Bad error message formatting when using custom usage text
New submission from Jake Hunsaker :
In the sos project, we build a custom `usage` string for our argparser parser,
and have noticed that doing so causes error messages from argparse to be badly
formatted.
For example if a bad option value is given, the error message is mangled into
the last line of our usage string:
```
# python3 bin/sos report --all-logs=on
usage: sos report [options]
sos [options]
[..snip...]
collect, collectorCollect an sos report from multiple nodes
simultaneously report: error: argument --all-logs: ignored explicit argument
'on'
```
This is especially strange since we build the usage string with a trailing
newline character:
```
for com in self._components:
aliases = self._components[com][1]
aliases.insert(0, com)
_com = ', '.join(aliases)
desc = self._components[com][0].desc
_com_string += (
"\t{com:<30}{desc}\n".format(com=_com, desc=desc)
)
usage_string = ("%(prog)s [options]\n\n"
"Available components:\n")
usage_string = usage_string + _com_string
epilog = ("See `sos --help` for more information")
self.parser = ArgumentParser(usage=usage_string, epilog=epilog)
```
So it appears the trailing newlines are being stripped (in our case,
unintentionally?). As expected, removing the trailing newline when passing
`usage_string` to our parse does not change this behavior.
However, if we don't set the usage string at all when instantiating our parser,
the error message is properly formatted beginning on a new line. Slightly
interesting is that without the usage_string being passed, the error message is
prefixed with "sos: report:" as expected for %(prog)s expansion, but when the
error message is mangled `%(prog)s` is left out as well.
A little more context is available here:
https://github.com/sosreport/sos/issues/2285
--
components: Library (Lib)
messages: 380598
nosy: TurboTurtle
priority: normal
severity: normal
status: open
title: [argparse] Bad error message formatting when using custom usage text
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue42297>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42297] [argparse] Bad error message formatting when using custom usage text
Jake Hunsaker added the comment: I'll try and get a simple reproducer made shortly, however as a quick note I've found that using '--all-logs on' results in a properly formatted error message. -- ___ Python tracker <https://bugs.python.org/issue42297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42297] [argparse] Bad error message formatting when using custom usage text
Jake Hunsaker added the comment:
Ah, ok - so I neglected to mention we're using subparsers which appears to be
relevant here. My apologies.
Here's a minimal reproducer that shows the behavior when using './arg_test.py
foo --bar=on'
```
#! /bin/python3
import argparse
usage_string = 'test usage string ending in newlines\n\n'
sub_cmd_usage = ''
for i in range(0, 3):
sub_cmd_usage += '\tfoo --bar\n'
usage_string += sub_cmd_usage
parser = argparse.ArgumentParser(usage=usage_string)
subparser = parser.add_subparsers(dest='subcmd', metavar='subcmd')
subcmd_parser = subparser.add_parser('foo')
subcmd_parser.add_argument('--bar', action="store_true", default=False)
if __name__ == '__main__':
args = parser.parse_args()
```
--
___
Python tracker
<https://bugs.python.org/issue42297>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42297] [argparse] Bad error message formatting when using custom usage text
Jake Hunsaker added the comment: Ok, yeah there seem to be several paths to avoid this behavior then. We should be fine exploring those options. Thanks for the pointer! -- ___ Python tracker <https://bugs.python.org/issue42297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: I will implement these changes - let’s try to hit that end-of-month target! -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Change by Jake Tesler : -- pull_requests: +13373 ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: New PR created with requested edits. :) -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: Victor Stinner: would you mind taking a look at the new PR? Is this more along the lines of what you had in mind? -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: In general, I’ve concluded most ‘editions’ of pthread_self() are not the same value as this feature aims to implement. I’m not familiar enough with AIX to be certain about that platform, though. If there’s an equivalent function in AIX to capture the actual integral thread ID in the same 3-line way as Linux, FreeBSD, et al., are implemented (the big block in PyThread_get_thread_native_id), then it’s worth including. If the mechanism required is a more complex one than just adding a few lines, then it might be best left for a new PR. :) -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: I will look into whether adding thread_self() for AIX would be simple enough for this PR. -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: Victor – the return value of _start_new_thread is the the `ident` parameter, and its not the same as the native id. See here: https://github.com/python/cpython/pull/11993#issuecomment-491544908 -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: Michael Felt - If you would like some help with adding/building AIX support for this functionality, tag me, I'd be glad to help out! :) -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Change by Jake Tesler : -- pull_requests: +14636 pull_request: https://github.com/python/cpython/pull/14845 ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
New submission from Jake Tesler : This functionality adds a native Thread ID to threading.Thread objects. This ID (TID), similar to the PID of a process, is assigned by the OS (kernel) and is generally used for externally monitoring resources consumed by the running thread (or process). This does not replace the `ident` attribute within Thread objects, which is assigned by the Python interpreter and is guaranteed as unique for the lifetime of the Python instance. -- messages: 336348 nosy: Jake Tesler priority: normal severity: normal status: open title: Threading: add builtin TID attribute to Thread objects type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30099] Lib2to3 fails with unreadable pickle file
New submission from Jake Merdich: There seem to have been a few issues in the past with creating the lib2to3 pickle files with the right permissions due to umask behavior (#15890). While I'm unaware of the status installer-level fixes have given, it seems prudent that the installed python should always function, given there is an obvious and trivial fallback (regenerating the grammar tables at runtime). The current codebase will throw a PermissionDenied exception if the pickle file is unreadable, rather than fall back to generating the grammar tables. To reproduce: Install python2.6+, 3.0+ chmod o-r $PYTHON_INSTALL/lib/pythonX.Y/lib2to3/*.pickle pythonX.Y -c "import lib2to3.pygram" Notably, this sort of borked installation is quite hard to detect unless a user without root tries to run setuptools (*whistles*). -- components: 2to3 (2.x to 3.x conversion tool) files: 0001-Fallback-to-regenerating-2to3-grammars-on-read-fail.patch keywords: patch messages: 291853 nosy: Jake Merdich priority: normal severity: normal status: open title: Lib2to3 fails with unreadable pickle file type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46811/0001-Fallback-to-regenerating-2to3-grammars-on-read-fail.patch ___ Python tracker <http://bugs.python.org/issue30099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30157] csn.Sniffer.sniff() regex error
New submission from Jake Davis: Line 220 of Lib/csv.py has an extra `>` in the first group: r'(?P>[^\w\n"\']) -- components: Library (Lib) messages: 292249 nosy: jcdavis1983 priority: normal pull_requests: 1389 severity: normal status: open title: csn.Sniffer.sniff() regex error versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30157] csv.Sniffer.sniff() regex error
Jake Davis added the comment: Will do! I will try to get a regression proof test into test_csv.py in the next 24 hours. Essentially I will make sure that the sniffer returns a positive match for each of the patterns that the regex is intended to hit. -- ___ Python tracker <http://bugs.python.org/issue30157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30157] csv.Sniffer.sniff() regex error
Jake Davis added the comment: I've added some unittests for Sniffer._guess_quote_and_delimiter(); they should prevent regression. -- ___ Python tracker <http://bugs.python.org/issue30157> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: *bump* Could someone look into reviewing this bug/PR? Thanks! -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: The feature is supported on Windows: the file supporting Windows threading is `thread_nt.h`, not `thread_pthread.h` since Windows doesn't use POSIX-style threads. Also it is different from threading.get_ident() - ident is a Python-issued unique identifier, TID is issued by the OS and is tracable system-wide. -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36084] Threading: add builtin TID attribute to Thread objects
Jake Tesler added the comment: So where do we go from here? -- ___ Python tracker <https://bugs.python.org/issue36084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31686] GZip library doesn't properly close files
New submission from Jake Lever : The attached code is designed to output compressed data to a gzip file. It creates two GzipFile objects, but only one is really used. It seems that it doesn't clean up and close the file properly. In Py2, the attached code will fail. The output file (debug.txt.gz) will be corrupt. However if the self.unused line is commented out, it works and the file is not corrupted. In Py3, a sys.exit call at the end is required to see the same behaviour. As example output, when the sys.exit is include in Py3, the output is below and the file is corrupt. Compressor.__init__ UnusedClass.write UnusedClass.write UnusedClass.write UnusedClass.write UnusedClass.write UnusedClass.write Compressor.compressToFile And when the sys.exit is commented out, the console output is below and the file is not corrupt. Compressor.__init__ UnusedClass.write UnusedClass.write UnusedClass.write UnusedClass.write UnusedClass.write UnusedClass.write Compressor.compressToFile UnusedClass.write UnusedClass.write UnusedClass.write -- files: gzipBug.py messages: 303662 nosy: Jake Lever priority: normal severity: normal status: open title: GZip library doesn't properly close files type: behavior versions: Python 2.7, Python 3.6 Added file: https://bugs.python.org/file47189/gzipBug.py ___ Python tracker <https://bugs.python.org/issue31686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21441] Buffer Protocol Documentation Error
New submission from Jake Vanderplas: The ``obj`` and ``buf`` structure elements are switched in the documentation of the Buffer Protocol. Compare https://docs.python.org/3.3/c-api/buffer.html#Py_buffer to https://github.com/python/cpython/blob/master/Include/object.h#L179-180 -- assignee: docs@python components: Documentation files: bufferdoc.patch keywords: patch messages: 217939 nosy: Jake.Vanderplas, docs@python priority: normal severity: normal status: open title: Buffer Protocol Documentation Error versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file35158/bufferdoc.patch ___ Python tracker <http://bugs.python.org/issue21441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6790] httplib and array do not play together well
New submission from Jake McGuire : As of Python 2.6 you can no longer pass an array to httplib.HTTPConnection.send. Issue1065257 added code to httplib to attempt to determine whether a file-like object was passed to certain methods (e.g. send), and to stream the data if so. The patch uses "hasattr(obj, 'read')" as a proxy for "is a file-like object". array.array objects have a method called "read" that is almost entirely disanalogous to the "read" method on a file-like object. Hilarity ensues. -- messages: 92015 nosy: jakemcguire severity: normal status: open title: httplib and array do not play together well type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6790> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7427] BadStatusLine is hell to debug
Jake McGuire added the comment: I think what's happening is that your connection is being closed due to inactivity, so the status line that comes back is empty. Printing repr(line) would probably make the emptiness clear, but maybe the httplib code should put in a more specific message in this case... -- nosy: +jakemcguire ___ Python tracker <http://bugs.python.org/issue7427> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Jake McGuire added the comment: The fromstring/asstring dance was due to my incomplete understanding of refcounting. PyDict_Next returns a borrowed reference but PyString_InternInPlace expects an owned reference. Thanks to Kirk McDonald, I have a new patch that does the refcounting correctly. What sort of test did you have in mind? Added file: http://bugs.python.org/file13169/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Jake McGuire added the comment: Ugh. Clearly I didn't check to see if it worked or not, as it didn't even compile. A new diff, tested and verified to work, is attached. I'll work on creating a test. Added file: http://bugs.python.org/file13178/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Changes by Jake McGuire : Removed file: http://bugs.python.org/file12882/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Changes by Jake McGuire : Removed file: http://bugs.python.org/file13169/cPickle.c.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5084] unpickling does not intern attribute names
Jake McGuire added the comment: This fell through the cracks. But the following unit test seems like it does the right thing (fails with the old module, works with the new ones). -- Added file: http://bugs.python.org/file13835/pickletester.diff ___ Python tracker <http://bugs.python.org/issue5084> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
New submission from Jake Garver: In compileall.py's main, we verify that the provided destdir (-d) exists at build time. But destdir will commonly be used to override the build time path with a runtime path. That runtime path will usually not exist at build time. Note that this logic was changed when compileall.py was migrated to argparse. I think the old logic accidentally avoided the isdir() check at build time. https://github.com/python/cpython/commit/11e99b06bda2a23478fcec40df8c18edc8a06668 With the attached patch, behavior is made consistent with python 2.7, intended or otherwise. -- components: Library (Lib) files: python34_compileall_ddir.diff keywords: patch messages: 248900 nosy: jgarver priority: normal severity: normal status: open title: Do not verify destdir argument to compileall type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file40216/python34_compileall_ddir.diff ___ Python tracker <http://bugs.python.org/issue24903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
Jake Garver added the comment: Thanks for the response and sorry for the mis-read. In 2.7, I did something like: python -m compileall -d /runtime/path foo.py But in 3.4, I get: -d destdir requires exactly one directory argument I'm doing this during a build. Then we package the pyc file into a runtime image. Let me know if I can further help (or confuse). -- ___ Python tracker <http://bugs.python.org/issue24903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
Jake Garver added the comment: I agree. I couldn't find a use for the check, so I removed it entirely in the provided patch. I'm running that way now with success, but of course I'm covering just one use case. Digging back a bit further, the isdir() check came in here: https://github.com/python/cpython/commit/dc6a4c158f8a6175c7d0d5d1a61c24c06767ef22 And even further, near the beginning of time, we find the original check: https://github.com/python/cpython/commit/995d45ede2432306a2a0306ce29cea4013bc2850 Speculation: In the context of the original code, "directory" in the error message makes more sense and that word should have been dropped when single file support was added. However, given that we loop over the args, I don't see how -d was limited to a single arg. With my patch in place, I tested compileall.py with multiple args and the -d. It works as expected and contains the -d path. python -m compileall -d /runtime/path foo.py bar.py foobar.py I'm happy to craft a new patch. How would you like it? -- versions: -Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue24903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24977] shutil copy to non-existant directory
New submission from Jake Howard: If you try and copy a file using shutil.copy to a directory that doesnt exist, it tries to copy the file to the location of the directory, and errors as shutil can't open a directory for 'WB' access, throwing an error, that doesnt reflect the problem. -- messages: 249474 nosy: TheOrangeOne priority: normal severity: normal status: open title: shutil copy to non-existant directory type: behavior ___ Python tracker <http://bugs.python.org/issue24977> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24903] Do not verify destdir argument to compileall
Jake Garver added the comment: Updated patch. Same as before, but updates tests. Sorry I went MIA on this issue. -- Added file: http://bugs.python.org/file40440/python34_compileall_ddir_2.diff ___ Python tracker <http://bugs.python.org/issue24903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25498] Python 3.4.3 core dump with simple sample code
New submission from Jake Montgomery: We are seeing a consistent "invalid memory access" crash in Python3.4.3. *Test setup* This is occurring on Ubuntu 14.04.1 LTS. It is occurring on multiple unrelated installs, but has not been tested with any other operating system. It occurs using the "Python 3.4.3 (default, Oct 14 2015, 20:28:29)" that is installed using apt-get. It does *not* appear to occur using Python 3.4.0. Other versions of python were not tested. *Reproducing* I was able to reduce the code needed to a pretty minimal python program, which is attached. Running this as "pyton3 ./pythoncrash.py" will trigger the crash, and a core dump if enabled. If run under python3.4.3-dbg The error is: python3.4-dbg: ../Objects/memoryobject.c:115: mbuf_dealloc: Assertion `self->exports == 0' failed. In some versions of this code, it had to be run twice, since it would only occur when the pyc files were already created. The attached version does not appear to have this behavior, but run it twice, at least, if you do not see the crash. The code supplied is "minimal", in that removing any line will cause the crash not to occur. *More clues* I suspect that the key is the multiprocessing.Value object, and its destruction. The other "import" statements may just be happenstance needed to create the correct memory conditions for the crash. I was able to start "stubbing out" the actual code in those imported packages, and the crash continued as long as the number of functions, classes, and class dependencies were maintained. But that became too tedious. In earlier versions of the test code, adding or removing significant numbers of function or classes could make the crash not manifest. *Stack trace* Running under python3.4.3-dbg, gdb gives the following stack trace: #0 0x7fc0425b4cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7fc0425b80d8 in __GI_abort () at abort.c:89 #2 0x7fc0425adb86 in __assert_fail_base ( fmt=0x7fc0426fe830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x707199 "self->exports == 0", file=file@entry=0x70715a "../Objects/memoryobject.c", line=line@entry=115, function=function@entry=0x708923 <__PRETTY_FUNCTION__.10355> "mbuf_dealloc") at assert.c:92 #3 0x7fc0425adc32 in __GI___assert_fail (assertion=0x707199 "self->exports == 0", file=0x70715a "../Objects/memoryobject.c", line=115, function=0x708923 <__PRETTY_FUNCTION__.10355> "mbuf_dealloc") at assert.c:101 #4 0x004beb92 in mbuf_dealloc (self=0x7fc042068058) at ../Objects/memoryobject.c:115 #5 0x004cd67b in _Py_Dealloc (op=) at ../Objects/object.c:1749 #6 0x004c0ec6 in memory_clear (self=0x7fc042026bf8) at ../Objects/memoryobject.c:1079 #7 0x004409c3 in delete_garbage (collectable=0x7fff21065180, old=0x9a4f40 ) at ../Modules/gcmodule.c:866 #8 0x00440f56 in collect (generation=2, n_collected=0x7fff210651e8, n_uncollectable=0x7fff210651f0, nofail=0) at ../Modules/gcmodule.c:1032 #9 0x0044144e in collect_with_callback (generation=2) at ../Modules/gcmodule.c:1140 #10 0x004421f2 in PyGC_Collect () at ../Modules/gcmodule.c:1616 #11 0x004226a0 in Py_Finalize () at ../Python/pythonrun.c:607 #12 0x00428f38 in Py_Exit (sts=0) at ../Python/pythonrun.c:2713 #13 0x00426077 in handle_system_exit () at ../Python/pythonrun.c:1812 #14 0x004260a2 in PyErr_PrintEx (set_sys_last_vars=1) at ../Python/pythonrun.c:1822 #15 0x00425cef in PyErr_Print () at ../Python/pythonrun.c:1718 #16 0x004255c4 in PyRun_SimpleFileExFlags (fp=0x29824c0, filename=0x7fc042442b68 "./pythoncrash.py", closeit=1, flags=0x7fff21065520) at ../Python/pythonrun.c:1611 #17 0x00424418 in PyRun_AnyFileExFlags (fp=0x29824c0, filename=0x7fc042442b68 "./pythoncrash.py", closeit=1, flags=0x7fff21065520) at ../Python/pythonrun.c:1292 #18 0x0043e9fb in run_file (fp=0x29824c0, filename=0x28b62f0 L"./pythoncrash.py", p_cf=0x7fff21065520) at ../Modules/main.c:319 #19 0x0043f781 in Py_Main (argc=2, argv=0x28b5020) at ../Modules/main.c:751 #20 0x0041e6d6 in main (argc=2, argv=0x7fff21065798) at ../Modules/python.c:69 The full core dump is available, if it would help. -- components: Interpreter Core files: pythoncrash.py messages: 253613 nosy: JakeMont priority: normal severity: normal status: open title: Python 3.4.3 core dump with simple sample code versions: Python 3.4 Added file: http://bugs.python.org/file40876/pythoncrash.py ___ Python tracker <http://bugs.python.org/issue25498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24324] Remove -Wunreachable-code flag
Changes by Jake Garver : Added file: http://bugs.python.org/file41663/Python351-no-unreachable-check.diff ___ Python tracker <http://bugs.python.org/issue24324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
