[issue16418] argparse with many choices can generate absurdly long usage message
Changes by paul j3 ajipa...@gmail.com: -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18322] test_stat nits
Roundup Robot added the comment: New changeset f3f38c84aebc by Antoine Pitrou in branch 'default': Issue #18322: fix some test_stat nits. http://hg.python.org/cpython/rev/f3f38c84aebc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18322] test_stat nits
Antoine Pitrou added the comment: Committed with unittest.main(). Thanks for the comments. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18266] Fix test discovery for test_largefile.py
Serhiy Storchaka added the comment: There is other problem with test_largefile. It not allows running only selected tests. I.e. ./python -m test.regrtest -v -m test_lseek test_largefile Looks as test_largefile was suboptimal converted to unittest. -- nosy: +facundobatista, giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18266 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18326] Not Clear Docs
New submission from icedream91: I think the documents talking about list.sort() in page http://docs.python.org/3/library/stdtypes.html#list.sort is not clear enough. What asterisk means in sort(*, key=None, reverse=None), may be cmp argument from Python 2, or anything else? Or it is a typo? I think document should explain what this asterisk means. Thanks. -- assignee: docs@python components: Documentation messages: 192034 nosy: docs@python, icedream91 priority: normal severity: normal status: open title: Not Clear Docs versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18326] Not Clear Docs
R. David Murray added the comment: It means they are keyword-only arguments. This could be mentioned in the text, with the term 'keyword-only arguments' linked to an appropriate glossary entry (which appears to need to be added). -- keywords: +easy nosy: +r.david.murray stage: - needs patch versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18280] Documentation is too personalized
Antoine Pitrou added the comment: The sockets tutorial deserves a good overhaul :-) -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18280 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Ronald Oussoren added the comment: Any review would be greatly appreciated. One thing I'm not too happy about is the use of magic numbers in the binary plist support code, but I think that using constants or a dispatch table would not make the code any clearer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18237] unittest.assertRaisesRegex(p) example is wrong in docs
Roundup Robot added the comment: New changeset 4a714fea95ef by Terry Jan Reedy in branch '2.7': Issue #18237: Fix assertRaisesRegexp error caought by Jeff Tratner. http://hg.python.org/cpython/rev/4a714fea95ef New changeset b3d19f0494e7 by Terry Jan Reedy in branch '3.3': Issue #18237: Fix assertRaisesRegexp error caought by Jeff Tratner. http://hg.python.org/cpython/rev/b3d19f0494e7 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18237] unittest.assertRaisesRegex(p) example is wrong in docs
Terry J. Reedy added the comment: I went with adding ' after changing '...' to If you think you might ever submit a more substantial patch, and we hope you do, please submit a Contributor Agreement (now optionally electronic). http://www.python.org/psf/contrib/ When processed (a week?), an * will appear after your name. -- resolution: - fixed stage: - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering
Łukasz Langa added the comment: Looks like the priority ordering you mention is not yet documented anywhere. It definitely makes sense but I'd like to take a step back for a moment to consider the following questions: 1. What additional functionality do our users get with this ordering? In other words, what purpose does this new ordering have? Apart from solving the conflict we're discussing, I can't see any. 2. What disadvantages does this ordering bring to the table? I think that simplicity is a feature. This ordering creates additional complexity in the language. Firstly, there is currently no obvious way for users to distinguish between implicit subclassing (via implementation) or subclassing by `abc.register()`. This creates the dangerous situation where backwards incompatibility introduced by switching between those ABC registration mechanism is nearly impossible to debug. Consider an example: version A of a library has a type which only implicitly subclasses an ABC. User code with singledispatch is created that works with the current state of things. Version B of the same library uses `ABC.register(Type)` and suddenly the dispatch changes without any way for the user to see what's going on. A similar example with explicit subclassing and a different form of registration is easier to debug, but not much, really. Secondly, it creates this awkward situation where dispatch for any custom `MutableMapping` can be different from the dispatch for `dict`. Although the latter is a `MutableMapping` only by means of `MutableMapping.register(dict)`, in reality the whole definition of what a mutable mapping is comes from the behaviour found in `dict`. Following your point of view, dict is less of a mutable mapping than a custom type subclassing the ABC explicitly. You're saying the user should respect the choice of its author but it's clearly suboptimal here. I strongly believe I should be able to swap a mutable mapping implementation with any other and get consistent dispatch. Thirdly, while I can't support this with any concrete examples, I have a gut feeling that considering all three ABC subclassing mechanisms to be equally binding will end up as a toolkit with better composability. The priority ordering on the other hand designs `abc.register()` and implicit subclassing as inferior MRO wannabes. Last but not least, the priority ordering will further complicate the implementation of `functools._compose_mro()` and friends. While the complexity of this code is not the reason of my stance on the matter, I think it nicely shows how much the user has to keep in her head to really know what's going on. Especially that we only consider this ordering to be decisive on a single interitance level. 3. Why is the ordering MRO - register - implicit? The reason I'm asking is that the whole existence of `abc.register()` seems to come from the following: * we want types that predate the creation of an ABC to be considered its subclasses; * we can't use implicit subclassing because either the existence of methods in question is not enough (e.g. Mapping versus Sequence); or the methods are added at runtime and don't appear in __dict__. Considering the above, one might argue that the following order is just as well justified: MRO - implicit - register. I'm aware that the decision to put register first is because if the user is unhappy with the dispatch, she can override the ordering by registering types which were implicit before. But, while I can register third-party types, I can't unregister any. In other words, I find this ordering arbitrary. I hope you don't perceive my position as stubborn, I just care enough to insist on this piece of machinery to be clearly defined and as simple as possible (but not simpler, sure). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18042] Provide enum.unique class decorator
Ethan Furman added the comment: Integrated comments. -- Added file: http://bugs.python.org/file30730/unique.stoneleaf.02.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18327] swapped arguments in compatible_for_assignment()?
New submission from Christian Heimes:
Coverity has found something fishy in our code base:
CID 983564 (#1 of 1): Arguments in wrong order
(SWAPPED_ARGUMENTS)swapped_arguments: The positions of arguments newto and
oldto are inconsistent with the positions of the corresponding parameters for
compatible_for_assignment(PyTypeObject *, PyTypeObject *, char *).
Object/typeobject.c:3326
if (compatible_for_assignment(newto, oldto, __class__)) {
Objects/typeobject.c.3265
static int
compatible_for_assignment(PyTypeObject* oldto, PyTypeObject* newto, char* attr)
--
components: Interpreter Core
messages: 192042
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: swapped arguments in compatible_for_assignment()?
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18327
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18206] license url in site.py should always use X.Y.Z form of version number
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +dbrecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18206 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17908] Unittest runner needs an option to call gc.collect() after each test
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +dbrecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18292] IDLE Improvements: Unit test for AutoExpand.py
Changes by Phil Webster webster.p...@gmail.com: -- nosy: +philwebster ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17845] Clarify successful build message
Changes by Demian Brecht demianbre...@gmail.com: -- nosy: +dbrecht ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18328] Use after free in pystate.c
New submission from Christian Heimes: Coverity doesn't like the code in and I think it's right. Can somebody look into the matter and check Python 3.3, too? http://hg.python.org/cpython/file/ac7bc6700ac3/Python/pystate.c#l376 http://hg.python.org/cpython/file/ac7bc6700ac3/Python/pystate.c#l394 10. freed_arg: tstate_delete_common(PyThreadState *) frees tstate. 395tstate_delete_common(tstate); 11. Condition autoInterpreterState, taking true branch CID 1019639 (#1 of 1): Use after free (USE_AFTER_FREE)12. use_after_free: Using freed pointer tstate. 396if (autoInterpreterState PyThread_get_key_value(autoTLSkey) == tstate) 397PyThread_delete_key_value(autoTLSkey); -- components: Interpreter Core messages: 192043 nosy: christian.heimes priority: normal severity: normal stage: test needed status: open title: Use after free in pystate.c type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18328 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14455] plistlib unable to read json and binary plist files
Serhiy Storchaka added the comment: I have added comments on Rietveld. I have to apologize for unwitting misleading of d9pouces. Functional version of the patch is enough Pythonic and it looks more clear to me than object-oriented one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14455 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
New submission from Марк Коренберг: Results or running attached program: $ python2.7 qwe.py TCP mode, makefile method. 198807.2 lines per second (189.6 MB/s). Delay is 5.03 seconds TCP mode, fdopen method. 1041666.7 lines per second (993.4 MB/s). Delay is 0.96 seconds UNIX mode, makefile method. 2040816.3 lines per second (1946.3 MB/s). Delay is 0.49 seconds UNIX mode, fdopen method. 1923076.9 lines per second (1834.0 MB/s). Delay is 0.52 seconds $ python3.2 qwe.py TCP mode, makefile method. 275482.1 lines per second (262.7 MB/s). Delay is 3.63 seconds TCP mode, fdopen method. 909090.9 lines per second (867.0 MB/s). Delay is 1.10 seconds UNIX mode, makefile method. 323624.6 lines per second (308.6 MB/s). Delay is 3.09 seconds UNIX mode, fdopen method. 1694915.3 lines per second (1616.4 MB/s). Delay is 0.59 seconds -- 1. in every case, socket.makefile() is MUCH slower than os.fdopen() when used as for line in fileobject 2. compare speeds between python 2.7 and python 3.2 in same operation. Especially, socketpair+makefile 3. Why not to return os.fdopen() for sockets when socket.makefile() called on unix systems? -- components: IO, Library (Lib) files: qwe.py messages: 192044 nosy: mmarkk priority: normal severity: normal status: open title: for line in socket.makefile() speed degradation type: performance versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30731/qwe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Yes, results are repeatable, and for python 2.7 I have roughly same timings for UNIX socket. Also, I have straced all variants and see that in all 4 cases (and for both python versions) IO is done using 8192 blocks in size, so buffering is not cause of problems. I have linux 3.5.0, Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Well, python 3.3 is slightly faster: $ python3.3 qwe.py TCP mode, makefile method. 380228.1 lines per second (362.6 MB/s). Delay is 2.63 seconds TCP mode, fdopen method. 877193.0 lines per second (836.6 MB/s). Delay is 1.14 seconds UNIX mode, makefile method. 469483.6 lines per second (447.7 MB/s). Delay is 2.13 seconds UNIX mode, fdopen method. 1562500.0 lines per second (1490.1 MB/s). Delay is 0.64 seconds But problem still exists -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12716] Reorganize os docs for files/dirs/fds
A.M. Kuchling added the comment: Closing this issue after a week. Mike Hoy: thanks for your patch. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12716 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4199] add shorthand global and nonlocal statements
A.M. Kuchling added the comment: Bumping version to 3.4. I'll send a note to python-dev about this issue. -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4199 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Serhiy Storchaka added the comment: Try to wrap socket.makefile() with io.BufferedReader(). -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Richard Oudkerk added the comment: I think in Python 3 makefile() returns a TextIOWrapper object by default. To force the use of binary you need to specfiy the mode: fileobj = ss.makefile(mode='rb') -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18330] Fix idlelib.PyShell.build_subprocess_arglist use of __import__
New submission from Terry J. Reedy:
The purpose of the function is to create a command line for the user
subprocess. Most of its body:
'''
# Maybe IDLE is installed and is being accessed via sys.path,
# or maybe it's not installed and the idle.py script is being
# run from the IDLE source directory.
del_exitf = idleConf.GetOption('main', 'General', 'delete-exitfunc',
default=False, type='bool')
if __name__ == 'idlelib.PyShell':
command = __import__('idlelib.run').run.main(%r) % (del_exitf,)
else:
command = __import__('run').main(%r) % (del_exitf,)
return [sys.executable] + w + [-c, command, str(self.port)]
'''
Question: is it really important to avoid binding the run module to 'run' in
the user process? If so, maybe we should use importlib.import_module, as
'direct use of __import__ is entirely discouraged.
The first command looks 'funny' because of the repetition of 'run'. The reason
is that __import__('idlelib.run') returns idlelib, not idlelib.run. Perhaps it
would work to delete .run in the import, or to use importlib.import_module.
The second command incorrectly assumes that if __name__ == '__main__' (the
alternative to 'idlelib.PyShell'), then the directory containing PyShell and
run is the current working directory. This is true if PyShell is run from that
directory, but
F:\Python\dev\py33\PCbuildpython_d -m idlelib.PyShell
F:\Python\dev\py33\PCbuildpython_d ../Lib/idlelib/PyShell.py
both report ImportError: No module named 'run' and open a shell window and
error message box a few seconds later. The shell closes when the messagebox is
dismissed.
It seems to me that the 'else' caters to a non-existent or impossible use case.
PyShell has several 'from idlelib.X import Y' statements. If those work, then
from idlelib import run' must work, and so too must the function equivalent.
--
messages: 192053
nosy: roger.serwy, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix idlelib.PyShell.build_subprocess_arglist use of __import__
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18330
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Changes by Марк Коренберг socketp...@gmail.com: Removed file: http://bugs.python.org/file30731/qwe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Eliminate unicode conversion for python3, but results still the same $ python2.7 qwe.py TCP mode, makefile method. 211416.5 lines per second (201.6 MB/s). Delay is 4.73 seconds TCP mode, fdopen method. 1041666.7 lines per second (993.4 MB/s). Delay is 0.96 seconds UNIX mode, makefile method. 2040816.3 lines per second (1946.3 MB/s). Delay is 0.49 seconds UNIX mode, fdopen method. 1886792.5 lines per second (1799.4 MB/s). Delay is 0.53 seconds $ python3.2 qwe.py TCP mode, makefile method. 487804.9 lines per second (465.2 MB/s). Delay is 2.05 seconds TCP mode, fdopen method. 900900.9 lines per second (859.2 MB/s). Delay is 1.11 seconds UNIX mode, makefile method. 625000.0 lines per second (596.0 MB/s). Delay is 1.60 seconds UNIX mode, fdopen method. 1492537.3 lines per second (1423.4 MB/s). Delay is 0.67 seconds $ python3.3 qwe.py TCP mode, makefile method. 512820.5 lines per second (489.1 MB/s). Delay is 1.95 seconds TCP mode, fdopen method. 884955.8 lines per second (844.0 MB/s). Delay is 1.13 seconds UNIX mode, makefile method. 680272.1 lines per second (648.8 MB/s). Delay is 1.47 seconds UNIX mode, fdopen method. 1587301.6 lines per second (1513.8 MB/s). Delay is 0.63 seconds Also, io.BufferedReader() is not my case. I understand that intermediate buffer will increase performance. Problem in implementation of socket.makefile(). That is I want to be fixed. -- Added file: http://bugs.python.org/file30732/qwe.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18329] for line in socket.makefile() speed degradation
Марк Коренберг added the comment: Can anyone test in python 3.4 ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18329 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18103] Create a GUI test framework for Idle
Roundup Robot added the comment: New changeset c818c215f1a4 by Terry Jan Reedy in branch '3.3': Issue #18103: Update README.txt and test_idle to describe and run gui tests. http://hg.python.org/cpython/rev/c818c215f1a4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18103] Create a GUI test framework for Idle
Roundup Robot added the comment: New changeset 0767363a0393 by Terry Jan Reedy in branch '2.7': Issue #18103: Update README.txt and test_idle to describe and run gui tests. http://hg.python.org/cpython/rev/0767363a0393 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18155] csv.Sniffer.has_header doesn't escape characters used in regex
Roundup Robot added the comment: New changeset 68ff68f9a0d5 by R David Murray in branch '3.3': #18155: Regex-escape delimiter, in case it is a regex special char. http://hg.python.org/cpython/rev/68ff68f9a0d5 New changeset acaf73e3d882 by R David Murray in branch 'default': Merge #18155: Regex-escape delimiter, in case it is a regex special char. http://hg.python.org/cpython/rev/acaf73e3d882 New changeset 0e1d538d36dc by R David Murray in branch '2.7': #18155: Regex-escape delimiter, in case it is a regex special char. http://hg.python.org/cpython/rev/0e1d538d36dc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18155] csv.Sniffer.has_header doesn't escape characters used in regex
R. David Murray added the comment: Committed, with slight modifications to the tests. Thanks Vajrasky. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18103] Create a GUI test framework for Idle
Terry J. Reedy added the comment: While I have not committed any gui tests, the patch is based on experiments with a couple of temporary files. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18103 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18244] singledispatch: When virtual-inheriting ABCs at distinct points in MRO, composed MRO is dependent on haystack ordering
Guido van Rossum added the comment: Looks like the priority ordering you mention is not yet documented anywhere. Because up till now it has not been needed -- all you can do with ABCs is use isinstance/issubclass. It definitely makes sense but I'd like to take a step back for a moment to consider the following questions: 1. What additional functionality do our users get with this ordering? In other words, what purpose does this new ordering have? Apart from solving the conflict we're discussing, I can't see any. There doesn't have to be any other functionality. We're just trying to address how ABCs should be ordered relative to classes explicitly in the MRO for the purpose of @singledispatch. 2. What disadvantages does this ordering bring to the table? I think that simplicity is a feature. This ordering creates additional complexity in the language. But so does not ordering. The underlying question is how to dispatch when two or more classes in an object's class hierarchy have a different dispatch rule. This is fundamentally a question of ordering. For regular method dispatch, the ordering used is the MRO, and there is always a unique answer: the class that comes first in the MRO wins. (Ambiguities and inconsistencies in the MRO are rejected at class definition time.) This is very convenient because the issue of coming up with a total ordering of base classes is solved once and for all, and because of the total ordering we never have to reject a request to dispatch (of regular methods or attribute lookup) as ambiguous. (Note: I call it a total ordering, but the total ordering is only within a specific class's MRO. Any class's explicit bases are totally ordered in that class's MRO -- but the order of two classes may be different in a different class's MRO. This is actually relevant for the definition of C3, and we'll see this below.) For @singledispatch, we are choosing to support ABCs (because it makes sense), and so we have to think about how handle ABCs that are relevant (isinstance/issubclass returns True) but not in the MRO. Let's introduce terminology so we can talk about different cases easily. Relevant: isinstance/issubclass returns True Explicit: it's in the MRO Implicit: relevant but not explicit Registered: Implicit due to a register() call Inferred: Implicit due to a special method These categories are not always exclusive, e.g. an ABC may be registered for one class in the MRO but inferred for a different one. The registration mechanism tries to avoid outright cycles but otherwise is not as strict about rejecting ambiguities as C3 is for the MRO calculation, and this I believe is the reason we're still debating the order. A simple example of something rejected by C3: - suppose we have classes B and C derived directly from object - class X(B, C) has MRO [X, B, C, object] - class Y(C, B) has MRO [Y, C, B, object] - class Z(X, Y) is *rejected* because there is no consistent ordering for B and C in the MRO for Z However, if we construct a similar situation using implicit ABCs, e.g. by removing B and C from the list of explicit bases of X and Y, and instead registering X and Y as their virtual subclasses -- then Z(X, Y) is valid and Z is a virtual subclass of both B and C. But there is no ordering preference in this case, so I think it's good if @singledispatch refuses the temptation to guess here, in the case where there are registered dispatches for B and C but none for X, Y or Z. I believe the rest of the discussion is purely about what to do if B was explicitly listed as a base but C wasn't (or vice versa). There are still a few different cases; the simplest is this: class X(B) -- MRO is [X, B, object] class Y(B) -- MRO is [Y, B, object] C.register(X) C.register(Y) class Z(X, Y) -- MRO is [Z, X, Y, B, object] IIUC you want @singledispatch to still reject a call for a Z instance if the only relevant registered dispatches are for B and C -- because you claim that X, Y and Z are just as much subclasses of B as they are of C. (It doesn't actually matter whether we use X, Y or Z as an example here -- all of them have the same problem.) But I disagree. First, in the all-explicit example, we can equally say that X is just as much a subclass of B as it is of C. And yet, because both appear in the explicit MRO, B wins when dispatching for X -- and C wins when dispatching for Y, because the explicit base classes are ordered differently there. So the property of being just as much a base class isn't used -- but the order in the explicit MRO is. It is the nature and intent of ABC registration that it does not have to occur in the same file as the class definition. In particular, it is possible that the class definitions of B, C, X, Y and Z all occur together, but the C.register() calls occur in a different, unrelated module, which is imported only on the whim of the top-level application, or as a side effect of some unrelated import made by the top-level app.
[issue10060] python.exe crashes or hangs on help() modules when bad modules found
Terry J. Reedy added the comment: This issue still seems to be about bad extension modules crashing CPython and we cannot fix that. -- resolution: - wont fix stage: - committed/rejected status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10060 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
Changes by Mike Gilbert floppymas...@gmail.com: -- nosy: +floppymaster ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10794] Infinite recursion while garbage collecting loops indefinitely
Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: -terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11126] Wave.py does not always write proper length in header
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11343] Make errors due to full parser stack identifiable
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
