[issue22302] Windows os.path.isabs UNC path bug
Akima added the comment: FYI: I've only tested this bug on Python 3.3.5 on Windows 7. I expect the bug exists in other versions of Python. -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22302 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22305] Documentation on deepcopy's problems is misleading
New submission from Shailesh Hegde: https://docs.python.org/version/library/copy.html Two problems often exist with deep copy operations that don’t exist with shallow copy operations: Recursive objects (compound objects that, directly or indirectly, contain a reference to themselves) may cause a recursive loop. Because deep copy copies everything it may copy too much, e.g., administrative data structures that should be shared even between copies. I believe the last line in above paragraph is missing a 'not' ahead of 'be shared'. It should read: administrative data structures that should be not shared even between copies -- assignee: docs@python components: Documentation messages: 226123 nosy: docs@python, shlsh priority: normal severity: normal status: open title: Documentation on deepcopy's problems is misleading versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10598] Add test for curses haskey replacement
Terry J. Reedy added the comment: For some reason, rev73781 above links to rev55058:fb542ed91e7f, whereas the actual patch is bff927c8b410. I think testing the replacement is reasonable, but should be call something like 'test_haskey_backup' and it should test that the backup worked, that curses.haskey exists and is the function in curses.haskey. It probably could go in default only. -- components: +Library (Lib), Tests -Extension Modules nosy: +terry.reedy stage: - needs patch title: curses fails to import on Solaris - Add test for curses haskey replacement type: - enhancement versions: +Python 3.4, Python 3.5 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10598 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
New submission from Akima: 1 / 0 (where both numbers are decimal.Decimal) produces a decimal.DivisionByZero exception as I would expect. This is useful. I can use a simple try except block to catch a potential division by zero error in my code. 0 / 0 (where both numbers are decimal.Decimal) produces a decimal.InvalidOperation exception. This is undesirable. I would expect another decimal.DivisionByZero exception. This means that if I want to catch a division by zero error in my code using a try except block, I now have to catch exceptions for both decimal.DivisionByZero and decimal.InvalidOperation. Presumably decimal.InvalidOperation can be raised in other scenarios, so catching it may result in masking a programming fault (which isn't just a division by zero: 0 / 0). If you perform the same division but using standard Python integers instead of decimal.Decimal objects, the behaviour is exactly as you would expect: 0 / 0 and 1 / 0 both produce a ZeroDivisionError exception. I have tested this in CPython 3.3.5, 3.2.3 and 2.7.3. All versions produce the same behaviour. Demonstration: Python 2.7.3 (default, Feb 27 2014, 19:58:35) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. from decimal import Decimal as d d(1) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/decimal.py, line 1323, in __truediv__ return context._raise_error(DivisionByZero, 'x / 0', sign) File /usr/lib/python2.7/decimal.py, line 3866, in _raise_error raise error(explanation) decimal.DivisionByZero: x / 0 d(0) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python2.7/decimal.py, line 1322, in __truediv__ return context._raise_error(DivisionUndefined, '0 / 0') File /usr/lib/python2.7/decimal.py, line 3866, in _raise_error raise error(explanation) decimal.InvalidOperation: 0 / 0 1 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: integer division or modulo by zero 0 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: integer division or modulo by zero Here is the same demonstration but using a Python 3.2.3 interpreter: Python 3.2.3 (default, Feb 27 2014, 21:31:18) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. from decimal import Decimal as d d(1) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.2/decimal.py, line 1300, in __truediv__ return context._raise_error(DivisionByZero, 'x / 0', sign) File /usr/lib/python3.2/decimal.py, line 3926, in _raise_error raise error(explanation) decimal.DivisionByZero: x / 0 d(0) / d(0) Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.2/decimal.py, line 1299, in __truediv__ return context._raise_error(DivisionUndefined, '0 / 0') File /usr/lib/python3.2/decimal.py, line 3926, in _raise_error raise error(explanation) decimal.InvalidOperation: 0 / 0 1 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: division by zero 0 / 0 Traceback (most recent call last): File stdin, line 1, in module ZeroDivisionError: division by zero -- messages: 226125 nosy: akima priority: normal severity: normal status: open title: Inconsistent division by 0 behaviour in decimal module type: behavior versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
STINNER Victor added the comment: The Python parser works well with UTF8. If you know the encoding, decode from your encoding and encode to UTF8. You should pass the UTF8 flag to the parser. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6029] FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]
Terry J. Reedy added the comment: Mark, the rev #s are not being translated correctly. Better to use the 10 digit hex #. Can you find the commit again? We have a SPARC Solaris 10 buildbot http://buildbot.python.org/all/waterfall?category=3.x.stablecategory=3.x.unstable The ctypes test is passing on 'Open CSW' (I don't know what that means) 2.7 and 3.5. The test suite has not been run recently on GCC recently. Peter or Clifford, can either of you report current status? -- assignee: theller - nosy: +terry.reedy versions: -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6029 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21072] Python docs and downloads not available for Egypt
Changes by Terry J. Reedy tjre...@udel.edu: -- versions: -Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21072 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed
Antoine Pitrou added the comment: This is not about stderr though, this is about the `file` argument that is passed to showwarning(). That stderr may be an invalid file is a rather rare condition, for good reason (even if you want to silence any program output, it is generally better to redirect stderr to /dev/null rather than make it an invalid or closed file). It would be better to research why the original except clause was added than try to blindly extend it, IMO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22298] Lib/warnings.py _show_warning does not protect against being called with a file like object which is closed
Antoine Pitrou added the comment: And so the original silencing came without a bug reference or an explanation: changeset: 25204:2e7fe55c0e11 branch: legacy-trunk user:Mark Hammond mhamm...@skippinet.com.au date:Wed Sep 11 13:22:35 2002 + files: Lib/warnings.py description: Ignore IOError exceptions when writing the message. I'm nosying Mark Hammond in case he remembers what his changeset addressed, but it's 12 years old and may not be relevant anymore. -- nosy: +mhammond ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22298 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Changes by Akima m...@aki.ma: -- components: +Library (Lib) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6029] FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]
Mark Lawrence added the comment: Terry r59626 in the file's revision history refers to eefd521f19ce which I assume is what you're after. FWIW I get that on Windows 8.1 by right clicking on the file, select TortoiseHg, then Revision History. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6029 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21965] Add support for Memory BIO to _ssl
Antoine Pitrou added the comment: Nice work, thank you! The new API looks mostly good to me. I am wondering about a couple of things: - is it necessary to start exposing server_hostname, server_side and pending()? - SSLObject is a bit vague, should we call it SSLMemoryObject? or do you expect we may want to support other kinds of BIOs some day? - should the basic implementations in SSLObject be shared (using some kind of mixin) with SSLSocket, or is it unpractical to do so? I'll take a look at the code later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +facundobatista, mark.dickinson, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22305] Documentation on deepcopy's problems is misleading
Steven D'Aprano added the comment: It should read: administrative data structures that should be not shared even between copies No. If they should NOT be shared, then making a deep copy is the correct thing to do. The problem with deepcopy is when you actually do want to share some deep data structures, but not others. Then making a copy is the wrong thing, since they will no longer be shared. The current documentation is correct. I'm going to leave the issue Open for the time being, in case somebody can think of wording that is more clear and less likely to be misunderstood. -- nosy: +steven.daprano resolution: - not a bug ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22261] Document how to use Concurrent Build when using MsBuild
sbspider added the comment: Uploaded a new patch. -- Added file: http://bugs.python.org/file36506/readme.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22261 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Stefan Krah added the comment:
The behavior is according to the specification:
http://speleotrove.com/decimal/decarith.html
The idea behind it is that 1/0 can be reasonably defined as infinity,
whereas 0/0 is undefined. You can see that if you disable the exceptions:
c = getcontext()
c.traps[DivisionByZero] = False
c.traps[InvalidOperation] = False
Decimal(1) / 0
Decimal('Infinity')
Decimal(0) / 0
Decimal('NaN')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22306
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6029] FAIL: test_longdouble (ctypes.test.test_callbacks.Callbacks) [SPARC/64-bit]
Peter Bray added the comment: Terry, I no longer have easy access to SPARC64 systems (they are in boxes), so unfortunately I will not be able to contribute to this issue in the near future. Peter -- components: -Tests ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6029 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Akima added the comment: Hi skrah. Thanks for the feedback. That specification is interesting. As this IBM spec appears to be a /general/ specification for performing decimal arithmatic and not targetted specifically at Python's decimal arithmatic implementation, I would expect all of Python to adhere to its recommendations (for consitency). If the division by 0 behaviour of the decimal module is in fact correct (as per the spec you have linked) and desirable, then perhaps the Python standard integer division by zero behaviour is incorrect. 0 / 0 ... raises a ZeroDivisionError exception. This is in conflict with the IBM spec and with the behaviour of the decimal module. (I realize that arithmatic in the decimal module is not supposed to be equivalent to arithmatic with standard python number types, but this exception behaviour seems like something that should be consistent between the two arithmatic implementations.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Akima added the comment: Sorry. Scratch my last comment. I see from the docs ( https://docs.python.org/3/library/decimal.html ) that the decimal module explicitly references that IBM spec. I imagine that standard python arithmatic doesn't even attempt to conform to this ibm spec. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22306] Inconsistent division by 0 behaviour in decimal module
Stefan Krah added the comment: According to IEEE 754-2008 binary floats should use the same exceptions in this case. 7.2 Invalid operation ... e) division: division(0, 0) or division(∞, ∞) 7.3 Division by zero The divideByZero exception shall be signaled if and only if an exact infinite result is defined for an operation on finite operands. But the Python binary float implementation is a lot older than the 2008 standard. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22306 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22307] os.getlogin() documentation has misleading side note
New submission from Carlo: The documentation for os.getlogin() says: ... ``pwd.getpwuid(os.getuid())[0]`` to get the login name of the currently effective user id Either, os.getuid() should be changed to os.geteuid(), or the wording should be changed. -- assignee: docs@python components: Documentation messages: 226139 nosy: Carlo, docs@python priority: normal severity: normal status: open title: os.getlogin() documentation has misleading side note versions: Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22307 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1425127] os.remove OSError: [Errno 13] Permission denied
Changes by Brian Curtin br...@python.org: -- nosy: -brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1425127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Antoine Pitrou: I understand. It would be nice to have that new Python string based readline hook. Its default implementation could be to call PyOS_Readline and decode the bytes using sys.stdin.encoding (as the tokenizer currently does). Tokenizer then woudn't need to decode if it called the new hook. Victor Stinner: I'm going to try the approach of reencoding my stream to UTF-8. So then my UTF-16-LE encoded stream is decoded, then encoded to UTF-8, interpreted as null-terminated *char, which is returned to the tokenizer, which again decodes it and encodes to UTF-8. I wonder if the last step could be short-circuited. What is this UTF8 flag to Python parser? I couldn't find any information. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22297] 2.7 json encoding broken for enums
Serhiy Storchaka added the comment: The enum types was added to the stdlib in 3.4. There are no the enum types in Python 2.7. There is no a bug, support for the enum types is new feature. -- nosy: +barry, eli.bendersky, ethan.furman, serhiy.storchaka resolution: - not a bug status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22297] 2.7 json encoding broken for enums
Antoine Pitrou added the comment: Edward, is this a regression? If yes, we should probably fix it. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22308] add {implementation} to sysconfig.py
New submission from mattip:
An issue was reported on PyPy where a user had a
~/.local/lib/python2.7/site-packages directory that contained cpython specific
libraries. We trakced it down to posix_user in sysconfig.py being set to an
implementation-specific cpython path, but used by pypy.
This patch against HEAD adds {implementation} and {implementation_lower}
fields to _CONFIG_VARS, making sysconfig.py compatable with other python
implementations. Perhaps valuable to jython as well, which would require
modifying _get_implementation() accordingly
--
components: Library (Lib)
files: sysconfig_head.patch
keywords: patch
messages: 226143
nosy: mattip
priority: normal
severity: normal
status: open
title: add {implementation} to sysconfig.py
type: behavior
Added file: http://bugs.python.org/file36507/sysconfig_head.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22308
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22308] add {implementation} to sysconfig.py
mattip added the comment: adding a diff patch to 2.7 -- Added file: http://bugs.python.org/file36508/sysconfig_2_7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22308 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22297] 2.7 json encoding broken for enums
Ethan Furman added the comment: This is not a regression. json only deals with standard types (int, str, etc.), and Enum is not a standard type. Enum was introduced in 3.4, so corresponding changes were made to json to support int and float subclasses, of which IntEnum is one. In other words, this was a bug that no one noticed for many many releases, and I'm not sure we should fix it in 2.7 now. Arguments for fixing? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20421] expose SSL socket protocol version
Antoine Pitrou added the comment: Updated patch with doc. -- stage: needs patch - patch review Added file: http://bugs.python.org/file36509/ssl_version2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20421 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22297] 2.7 json encoding broken for enums
Ethan Furman added the comment: One argument against fixing: If we do fix in 2.7.9 then any program targeting it will be unable to target 3.0-3.3, as those versions do not have the fix from 3.4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22297] 2.7 json encoding broken for enums
Barry A. Warsaw added the comment:
On Aug 30, 2014, at 07:34 PM, Ethan Furman wrote:
In other words, this was a bug that no one noticed for many many releases,
and I'm not sure we should fix it in 2.7 now.
Arguments for fixing?
-1 on fixing it, but we *can* document workarounds. Here's what I use in
Mailman 3.
class ExtendedEncoder(json.JSONEncoder):
An extended JSON encoder which knows about other data types.
def default(self, obj):
if isinstance(obj, datetime):
return obj.isoformat()
elif isinstance(obj, timedelta):
# as_timedelta() does not recognize microseconds, so convert these
# to floating seconds, but only if there are any seconds.
if obj.seconds 0 or obj.microseconds 0:
seconds = obj.seconds + obj.microseconds / 100.0
return '{0}d{1}s'.format(obj.days, seconds)
return '{0}d'.format(obj.days)
elif isinstance(obj, Enum):
# It's up to the decoding validator to associate this name with
# the right Enum class.
return obj.name
return json.JSONEncoder.default(self, obj)
(Frankly, I wish it was easier to extend the encoder, e.g. by registering
callbacks for non-standard types.)
I don't automatically decode enums because on PUTs, POSTs, and PATCHs, I know
which attributes should be enums, so I can convert them explicitly when I
validate input forms.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22297
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22215] embedded NUL character exceptions
Roundup Robot added the comment: New changeset a058760cb069 by R David Murray in branch '3.4': #22215: have the smtplib 'quit' command reset the state. http://hg.python.org/cpython/rev/a058760cb069 New changeset d0d4ab0ba70e by R David Murray in branch 'default': Merge #22215: have the smtplib 'quit' command reset the state. http://hg.python.org/cpython/rev/d0d4ab0ba70e New changeset 7288519594de by R David Murray in branch '2.7': #22215: have the smtplib 'quit' command reset the state. http://hg.python.org/cpython/rev/7288519594de -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22215 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22216] smtplip STARTTLS fails at second attampt due to unsufficiant quit()
R. David Murray added the comment: Thanks, Milan. I could swear I typed a '6' in the commit message, but apparently not... New changeset a058760cb069 by R David Murray in branch '3.4': #22215: have the smtplib 'quit' command reset the state. http://hg.python.org/cpython/rev/a058760cb069 New changeset d0d4ab0ba70e by R David Murray in branch 'default': Merge #22215: have the smtplib 'quit' command reset the state. http://hg.python.org/cpython/rev/d0d4ab0ba70e New changeset 7288519594de by R David Murray in branch '2.7': #22215: have the smtplib 'quit' command reset the state. http://hg.python.org/cpython/rev/7288519594de -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22215] embedded NUL character exceptions
Changes by R. David Murray rdmur...@bitdance.com: -- Removed message: http://bugs.python.org/msg226149 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22215 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22309] distutils/spawn.py handle fork() not implemented.
New submission from John Malmberg: Distutils currently can not handle a Posix platform that does not implement fork(). This patch retries with the _spawn_nt to use the spawn() methods if fork() is not implemented. A platform that does not implement fork() can provide spawn*() methods for python to use. -- components: Distutils files: lib_distutils_spawn_py.gdiff messages: 226151 nosy: John.Malmberg, dstufft, eric.araujo priority: normal severity: normal status: open title: distutils/spawn.py handle fork() not implemented. type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36510/lib_distutils_spawn_py.gdiff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22309 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22283] AMD64 FreeBSD 9.0 3.x fails to build the _decimal module: #error libmpdec version = 2.4.1 required
Stefan Krah added the comment: I've upgraded the system libmpdec to 2.4.1. -- resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22283 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22309] distutils/spawn.py handle fork() not implemented.
Ned Deily added the comment: As far as I can tell, a Posix-compliant system is required to implement fork(). Which platform doesn't? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22309 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20421] expose SSL socket protocol version
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +geertj ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20421 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22310] Report actual EOF character instead of assuming Ctrl-D
New submission from John Malmberg: Have setquit() use the actual EOF character where available instead of assuming Ctrl-D. -- components: Library (Lib) files: lib_site_py.gdiff messages: 226154 nosy: John.Malmberg priority: normal severity: normal status: open title: Report actual EOF character instead of assuming Ctrl-D type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file36511/lib_site_py.gdiff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22310 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22310] Report actual EOF character instead of assuming Ctrl-D
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22310 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22307] os.getlogin() documentation has misleading side note
Roundup Robot added the comment: New changeset 59f2edeb8443 by Benjamin Peterson in branch '2.7': getuid() returns real process id not effective (closes #22307) http://hg.python.org/cpython/rev/59f2edeb8443 New changeset c30163548f64 by Benjamin Peterson in branch '3.4': getuid() returns real process id not effective (closes #22307) http://hg.python.org/cpython/rev/c30163548f64 New changeset 164a17eca081 by Benjamin Peterson in branch 'default': merge 3.4 (closes #22307) http://hg.python.org/cpython/rev/164a17eca081 -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22307 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22257] PEP 432: Redesign the interpreter startup sequence
Nick Coghlan added the comment: It's still deferred for the time being. Based on what I learned on my previous attempt at implementing it, there's some prep work I need to do where I believe reviewing someone else's attempt at doing it would actually be *more* work than doing the work myself (this is a truly arcane area of the current implementation - *I* find it hard to follow, and I've been hacking on it for years. PEP 432 was actually inspired by the sheer amount of work that was involved in getting the new pure Python import system integrated properly for Python 3.3). That prep work is refactoring the mammoth pythonrun.c file to split out a separate lifecycle.c file that just has the startup and shutdown code, leaving pythonrun.c as a pure runtime module. Anything that remains in pythonrun.c should be able to assume a fully functional Python interpreter is available, while the code in lifecycle.c will need to be able to cope with the fact that the interpreter may only be partially functional (whether that's due to it being setup or destroyed). The reason this matters is that it lets me bring the C linker to bear on the problem of enforcing state encapsulation. This proved absolutely essential in my initial PEP 432 implementation attempt, but doing the restructure in the fork resulted in an unacceptably high number of merge conflicts. Doing the restructure *first* should make it far more feasible to maintain the feature branch, and make it practical to restart work on the PEP itself. Once we get to that point, then it should actually be possible to have a proper collaborative branch in my CPython sandbox repo on BitBucket, and keep it in sync with CPython trunk relatively easily. First step is getting the restructure patch together, though. I actually *have* started work on that, but it isn't in a sensible enough state to be worth sharing at this point. Once it is, I'll open a separate tracker issue specifically for that, and make this one depend on it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22257 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22309] distutils/spawn.py handle fork() not implemented.
John Malmberg added the comment: There are multiple degrees of Posix compliance. While X/Open documents the Posix requirements for implementing fork(), so far I have not found anything that requires that fork() be present. Configure tests for c-python also test for the presence of fork(). OpenVMS complies with many Posix standards, but does not implement fork(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22309 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22257] PEP 432: Redesign the interpreter startup sequence
Nick Coghlan added the comment: As far as the specific 5 phase vs 2 steps goes, the two steps in PEP 432 terms are the Pre-Initialized - Initializing transition and the Initializing - Initialized transition. What Gregory is talking about is a potentially good way to organise the second step - systemd in Linux is similarly organised around the idea of a directed acyclic graph of dependencies. For the initial implementation, we're unlikely to go that far though - we'll likely keep the existing initialisation code, and just rearrange the high level invocations. The other phases in PEP 432 are due to the fact that run __main__ is a separate step, distinct from interpreter initialisation. When you embed Python as the scripting engine in a larger application, the idea of having a __main__ module may not actually make any sense. In those cases, it will still be there (as the interpreter creates it automatically), it will just be empty. But for the CPython CLI, we need that extra run main step. (There's a strong case to be made for that being in a separate PEP, and I may still do that - this discussion is certainly pushing me in that direction) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22257 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22305] Documentation on deepcopy's problems is misleading
Shailesh Hegde added the comment: Thanks. Because deep copy copies everything it may copy too much, e.g., administrative data structures that need to be shared even between copies, which may not be the desired goal. helps me understand better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
