[issue43847] realpath of bytestr smb drive letters fail
New submission from ed : some win7sp1 and win10:20H2 boxes cannot realpath a networked drive letter such as b"n:" (also affects b"n:\\") * observed with 3.8.7 and 3.9.1 * 3.7.9 is fine requirements to trigger: * bytestring (not unicode str) * just the drive letter (subfolders are ok) * networked drive (regular disks and vmhgfs are ok) * enterprise/AD network? (doesn't seem to happen with samba) hits the following exceptions in succession: * access denied at L601: "path = _getfinalpathname(path)" * "cant concat str to bytes" at L621: "return path + tail" -- components: Windows messages: 391074 nosy: 9001, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: realpath of bytestr smb drive letters fail type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1273] email module example email-unpack.py error
New submission from Ed Vinyard: In the email module example, email-unpack.py (http://docs.python.org/lib/email-unpack.txt), line 56 throws an AttributeError. It is currently ext = mimetypes.guess_extension(part.get_type()) I think this line should be ext = mimetypes.guess_extension(part.get_content_type()) The Message documentation (http://docs.python.org/lib/module-email.message.html) mentions that "Changed in version 2.5: The previously deprecated methods get_type(), get_main_type(), and get_subtype() were removed." -- components: Documentation messages: 56376 nosy: esv severity: minor status: open title: email module example email-unpack.py error type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1273> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)
Changes by Ed Summers <[EMAIL PROTECTED]>: -- nosy: +edsu ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1544339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45336] Issue with xml.tree.ElementTree.write
New submission from ed wolf : When executing the following command after modifiy an xml file an error is prodcued. import xml.etree.ElementTree as ET rtexmlFile = 'Fox_CM3550A_SWP1_Rte_ecuc.arxml' rte_ecu_tree = ET.parse(rtexmlFile) root = rte_ecu_tree.getroot() rte_ecu_tree.write(rtexmlFile, encoding="UTF-8", xml_declaration="True", default_namespace="None" method="xml",short_empty_elements="True" ) ValueError: cannot use non-qualified names with default_namespace option The documentation for the ElementTree.write function indicates the following format for this command but this format does not seem to wrok The write command does not also take into account when having standalone in the xml defintion. For ex, ElementTree.write will not add standalone back to the xml file Is this a bug in version 3.7? write(file, encoding="us-ascii", xml_declaration=None, default_namespace=None, method="xml", *, short_empty_elements=True) Writes the element tree to a file, as XML. file is a file name, or a file object opened for writing. encoding 1 is the output encoding (default is US-ASCII). xml_declaration controls if an XML declaration should be added to the file. Use False for never, True for always, None for only if not US-ASCII or UTF-8 or Unicode (default is None). default_namespace sets the default XML namespace (for “xmlns”). method is either "xml", "html" or "text" (default is "xml"). The keyword-only short_empty_elements parameter controls the formatting of elements that contain no content. If True (the default), they are emitted as a single self-closed tag, otherwise they are emitted as a pair of start/end tags. The output is either a string (str) or binary (bytes). This is controlled by the encoding argument. If encoding is "unicode", the output is a string; otherwise, it’s binary. Note that this may conflict with the type of file if it’s an open file object; make sure you do not try to write a string to a binary stream and vice versa. -- assignee: docs@python components: Documentation messages: 402981 nosy: docs@python, twowolfs priority: normal severity: normal status: open title: Issue with xml.tree.ElementTree.write type: performance versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue45336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45336] Issue with xml.tree.ElementTree.write
ed wolf added the comment: Hi Andrew I removed the quotes and still see an issue with the standalone not being added to the xml declaration. I set the command as follows rte_ecu_tree.write(rtexmlFile, encoding="UTF-8", xml_declaration=True, default_namespace=None, method="xml",short_empty_elements=True ) The xml declaration came out as but should be standalone did not get added to the declaration. -- ___ Python tracker <https://bugs.python.org/issue45336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45336] xml.tree.ElementTree.write does not support `standalone` option
ed wolf added the comment: Will ElementTree.write be updated to correct this issue? -- ___ Python tracker <https://bugs.python.org/issue45336> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42342] asyncio.open_connection(local_addr=('localhost', port)) fails with TypeError: AF_INET address must be a pair (host, port)
New submission from Ed Catmur :
Context: CentOS 7.8.2003, Python 3.8 from SCL. localhost has IPv4 and IPv6
bindings, IPv6 first:
$ python -c "import
socket;print(socket.getaddrinfo('localhost',0,type=socket.SOCK_STREAM))"
[(, , 6, '', ('::1', 0,
0, 0)), (, , 6, '',
('127.0.0.1', 0))]
import asyncio
async def main():
await asyncio.open_connection('localhost', 9990, local_addr=('localhost',
9991))
asyncio.run(main())
Traceback (most recent call last):
File "async.py", line 4, in
asyncio.run(main())
File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/runners.py", line
43, in run
return loop.run_until_complete(main)
File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/base_events.py",
line 608, in run_until_complete
return future.result()
File "async.py", line 3, in main
await asyncio.open_connection('10.10.10.10', 9990, local_addr=('localhost',
9991))
File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/streams.py", line
52, in open_connection
transport, _ = await loop.create_connection(
File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/base_events.py",
line 1002, in create_connection
sock = await self._connect_sock(
File "/opt/rh/rh-python38/root/usr/lib64/python3.8/asyncio/base_events.py",
line 904, in _connect_sock
sock.bind(laddr)
TypeError: AF_INET address must be a pair (host, port)
It looks like this has a similar root cause to issue 35302 - we should be
filtering local addrinfos by family for valid combinations.
--
components: asyncio
messages: 380874
nosy: asvetlov, ecatmur2, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.open_connection(local_addr=('localhost', port)) fails with
TypeError: AF_INET address must be a pair (host, port)
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue42342>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42378] logging reopens file with same mode, possibly truncating
New submission from Ed Catmur :
If a logging.FileHandler is configured with mode='w', or if logging.basicConfig
is called with filemode='w' (as suggested by the Basic Logging Tutorial
https://docs.python.org/3/howto/logging.html#logging-basic-tutorial)
and if some code logs during shutdown, after logging has closed its handlers
(asyncio is prone to do this, e.g.),
then logging.FileHandler._open will reopen the log file with the same mode as
it was originally opened with, potentially truncating it and losing valuable
information:
import atexit
atexit.register(lambda: logging.info("so long"))
import logging
logging.basicConfig(filename='test.log', filemode='w', level=logging.INFO)
logging.info("super important stuff")
$ python truncate.py
$ cat test.log
INFO:root:so long
I have a hunch that the fix to issue 26789 will potentially make things worse,
as previously at least there was a chance that logging had been fully unloaded
so that the call to open would fail.
https://stackoverflow.com/questions/39838616/why-is-python-logging-framework-losing-messages
--
components: Library (Lib)
messages: 381146
nosy: ecatmur2
priority: normal
severity: normal
status: open
title: logging reopens file with same mode, possibly truncating
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue42378>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27640] add the '--disable-test-suite' option to configure
Changes by Ed Morley : -- nosy: +edmorley ___ Python tracker <http://bugs.python.org/issue27640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30104] Float rounding errors on AMD64 FreeBSD CURRENT Debug 3.x buildbot
Changes by Ed Maste : -- nosy: +emaste ___ Python tracker <http://bugs.python.org/issue30104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33252] Clarify ResourceWarning documentation
New submission from Ed Morley : The `ResourceWarning` warning has always been ignored by default, since it was added in Python 3.2 in: https://github.com/python/cpython/commit/08be72d0aa0112118b79d271479598c218adfd23#diff-db4e2b9efea108a38c53e06fa99cdd77R391 However there are several places in the docs where the "ignored by default" aspect is not mentioned even though it is for `DeprecationWarning` and similar - which caused me quite a bit of confusion today. The docs were partly improved in Python 3.7 onwards by: https://github.com/python/cpython/commit/9b99747386b690007027c3be2a5d7cfe3d3634f5 ...however: (a) there is still at least one place that still needs updating on master (https://docs.python.org/3.8/library/warnings.html#warning-categories) (b) it would be good to backport the docs fixes to 3.4/3.5/3.6 (I was looking at the 3.6 docs today) I'm happy to open PRs to fix this; but filing this issue so I have something to reference. -- assignee: docs@python components: Documentation messages: 315153 nosy: docs@python, edmorley priority: normal severity: normal status: open title: Clarify ResourceWarning documentation type: enhancement versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available
Ed Schouten added the comment: Having looked at various implementations of crypt() and crypt_r(), I can't think of a reason why there would be any significant difference in performance. On systems like FreeBSD, crypt() is just a simple wrapper around crypt_r(): https://svnweb.freebsd.org/base/head/lib/libcrypt/crypt.c?view=markup#l134 If there would be any difference in performance, it would also be astronomically small compared to the computation time spent by the cryptographic hash functions themselves. -- ___ Python tracker <https://bugs.python.org/issue28503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available
Ed Schouten added the comment: Ah, you folks switched to Git + Github in the mean time. Nice! I've just sent this pull request: https://github.com/python/cpython/pull/4691 -- ___ Python tracker <https://bugs.python.org/issue28503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS)
Changes by Ed Maste : -- nosy: +Ed.Maste ___ Python tracker <http://bugs.python.org/issue15745> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16000] test_curses should use unittest
Ed Campbell added the comment: I think this is a real improvement. Thanks. I have a few comments: I suspect you know this, but the rendering problem occurs because of the call to curses.endwin() in tearDown(). I experimented with delaying this until teadDownClass() but this led to even more undesirable side effects with the tests running in parallel. Your print() call seems like a simple workaround. There is only a single test case so I don't see the advantage of using a setUpModule function over setUpClass. Is there one? I'd put the code in setUpClass (or possibly put the curses.setupterm() call in setUp and have neither setUpModule or setUpClass). If and when further test cases are added I'd consider factoring out common code into a setUpModule. I'd also consider putting the skip test if not sys.__stdout__.isatty() that's in your current setUpModule as a decorator with the other @unittest.skipIf class decorators. Is there a reason you singled this one out to go in setUpModule? You have a typo on line 30: 'unkwown' should be 'unknown' -- ___ Python tracker <http://bugs.python.org/issue16000> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue11445> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work
New submission from Ed Wodrich : Greetings, I am a brand new user attempting to learn Python. I downloaded and installed the .msi installer version 3.2.3 on May 5, 2012. I am running Windows XP SP2 32-bit on a Pentium 4. I opted to load all features of the program. Installation finished without any errors. Admittedly, despite previous programming experience with other languages, I have a lot to learn. What I saw when I tried using the IDLE was that it would not end with ctrl-Z followed by carriage return. Using either quit() and replying to the dialog or using ctrl-d followed by carriage return worked. I am submitting this because the GUI interface and what documentation I have seen so far states that ctrl-z followed by carriage return is the method to use in Windows. IMHO possible fix options (presuming this is not something weird because I don't know what I am doing yet) would be to update the documentation for consistency or to change the behavior of the IDLE? Thank you, in advance, for your efforts with regard to this issue. Best Regards, Ed -- components: IDLE messages: 160042 nosy: ewodrich priority: normal severity: normal status: open title: Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue14735> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14735] Version 3.2.3 IDLE CTRL-Z plus Carriage Return to end does not work
Changes by Ed Wodrich : -- nosy: -ewodrich ___ Python tracker <http://bugs.python.org/issue14735> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16000] test_curses should use unittest
Ed Campbell added the comment: I'd suggest using unittest.TestCase.assertRaises() as a context manager to remove some try-excepts. For example I think function test_userptr_without_set() on line 245 could use: with self.assertRaises(curses.panel.error): p.userptr() I could create a patch if it would help. -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue16000> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe
New submission from Ed Morley: A python.org 2.7.6 release of the Windows MSI installer, results in only the following python binaries in the installation directory: C:\Python27\python.exe C:\Python27\pythonw.exe In Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=957721 we would like to be able to force our 'mach' script to use Python2.7 (due to the assorted Python versions present on our CI machines), however doing so via the script shebang line breaks local developer workflows on Windows, since the default Python install doesn't include python2.7.exe and so the binary isn't found. As such, it would be great if python.exe could be symlinked to pythonX.Y.exe (and also I guess pythonX.exe) as part of the Windows installation/build - giving us parity with Unix based platforms. This can be done on Windows using mklink (http://ss64.com/nt/mklink.html), eg: c:\Python27>mklink python2.7.exe python.exe symbolic link created for python2.7.exe <<===>> python.exe c:\Python27>mklink python2.exe python.exe symbolic link created for python2.exe <<===>> python.exe c:\Python27>dir python* 10/11/2013 19:2426,624 python.exe 14/05/2014 12:04 python2.exe [python.exe] 14/05/2014 12:04 python2.7.exe [python.exe] 10/11/2013 19:2427,136 pythonw.exe Alternatively, just a plain copy of the binary prior to creating the MSI would be just as helpful for us too. I searched for a while to see if there were any bugs filed for this already, but the closest I could find was: * http://legacy.python.org/dev/peps/pep-0397/ - which is about a smart launcher that uses the shebang lines to run the correct Python version when multiple are installed (and thus is quite a different request to that in this bug). * and https://mail.python.org/pipermail/python-dev/2011-March/108850.html which suggests the idea as in this bug summary here, but it seems like a bug for it was never filed. Many thanks :-) -- components: Build, Installation, Windows messages: 218521 nosy: edmorley, loewis priority: normal severity: normal status: open title: Windows MSI installer should mklink (symlink) python.exe to python2.7.exe type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21506] Windows MSI installer should mklink (symlink) python.exe to python2.7.exe
Ed Morley added the comment: Meant to add: the ActivePython release does this already - but it would be great if upstream did too. -- ___ Python tracker <http://bugs.python.org/issue21506> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16773] int() half-accepts UserString
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue16773> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue15663> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16848] Mac OS X: python-config --ldflags and location of Python.framework
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue16848> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10544] yield expression inside generator expression does nothing
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue10544> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17128] OS X system openssl deprecated - installer should build local libssl
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue17128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22447] logging.config.fileConfig attempts to write to file even when none configured
New submission from Ed Sesek: See the attached config file. logging.config.fileConfig() is attempting to write to the file specified in the file_handler section even though that handler is not configured for use in this config. If its going to write to the file, it should only do so if the file is configured to be used. In the case where it cannot write to the file it throws an exception with a blank message. -- components: Library (Lib) files: pixcli_template.ini messages: 227122 nosy: esesek priority: normal severity: normal status: open title: logging.config.fileConfig attempts to write to file even when none configured type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file36664/pixcli_template.ini ___ Python tracker <http://bugs.python.org/issue22447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7365] grp and pwd should treat uid and gid as unsigned
New submission from Ed Plese :
Both Linux and Solaris define uid_t and gid_t as unsigned integers. The
pwd and grp modules cast these to signed long values that are then
converted with PyInt_FromLong. For large values, greater than 2 ** 32 -
1, the result is correct when Python is compiled as a 64-bit executable,
but is incorrect when compiled as a 32-bit executable.
Similar bugs have been noted in the posix module as reported in #4591.
For example, on OpenSolaris build 127, the 32-bit version of Python
returns a negative uid: pw_uid=-2147483647:
$ file /usr/bin/python2.6
/usr/bin/python2.6: ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped, no debugging information available
$ /usr/bin/python2.6
Python 2.6.2 (r262, Oct 26 2009, 01:06:14) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('t...@foo.com')
pwd.struct_passwd(pw_name='t...@foo.com', pw_passwd='x',
pw_uid=-2147483647, pw_gid=1, pw_gecos='Test User', pw_dir='',
pw_shell='')
$ file /usr/bin/amd64/python2.6
/usr/bin/amd64/python2.6: ELF 64-bit LSB executable AMD64 Version
1 [SSE FXSR FPU], dynamically linked, not stripped, no debugging
information available
$ /usr/bin/amd64/python2.6
Python 2.6.2 (r262, Oct 26 2009, 01:09:04) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import pwd
>>> pwd.getpwnam('t...@foo.com')
pwd.struct_passwd(pw_name='t...@foo.com', pw_passwd='x',
pw_uid=2147483649, pw_gid=1, pw_gecos='Test User', pw_dir='',
pw_shell='')
The attached patch against 2.6.4 changes PyInt_FromLong to
PyLong_FromUnsignedLong and changes casts to unsigned long.
--
components: Extension Modules
files: pwd-grp-unsigned-uid.patch
keywords: patch
messages: 95520
nosy: eplese
severity: normal
status: open
title: grp and pwd should treat uid and gid as unsigned
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file15367/pwd-grp-unsigned-uid.patch
___
Python tracker
<http://bugs.python.org/issue7365>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: Looks good to me! -- ___ Python tracker <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27652] [Patch] Make use of non-standard error number ESHUTDOWN optional
New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we noticed that the core Python code maps ESHUTDOWN over to BrokenPipeError. This is fine, except for the fact that ESHUTDOWN is used unconditionally. It's not part of POSIX. Attached is a patch to make its use optional. -- components: Interpreter Core files: patch-no-eshutdown messages: 271678 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make use of non-standard error number ESHUTDOWN optional versions: Python 3.6 Added file: http://bugs.python.org/file43948/patch-no-eshutdown ___ Python tracker <http://bugs.python.org/issue27652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27653] [Patch] Also disable the use of on CloudABI
New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed environment, there currently isn't any support for modifying low-level network properties, such as TCP socket attributes. For this reason is missing, just like on a couple of other platforms (Symbian, Cygwin, etc). The attached patch extends the current '#ifndef' to also take CloudABI into consideration. -- components: Extension Modules files: patch-no-netinet-tcp_h messages: 271679 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Also disable the use of on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43949/patch-no-netinet-tcp_h ___ Python tracker <http://bugs.python.org/issue27653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27654] [Patch] Use arc4random_buf() on CloudABI
New submission from Ed Schouten: While porting Python over to CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we stumbled upon a small issue that caused the build to fail. As CloudABI is a sandboxed runtime environment, there is no support for accessing the global filesystem namespace. This means that dev_urandom_noraise()/dev_urandom_python() are not capable of accessing /dev/urandom. The attached change extends these functions to use CloudABI's arc4random_buf() function, which is also present on a lot of other operating systems (the BSDs, Mac OS X, etc). I'm not enabling the use of arc4random_buf() on those operating systems yet, as that should likely be decided by the people responsible for those ports. Alternatively, if we do think arc4random_buf() should be used on all operating systems that support it, we can extend Autoconf to test for its presence. Be sure to let me know and I'll update the patch accordingly. -- components: Interpreter Core files: patch-arc4random messages: 271680 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Use arc4random_buf() on CloudABI versions: Python 3.6 Added file: http://bugs.python.org/file43950/patch-arc4random ___ Python tracker <http://bugs.python.org/issue27654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27652] Make use of non-standard error number ESHUTDOWN optional
Ed Schouten added the comment: I've filed the contributor form earlier today, but I suspect it still takes some time to get processed. The reason why the Mercurial headers were missing from the patch was because I generated this patch from the Python 3.6.0a3 source tarball. I'll make sure to switch over to the Mercurial sources from now on. Thanks for the quick response! -- ___ Python tracker <http://bugs.python.org/issue27652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27655] [Patch] Don't require presence of POLLPRI
New submission from Ed Schouten: RFC 6093 states that applications "SHOULD NOT" make use of TCP's out-of-band data. For this reason, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide support for it. This means that its poll() function does provide support for POLLIN and POLLOUT, but not for POLLPRI. Attached is a patch that patches up the selectmodule to not define POLLPRI in case the host environment does not support it. -- components: Extension Modules files: pollpri.diff keywords: patch messages: 271689 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Don't require presence of POLLPRI versions: Python 3.6 Added file: http://bugs.python.org/file43951/pollpri.diff ___ Python tracker <http://bugs.python.org/issue27655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27656] [Patch] Make presence of SCHED_* optional
New submission from Ed Schouten: The SCHED_* constants that are part of POSIX's are all optional: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html Python already declares the SCHED_SPORADIC constant as part of the POSIX module optionally, depending on whether it is present in C, but doesn't do this for the other SCHED_* constants. This is problematic for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which doesn't support any scheduler interaction at all. Attached is a patch to only define these if present. -- components: Extension Modules files: sched.diff keywords: patch messages: 271697 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make presence of SCHED_* optional versions: Python 3.6 Added file: http://bugs.python.org/file43952/sched.diff ___ Python tracker <http://bugs.python.org/issue27656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27655] [Patch] Don't require presence of POLLPRI
Ed Schouten added the comment: That's a very good question. One of the goals of CloudABI's C library is to leave out definitions for things that are known not to work in the environment. For example, our doesn't contain open(), as with our security model (Capsicum), there is nothing meaningful that this function could do anyway. Though this may seem annoying, this actually saves us a lot of time by allowing us to very easily detect software that will break. The same reasoning applies to POLLPRI here. We could in theory implement it as an event that simply never triggers, but then it would be nothing more than a convoluted way of letting your program get stuck indefinitely. Also worth taking into account here: I understand why the selectmodule provides support for POLLPRI. It simply wants to expose the entire poll() interface into Python code, but I'd argue that we'd have to look at the bigger picture. Support for out-of-band data in Python is incomplete anyway. The socket module also doesn't provide a binding for sockatmark(). -- ___ Python tracker <http://bugs.python.org/issue27655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27655] [Patch] Don't require presence of POLLPRI
Ed Schouten added the comment: Believe it our not, dealing with the absence of those system calls is more contained than you'd think. What is pretty nice about Python is that (almost) all of the file system operations are performed through posixmodule.c. Most of the changes in that area are thus made to that source file (and configure.ac). Furthermore, it looks like posixmodule.c can be simplified a lot. What makes it so incredibly complex right now is that it wants to fall back to non-at() operations in case no directory file descriptor is provided, which is not needed. If that would get fixed, we'd kill two birds with one stone: the code would get a lot simpler, while almost automatically gaining support for CloudABI. But let's save this discussion for a separate thread. -- ___ Python tracker <http://bugs.python.org/issue27655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
New submission from Ed Schouten: CloudABI is a sandboxed UNIX-like environment (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). As it implements a security framework similar to FreeBSD's Capsicum, file system access is only permitted by using POSIX-2008-style directory file descriptors. To explain it simply, the API is as follows: - Take POSIX 2008 - Remove all the non-*at() functions - Remove AT_FDCWD It would be nice if Python could support CloudABI out of the box, but in my opinion this should be done in a way that's as unintrusive as possible. We shouldn't make a mess out of Python, just to support CloudABI. I've been looking at Python's posixmodule and I think there's some low-hanging fruit. We can make changes that significantly reduce the size of our patchset for CloudABI, while also making the existing code easier to understand: - When support for *at() functions was added, they didn't replace the calls to the non-*at() functions. The non-*at() functions are still invoked when dir_fd == AT_FDCWD. This can be changed to invoke the *at() functions unconditionally. The advantage of this approach is that AT_FDCWD then only needs to be used in dir_fd_converter() and a small number of other places. It also means that the code builds on systems that don't prove the non-*at() functions. - The *_DIR_FD_CONVERTER macros aren't used in a small number of places, requiring us to do additional checks against AT_FDCWD in os_*_impl(). In os.link(), os.rename() and os.replace(), we call into dir_fd_converter() unconditionally, only to let the respective implementation functions perform additional checks. If dir_fd_unavailable() would be used instead, the implementations would be cleaner. The attached patch does this refactoring, also making some minor cleanups along the way. -- components: Extension Modules files: posixmodule-refactoring.diff keywords: patch messages: 272114 nosy: EdSchouten priority: normal severity: normal status: open title: [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present versions: Python 3.6 Added file: http://bugs.python.org/file44033/posixmodule-refactoring.diff ___ Python tracker <http://bugs.python.org/issue27701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27702] [Patch] Only use SOCK_RAW when defined
New submission from Ed Schouten: POSIX only requires socket types SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET to be present. SOCK_RAW is optional, as it is placed between [RS] tags in the specification: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html It looks like Python's socketmodule.c does try to use it unconditionally. Comply to POSIX by only exposing it optionally, just like we do for some of the other socket types (SOCK_RDM, etc). -- components: Extension Modules files: sock_raw.diff keywords: patch messages: 272117 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Only use SOCK_RAW when defined versions: Python 3.6 Added file: http://bugs.python.org/file44034/sock_raw.diff ___ Python tracker <http://bugs.python.org/issue27702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27764] [Patch] Complete bits necessary for making fcntl's file locking optional
New submission from Ed Schouten: Python's fcntl module already provides some support for making support for file locking optional. For example, constants like F_SETFL are only defined if present. Unfortunately, the accompanying functions 'flock()' and 'lockf()' are present unconditionally. CloudABI, a sandboxed runtime environment for UNIX (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), doesn't implement these ways of doing file locking, for the reason that these operations do not fit nicely within its process model. These locks are per-process; not per-descriptor. This means that processes cannot safely be composed or decomposed. Attached is a relatively small patch to make flock() and lockf() optional, only compiling them when the necessary APIs are present. The LOCK_* constants are now also defined optionally. -- components: Extension Modules files: patch-no-flock.txt messages: 272692 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Complete bits necessary for making fcntl's file locking optional versions: Python 3.6 Added file: http://bugs.python.org/file44105/patch-no-flock.txt ___ Python tracker <http://bugs.python.org/issue27764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15730] Silence unused value warnings under Mac OS X 10.8/clang
Changes by Ed Campbell : -- nosy: +esc24 ___ Python tracker <http://bugs.python.org/issue15730> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX)
Changes by Ed Maste : -- nosy: +Ed.Maste ___ Python tracker <http://bugs.python.org/issue23458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX)
Ed Maste added the comment: For reference, this fd leak was causing one of LLDB's tests to fail. It is now marked XFAIL pending a resolution of this issue: http://llvm.org/viewvc/llvm-project?view=revision&revision=229704 Linux is also affected, the Linux LLDB tests were previously running on an earlier Python version which did not demonstrate this problem. -- ___ Python tracker <http://bugs.python.org/issue23458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24388] Python readline module crashes in history_get on FreeBSD with libedit
New submission from Ed Maste: I encountered a segfault in Python's call_readline from LLDB on FreeBSD, with libedit. There is a fix for this issue already in readline.c, but under #ifdef __APPLE__ Backtrace: (lldb) target create "/data/emaste/src/llvm/build/bin/lldb" --core "lldb-3.7.0.core" Core file '/tank/emaste/projects/lldb-talk/demo/lldb-3.7.0.core' (x86_64) was loaded. (lldb) bt * thread #1: tid = 0, 0x000809706dcd readline.so`call_readline(sys_stdin=0x0008055d9d10, sys_stdout=0x0008055d9e40, prompt=0x000806eb7854) + 397 at readline.c:1132, name = 'lldb-3.7.0', stop reason = signal SIGSEGV * frame #0: 0x000809706dcd readline.so`call_readline(sys_stdin=0x0008055d9d10, sys_stdout=0x0008055d9e40, prompt=0x000806eb7854) + 397 at readline.c:1132 frame #1: 0x000805c48f1f libpython2.7.so.1`PyOS_Readline(sys_stdin=0x0008055d9d10, sys_stdout=0x0008055d9e40, prompt=0x000806eb7854) + 383 at myreadline.c:207 frame #2: 0x000805d7f94f libpython2.7.so.1`builtin_raw_input(self=0x, args=0x00080bec1df0) + 639 at bltinmodule.c:2060 frame #3: 0x000805cce5c6 libpython2.7.so.1`PyCFunction_Call(func=0x0008007b78d0, arg=0x00080bec1df0, kw=0x) + 166 at methodobject.c:81 frame #4: 0x000805d992aa libpython2.7.so.1`call_function(pp_stack=0x7fffbcd0, oparg=1) + 1754 at ceval.c:4033 frame #5: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x000806ecfdf0, throwflag=0) + 51160 at ceval.c:2679 frame #6: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x000805a6af60, globals=0x000806f9a580, locals=0x, args=0x00080a06c670, argcount=2, kws=0x00080a06c680, kwcount=0, defs=0x000805aaeda8, defcount=1, closure=0x) + 5284 at ceval.c:3265 frame #7: 0x000805d9c2b6 libpython2.7.so.1`fast_function(func=0x000806f7da38, pp_stack=0x7fffc520, n=2, na=2, nk=0) + 822 at ceval.c:4129 frame #8: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffc520, oparg=1) + 2296 at ceval.c:4054 frame #9: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080a06c4b0, throwflag=0) + 51160 at ceval.c:2679 frame #10: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x000805a5ebf0, globals=0x000806f9a580, locals=0x, args=0x00080a06c3e0, argcount=2, kws=0x00080a06c3f0, kwcount=0, defs=0x000805aaecc8, defcount=1, closure=0x) + 5284 at ceval.c:3265 frame #11: 0x000805d9c2b6 libpython2.7.so.1`fast_function(func=0x000806f7d8e8, pp_stack=0x7fffcd70, n=2, na=2, nk=0) + 822 at ceval.c:4129 frame #12: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffcd70, oparg=1) + 2296 at ceval.c:4054 frame #13: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080a06c230, throwflag=0) + 51160 at ceval.c:2679 frame #14: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x000805a869e0, globals=0x000806f9a580, locals=0x, args=0x00080a06b9f8, argcount=0, kws=0x00080a06b9f8, kwcount=2, defs=0x0008009af688, defcount=3, closure=0x) + 5284 at ceval.c:3265 frame #15: 0x000805d9c2b6 libpython2.7.so.1`fast_function(func=0x000806f7d300, pp_stack=0x7fffd5c0, n=4, na=0, nk=2) + 822 at ceval.c:4129 frame #16: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffd5c0, oparg=512) + 2296 at ceval.c:4054 frame #17: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080a06b830, throwflag=0) + 51160 at ceval.c:2679 frame #18: 0x000805d9c16a libpython2.7.so.1`fast_function(func=0x000806f9d300, pp_stack=0x7fffdbd0, n=1, na=1, nk=0) + 490 at ceval.c:4119 frame #19: 0x000805d994c8 libpython2.7.so.1`call_function(pp_stack=0x7fffdbd0, oparg=1) + 2296 at ceval.c:4054 frame #20: 0x000805d93538 libpython2.7.so.1`PyEval_EvalFrameEx(f=0x00080098c9c0, throwflag=0) + 51160 at ceval.c:2679 frame #21: 0x000805d86c54 libpython2.7.so.1`PyEval_EvalCodeEx(co=0x0008008ffa90, globals=0x0008007d8580, locals=0x0008007d8580, args=0x, argcount=0, kws=0x, kwcount=0, defs=0x, defcount=0, closure=0x) + 5284 at ceval.c:3265 frame #22: 0x000805d857a5 libpython2.7.so.1`PyEval_EvalCode(co=0x0008008ffa90, globals=0x0008007d8580, locals=0x0008007d8580) + 85 at ceval.c:667 frame #23: 0x000805dd4a15 libpython2.7.so.1`run_mod(mod=0x00080a14f128, filename=0x000805e22022, globals=0x0008007d8580, locals=0x0008007d8580, flags=0x, arena=0x00080a027800) + 101 at pythonrun.c:1371 frame #24: 0x000805dd
[issue24388] Python readline module crashes in history_get on FreeBSD with libedit
Ed Maste added the comment: Presumably the #ifdefs ought to just be deleted though, relying on the runtime detection of libedit compatibility issues on any platform. -- ___ Python tracker <http://bugs.python.org/issue24388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: This issue causes the LLDB debugger to crash on FreeBSD (it uses Python as its embedded script interpreter). What needs to be done to make some progress on this issue? -- ___ Python tracker <http://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: Note that the patch in Issue24388 is more a proof of concept. I'm not sure it's the "right" fix. LLDB is a bit of a special case: LLDB links against libedit, but the Python libedit module is built as if readline is in use. It turns out this "magically" works out, presumably due to the runtime workaround detection. As far as I know this issue would affect Linux as well, but perhaps the version of libedit on common Linux distributions is one with the 0-based vs 1-based history fix? -- ___ Python tracker <http://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: It looks like rust developers hit the issue in Issue24388 with lldb on Ubuntu 15.04 as well: https://github.com/rust-lang/rust/issues/26297 -- ___ Python tracker <http://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: Actually, in msg245395 I should claim the issue is with libedit / GNU readline compatibility and/or the workarounds in Python's readline module, not that it's specifically Issue24388. -- ___ Python tracker <http://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Ed Maste added the comment: I believe the 0-based vs 1-based history is only one of a few different inconsistencies between libedit and readline. Workarounds will be necessary until a fixed libedit is deployed on all operating systems / distros of interest, but yes I agree that eventually they should not be needed. -- ___ Python tracker <http://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24520] Stop using deprecated floating-point environment functions on FreeBSD
Changes by Ed Maste : -- nosy: +emaste ___ Python tracker <http://bugs.python.org/issue24520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
New submission from Ed Schouten: While trying to port Python over to a new platform (CloudABI), I noticed a couple of compiler errors in PyThread_create_key(), PyThread_delete_key(), PyThread_delete_key_value() and PyThread_set_key_value() caused by fact that pthread_key_t is converted to an integer (and vice versa) POSIX doesn't seem to require that pthread_key_t is an integer or any other arithmetic type: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html Old revisions of the standard did require pthread_t to be an arithmetic type, but this requirement was dropped later on. In my opinion we should strongly consider changing the API, so that we can treat the key created by pthread_key_create() or returned by TlsAlloc() as an opaque type. -- components: Interpreter Core messages: 254846 nosy: EdSchouten priority: normal severity: normal status: open title: PyThread assumes pthread_key_t is an integer, which is against POSIX versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26507] Use highest pickle protocol in multiprocessing
New submission from Ed Behn: Currently, the default pickle protocol is used to return worker results in a multiprocessing pool. The highest protocol should be used because backwards compatibility is not an issue. -- components: Extension Modules files: patch messages: 261318 nosy: ebehn priority: normal severity: normal status: open title: Use highest pickle protocol in multiprocessing type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42086/patch ___ Python tracker <http://bugs.python.org/issue26507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26507] Use highest pickle protocol in multiprocessing
Changes by Ed Behn : Added file: http://bugs.python.org/file42087/patch ___ Python tracker <http://bugs.python.org/issue26507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27045] Forward slashes in Windows paths
New submission from Ed Doxtator: In the documentation for pyvenv (https://docs.python.org/dev/library/venv.html), there is a table that shows by platform the command required to activate a virtual environment by OS. For Windows, the values are: PlatformShell Command to activate virtual environment --- Windows cmd.exe C:> /Scripts/activate.bat PowerShell PS C:> /Scripts/Activate.ps1 The commands are incorrect-- they contain forward slashes and should be back slashes. -- assignee: docs@python components: Documentation messages: 265744 nosy: doc, docs@python priority: normal severity: normal status: open title: Forward slashes in Windows paths type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27045> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: I think that PEP 11 also doesn't rule out changes in this area. For example, consider the paragraph starting with the sentence "This policy does not disqualify supporting other platforms indirectly. [...]" Attached is a patch that accomplishes the same with a constant running time for operations on keys by using an array. Allocation of new keys runs in expected constant time by using a randomised allocation pattern. If we're not big fans of using randomised access, changing this to a linear scan would already be an improvement: keys are only allocated infrequently, but hopefully accessed quite often. -- Added file: http://bugs.python.org/file44303/key-constant-time.diff ___ Python tracker <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27654] [Patch] Use arc4random_buf() on CloudABI
Ed Schouten added the comment: Sure thing! Attached is an updated patch. -- Added file: http://bugs.python.org/file44434/patch-arc4random ___ Python tracker <http://bugs.python.org/issue27654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28058] [Patch] Don't use st_uid and st_gid on CloudABI
New submission from Ed Schouten: CloudABI is a UNIX-like runtime environment that uses a capability-based security model. As there is no support for traditional UNIX credentials (uid_t, gid_t), its struct stat doesn't provide st_uid and st_gid. Python can already deal with the absence of these fields, as it also needs to treat Windows similarly. Attached is a patch that simply adds CloudABI to the relevant '#if' in posixmodule.c. -- components: Extension Modules files: patch-st_uid-st_gid messages: 275591 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Don't use st_uid and st_gid on CloudABI versions: Python 3.7 Added file: http://bugs.python.org/file44525/patch-st_uid-st_gid ___ Python tracker <http://bugs.python.org/issue28058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28066] [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
New submission from Ed Schouten: For CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) we're providing packages containing a precompiled copy of Python. As we had to make some changes to importlib (namely to deal with directory file descriptors), we have to do a rebuild of importlib.h during the cross compilation process, using Programs/_freeze_importlib. We've run into a couple of issues that require us to patch up the build system to make this work: - First of all, Programs/_freeze_importlib is built using the compiler for the target. There is no way to override this. The OpenWRT folks have also run into this issue and have patched up the Makefile to add a $FREEZE_IMPORTLIB that allows you to use a different executable: https://github.com/openwrt/packages/blob/master/lang/python3/patches/013-make-freeze-import-lib-into-an-override-able-var.patch This patch is almost correct; it doesn't prevent _freeze_importlib from being built, which is needed in our case as it doesn't build cleanly on CloudABI. - Second, if an out-of-tree build is performed, we need to make sure that Python/frozen.c imports the right copy of importlib.h. We must add -IPython to the compiler flags to realise. Attached is a patch that contains the modifications that we've made to Makefile.pre.in to make cross compilation work for us. -- components: Interpreter Core files: patch-freeze-importlib messages: 275674 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h versions: Python 3.7 Added file: http://bugs.python.org/file44536/patch-freeze-importlib ___ Python tracker <http://bugs.python.org/issue28066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28066] [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
Ed Schouten added the comment: The nice thing is that in our case, the importlib changes are already compatible with the native build. So yes, we can reuse the frozen module from the native build. :-) Ah, yes. Issue 27641 already prevents that it's cross compiled. This patch was written prior to that and simply rebased. Still, one problem remains: our strategy for creating importlib.h and importlib_external.h doesn't take out-of-tree builds into account. Even if we regenerate it, frozen.c won't pick it up because its directory is not part of the compiler search path. Attached is a patch that makes us write the results of _freeze_importlib into $(srcdir)/Python/importlib*.h instead, so that even with an out-of-tree build, we actually update the header files used by frozen.c. -- Added file: http://bugs.python.org/file44545/patch-freeze-importlib ___ Python tracker <http://bugs.python.org/issue28066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28066] [Patch] Fix the ability to cross compile Python when doing a rebuild of importlib.h
Ed Schouten added the comment: It does. I can now cross build Python for CloudABI by copying importlib.h and importlib_external.h from the native build directory to the target build directory. Thanks! -- ___ Python tracker <http://bugs.python.org/issue28066> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
Ed Schouten added the comment: Hmmm... Taking a second look at my patch: I still think it's conceptually a good idea to pursue this, but I think it may be wiser to first focus on the bits that are strictly necessary from my side. The patch that I've posted previously has the disadvantage that it's hard to grasp what belongs to gether. Attached is a trimmed down version of my original patch that only focuses on patching up the os_*_impl()s to use the *at() functions exclusively if possible. Hopefully this change should be fairly easy to understand. Any thoughts? -- Added file: http://bugs.python.org/file44561/patch-issue27701 ___ Python tracker <http://bugs.python.org/issue27701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28081] [Patch] timemodule: Complete Autoconf bits for clock_*() functions: make clock_getres() and clock_settime() optional
New submission from Ed Schouten: Our Autoconf bits already test for the presence of the POSIX 2008 clock_gettime() and clock_getres() functions, which is nice. Still, I'd like to make two improvements there: 1. In timemodule.c, properly guard the use of clock_getres() bits with HAVE_CLOCK_GETRES instead of using HAVE_CLOCK_GETTIME. There don't seem to be any shared functions/structures/etc., so we can safely decouple them. 2. For consistency, also add Autoconf bits for clock_settime(). In timemodule.c, use HAVE_CLOCK_SETTIME as a guard. The reason why I'm sending in this patch is because CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does provide clock_gettime() and clock_getres(), but not clock_settime(). The reason for this is that CloudABI is meant for running unprivileged/sandboxed code. There is no need to provide an API for adjusting system-wide clocks. Do note that this patch does not contain any changes to Autoconf generated files. -- components: Extension Modules files: patch-clock_settime messages: 275827 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] timemodule: Complete Autoconf bits for clock_*() functions: make clock_getres() and clock_settime() optional Added file: http://bugs.python.org/file44563/patch-clock_settime ___ Python tracker <http://bugs.python.org/issue28081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] Also stop using localtime() in timemodule
New submission from Ed Schouten: In issue 28067, we changed _datetimemodule to stop using localtime() and gmtime(), which is nice. I actually needed such a change for CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) which does not provide the thread-unsafe variants. Only localtime_r() and gmtime_r() are provided. If we're starting to make use of these functions, let's complete this by also changing timemodule to use them. I've attached a patch. Maybe it now makes sense to move the Windows wrappers to some header file, so that they can be shared between both modules. What would be the right location for this? -- components: Extension Modules files: patch-no-gmtime-localtime messages: 276421 nosy: EdSchouten priority: normal severity: normal status: open title: Also stop using localtime() in timemodule versions: Python 3.6 Added file: http://bugs.python.org/file44660/patch-no-gmtime-localtime ___ Python tracker <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28153] [Patch] selectmodule: Make kqueue()'s event filters optional
New submission from Ed Schouten: Just like the BSDs and Mac OS X, CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) provides support for kqueue(). Its implementation, however, is far more limited. It can only be used for polling on descriptors (EVFILT_READ/EVFILT_WRITE) and waiting on timers (EVFILT_TIMER). The existing selectmodule already allows some filters to be present optionally (e.g., EVFILT_NETDEV). The attached patch extends this work by only defining the filter and corresponding filter flags when available. I've also added guards around EV_SYSFLAGS and EV_FLAG1. EV_SYSFLAGS is a flag that's typically only used by the kernel to trim off flags that are only used internally. EV_FLAG1 is an example of such a flag, which seems to be used by FreeBSD to mark incoming AIO events as validated. I would even go as far as to remove these two flags from the module entirely, but let's not take the risk. -- components: Extension Modules files: patch-kqueue-EVFILT messages: 276459 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] selectmodule: Make kqueue()'s event filters optional versions: Python 3.6 Added file: http://bugs.python.org/file44662/patch-kqueue-EVFILT ___ Python tracker <http://bugs.python.org/issue28153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Changes by Ed Schouten : -- title: Also stop using localtime() in timemodule -> [Patch] Also stop using localtime() in timemodule ___ Python tracker <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28156] [Patch] posixmodule: Make the presence of os.getpid() optional
New submission from Ed Schouten: CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not provide getpid(). Though this may sound quite silly at first, there is quite a good reason for this. One of the things that CloudABI wants to achieve is making large scale (cluster/cloud) computing easier. In such an environment there is rarely a need for having machine-local unique process identifiers. They have to be globally unique and preferably not recycled. POSIX requires that pid_t is a signed integer that must have a positive value. Most C compilers only provide full support for integers up to 64 bits in size. This means that CloudABI could only provide 63-bit process identifiers, which is far smaller than, say, a UUID. For this reason we've decided to omit getpid() altogether. Attached is a patch that makes use of the already existing HAVE_GETPID definition in pyconfig.h to disable the os.getpid() function that is part of the posixmodule. -- components: Extension Modules files: patch-no-getpid messages: 276470 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] posixmodule: Make the presence of os.getpid() optional versions: Python 3.6 Added file: http://bugs.python.org/file44664/patch-no-getpid ___ Python tracker <http://bugs.python.org/issue28156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: Hi Alexander, I'm absolutely no expert when it comes to the Python codebase, so I've got a question. If we're going to movein this to Include/pytime.h, we should likely introduce full wrappers that have a name starting with _PyTime_, right? This header seem to be part of the installation, so we should likely not declare any commonly used symbols there. -- ___ Python tracker <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: As a person who keeps a close eye on the Austin Group mailing lists (i.e., 'the POSIX working group'), my guess is that it's very unlikely that POSIX will ever add those *_s() extensions. Here's a discussion on Reddit that actually captures all of the arguments pretty well: https://www.reddit.com/r/C_Programming/comments/3ivi77/eli5_why_does_glibc_still_not_support_the/ That said, any API will do. The localtime_r() function has the disadvantage that the return value is a bit odd: can it return any other tm structure than the one provided? localtime_s() is a bit weird in that its input argument is stored after the output argument. Both functions also unnecessarily pass the time_t by reference. Maybe we can just pick a prototype that's as Pythonesque as possible that also fixes these shortcomings. Any thoughts? -- ___ Python tracker <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: Does this patch look all right to you? -- Added file: http://bugs.python.org/file44667/patch-pytime-localtime-gmtime ___ Python tracker <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28148] [Patch] Also stop using localtime() in timemodule
Ed Schouten added the comment: I've been brainwashed by https://google.github.io/styleguide/cppguide.html#Function_Parameter_Ordering over the last couple of years, which is why I thought `localtime()/localtime_r()`'s way of ordering the arguments made most sense here. ;-) -- ___ Python tracker <http://bugs.python.org/issue28148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27701] [posixmodule] [Refactoring patch] Simply call into *at() functions unconditionally when present
Ed Schouten added the comment: Attached is an updated version of the patch that applies cleanly against Python 3.6.0b2. -- Added file: http://bugs.python.org/file45181/27701.diff ___ Python tracker <http://bugs.python.org/issue27701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28501] [Patch] Make os.umask() optional
New submission from Ed Schouten: CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we got Python to work (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches for this are slowly being upstreamed. As CloudABI uses a capability-based security model as opposed to a discretionary access control system, there is no support for UNIX credentials and permissions. This means that umask() is also absent. It looks like umask() is only used by Python in its posixmodule. The attached patch adds a new Autoconf check and adds the proper #if logic around its implementation. Changes to the Autoconf/Automake files are not provided by this patch, as my versions of these tools generate files containing unnecessary changes. -- components: Extension Modules files: umask-optional.diff keywords: patch messages: 279182 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make os.umask() optional versions: Python 3.6 Added file: http://bugs.python.org/file45183/umask-optional.diff ___ Python tracker <http://bugs.python.org/issue28501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28502] [Patch] Make os.chdir() optional
New submission from Ed Schouten: CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we got Python to work (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches for this are slowly being upstreamed. CloudABI uses a capability-based security model, similar to Capsicum (https://www.cl.cam.ac.uk/research/security/capsicum/). With this model, the file system can only be accessed by using file descriptors to directories. Files inside of them can be used by using openat() (in Python: os.open(dirfd=...). This means that there is no need to provide support for process working directories. chdir() is therefore entirely absent. It looks like chdir() is only used by Python in its posixmodule. The attached patch adds a new Autoconf check and adds the proper #if logic around its implementation. Changes to the Autoconf/Automake files are not provided by this patch, as my versions of these tools generate files containing unnecessary changes. -- components: Extension Modules files: chdir-optional.diff keywords: patch messages: 279183 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Make os.chdir() optional versions: Python 3.6 Added file: http://bugs.python.org/file45184/chdir-optional.diff ___ Python tracker <http://bugs.python.org/issue28502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28503] [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available
New submission from Ed Schouten: The '_crypt' module provides a binding to the C crypt(3) function. It is used by the crypt.crypt() function. Looking at the C code, there are a couple of things we can improve: - Because crypt() only depends on primitive C types, we currently get away with calling it without it being declared. Ensure that we include , which is the POSIX header file declaring this. - The disadvantage of crypt() is that it's thread-unsafe. Systems like Linux and recent versions of FreeBSD nowadays provide crypt_r() as a replacement. This function allows you to pass in a 'crypt_data' object that will hold the resulting string for you. Extend the code to use this function when available. This patch is actually needed to make this module build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html). CloudABI's C library doesn't provide any thread-unsafe functions, meaning that crypt_r() is the only way you can crypt passwords. -- components: Extension Modules files: crypt.diff keywords: patch messages: 279186 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] '_crypt' module: fix implicit declaration of crypt(), use crypt_r() where available versions: Python 3.6 Added file: http://bugs.python.org/file45185/crypt.diff ___ Python tracker <http://bugs.python.org/issue28503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28619] [Patch] Stop using inet_ntoa() when possible.
New submission from Ed Schouten: Modern C code should use inet_ntop()/inet_pton() as opposed to inet_addr()/inet_aton()/inet_ntoa(). Though the former functions may typically act as drop-in replacements for the latter, the inet_addr()/inet_aton() functions still have the advantage over inet_pton() of allowing you to parse IPv4 addresses that don't use the dotted quad notation (e.g. '0x0a01' for 10.0.0.1). There is no difference between inet_ntop() and inet_ntoa(), as they both always print the address in dotted quad form. inet_ntop() does have the advantage of being thread-safe, as inet_ntoa() uses internal storage for the return value. In other words, we'd better not use inet_ntoa() at all. Attached is a patch for Python's socketmodule that changes the existing call to inet_ntoa() to use inet_ntop() when available. This has the advantage of fixing the build on CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html), which intentionally omits any APIs that are thread-unsafe. -- components: Extension Modules files: patch-inet_ntoa.diff keywords: patch messages: 280109 nosy: EdSchouten priority: normal severity: normal status: open title: [Patch] Stop using inet_ntoa() when possible. versions: Python 3.7 Added file: http://bugs.python.org/file45364/patch-inet_ntoa.diff ___ Python tracker <http://bugs.python.org/issue28619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: It can also be a structure or a union. -- ___ Python tracker <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25658] PyThread assumes pthread_key_t is an integer, which is against POSIX
Ed Schouten added the comment: CloudABI uses a structure type, which is exactly why I filed this bug report. Instead of speculating about what kind of type existing implementations use, please just focus on the specification to which we're trying to stick: POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html "All of the types shall be defined as arithmetic types of an appropriate length, with the following exceptions: [...] pthread_key_t [...]" -- ___ Python tracker <http://bugs.python.org/issue25658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
