[issue24062] links to os.stat() in documentation lead to stat module instead
Roundup Robot added the comment: New changeset 5850f0c17c34 by Berker Peksag in branch '3.4': Issue #24062: Fix os.stat links. Patch by July Tikhonov. https://hg.python.org/cpython/rev/5850f0c17c34 New changeset 18882c93f4bd by Berker Peksag in branch 'default': Issue #24062: Fix os.stat links. Patch by July Tikhonov. https://hg.python.org/cpython/rev/18882c93f4bd -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24062 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24062] links to os.stat() in documentation lead to stat module instead
Berker Peksag added the comment: Thanks for the patch, July. -- nosy: +berker.peksag resolution: - fixed stage: - resolved status: open - closed versions: -Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24062 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16669] Docstrings for namedtuple
Peter Otten added the comment: Here's a variant that builds on your code, but makes for a nicer API. Single-line docstrings can be passed along with the attribute name, and with namedtuple.with_docstrings(... all info required to build the class ...) from a user perspective the factory looks like a class method: from functools import partial from collections import namedtuple def _with_docstrings(cls, typename, field_names_with_doc, *, verbose=False, rename=False, doc=None): field_names = [] field_docs = [] if isinstance(field_names_with_doc, str): field_names_with_doc = [ line for line in field_names_with_doc.splitlines() if line.strip()] for item in field_names_with_doc: if isinstance(item, str): item = item.split(None, 1) if len(item) == 1: [fieldname] = item fielddoc = None else: fieldname, fielddoc = item field_names.append(fieldname) field_docs.append(fielddoc) nt = cls(typename, field_names, verbose=verbose, rename=rename) for fieldname, fielddoc in zip(field_names, field_docs): if fielddoc is not None: new_property = property(getattr(nt, fieldname), doc=fielddoc) setattr(nt, fieldname, new_property) if doc is not None: nt.__doc__ = doc return nt namedtuple.with_docstrings = partial(_with_docstrings, namedtuple) if __name__ == __main__: Point = namedtuple.with_docstrings(Point, x abscissa\ny ordinate) Address = namedtuple.with_docstrings( Address, name Surname first_name First name city email Email address ) Whatever = namedtuple.with_docstrings( Whatever, [(foo, doc for\n foo), (bar, doc for bar), baz], doc=The Whatever class. Example for a namedtuple with multiline docstrings for its attributes.) -- nosy: +peter.otten ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24064] Make the property doctstring writeable
Berker Peksag added the comment: Here is a patch. I'm not familiar with this part of the CPython source. So please tell me if there is a better way to do it. I only updated Doc/whatsnew/3.5, but other places in the documentation needs to be updated. -- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file39214/issue24064.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24040] plistlib assumes dict_type is descendent of dict
Ronald Oussoren added the comment:
To react to myself: checking for self.dict_type might break users that pass in
a callable:
x = plistlib.load(fp, dict_type=lambda:{})
As Behdad memtioned testing that the type isn't list would be better:
if not isinstance(..., list):
That attached patch adds a testcase and removes replaces the test for type({})
for something better.
Note: it also replaces ``type([])`` with ``list``, the latter is cleaner.
--
Added file: http://bugs.python.org/file39215/issue-24040.txt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24040
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20210] Provide configure options to enable/disable Python modules and extensions
Krasimir added the comment: @Thomas: Thank you for the patches! Adding more flexibility to the build system that allows for cross-compiling and building embeddable/distributable python is definitely something that needs to be done is my opinion. So I definitely find your work very valuable to me. I admit that I use all patches, related to feature configuration from http://git.buildroot.net/buildroot/tree/package/python Thank you and keep up the great work! I'm positive about the direction that a flexibility/configurability should be in place, especially when talking for such a mature project. -- nosy: +krasimir_vanev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20210 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24066] send_message should take all the addresses in the To: header into account
New submission from Kirill Elagin: If I have a message with multiple `To` headers and I send it using `send_message` not specifying `to_addrs`, the message gets sent only to one of the recipients. I’m attaching my patch that makes it send to _all_ the addresses listed in `To`, `Cc` and `Bcc`. I didn’t add any new tests as the existing ones already cover those cases and I have no idea how on Earth do they pass. -- components: Library (Lib) messages: 242158 nosy: kirelagin priority: normal severity: normal status: open title: send_message should take all the addresses in the To: header into account ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1). Are you serious? I've seen senior programmers who thought that status 0 means failure and status = 0 means success. Why would anyone who understands English would need to know what the numerical value of EXIT_FAILURE is to understand that status=EXIT_FAILURE means failure? Not to mention that google returns a pageful of relevant links for EXIT_FAILURE. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Antoine Pitrou added the comment: So you need to: - have an API to wrap a clear-text protocol in a SSL protocol (see e.g. BaseProactorEventLoop._make_ssl_transport()... note how there's a waiter argument, what should be done with that?) - be able to replace a protocol with another on the transport (perhaps using a new, optional Transport API?) - perhaps a higher-level API that combines the two Also for convenience a protocol should probably be able to inspect whether it has *already* been wrapped. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Steve Dougherty added the comment: I've added a patch to change the order of evaluation and of STORE_MAP's arguments. It includes a test incorporating the review on the previous version. I noticed I had to remove existing .pyc files to avoid TypeErrors about values being unhashable. I take it the version numbers in the filenames are sufficient to prevent that problem in a release? -- Added file: http://bugs.python.org/file39218/issue11205.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24067] Weakproxy is an instance of collections.Iterator
New submission from Eyal Reuveni: Calling weakref.proxy() on an object returns something that is an instance of collections.Iterator, regardless of whether the object is an instance of collections.Iterator or even if the object itself is iterable. To reproduce, run the following code (verified in python2.7 and 3.4 on my Mac): import collections import weakref class NotIterator: pass not_iterator = NotIterator() isinstance(not_iterator, collections.Iterator) # returns False proxy_object = weakref.proxy(not_iterator) isinstance(proxy_object, collections.Iterator) # returns True, should be False -- components: Library (Lib) messages: 242159 nosy: ereuveni priority: normal severity: normal status: open title: Weakproxy is an instance of collections.Iterator type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax
Changes by Guido van Rossum gu...@python.org: -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24017 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: if you use them, your code won't work with long time supported CPython versions like 3.4 for the next decade or so. This would be a generic argument against any new feature. I don't think it is very compelling in this case. For people who develop on a latest version. these constants will pop up in sys.tab autocompletion and they will likely use them. If they need to support pre-3.5 versions, try: from sys import exit, EXIT_FAILURE except ImportError: from sys import exit EXIT_FAILURE = 1 is not a hard work-around. You would say, why not just use EXIT_FAILURE = 1 to begin with? To avoid Bob using EXIT_FAILURE = -1, Alice using EX_FAIL = 1 and Karl giving up and using exit(1) in perpetuity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Raymond Hettinger added the comment: The latest patch looks good overall. Łukasz, assigning back to you. -- assignee: rhettinger - lukasz.langa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: Having looked at the implementation, the easiest way to do this will be to add an applocal = true option to pyvenv.cfg, which would behave identically to setting %PYTHONHOME% to the directory containing the config before launch. I wanted to support relative paths for home = but the path handling is so far from sufficient that it wouldn't be secure. As it is, I've fixed a lot of potential buffer overruns in getpathp.c already, but I don't want to implement true relative paths, so I'd prefer to require home = to be absolute and add a second property that effectively means home = .. Any thoughts/comments/preferences? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9858] Python and C implementations of io are out of sync
Laura Rupprecht added the comment: There were originally three methods present in RawIOBase that were not present in PyRawIOBase_Type: 1. readinto 2. write 3. __weakref__ I've created a patch that adds the first two to PyRawIOBase_Type. The python class readinto and write methods raise UnsupportedOperation, so the c methods return a PyExc_NotImplementedError. The next major question I have is whether we need to implement a __weakref__ method or this should be ignored in the test. -- keywords: +patch nosy: +laura Added file: http://bugs.python.org/file39212/issue9858.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24018] add a Generator ABC
Stefan Behnel added the comment: Please either 1) drop the throw() method entirely or 2) make throw an abstractmethod() Ok, as I already said, I think it's important to provide the complete protocol as code will usually expect that. Also, close() has a helpful implementation, but it depends on throw(). Thus, I'll go with 2) and make throw() abstract. It's easy enough to call super(), but then it's explicit. I agree that that's better here. Patch updated. -- Added file: http://bugs.python.org/file39213/generator_abc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24018 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22057] The doc say all globals are copied on eval(), but only __builtins__ is copied
Raymond Hettinger added the comment: The patch looks good (though it would have been easier to check the diff if the text had not be reflowed). I will apply it when I get a chance. Or if anyone else wants to grab it, go ahead. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22057 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Raymond Hettinger added the comment: Hmm, the presense of _PyTuple_DebugMallocStats, repeat_traverse, and visit_decref suggests that the profile may have been run with debugging code enabled and GC enabled. The property patch looks good. Depending on how far you want to go with this, you could save your tuple of length-1 statically and reuse it on successive calls if its refcnt doesn't grow (see the code for zip() for an example of how to do this). That would save the PyTuple_New and tupledealloc calls. Going further, potentially you could in-line some of the code it PyObject_Call, caching the callsite and its NULL check, and looking at the other steps to see if they are all necessary in the context of a property_desc_get(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows
Changes by irdb dalba.w...@gmail.com: -- nosy: +irdb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23975] numbers.Rational implements __float__ incorrectly
Wolfgang Maier added the comment: After considering this for a while, I think: return float(self.numerator / self.denominator) is the best solution: * it is simple and works reasonably well as a default * it fixes Rational.__float__ for cases, in which numerator / denominator returns a custom Real instance * in the problematic scenario brought up by Mark, in which truediv of the numerator and denominator returns another Rational creating a potentially infinite recursion, a RuntimeError will be raised when the maximum recursion limit is reached. This is not an unheard of error to run into while trying to implement a custom numeric type and will provide reasonable (though not ideal) information about the problem. * the workaround for the above is obvious: it is ok for self.numerator / self.denominator to return a Rational instance, but its type should overwrite Rational.__float__ to break the recursion. This could get documented in the docstring of Rational.__float__. I've attached a tentative patch. -- keywords: +patch Added file: http://bugs.python.org/file39217/Rational.__float__.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23975 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Joe Jevnik added the comment: I switched to the static tuple. -- Added file: http://bugs.python.org/file39216/with-static-tuple.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Ronald Oussoren added the comment: I don't recall exactly why the universal build support is done the way it is, adding it is too long ago. The reason is likely no longer relevant with any reasonably up-to-date toolset. The patch was created around the time x86 support was added to OSX and at the time there were numerous rough edges (and IIRC I worked on this using a Developer Transition Kit at work, that is before Apple shipped consumer hardware with x86 support, let alone non-beta software with x86 support) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8027 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Joe Jevnik added the comment: I don't think that I can cache the __call__ of the fget object because it might be an instance of a heaptype, and if someone changed the __class__ of the object in between calls to another heaptype that had a different __call__, you would still get the __call__ from the first type. I also don't know if this is supported behavior or just something that works by accident. I read through PyObject_Call, and all the code is needed assuming we are not caching the tp_call value. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22906] PEP 479: Change StopIteration handling inside generators
Chris Angelico added the comment: Had a peek at the 2.7 branch in the web (https://hg.python.org/cpython/file/4234b0dd2a54/Lib/test) and all the tests appear to be testing the behaviour *with* the future directive, not bothering to test the old behaviour. It makes sense - that way, when the future directive becomes permanent, there's no suddenly-failing test - can someone confirm that that's the intention? The current test simply triggers a StopIteration and verifies that RuntimeError comes up off it, without testing the current behaviour, nor testing any of the aspects that haven't changed. I'm basically assuming that generators themselves are adequately tested elsewhere, such that a bug in the PEP 479 code that breaks generators in any other way should be caught by a test failure someplace else. Can anyone think of other aspects of PEP 479 that need to be tested? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22906 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16669] Docstrings for namedtuple
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg242118 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
Andrew Svetlov added the comment: Fixed. Sorry for long delay. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16669] Docstrings for namedtuple
Raymond Hettinger added the comment: Ideally, I prefer to stick with either a separate customization step or with the original __new__ constructor, and that uses **kwds so we can use a standard syntax for the name value pairs and to allow that possibility of someone passing in an existing dict using NT.set_docstrings(**d). Also FWIW, the addition can be simplified a bit when Issue 24064 is added: for fieldname, docstring in docstrings.items(): getattr(cls, fieldname).__doc__ = docstring -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15064] Use context manager protocol for more multiprocessing types
Dan O'Reilly added the comment: It's probably too late to do anything about this now, but wouldn't it make more sense for `Pool.__exit__` to call `close`, rather than `terminate`? The vast majority of the time, that's probably what the user of the `Pool` would want to run. It also would make the behavior consistent with `concurrent.futures.ProcessPoolExecutor`, which will always wait for pending tasks to complete before exiting the `with` block. -- nosy: +dan.oreilly ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16669] Docstrings for namedtuple
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- Removed message: http://bugs.python.org/msg242119 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
Roundup Robot added the comment: New changeset 69951573cb0e by Andrew Svetlov in branch '3.4': Issue #21354: PyCFunction_New function is exposed by python DLL again. https://hg.python.org/cpython/rev/69951573cb0e -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16669] Docstrings for namedtuple
Raymond Hettinger added the comment: Sorry Peter, I don't like that variant and want to stick with a separate customization step that uses **kwds so we can use normal syntax for the name value pairs and to allow that possibility of someone passing in an existing dict using NT.set_docstrings(**d). Also FWIW, the addition can be simplified a bit when Issue 24064 is added: for fieldname, docstring in docstrings.items(): getattr(cls, fieldname).__doc__ = docstring -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16669] Docstrings for namedtuple
Raymond Hettinger added the comment: The need for this may be eliminated by issue 24064. Then we change the docstrings just like any other object with no special rules or methods. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23911] Move path-based bootstrap code to a separate frozen file.
Eric Snow added the comment: Glad to hear the patch is conceptually consistent with other components. :) And the internal/external suggestion is a good one. I'll update the patch when I have a minute. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11205] Evaluation order of dictionary display is different from reference manual.
Nick Coghlan added the comment: The pyc issue suggests the magic number embedded in pyc files to indicate bytecode compatibility needs to be incremented. If I recall correctly, that lives in Lib/importlib/_bootstrap.py these days. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11205 ___ ___ Python-bugs-list mailing list Unsubscribe: https://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
Adam added the comment: Is this enhancement still open? I've run into this problem previously, and would be more than happy to implement this feature. -- nosy: +azsorkin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15064] Use context manager protocol for more multiprocessing types
Ned Deily added the comment: Dan, this issue was closed and the code associated with it released a few years ago. Comments here will likely be ignored. If you want to pursue your suggestion, please open a new issue for it. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9782] _multiprocessing.c warnings under 64-bit Windows
Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9782 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24066] send_message should take all the addresses in the To: header into account
Ned Deily added the comment: Kirill, the patch is missing. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24066 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21345] multiprocessing.Pool._handle_workers sleeps too long
Changes by Davin Potts pyt...@discontinuity.net: -- nosy: +davin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24067] Weakproxy is an instance of collections.Iterator
Changes by Ned Deily n...@acm.org: -- nosy: +fdrake, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16620] Avoid using private function glob.glob1() in msi module and tools
Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: +steve.dower ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23614] Opaque error message on UTF-8 decoding to surrogates
Chris Angelico added the comment: Got around to tracking down where this is actually being done. It's in Objects/stringlib/codecs.h and it looks to be a hot area for optimization. I don't want to fiddle with it without knowing a lot about the performance implications (UTF-8 encode/decode being a pretty common operation), and since my knowledge of CPU operation costs is about fifteen or twenty years out of date, it's probably best I not do this. It would be nice if the message could be improved per Ezio's suggestion, but that would mean returning more information to the caller. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23614 ___ ___ Python-bugs-list mailing list Unsubscribe: https://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 Ned Deily n...@acm.org: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19543] Add -3 warnings for codec convenience method changes
Serhiy Storchaka added the comment: I think we should just backport issue19619 and issue20404. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19543 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22544] Inconsistent cmath.log behaviour
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22544 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Raymond Hettinger added the comment: What kind of speed improvement have you gotten? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23910 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23910] C implementation of namedtuple (WIP)
Joe Jevnik added the comment:
I am currently on a different machine so these numbers are not relative to the
others posted earlier.
* default
./python -m timeit -s from collections import namedtuple as n;a = n('n', 'a b
c')(1, 2, 3) a.a
1000 loops, best of 3: 0.0699 usec per loop
* patch
./python -m timeit -s from collections import namedtuple as n;a = n('n', 'a b
c')(1, 2, 3) a.a
1000 loops, best of 3: 0.0468 usec per loop
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23910
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21354 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Antoine Pitrou added the comment: We already have over a dozen BSDish exit codes in os that are hardly ever used. Then precisely, those new codes should go in the os module as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: Those should be in the os module, not in sys. I disagree. The whole point of this proposal is to have platform-independent status codes available next to the sys.exit() function. We already have over a dozen BSDish exit codes in os that are hardly ever used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Thomas Kluyver added the comment: Would that option be the only thing that needs to be set to make Python app-local? I'm not familiar with what lives in pyvenv.cfg. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23955] Add python.ini file for embedded/applocal installs
Steve Dower added the comment: None of the other options really have much use in this case, since they're mostly about how to combine multiple environments rather than excluding implicit ones. Setting PYTHONHOME to the current directory certainly seems to be enough AFAICT, at least for Windows, as that bypasses the most problematic registry lookup. Having an applocal option means we can go further and ignore all registry keys and environment variables. I haven't looked into how to duplicate the behaviour on other OSs, but Modules/getpath.c looks similar enough to PC/getpathp.c that I guess it'll be similar. Adding the MacOS folks in case they have suggestions/concerns. -- nosy: +ned.deily, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23955 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21791] Proper return status of os.WNOHANG is not always (0, 0)
Davin Potts added the comment: The man pages for waitpid on OpenBSD 5.x do not suggest any meaningful value will be returned in status when WNOHANG is requested and no child processes have anything to report. The following session attempts to exercise os.waitpid using Python 2.7.9 on an OpenBSD 5.3 i386 system: import os os.spawnl(os.P_NOWAIT, '/bin/sleep', 'sleep', '10') 19491 os.waitpid(-1, os.WNOHANG) (0, 0) os.waitpid(-1, os.WNOHANG) # wait a few seconds, try again (0, 0) os.waitpid(-1, os.WNOHANG) # waited long enough for sleep to exit (19491, 0) os.waitpid(-1, os.WNOHANG) # at this point, no children remain Traceback (most recent call last): File stdin, line 1, in module OSError: [Errno 10] No child processes Can you provide any further information, like: * OpenBSD docs that explain that we should expect non-zero values for status coming from waitpid? * Example Python code to provoke the behavior originally described? * Other suggestion of why OpenBSD's waitpid, which itself depends upon wait4, when called (the way Python calls it) with an already initialized status=0 and WNOHANG should return a modified value for status when the child had nothing to report? -- nosy: +davin status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21791 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Ethan Furman added the comment: I agree with Antoine -- all the exit codes should be in one place. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Antoine Pitrou added the comment: Well, my favourite answer would be use sys.exit(0) and sys.exit(1), respectively (or raise SystemExit without or with an error message), as everyone is already doing right now. Since I don't really get the usability argument of adding those constants, it's hard for me to buy that they should sit close to sys.exit(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: Ethan all the exit codes should be in one place. Do you realize that os.EX_* codes are not available on Windows? Having platform-independent EXIT_* codes next to posix-only EX_* codes will send the wrong message about their availability. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23749] asyncio missing wrap_socket
Guido van Rossum added the comment: We didn't do this originally because the 3.4 SSL module didn't have this functionality (or maybe it was 3.3 that didn't have this) but now that we do have it I'd be very happy if you could implement this! I'm not sure what the right interface is, probably coroutine methods on StreamReader and StreamWriter that take an SSLContext object (and from then on the reader/writer is using SSL), but there also would have to be a lower-level way to do the same thing to a Transport. This would probably have to return a new Transport that uses the original, wrapped transport for reading/writing. You probably should write a small test app that proves this works for real too. Perhaps start with a synchronous test app that uses the existing wrap_socket() and then work on the async interface until you can reproduce the same thing there. Let us know if you need more information. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23749 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24065] Outdated *_RESTRICTED flags in structmember.h
Antoine Pitrou added the comment: +1 for deprecating them. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24065 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24065] Outdated *_RESTRICTED flags in structmember.h
New submission from Berker Peksag: Looks like READ_RESTRICTED, PY_WRITE_RESTRICTED and RESTRICTED flags were used for restricted mode [1] in Python 2. restricted mode has been deprecated in Python 2.3. Also, the current documentation is outdated. WRITE_RESTRICTED is now PY_WRITE_RESTRICTED: https://docs.python.org/3/extending/newtypes.html#generic-attribute-management There are a few usages of these flags in the CPython source: PY_WRITE_RESTRICTED * Objects/funcobject.c * Objects/methodobject.c RESTRICTED * Objects/funcobject.c * Objects/classobject.c Are they still useful or can we deprecate/remove them now? [1] https://github.com/python/cpython/blob/2.7/Python/structmember.c#L180 -- components: Interpreter Core messages: 242134 nosy: berker.peksag priority: normal severity: normal status: open title: Outdated *_RESTRICTED flags in structmember.h type: enhancement versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24065 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: Antoine Since I don't really get the usability argument of adding those constants .. If I am alone in finding exit(EXIT_FAILURE) clearer than exit(1), I should certainly drop my proposal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Antoine Pitrou added the comment: Well it would be clearer if not for the widely established knowledge (amongst most or all programming languages) that zero means success and non-zero means failure. So in this case I find it personally useless. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Stefan Krah added the comment: I'm +0 on adding these. The only reason is that I've seen academic code written by well-known researchers that used 1 for a successful exit. :) I'm not sure about the os module. These are C99 and not OS specific. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24037] Argument Clinic: add the boolint converter
Tal Einat added the comment: If I was writing a function/method with a conceptually boolean parameter (True/False), I wouldn't want that to accept any Python object. For example, I would want passing a tuple or list to raise a TypeError. But according to the docs[1], that's what the 'p' converter does. If Python had a separate boolean type, this would be simple, but bool is a subclass of int, and it is easy to get a 0 or a 1 instead of True or False without noticing. So it seems reasonable when using the C API to accept an int when you want to get a boolean. I'd want a converter to convert it to a C bool, of course. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24037 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: Then precisely, those new codes should go in the os module as well. What is your logic? Having os.EX_ codes in os does not help as far as sys.exit() is concerned: no-one is using them and they are not available on all platforms. If we add EXIT_FAILURE and EXIT_SUCCESS to os now, we will only create confusion: should I use os.EX_OK or os.EXIT_SUCCESS? Note that sys.exit() is different from os._exit(). It may not even result in termination of the interpreter. Why should users of sys.exit() be required to import os if they want to indicate a failure? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: This can be implemented as separate module on PyPI. Sure! Make them even less discoverable! Let me try to state my motivations for adding these constants: 1. I find exit(EXIT_FAILURE) much clearer than exit(1). 2. I want people to standardize on status=1 for a generic failure code. I do see exit(-1) used as often as exit(1). 3. I want discourage people from using computed integer results as exit status. For example, # process files and store errors in a list sys.exit(len(errors)) # bad - success for multiples of 256 errors sys.exit(sys.EXIT_SUCCESS if not errors else sys.EXIT_FAILURE) # good -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Ethan Furman added the comment: An entire PyPI module for two constants? Change of heart, I'm okay with them going in sys, but only +0 on adding them. This SO answer* has an interesting point to make about the nature of return codes and what their values should be; tl;dr - the convention should be between your program and the other program(s) you are trying communicate with. * http://stackoverflow.com/a/8869000/208880 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: the convention should be between your program and the other program(s) you are trying communicate with. This may be true in general, but Python stdlib sets the convention in its subprocess.check_call and subprocess.check_output methods. These methods use 0=success convention. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Antoine Pitrou added the comment: I want people to standardize on status=1 for a generic failure code. Why that? Multiple error codes can be used by the same program, depending on the kind of error. I want discourage people from using computed integer results as exit status. Ok, that's the first good argument for this feature. Although I would encourage people raise an exception if they want to signify a failure, rather than simply change the error code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://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
Guido van Rossum added the comment: Does the cpython test runner have this? Might be nice there. Not sure if the default test runner is something to extend at this point. Eveybody is using py.test anyway... On Monday, April 27, 2015, Ned Deily rep...@bugs.python.org wrote: Changes by Ned Deily n...@acm.org javascript:;: -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org javascript:; http://bugs.python.org/issue17908 ___ -- title: Unittest runner needs an option to call gc.collect() after each test - Unittest runner needs an option to call gc.collect() after each test ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17908 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: Stefan I've seen academic code written by well-known researchers Stefan that used 1 for a successful exit. Thank you! What I've seen more than once was exit(True) to indicate success where True is not necessarily a literal, but something like len(results) 0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Serhiy Storchaka added the comment: This can be implemented as separate module on PyPI. No need to add these aliases for 0 and 1 to the stdlib. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24064] Make the property doctstring writeable
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24064 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Berker Peksag added the comment: 1. I find exit(EXIT_FAILURE) much clearer than exit(1). import sys exit(sys.EXIT_FAILURE) or import sys sys.exit(sys.EXIT_FAILURE) don't look too clear to me. On the other hand, these constants may helpful to people who came from C world. 3. I want discourage people from using computed integer results as exit status. Adding a FAQ entry or updating sys.exit() documentation would be more suitable to achieve the aim of this item. I wouldn't add two constants to the stdlib because of a bad programming practice. -- nosy: +berker.peksag ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Stefan Behnel added the comment: why not spell them sys.exit.FAILURE and sys.exit.SUCCESS ? -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: I want people to standardize on status=1 for a generic failure code. Why that? Multiple error codes can be used by the same program, depending on the kind of error. Antoine, please read what I write carefully before disagreeing. I want to standardize on status=1 for a **generic** failure code. Cooperating processes can certainly agree on other values for the specific failure modes. What I really want to avoid is the use of -1 as a generic failure code, because it leads to a rather common error rc = subprocess.call(..) if rc 0: raise Error # never reached! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Serhiy Storchaka added the comment: How often you see EXIT_SUCCESS and EXIT_FAILURE in C code besides GNU tools that should support VMS? And even GNU tools usually use multiple error codes for different kinds of errors. I think that these constants are rather unusual for C programmers. I'm only -0 on adding these constants, not -1, because I'm sure they will be never used. But this will add a burden on the documentation and will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Alexander Belopolsky added the comment: And even GNU tools usually use multiple error codes for different kinds of errors. And how often do they not give them symbolic names? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Stefan Behnel added the comment: Actually, my guess is also that these constants will not be used. Not because they are not helpful, but because they'd only be available in Python 3.5+. Meaning that if you use them, your code won't work with long time supported CPython versions like 3.4 for the next decade or so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
