[issue1739468] Add a -z interpreter flag to execute a zip file
Paul Moore added the comment: PJE's patch looks OK. I agree with Nick that the chain of &&s in PyImport_GetImporter should be expanded into a chain of ifs. As it stands, the code is needlessly obfuscated. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1739468> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1468] MSI installer does not include SSL test .pem files
New submission from Paul Moore: The latest MSI daily snapshot installer for Python 2.6 (19 Nov) does not include the .pem files for the SSL tests from the Lib\test directory. -- components: Installation messages: 57666 nosy: pmoore severity: normal status: open title: MSI installer does not include SSL test .pem files versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1468> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1468] MSI installer does not include SSL test .pem files
Paul Moore added the comment: The following looks like it may be OK. I have no way of testing it, unfortunately, as I don't currently have a working build environment, and I've no idea how to build the MSI even if I did... Added file: http://bugs.python.org/file8782/msi.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1468> __ msi.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1489] test_socket_ssl hanhs on Windows (deadlock)
New submission from Paul Moore: When running the test suite on Windows, test_socket_ssl hangs. After a bit of investigation, it appears that the test is hanging at line 184 (if self.s.stdout.readline() != "ERROR\n":) in OpenSSLServer._external. The problem is that the test assumes it can read a line of stdout from the openssl.exe process. However, the openssl.exe on my PC (from the GnuWin32 project) appears to buffer its output, so the Python process deadlocks waiting for a response. An easy (if clumsy) fix is to simply skip the check on the output of the server. I have attached a patch which does this for win32 only (on the assumption that other platforms don't have this issue). I guess that other openssl builds don't have the same problem - however, I can't see an easy way of testing for this. -- components: Tests files: test_socket_ssl.diff messages: 57768 nosy: pmoore severity: normal status: open title: test_socket_ssl hanhs on Windows (deadlock) versions: Python 2.6 Added file: http://bugs.python.org/file8796/test_socket_ssl.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1489> __ test_socket_ssl.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13123] bdist_wininst uninstaller does not remove pycache directories
New submission from Paul Moore : When uninstalling a package installed using a bdist_wininst installer, the uninstall reports "XXX files and directories could not be removed". The problem appears to be the __pycache__ directories introduced in Python 3.2, which are not removed properly. -- assignee: tarek components: Distutils, Windows messages: 145090 nosy: eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: bdist_wininst uninstaller does not remove pycache directories type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13123] bdist_wininst uninstaller does not remove pycache directories
Paul Moore added the comment: Not really (tbh, not at all). If I get some spare time, I can have a look at producing a patch, but I have little time available for coding at the moment (and I'm switching constantly between 3 PCs, so never have a working development environment when I need one :-() If I get anything workable before you do, I'll post it here. -- ___ Python tracker <http://bugs.python.org/issue13123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13123] bdist_wininst uninstaller does not remove pycache directories
Paul Moore added the comment: On 9 October 2011 04:21, Éric Araujo wrote: > > Éric Araujo added the comment: > > I don’t have a Windows VM set up yet, but I can try to write a patch in the > coming weeks and ask you to test it. Deal? No problem there! -- ___ Python tracker <http://bugs.python.org/issue13123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12779] Update packaging documentation
Changes by Paul Moore : -- nosy: +pmoore ___ Python tracker <http://bugs.python.org/issue12779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13162] Trying to install a binary extension as a resource file causes pysetup to give a traceback
New submission from Paul Moore :
I am trying to create a pysetup package that contains a precompiled binary
extension, which can be installed without compiling, by using the resource file
feature of setup.cfg. This may be incorrect usage of pysetup, but at a minimum,
a proper error message should be given rather than a traceback.
With a directory containing an extension hello.pyd plus the following setup.cfg
file:
[metadata]
name = hello
version = 0.1
author = Paul Moore
author-email = p.f.mo...@gmail.com
summary = Test C extension
[files]
resources =
hello.pyd = {platlib}
I get a traceback when I do pysetup install:
PS D:\Data\python-sample\bin> pysetup install
Installing from source directory: 'D:\\Data\\python-sample\\bin'
running install_dist
running build
running install_data
running install_distinfo
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RESOURCES
Traceback (most recent call last):
File "D:\Data\cpython\lib\runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "D:\Data\cpython\lib\runpy.py", line 73, in _run_code
exec(code, run_globals)
File "D:\Data\cpython\lib\packaging\run.py", line 666, in
sys.exit(main())
File "D:\Data\cpython\lib\packaging\run.py", line 653, in main
return dispatcher()
File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__
return func(self, self.args)
File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper
return f(*args, **kwargs)
File "D:\Data\cpython\lib\packaging\run.py", line 164, in _install
return not install_local_project(target)
File "D:\Data\cpython\lib\packaging\install.py", line 122, in
install_local_project
return _run_install_from_dir(path)
File "D:\Data\cpython\lib\packaging\install.py", line 160, in
_run_install_from_dir
func(source_dir)
File "D:\Data\cpython\lib\packaging\install.py", line 87, in
_run_packaging_install
dist.run_command('install_dist')
File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command
cmd_obj.run()
File "D:\Data\cpython\lib\packaging\command\install_dist.py", line 506, in run
self.run_command(cmd_name)
File "D:\Data\cpython\lib\packaging\command\cmd.py", line 330, in run_command
self.distribution.run_command(command)
File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command
cmd_obj.run()
File "D:\Data\cpython\lib\packaging\command\install_distinfo.py", line 112,
in run
writer.writerow(row)
TypeError: 'str' does not support the buffer interface
If this configuration is invalid a better error message should be given.
However, I would also like to know what (if any) would be the correct way of
writing a setup.cfg file to install a compiled extension like this.
For background on why I am trying to do things in this (odd) way, see the
python-dev thread starting at
http://mail.python.org/pipermail/python-dev/2011-October/113956.html
--
assignee: tarek
components: Distutils2, Library (Lib)
messages: 145441
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: Trying to install a binary extension as a resource file causes pysetup
to give a traceback
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13162>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13172] pysetup run --list-commands fails with a traceback
New submission from Paul Moore : In a directory with 2 files, setup.cfg and a single C file containing source for an extension module. The same happens with a pure-python module. This is on Windows. PS D:\Data\python-sample> D:\Data\cpython\PCbuild\python.exe -m packaging.run run --list-commands List of available commands: bdist: create a built (binary) distribution bdist_dumb: create a "dumb" built distribution Traceback (most recent call last): File "D:\Data\cpython\lib\packaging\util.py", line 652, in resolve_name ret = getattr(ret, part) AttributeError: 'module' object has no attribute 'bdist_msi' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "D:\Data\cpython\lib\runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "D:\Data\cpython\lib\runpy.py", line 73, in _run_code exec(code, run_globals) File "D:\Data\cpython\lib\packaging\run.py", line 666, in sys.exit(main()) File "D:\Data\cpython\lib\packaging\run.py", line 653, in main return dispatcher() File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__ return func(self, self.args) File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper return f(*args, **kwargs) File "D:\Data\cpython\lib\packaging\run.py", line 264, in _run cls = dispatcher.cmdclass.get(cmd) or get_command_class(cmd) File "D:\Data\cpython\lib\packaging\command\__init__.py", line 61, in get_command_class cls = resolve_name(cls) File "D:\Data\cpython\lib\packaging\util.py", line 654, in resolve_name raise ImportError(exc) ImportError: 'module' object has no attribute 'bdist_msi' -- assignee: tarek components: Distutils2 messages: 145478 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: pysetup run --list-commands fails with a traceback type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13172> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
New submission from Paul Moore : On Windows, packaging seems to create RECORD files with an additional CR at the end of the line. (So the line end is CR CR LF). This does not seem to be consistent, but it is likely to be because a file is being opened in text mode rather than binary. I am trying to develop a reproducible test case, but am having difficulty at the moment. I have opened this bug in any case as a place holder and in case someone else can reproduce the issue. -- assignee: tarek components: Distutils2 messages: 145488 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: packaging uses wrong line endings in RECORD files on Windows type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13172] pysetup run --list-commands fails with a traceback
Paul Moore added the comment: No it didn't - I had not built the _msi module when I built Python for some reason. I have built _msi now, and everything works. Sorry for the false alarm. Arguably, the command shouldn't fail, it should simply omit the bdist_msi command from the listing. But as _msi is part of Python, the installation is broken if it isn't present so I guess that handling the issue gracefully isn't really important. (I assume the missing _msi extension isn't an issue on Unix). -- ___ Python tracker <http://bugs.python.org/issue13172> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13180] pysetup silently ignores invalid entries in setup.cfg
New submission from Paul Moore : With a simple setup.cfg defining a distribution containing a single Python module, if you misspell the "modules" keyword (say, as "module") then pysetup does nothing without reporting the error. This silent failure is very hard to debug, and even if pysetup is ignoring unknown items by design, it should at a minimum report ignored items and probably try to warn on common misspellings like this one. PS D:\Data\python-sample\python> type .\setup.cfg [metadata] name = hello version = 0.1 author = Paul Moore author-email = p.f.mo...@gmail.com summary = Test Python module [files] module = hello PS D:\Data\python-sample\python> pysetup run build running build PS D:\Data\python-sample\python> dir Directory: D:\Data\python-sample\python ModeLastWriteTime Length Name - -- -a---13/10/2011 19:46 42 hello.py -a---14/10/2011 18:42155 setup.cfg (No build directory created!) -- assignee: tarek components: Distutils2 messages: 145552 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: pysetup silently ignores invalid entries in setup.cfg type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13180> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
Paul Moore added the comment: Unfortunately, no. I have been unable to get this in a reproducible form - but I have seen it a few times now. I will keep trying to reproduce. The worst thing is that packaging fails to recognise the data in RECORD and won't uninstall the package. It would be helpful if packaging were a little more permissive in how it handles this sort of problem in RECORD. -- ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13181] pysetup install creates .pyc files but pysetup remove doesn't delete them
New submission from Paul Moore : The title explains. Here is an example: PS D:\Data\python-sample\python> pysetup install Installing from source directory: 'D:\\Data\\python-sample\\python' running install_dist running build running build_py running install_lib byte-compiling D:\Data\cpython\Lib\site-packages\hello.py to hello.cpython-33.pyc running install_distinfo creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD PS D:\Data\python-sample\python> pysetup remove hello Removing 'hello': D:\Data\cpython\Lib\site-packages\hello.py D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD Proceed (y/n)? y Success: removed 5 files and 1 dirs PS D:\Data\python-sample> dir D:\Data\cpython\Lib\site-packages\__pycache__ Directory: D:\Data\cpython\Lib\site-packages\__pycache__ ModeLastWriteTime Length Name - -- -a---14/10/2011 18:53314 hello.cpython-33.pyc The pyc file should have been removed. It's not critical (the pyc file gets ignored, see PEP 3147) but as pysetup created it, pysetup should remove it... -- assignee: tarek components: Distutils2 messages: 145554 nosy: alexis, eric.araujo, pmoore, tarek priority: low severity: normal status: open title: pysetup install creates .pyc files but pysetup remove doesn't delete them type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13182] pysetup run bdist_wininst does not work (tries to use "install" command)
New submission from Paul Moore :
PS D:\Data\python-sample\python> pysetup run bdist_wininst
running bdist_wininst
running build
running build_py
Invalid command install
Traceback (most recent call last):
File "D:\Data\cpython\lib\packaging\command\__init__.py", line 57, in
get_command_class
cls = _COMMANDS[name]
KeyError: 'install'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "D:\Data\cpython\lib\packaging\run.py", line 653, in main
return dispatcher()
File "D:\Data\cpython\lib\packaging\run.py", line 642, in __call__
return func(self, self.args)
File "D:\Data\cpython\lib\packaging\run.py", line 91, in wrapper
return f(*args, **kwargs)
File "D:\Data\cpython\lib\packaging\run.py", line 288, in _run
dist.run_command(cmd, dispatcher.command_options[cmd])
File "D:\Data\cpython\lib\packaging\dist.py", line 709, in run_command
cmd_obj.run()
File "D:\Data\cpython\lib\packaging\command\bdist_wininst.py", line 119, in
run
reinit_subcommands=True)
File "D:\Data\cpython\lib\packaging\command\cmd.py", line 323, in
get_reinitialized_command
command, reinit_subcommands)
File "D:\Data\cpython\lib\packaging\dist.py", line 660, in
get_reinitialized_command
command = self.get_command_obj(command_name)
File "D:\Data\cpython\lib\packaging\dist.py", line 583, in get_command_obj
cls = get_command_class(command)
File "D:\Data\cpython\lib\packaging\command\__init__.py", line 59, in
get_command_class
raise PackagingModuleError("Invalid command %s" % name)
packaging.errors.PackagingModuleError: Invalid command install
Looking at bdist_wininst.py (line 118) it is indeed trying to use an "install"
command, which is not present in command\__init__.py
--
assignee: tarek
components: Distutils2
messages: 14
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: pysetup run bdist_wininst does not work (tries to use "install" command)
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue13182>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
Paul Moore added the comment: Windows 7, 32 bit. -- ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13172] pysetup run --list-commands fails with a traceback
Paul Moore added the comment: I suppose so, yes. But it feels symptomatic of a general lack of clean error handling, which I think should be fixed :-( -- ___ Python tracker <http://bugs.python.org/issue13172> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
Paul Moore added the comment: I found the problem - it's in packaging.util.write_record_file. The file passed to csv.writer should be opened with newline=''. -- ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
Paul Moore added the comment: Here's a patch. It includes a test, but I don't expect the test will catch the issue except on Windows... -- keywords: +patch Added file: http://bugs.python.org/file23416/recordfix.patch ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13189] New bdist_simple binary distribution format for packaging
New submission from Paul Moore : The attached patch is a first version of a bdist_simple binary distribution format for packaging. There is a bdist_simple command to build the distribution, and pysetup install has been updated to handle bdist_simple format distributions (only as local files, there is no support for discovering or downloading binary distributions at this point). The patch still needs documentation and tests, but has been manually tested on Windows, for both Python and C distributions. -- assignee: tarek components: Distutils2 files: bdist_simple.patch keywords: patch messages: 145621 nosy: alexis, eric.araujo, pmoore, tarek priority: normal severity: normal status: open title: New bdist_simple binary distribution format for packaging type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23417/bdist_simple.patch ___ Python tracker <http://bugs.python.org/issue13189> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13189] New bdist_simple binary distribution format for packaging
Changes by Paul Moore : Removed file: http://bugs.python.org/file23417/bdist_simple.patch ___ Python tracker <http://bugs.python.org/issue13189> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13189] New bdist_simple binary distribution format for packaging
Paul Moore added the comment: New patch including some basic tests. -- Added file: http://bugs.python.org/file23422/bdist_simple.patch ___ Python tracker <http://bugs.python.org/issue13189> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13175] packaging uses wrong line endings in RECORD files on Windows
Paul Moore added the comment: On 17 October 2011 14:15, Éric Araujo wrote: >> The file passed to csv.writer should be opened with newline=''. > How will we port this to 2.x? No idea :-( The 2.7 documentation says use the 'b' flag, but that probably doesn't allow an encoding parameter (it doesn't on 3.x). >> I don't expect the test will catch the issue except on Windows... > Do you mean that the test will fail or be a no-op on other OSes? We can mark > it as Windows-specific (@unittest.skipIf(sys.platform != 'win32', 'test only > relevant on win32')) or just let it run if it’s harmless. The important > point is: does it fail before the fix, does it pass after? The test fails before the fix, passes after. It's a no-op on platforms where text and binary files are the same, (i.e., non-Windows systems). So it's harmless. -- ___ Python tracker <http://bugs.python.org/issue13175> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13181] pysetup install creates .pyc files but pysetup remove doesn't delete them
Paul Moore added the comment: > That’s odd. Are the pyc files in RECORD? Yes, but not in __pycache__ where they should be. PS D:\Data\python-sample\python> type D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD D:\Data\cpython\Lib\site-packages\hello.py,798c341fba13dcecba260e25d2b976b6,42 D:\Data\cpython\Lib\site-packages\hello.pyc,, D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA,bcae83fd032d0c33cea5dc14a1ca1bc5,206 D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER,44e3fde05f3f537ed85831969acf396d,9 D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED,d41d8cd98f00b204e9800998ecf8427e,0 D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD,, -- ___ Python tracker <http://bugs.python.org/issue13181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13172] Improve detection of availability of bdist_msi command
Paul Moore added the comment: > Would you be satisfied with a more helpful traceback that would point you > immediately to missing msi? Do you prefer that bdist_msi > catch an ImportError for _msi and print a short error message instead of a > traceback in all its glory? I'd be happy with a more explicit error. As you say, it's a broken build so not worth worrying too much about, but it did take me quite a while to work out what the problem was, including having to raise this bug report. (The existing traceback doesn't even mention _msi). So yes, a simple error would be ideal. -- ___ Python tracker <http://bugs.python.org/issue13172> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13193] test_packaging and test_distutils failures under Windows
Paul Moore added the comment: I'm not getting the second error on my home PC. As the failing buildbot is mine, I'll have a look on there to see if I can reproduce when I get the chance. -- ___ Python tracker <http://bugs.python.org/issue13193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13193] test_packaging and test_distutils failures under Windows
Paul Moore added the comment: First one - the problem is in packaging.manifest._translate_pattern, which uses os.path.join on regex parts. That won't work on Windows where os.sep is a backslash, as the backslash is a RE metacharacter. Actually, the file list seems to only use '/' as a path separator, so you can just use pattern_re = "^" + prefix_re + '/' + ".*" + pattern_re Whether this is right or not depends on whether the test is correctly supplying the expected file list as always /-separated. I don't know enough to be certain on that. An alternative would be to use '[/\\]' in the above, to catch both / and \ separators. Technically wrong, but robust enough to do for now if needed. -- ___ Python tracker <http://bugs.python.org/issue13193> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13181] pysetup install creates .pyc files but pysetup remove doesn't delete them
Paul Moore added the comment: Yes, working correctly now -- ___ Python tracker <http://bugs.python.org/issue13181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11805] package_data only allows one glob per-package
Paul Moore added the comment:
I see what you're saying - and looking through sysconfig.cfg, I can see how
things are expected to be laid out (and how I'd configure it if I didn't like
it :-))
But as far as I can see, there's no way in packaging to describe a module that
works like sysconfig itself! (A module with a resource which is expected to
live alongside the .py file). Installing the cfg file to {purelib} would work
in practice, but if the distribution containing sysconfig was later changed to
include a C extension, then the code would get silently switched to install
into platlib, and the .cfg file would no longer be alongside the .py file.
(This is only actually the case when purebase and base differ - which never
happens on Windows, and I don't really understand when it would happen on Unix.
So I can't really say how likely and/or important this possibility is. But it's
certainly there.)
I'd like to see an extra category that was guaranteed to point to where the
code files were going to be installed (i.e., the same as whichever one of
platlib or purelib the packaging installer chooses). With that, it would be
possible (but still clumsy) to implement package data reliably.
OK, having said all that, I do think that saying "package_data was wrong, let’s
move away from that" is a bit user-unfriendly. Whether it causes issues for OS
distributors, or is "wrong" as a matter of principle, people do use it, a lot.
It's the basis of the whole egg concept (a package and its data as a single
self-contained object), it's used by distutils itself as you mention, as well
as in a number of other places in the stdlib. If you don't support it, I
predict that people are simply going to invent more and more elaborate hacks to
emulate it.
Actually, given that packaging should allow a hook to find out where a given
file is going to be installed (if it isn't, expect a feature request :-)), it
should be reasonably easy to write a hook to add a custom category for this
purpose. But I'd argue that it's better to put the feature in packaging
directly, rather than see the same workaround implemented over and over again.
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue11805>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)
Changes by Paul Moore : -- nosy: +pmoore ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11805] package_data only allows one glob per-package
Paul Moore added the comment: One important point - in the "new world" where data files living alongside code is unsupported, the bdist_msi and bdist_wininst installers need to be updated to install data files as needed. This may work already (I'll do some tests to see how well when I get back to my PC with dev builds on it) but right now bdist_wininst for example does not support the full generality of the resource mechanism (and it's not clear to me how it can be made to...) so there will be restrictions on what can be allowed until the wininst format is updated. For installs from source, the suggested "new world" is fine. But without a binary install process that's as flexible as a source install, the current "alongside the code" approach has the benefit of working well with the existing installer technology. -- ___ Python tracker <http://bugs.python.org/issue11805> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Paul Moore : -- nosy: +pmoore ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5689] Support xz compression in tarfile module
Paul Moore added the comment: A simple rebuild and test run of that test in debug mode didn't fail... I'll run the full test suite as a check, but that could take some time - that buildslave isn't the fastest in the world... -- ___ Python tracker <http://bugs.python.org/issue5689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12678] test_packaging and test_distutils failures under Windows
Changes by Paul Moore : -- nosy: +pmoore ___ Python tracker <http://bugs.python.org/issue12678> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9055] test_issue_8959_b fails when run from a service
Paul Moore added the comment: Certainly the 2.7 branch on my buildbot is now OK (3.x is failing for other reasons :-() -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue9055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Paul Moore added the comment: Seems to be correctly skipping the test now - failures are because of other issues (a load more hg builds means that the buildslave is getting a bit tight on space...) This change looks fine. Thanks! -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue9931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7213] Popen.subprocess change close_fds default to True
Paul Moore added the comment:
This bug appears to be Unix-only. On Windows:
>>> from subprocess import *
>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE)
>>> p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE)
>>> p1.stdin.write("\n")
>>> p1.stdin.close()
>>> p2.stdout.read()
'\n'
>>>
So there's no clear reason why the default should change on Windows. (It's not
possible to specify close_fds explicitly on Windows for this case:
>>> p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE, close_fds=True)
Traceback (most recent call last):
File "", line 1, in
File "D:\Apps\Python27\lib\subprocess.py", line 630, in __init__
raise ValueError("close_fds is not supported on Windows "
ValueError: close_fds is not supported on Windows platforms if you redirect
stdin/stdout/stderr
which may imply that False is not only reasonable, but necessary on Windows. I
haven't dug into this enough to know for sure if this is the case, though).
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue7213>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Paul Moore added the comment: Patch looks good to me. Can this be applied? As a temporary workaround I have set my buildbot to run interactively. Once the fix is applied, I will switch back to running as a service. -- keywords: +buildbot ___ Python tracker <http://bugs.python.org/issue9931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Changes by Paul Moore : -- nosy: +gpolo ___ Python tracker <http://bugs.python.org/issue9931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Paul Moore added the comment: > Perhaps somewhat orthogonal to the patch, but in terms of the original hang > issue, does your service definition have the "interact with desktop" option > checked? That ought to permit any normal UI processing to take place as if > you were running it interactively. It runs as a specific user, not as LocalSystem (and only LocalSystem has the "interact with desktop" checkbox, so yes, I think it does...) -- ___ Python tracker <http://bugs.python.org/issue9931> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3496] distutils fails with mingw binutils 2.18.50.20080109
New submission from Paul Moore <[EMAIL PROTECTED]>: The latest version of Mingw binutils, 2.18.50.20080109, uses a 4-part version number which distutils does not like (StrictVersion only allows for 3 parts). The attached patch fixes this, simply by using LooseVersion (the version number has already been checked to be a series of numbers in the regex check just previous). Can this be fixed for 2.6/3.0, as it is likely that the new binutils will become common while these versions of Python are current? -- components: Distutils files: distutils.patch keywords: patch messages: 70655 nosy: pmoore severity: normal status: open title: distutils fails with mingw binutils 2.18.50.20080109 type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file11043/distutils.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3496> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
New submission from Paul Moore : test_support.find_unused_port attempts to find an unused port to use. The approach is fragile (as noted in the docstring) in certain cases. In particular, it appears that Windows takes a short time to free the socket after it is closed, meaning that when the caller tries to open a socket on the returned port number, it gets permission issues. A sleep(0.1) just before returning the port number appears to address the issue, but this is not a proper solution. http://msdn.microsoft.com/en-us/library/ms737582%28v=VS.85%29.aspx describes the SO_LINGER and SO_DONTLINGER socket options, which may be related, but in my initial tests I haven't been able to get these to work. -- components: Tests, Windows keywords: buildbot messages: 104614 nosy: pmoore priority: normal severity: normal status: open title: test_support.find_unused_port can cause socket conflicts on Windows ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Changes by Paul Moore : -- nosy: +pitrou ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Paul Moore added the comment: OK. I've attached a patch which removes the use of get_unused_port for test_smtplib and test_multiprocessing. It doesn't use bind_port as both cases test classes that create their own port internally, rather I've used port 0 and then introspected the actual port assigned. The same process could probably be used for the remaining uses of get_unused_port, but I haven't tackled them yet. Tested on my local PC and on the buildbot where I see the bug. Both tests run fine in both cases. I'm running the full test suite now. -- keywords: +patch Added file: http://bugs.python.org/file17150/unused1.patch ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Paul Moore added the comment: Here's a patch for test_logging. It needed a minor tweak to logging.config - but I can't see anywhere that this affects the documentation, so I didn't do a doc patch. I hope that's OK. I'll have a look at test_socket but that looks a bit too deep for me. And test_httplib seems to be testing that if you supply a specific port, the connection socket actually connects on that port, so I can't really see any way of avoiding needing a specific unused port there :-( -- Added file: http://bugs.python.org/file17161/test_logging.patch ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Paul Moore added the comment: Might work - but the only ones that were actually failing for me were test_multiprocessing and test_smtplib. So I'm not quite sure where/when the error would be raised on the remaining 2 (socket & httplib). But I'll keep it in mind. To be honest, the remaining tests haven't actually failed in my experience, I'm now really only seeing if I can remove all uses of find_unused_port on the basis of Jean-Paul's comment that it's "the wrong approach". -- ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Paul Moore added the comment: One of the tests in test_socket is checking that an attempt to connect to a port with no server running gives socket.error. For that, we need a port that's guaranteed to have no server present. I think that one of the tests in test_httplib checks the source_address attribute to make sure the port it contains is the one you connected on - again, you need a specific port and it can't be in use. (Sorry, I'm not precise on the details of this one as it's only in trunk and I'm not at a PC with a trunk checkout at the moment). Arguably these tests are of limited value and could simply be deleted, but they are there, and I don't see a way of implementing them without using something that gives you an unused port number... -- ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8576] test_support.find_unused_port can cause socket conflicts on Windows
Paul Moore added the comment: Thanks for the suggestions, I'll see if I can implement something based on them. -- ___ Python tracker <http://bugs.python.org/issue8576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1561] py3k: test_mailbox fails on Windows
Paul Moore added the comment: I believe that mailbox.py is expected to work with files opened in binary mode. A long time ago I opened a bug on th email package (http://bugs.python.org/issue586899) which turned out to be because mailbox.py required binary mode files. The conclusion was that it wouldn't be fixed (mainly because I couldn't work out a reasonable patch). I could look again, but I doubt I'll be any better able to work out what to do now... -- nosy: +pmoore __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1561> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
New submission from Paul Moore <[EMAIL PROTECTED]>: This patch adds a new get_data function to the pkgutil module, allowing access to data stored in the package directory. It wraps the PEP 302 loader "get_data" function, so that it works with such loaders (for example, zipimport). The patch includes documentation and tests (I created a new test_pkgutil test module, but did not add tests for the existing pkgutil functionality). All tests pass on Windows against svn rev 61679 (except test_tcl, which was skipped as I didn't build TCL support). -- components: Library (Lib) files: pkgutil.patch keywords: patch messages: 64208 nosy: pmoore severity: normal status: open title: Patch to add a get_data function to pkgutil type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9792/pkgutil.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: I'm not sure I understand. It uses pkgutil.get_loader, which returns a wrapper for filesystem modules. You pointed me to it. It seems to work, that's what test_getdata_filesys is testing in test_pkgutil.py. Can you supply a testcase that fails? (BTW, this is a patch for the trunk - ie 2.6-to be. I can't see why 2.5 would be different, but maybe that's the problem for you?) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: Is that true? loader.load_module(pkg) should return sys.modules[pkg] without reloading if it already exists. See PEP 302 "Specification part 1: The Importer Protocol": The load_module() method has a few responsibilities that it must fulfil *before* it runs any code: - If there is an existing module object named 'fullname' in sys.modules, the loader must use that existing module. (Otherwise, the reload() builtin will not work correctly.) If a module named 'fullname' does not exist in sys.modules, the loader must create a new module object and add it to sys.modules. I've added a test for this, but I'm not 100% sure it's right. It certainly works with unchanged code. If you can make it fail, let me know and I'll work up a fix. But I think repeated calls to load_module() should be safe (assuming loaders work as required by PEP 302). Added file: http://bugs.python.org/file9799/pkgutil.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Changes by Paul Moore <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9792/pkgutil.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: Nick, thanks I now see the issue. I'll work up a test to check for this (and then correct it :-)). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: But that's not a valid loader. I'm still struggling here. I see what you're trying to get at, but I can't see how I can write a valid loader that does this. To test the problem you're suggesting (that the code calls load_module when the module is already loaded) I need a valid loader which does something detectably different of the module is already loaded when it runs. Obviously, I can fix the get_data code - that's not even remotely hard. But I'd rather create a failing test with the current code, so that I can confirm that the "problem" is fixed. At the moment, I can't even demonstrate a problem! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: It has to be a valid loader, as I see no reason to support loaders that aren't valid. In any case, I did try incrementing a counter and it doesn't demonstrate the problem. If you try the currently attached patch, you should see that. (I assume you've tried or at least read the current patch - but the fact that you're suggesting the approach I have implemented makes me wonder. I did re-upload the patch after you reported the issue - msg 64225 - maybe you didn't notice this, as I deleted the old patch?) If you do see what I mean, please tell me where my code is wrong. I don't want to add a fix without a test showing why the current behaviour is wrong. The test_alreadyloaded test is intended to do that, but the current pkgutil code doesn't fail the test - so either the test is wrong (and I'd appreciate help fixing the test) or the "problem" isn't real, and I can leave the code as is. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: Thanks for the update. Something's seriously screwy here. I am getting no failures, so you can probably see why I was confused. Can you tell me what platform, etc (anything that might be relevant) and I'll try to see what's going on. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: By the way, for comparison, I'm running the test (under Windows) using rt -q -v test_pkgutil from the PCBuild directory. I can't see how test_getdata_filesys can fail, as long as you're running it from the correct place - it reads the test_pkgutil.py file relative to the test package, so it won't run outside of there (maybe I should change this, but that's a separate issue for now). Here's my output: >rt -q -v test_pkgutil .\\python -E -tt ../lib/test/regrtest.py -v test_pkgutil test_pkgutil test_alreadyloaded (test.test_pkgutil.PkgutilTests) ... ok test_getdata_filesys (test.test_pkgutil.PkgutilTests) ... ok test_getdata_pep302 (test.test_pkgutil.PkgutilTests) ... ok -- Ran 3 tests in 0.000s OK 1 test OK. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: Ah, no. I see your command line. I get the same failure as you in that case. I can see why test_getdata_filesys fails in that case, I'll fix that. I'm confused as to why test_alreadyloaded fails there but not via rt.bat, but nevertheless I can fix that now I can see it. Thanks for your patience. Leave it with me. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: OK, I found it. There were 2 problems, the double-loading one, and a problem with adding my importer to sys.meta_path - if the test failed, I wasn't removing it (so it was there for the next test, and interfering with it). Here's a fixed patch. Thanks, Phillip, for persevering! Added file: http://bugs.python.org/file9806/pkgutil.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Changes by Paul Moore <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9799/pkgutil.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2439] Patch to add a get_data function to pkgutil
Paul Moore <[EMAIL PROTECTED]> added the comment: Thanks, Paul. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2439> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
New submission from Paul Moore : This patch takes the existing "simplegeneric" decorator, currently an internal implementation detail of the pkgutil module, and exposes it as a feature of the functools module. Documentation and tests have been added, and the pkgutil code has been updated to use the functools implementation. Open issue: The syntax for registering an overload is rather manual: def xxx_impl(xxx): pass generic_fn.register(XXX, xxx_impl) It might be better to make the registration function a decorator: @generic_fn.register(XXX) def xxx_impl(xxx): pass However, this would involve changing the existing (working) code, and I didn't want to do that before there was agreement that the general idea (of exposing the functionality) was sound. -- assignee: ncoghlan components: Library (Lib) files: generic.patch keywords: needs review, patch messages: 80986 nosy: ncoghlan, pmoore priority: normal severity: normal stage: patch review status: open title: Expose simplegeneric function in functools module type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12921/generic.patch ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment: Well spotted! I missed that when I checked. I will add tests and documentation. I agree that generic is better. I only left it as it was because the original intent was simply to move the existing code - but that's not a particularly good reason for keeping a clumsy name. There shouldn't be a clash, as any more general mechanism can either be in its own module or the existing function can be extended in a compatible manner. I'll make this change too. Thanks for the feedback! ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment: Here's an updated patch. Added file: http://bugs.python.org/file12936/generic.patch ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment: Fair comment. As Ryan said, it's a bit of a bikeshed issue. I prefer "generic", on the basis that I'd prefer to keep the simple name for the simple use - something as complex as the RuleDispatch version could use the name "dispatch" (if they want to keep it the name simple) or "multimethod" (to emphasize that it dispatches on more than just one argument). If the consensus is for keeping it as "simplegeneric", I'll go with that, but I'll wait for other views first. BTW, another option is simply to clarify the limitations in the documentation. I can add something there if that would be enough for you. ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment: Agreed about the compatibility. It's there from pkgutil, where to be honest, it's even less necessary, as simplegeneric was for internal use only, there. I'm certainly not aware of any backward compatibility requirements for functools. Assuming nobody speaks up to the contrary, I'll rip out the compatibility bits in the next version of the patch. I'm unsure about the non-decorator version of register. I can imagine use cases for it - consider pprint, for example, where you might want to register str as the overload for your particular type. But it's not a big deal either way. ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment: Agreed (in principle). However, in practice the subtleties of override order must be documented (and a method of implementation must be established!!!) Consider: >>> class A: ... pass ... >>> class C: ... __metaclass__ = abc.ABCMeta ... >>> class D: ... __metaclass__ = abc.ABCMeta ... >>> C.register(A) >>> D.register(A) >>> @generic ... def pprint(obj): ... print "Base", str(obj) ... >>> @pprint.register(C) ... def pprint_C(obj): ... print "Charlie", obj ... >>> @pprint.register(D) ... def pprint_D(obj): ... print "Delta", obj ... >>> pprint(A()) What should be printed? A() is a C and a D, but which takes precedence? There is no concept of a MRO for ABCs, so how would the "correct" answer be defined? "Neither" may not be perfect, but at least it's clearly defined. Relying on order of registration for overloads of the generic function seems to me to be unacceptable, before anyone suggests it, as it introduces a dependency on what order code is imported. So while the theory makes sense, the practice is not so clear. Respecting ABCs seems to me to contradict the "simple" aspect of simplegeneric, so a documented limitation is appropriate. (But given the above, I'm more inclined now to leave the name as "simplegeneric", precisely to make this point :-)) ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment:
Very good point. Registering for the standard ABCs seems like an
important use case. Unfortunately, it seems to me that ABCs simply don't
provide that capability - is there a way, for a given class, of listing
all the ABCs it's registered under? Even if the order is arbitrary,
that's OK.
Without that, I fail to see how *any* generic function implementation
("simple" or not) could support ABCs. (Excluding obviously broken
approaches such as registration-order dependent overload resolution).
The problem is that ABCs are all about isinstance testing, where generic
functions are all about *avoiding* isinstance testing. (As a compromise,
you could have a base generic function that did isinstance testing for
the sequence ABC).
___
Python tracker
<http://bugs.python.org/issue5135>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5135] Expose simplegeneric function in functools module
Paul Moore added the comment: Here's an updated patch. I've reverted to the name "simplegeneric" and documented the limitation around ABCs (I've tried to give an explanation why it's there, as well as a hint on now to work around the limitation - let me know if I'm overdoing it, or the text needs rewording). I've also fixed the wrapper to use update_wrapper to copy the attributes. That way, there's no duplication. Added file: http://bugs.python.org/file12957/generic.patch ___ Python tracker <http://bugs.python.org/issue5135> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue870479] Scripts need platform-dependent handling
Paul Moore added the comment: In principle I don't have a problem with the automatic generation of an EXE (I assume it generates a shell script with no extension on Unix?) but it should be done in such a way that the EXE is version-independent. This is necessary to ensure that pure-python packages, when made into bdist_wininst installers, continue to be version-independent. (At the moment, distutils generates version-dependent bdist_wininst packages *only* for C extensions. Setuptools generates version-dependent installers all the time, which is a pain). This may mean that a reimplementation is required, rather than copying the setuptools code. ___ Python tracker <http://bugs.python.org/issue870479> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46566] Support -3.11-arm64 in py.exe launcher
Paul Moore added the comment: > as well as potentially being able to be a script or .pyz launcher with a > simple rename. Would it be possible to also make the launcher work when prepended to a zipfile? That's a really useful use-case (make a zipapp automatically runnable, but still a single file) that at the moment needs a 3rd party launcher (Vinay's simple-launcher project). If not, then that's fine, but if we're already doing a significant rewrite that might be a good time to add it. -- ___ Python tracker <https://bugs.python.org/issue46566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47170] py launcher on windows opens new terminal window when parsing python script with shebang
Paul Moore added the comment: This is Windows (shell) behaviour. To avoid this, you need to add the .py extension to the PATHEXT environment variable. -- ___ Python tracker <https://bugs.python.org/issue47170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25172] Unix-only crypt should not be present on Windows.
Paul Moore added the comment: I added the label for you. -- ___ Python tracker <https://bugs.python.org/issue25172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25172] Unix-only crypt should not be present on Windows.
Paul Moore added the comment: To clarify, I think adding the label needs core dev (or maybe triager) rights on github, so I don't think it's something you can do yourself. -- ___ Python tracker <https://bugs.python.org/issue25172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37850] Console: holding right arrow key reproduces entire previous input
Paul Moore added the comment: This is normal behaviour of the Windows console command line editing. Python simply inherits the standard console behaviour. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38369] Python 3.7.4 venv command does not install pip
New submission from Paul Moore : The venv module with Python 3.4 on Windows doesn't install pip - even though the --without-pip flag is not specified. This appears to be a regression since pip is installed when using 3.7: >C:\Utils\PythonVersions\Python-3.7.3\python.exe -m venv ve-373 >dir .\ve-373\Scripts\pip.exe Directory: C:\Work\Scratch\vv\ve-373\Scripts ModeLastWriteTime Length Name - -- -a 04/10/2019 10:08 102765 pip.exe >py -m venv ve-374 >dir .\ve-374\Scripts\pip.exe dir : Cannot find path 'C:\Work\Scratch\vv\ve-374\Scripts\pip.exe' because it does not exist. At line:1 char:1 + dir .\ve-374\Scripts\pip.exe + + CategoryInfo : ObjectNotFound: (C:\Work\Scratch...Scripts\pip.exe:String) [Get-ChildItem], ItemNotFoundException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand >py -V Python 3.7.4 -- assignee: steve.dower components: Library (Lib) messages: 353911 nosy: paul.moore, steve.dower priority: normal severity: normal status: open title: Python 3.7.4 venv command does not install pip type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38369] Python 3.7.4 venv command does not install pip
Paul Moore added the comment: This appears to be somehow caused by running Python 3.7.4 from an active virtualenv (which I'd forgotten I had active when I did the test). Regardless, I'd have expected that the command would either correctly create a venv containing pip, or fail to create the venv at all. Creating an incomplete venv is extremely confusing for the user, if nothing else. It looks like this is *not* a regression - it's been like this since 3.6.8 at least. Actually, the created venv looks pretty broken to me - it has the *parent* environment in `sys.path`, but does not have its *own* environment there: >.\ve-368a\Scripts\python.exe Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path ['', 'C:\\Work\\Scratch\\vv\\ve-368a\\Scripts\\python36.zip', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\DLLs', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\lib', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\Scripts', 'C:\\Utils\\PythonVersions\\Python-3.6.8\\Lib', 'C:\\Utils\\PythonVersions\\Python-3.6.8\\DLLs', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\lib\\site-packages'] Note the lack of ve-368a directories, and the presence of a lot of directories from .virtualenvs (the parent environment). -- ___ Python tracker <https://bugs.python.org/issue38369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38369] Python 3.7.4 venv command does not install pip
Paul Moore added the comment: Further update - this appears to also happen on Ubuntu (at least the version available through the Windows Linux subsystem), so it's not a Windows-specific issue. -- assignee: steve.dower -> ___ Python tracker <https://bugs.python.org/issue38369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38369] Python 3.7.4 venv command does not install pip
Paul Moore added the comment: Sigh. Never mind, this appears to be because virtualenv uses its own hacked copy of site.py which is missing a lot of the venv support code. I'll report this over on virtualenv. -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38533] v3.7.5 py script run ok with python.exe but not pythonw.exe (python silent console not working)
Paul Moore added the comment: Can you give an example of a script that fails? If you try to print (or otherwise use the standard IO streams) pythonw will fail, because there are no stdio streams for a GUI executable - and the traceback, which goes to stderr by default, will be lost. This is my best guess as to your issue here, but without a reproducible example, it's hard to say anything useful. -- ___ Python tracker <https://bugs.python.org/issue38533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43697] Importlib documentation does not cover how meta path finders should handle namespace packages
New submission from Paul Moore : I am trying to write a meta path finder that "redirects" module loads to a different part of the filesystem. There's not much information in the importlib documentation, but PEP 451 says "find_spec() must return a spec with "loader" set to None (a.k.a. not set) and with submodule_search_locations set to the same portions as would have been provided by find_loader()". I have done that, and it does work as long as all parts of the namespace package are handled by the *same* metapath loader. But if I have (for instance) one portion of the namespace package handled by my finder, and want to leave the filesystem finder to handle other parts, that doesn't work. Is there a supported way to set up a finder on sys.meta_path which will expose just one "portion" of a namespace package? -- assignee: brett.cannon components: Documentation messages: 389997 nosy: brett.cannon, paul.moore priority: normal severity: normal status: open title: Importlib documentation does not cover how meta path finders should handle namespace packages type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43697] Importlib documentation does not cover how meta path finders should handle namespace packages
Paul Moore added the comment:
OK, cool. That might be worth explaining somewhere in the docs (although I
don't really know where, as I'm not sure where namespace packages are
documented, either :-))
I'm not at all sure what would happen if we have meta path finders A and B on
sys.meta_path in that order, and A.find_spec("foo.bar") returns a spec, but
A.find_spec("foo") doesn't and B.find_spec("foo") does. I think the honest
answer is "I get a headache" ;-)
--
___
Python tracker
<https://bugs.python.org/issue43697>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43697] Importlib documentation does not cover how meta path finders should handle namespace packages
Paul Moore added the comment: > if they return a spec they can, if they don't then they can't What I've never really got clear in my mind is how dotted names get handled. But that's probably just a matter of needing to experiment a bit (I don't think it's particularly complicated, I just need to get a better feel for it). > https://docs.python.org/3/reference/import.html#namespace-packages Ouch. I'd completely missed how much there is in there. Sorry about that, I should have done my research. Thanks for the help. -- ___ Python tracker <https://bugs.python.org/issue43697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Paul Moore added the comment: There's a lot of technical discussion of implementation details here, but not much about use cases. IMO, what's more important is whether NamedTemporaryFile is *useful* to people, and what they want to use it *for*. Working out how to implement it can come after we know what people want it to do. My particular use case is actually pretty simple, and I suspect constitutes a fairly major proportion of what people want of this API: 1. Create a temporary file. 2. Write some data into it. 3. At some point, we're done writing to the file. 4. Only after that point, pass the name of the file to "somewhere else" for processing. That's often, in my use cases, as an argument to a subprocess. 5. Once we're all done, clean up securely. The key additional requirement is that this is done "safely" (by which I mean I don't have to think about race conditions, etc, as someone else has that covered). What I think that means is that we need to maintain an open filehandle of *some* sort continually, but there's a point where the user can say "I'm done writing, I want to share this now". Is there an actual known use case for the behaviour of deleting the file on close *rather* than at the end of the CM's scope? That's unlike any other CM I know of, where the scope ending is what triggers tidy-up. Maybe NamedTemporaryFile should be retained for backward compatibility, but as a normal function, with the CM behaviour deprecated. It would still be essentially useless on Windows, but we maybe don't care about that. In addition, we create a *new* context manager, that simply creates the file at the start and deletes it at close of scope. It returns a writeable file object, but that can be closed (and the documentation notes that for portability it *must* be closed before passing the name to another process for use). I don't know enough about how we protect this against race condition attacks, but I'm pretty sure that this API gives us the best chance we're likely to have of doing so in a cross-platform manner. (Maybe we have a "reopen" method rather than "close". Or can we open *two* file handles at the start, one for writing and one for reading, return the one for writing, and keep the one for reading internal, purely to keep the file locked? I feel like that wouldn't work because if *we* can open a write handle, so could an attacker - but as I say, I'm not an expert). Basically, I may be wrong, but I feel that we should stop trying to "rescue" NamedTemporaryFile, and instead try providing an *alternative* that handles the cross-platform use case that started all of this. -- ___ Python tracker <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Paul Moore added the comment: Sorry - I'm maybe making an unwarranted assumption. If simply removing "delete on close" behaviour in the CM case is acceptable, then I'm 100% in favour of that. I'd assumed that it was somehow unacceptable, but you're right, and it's not clear if Eryk is agreeing or disagreeing with you (I assumed he was disagreeing, based mainly on the length and complexity of his response :-)) It didn't help that somehow Steve's reply wasn't visible when I posted mine. Apologies for the noise. -- ___ Python tracker <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0
Paul Moore added the comment: New changeset 196983563d05e32d2dcf217e955a919f9e0c25e1 by Stéphane Bidoul in branch 'master': bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25576) https://github.com/python/cpython/commit/196983563d05e32d2dcf217e955a919f9e0c25e1 -- ___ Python tracker <https://bugs.python.org/issue43930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0
Paul Moore added the comment: New changeset d962b00fcffa9070acdca850753f254828caa1d7 by Stéphane Bidoul in branch '3.9': [3.9] bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25578) https://github.com/python/cpython/commit/d962b00fcffa9070acdca850753f254828caa1d7 -- ___ Python tracker <https://bugs.python.org/issue43930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43930] Update bundled pip to 21.1 and setuptools to 56.0.0
Paul Moore added the comment: New changeset fc82f3f8fb36f88a4e7238a463812c2916bd4db0 by Stéphane Bidoul in branch '3.8': [3.8] bpo-43930: Update bundled pip to 21.1 and setuptools to 56.0.0 (GH-25576) (GH-25579) https://github.com/python/cpython/commit/fc82f3f8fb36f88a4e7238a463812c2916bd4db0 -- ___ Python tracker <https://bugs.python.org/issue43930> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43312] Interface to select preferred "user" or "home" sysconfig scheme for an environment
Paul Moore added the comment: New changeset d92513390a1a0da781bb08c284136f4d7abea36d by Tzu-ping Chung in branch 'master': bpo-43312: Functions returning default and preferred sysconfig schemes (GH-24644) https://github.com/python/cpython/commit/d92513390a1a0da781bb08c284136f4d7abea36d -- nosy: +paul.moore ___ Python tracker <https://bugs.python.org/issue43312> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43958] Importlib.metadata docs claim PackagePath is a Path subclass
New submission from Paul Moore : The importlib.metadata documentation states that the PackagePath class is "a pathlib.Path derived object". This isn't true - it's a PurePath subclass, and in particular it does not have a resolve() method. In fact, it has an undocumented custom locate() method that converts it into a Path object. I propose changing the documentation to make it clear that it is a PurePath subclass, and explicitly documenting the locate() method. -- assignee: docs@python components: Documentation messages: 392123 nosy: docs@python, paul.moore priority: normal severity: normal status: open title: Importlib.metadata docs claim PackagePath is a Path subclass type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43958] Importlib.metadata docs claim PackagePath is a Path subclass
Change by Paul Moore : -- keywords: +patch pull_requests: +24358 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25669 ___ Python tracker <https://bugs.python.org/issue43958> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Paul Moore added the comment: To be explicit, I'm +1 on breaking backward compatibility in the minor form described by Ethan: if NamedTemporaryFile is used as a context manager, the file is closed *on context manager exit* and *not* when the file is closed. Breaking compatibility is allowed in minor versions (3.11 at this point, as this won't make it in before 3.10 feature freeze). So this is an acceptable change. I don't personally think this needs a transition period or deprecation, and in particular I don't think that Jason's "gradual transition" proposal is necessary. I'd be sad if we ended up with an over-complicated solution for no better reason than an excess of caution over a backward compatibility issue that we're not sure will impact anyone. Do we have any actual examples of code that needs the current CM behaviour (as opposed to a general concern that someone might be using the functionality)? (My original over-complicated proposal was based on a mistaken belief that it had already been established that backward incompatibility was absolutely not allowed. But I never subscribed to that view myself.) -- ___ Python tracker <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41282] Deprecate and remove distutils
Paul Moore added the comment: I'd suggest also posting it on the Packaging discourse, to get feedback from other distro maintainers. -- ___ Python tracker <https://bugs.python.org/issue41282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Paul Moore added the comment: Looking at the various comments, I think we have 5 votes for deleting on CM exit when used as a CM, and no change in behaviour otherwise (me, Zachary, Ethan, Jason and Steve). Steve also wants O_TEMPORARY to be removed, which doesn't seem controversial among this group of people. Eryk has argued for a delete_on_close flag that would need to be explicitly set to False, retaining the use of O_TEMPORARY in the default case, but there doesn't seem to be a lot of support for that. If I've misrepresented anyone's view, please speak up! I didn't look back at the stuff from 2013 and earlier, I'll admit. I do think this needs care to implement (and document!) correctly. For example, consider the following case: ntf = NamedTemporaryFile() # Do some stuff (1) with ntf: # Do some stuff (2) # Do some followup stuff I assume we'd want a close in (1) to delete the file, but a close in (2) to leave it open until the CM exit. Evgeny, would you be willing to update your PR (including adding the docs change, and tests to catch as many edge cases as you can think up) to match this behaviour? -- ___ Python tracker <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Paul Moore added the comment: Eryk, thank you for clarifying. I apologise - I got bogged down somewhere in the middle of the discussion on reimplementing bits of the CRT (your posts are so information-dense that my usual habit of skimming breaks down - that's not a complaint, though!) -- ___ Python tracker <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43993] Update bundled pip to 21.1.1
Paul Moore added the comment: New changeset bf99b7151663905fd5e71efe45184dc8fffc3236 by Stéphane Bidoul in branch 'master': bpo-43993: Update vendored pip to 21.1.1 (GH-25761) https://github.com/python/cpython/commit/bf99b7151663905fd5e71efe45184dc8fffc3236 -- nosy: +paul.moore ___ Python tracker <https://bugs.python.org/issue43993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43993] Update bundled pip to 21.1.1
Paul Moore added the comment: New changeset af1e06c62f3958082c4b409e771f291d12479b3d by Stéphane Bidoul in branch '3.9': [3.9] bpo-43993: Update vendored pip to 21.1.1 (GH-25761). (GH-25782) https://github.com/python/cpython/commit/af1e06c62f3958082c4b409e771f291d12479b3d -- ___ Python tracker <https://bugs.python.org/issue43993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43993] Update bundled pip to 21.1.1
Paul Moore added the comment: New changeset 6034c4aa58fe7257d39b53c77944393700c66396 by Stéphane Bidoul in branch '3.8': [3.8] bpo-43993: Update vendored pip to 21.1.1 (GH-25761). (GH-25783) https://github.com/python/cpython/commit/6034c4aa58fe7257d39b53c77944393700c66396 -- ___ Python tracker <https://bugs.python.org/issue43993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
