[issue21822] KeyboardInterrupt during Thread.join hangs that Thread
Change by Steve : -- nosy: -tupl ___ Python tracker <https://bugs.python.org/issue21822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21292] C API in debug fails
New submission from Steve: Although not a bug, it annoys me enough that it is a bug in my head! The problem is that trying to compile an application in debug that embeds Python fails. Case in point; we canned the idea of embedding Python (went with Lua) for that reason only. We did not have the option of incorporating a Python build into our build system and not being able to compile in debug was not an option either. We would have been happy to compile in debug with a release lib of Python, but since it was not possible, it got killed. The fix: It should be possible for someone to compile an application in debug that embeds python without having the Python debug libraries. -- components: Library (Lib) messages: 216759 nosy: Banger priority: normal severity: normal status: open title: C API in debug fails type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue21292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21292] C API in debug fails
Steve added the comment: It is under windows -- ___ Python tracker <http://bugs.python.org/issue21292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21292] C API in debug fails
Steve added the comment: A bit more info: - When building in debug you need the Pythonxx_d.lib. - This lib does not come with the normal install (or any other install). That part is fine and normal (you don't include debug libs with install). - To get that lib you have to build Python in debug to get it. This is too much, I should not have to rebuild a library just because I want to build MY application in debug. - Copying the Pythonxx.lib file to Pythonxx_d.lib works for many basic functions, but for others, it is missing necessary defiitions (i.e. linking fails). -- ___ Python tracker <http://bugs.python.org/issue21292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21292] C API in debug fails
Steve added the comment: Indeed, but not defining _DEBUG for debug compiling is not realistic. Too many dependencies. I am not even sure it would work, because if we bind with the debug libraries, but build with the "release" headers, it might break. In any case it is not an option we have on the table at this moment. As for the linking part, I am not sure I am following you. Your runtime libraries and DLLs should not need to be linked to anything. They may be dependent on the release msvcrt, and that is fine (like I said, we can live with the Python parts in release). We have many other such libraries that are only in release mode (even when we build in debug). -- ___ Python tracker <http://bugs.python.org/issue21292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21508] C API PyArg_ParseTuple doc is innacurate
New submission from Steve:
PyArg_ParseTuple is defined as returning an "int", but the documentation talks
about returning a true/false value, and failling on false. In addition to
being inaccurate, considering that most other functions fail on !=0 ("true"),
it can lead to confusion.
Doc:
int PyArg_ParseTuple(PyObject *args, const char *format, ...)
Parse the parameters of a function that takes only positional parameters into
local variables. Returns true on success; on failure, it returns false and
raises the appropriate exception.
--
assignee: docs@python
components: Documentation
messages: 218536
nosy: Banger, docs@python
priority: normal
severity: normal
status: open
title: C API PyArg_ParseTuple doc is innacurate
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue21508>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21508] C API PyArg_ParseTuple doc is innacurate
Steve added the comment: I would prefer the function to return "bool". But what I prefer is irrelevant, what counts is accuracy and clarity. And to this end, the return type and the comment have to match. For a int return value, the document should mention a condition relative to an integer value (e.g.: ==0, !=0, ==-1, <0, ==42, etc). In this particular case, to minimize the changes, success should be defined as !=0 and failure ==0. Although there is a bigger problem that I mentioned in that the Python C API uses two different return value standards: in most places, ==0 is success, in this case (and some other places) ==0 is a failure. As for "implementation constraints" I don't see how making the documentation accurate affects that in any way. If ever the implementation is expanded, the documentation will need to change. The only alternative is to make the doc vague or simply wrong. -- ___ Python tracker <http://bugs.python.org/issue21508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21822] KeyboardInterrupt during Thread.join hangs that Thread
New submission from Steve: I am attempting to join a thread after a previous join was interrupted by Ctrl-C. I did not find any warning for this case in threading module docs, so I assume this is legal. The full test script is attached, but the essential code is: def work(t): sleep(t) twork = 3; twait = 4 t = Thread(target=work, args=(twork,)) try: t.start() t.join(twait) # here I do Ctrl-C except KeyboardInterrupt: pass t.join() # this hangs if twork < twait I can observe the following reproduce sequence: 1. start another thread that sleeps (or works) for T seconds 2. join that thread with timeout longer than T 3. before thread finishes and join returns, hit Ctrl-C to raise KeyboardInterrupt (KI) 4. after T seconds, thread finishes its (Python) code and KI is raised 5. Process Explorer confirms that thread really terminates (looked at .ident()) 6. thread still reports .is_alive() == True 7. second attempt to join that thread hangs indefinitely I tried replacing try-except clause with custom signal handler for SIGINT, as shown in the script. If the handler does not raise an exception, the thread can be normally joined. If it does, however, the behavior is the same as with default handler. My _guess_ is that the exception prevents some finishing code that puts Thread into proper stopped state after its target completes. Running Python 3.4.0 on Windows 7 x64 -- components: Library (Lib) files: join.py messages: 221180 nosy: tupl priority: normal severity: normal status: open title: KeyboardInterrupt during Thread.join hangs that Thread versions: Python 3.4 Added file: http://bugs.python.org/file35715/join.py ___ Python tracker <http://bugs.python.org/issue21822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper
Steve added the comment:
I just noticed that this is reporducible consistently with the python
requests[1] module, if you route your request through a proxy. I was wondering
whether I should report this as a 'requests' bug or would this be the right
place to add a 'me too' ? Here's the reporducer:
[steve@localhost ~/venvs]$ mkdir requests_bug
[steve@localhost ~/venvs]$ cd requests_bug/
[steve@localhost ~/venvs/requests_bug]$ virtualenv .
New python executable in ./bin/python
Installing
Setuptools..done.
Installing
Pip.....done.
[steve@localhost ~/venvs/requests_bug]$ . bin/activate
(requests_bug)[steve@localhost ~/venvs/requests_bug]$ pip install requests
Downloading/unpacking requests
Downloading requests-2.2.0.tar.gz (421kB): 421kB downloaded
Running setup.py egg_info for package requests
Installing collected packages: requests
Running setup.py install for requests
Successfully installed requests
Cleaning up...
(requests_bug)[steve@localhost ~/venvs/requests_bug]$ python
Python 2.7.5 (default, Nov 12 2013, 16:18:42)
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
You've got color, tab completion and pretty-printing. History will be saved
in /home/steve/.pyhistory when you exit.
Typing '\e' will open your $EDITOR with the last executed statement
>>> import requests
>>> requests.get('https://www.google.com/', verify=False)
>>> requests.get('https://www.google.com/', verify=False,
>>> proxies={'https':'https://192.168.117.157:443'})
Traceback (most recent call last):
File "", line 1, in
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/api.py",
line 55, in get
return request('get', url, **kwargs)
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/api.py",
line 44, in request
return session.request(method=method, url=url, **kwargs)
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/sessions.py",
line 383, in request
resp = self.send(prep, **send_kwargs)
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/sessions.py",
line 486, in send
r = adapter.send(request, **kwargs)
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/adapters.py",
line 334, in send
timeout=timeout
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py",
line 475, in urlopen
conn = self._get_conn(timeout=pool_timeout)
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py",
line 217, in _get_conn
return conn or self._new_conn()
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py",
line 656, in _new_conn
return self._prepare_conn(conn)
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py",
line 625, in _prepare_conn
conn.connect()
File
"/home/steve/venvs/requests_bug/lib/python2.7/site-packages/requests/packages/urllib3/connection.py",
line 90, in connect
self._tunnel()
File "/usr/lib64/python2.7/httplib.py", line 759, in _tunnel
line = response.fp.readline(_MAXLINE + 1)
TypeError: readline() takes exactly 1 argument (2 given)
>>>
cheers,
- steve
[1] requests-2.2.0
--
nosy: +lonetwin
___
Python tracker
<http://bugs.python.org/issue17849>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations
New submission from Steve: If you change the sys.ps1 to have some color, you end up messing up readline's input line calculations and the characters in the line you are typing might not get displayed properly. This behaviour is easier to demonstrate/reporduce than explain ...: On a python promt with readline enabled (for instance, on any linux box): [steve@localhost ~]$ python Python 2.7.5 (default, Nov 12 2013, 16:18:42) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.ps1 = '\033[31m>>> \033[0m' >>> # doing a reverse-i-search (Ctrl+r) on the next line will mess up the >>> prompt display ... >>> h)`sys': sys.ps1 = '\033[31m>>> \033[0m' (...press Ctrl-L to clear...) (reverse-i-search)`': (press enter) >>> arch)`': I did some (amateur) investigation and the root cause might be similar to what's reported at: http://trac.haskell.org/haskeline/ticket/78 https://groups.google.com/forum/#!topic/gnu.bash.bug/5P0gWzzLVOU FWIW, I bumped into this issue while customizing my .pythonrc[1] and although it might be a silly small annoyance, it would be really nice if this bug could be fixed. [1] https://gist.github.com/lonetwin/5902720 -- components: Library (Lib) messages: 208890 nosy: lonetwin priority: normal severity: normal status: open title: Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations type: behavior versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue20359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations
Steve added the comment: wow, that was super quick ! Yes, indeed. Surrounding the escape sequences with '\0x1' & '\0x2' fixes this issue. Thanks ! -- ___ Python tracker <http://bugs.python.org/issue20359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations
Steve added the comment: ...of course I meant \x01 and \x02, like you suggested -- ___ Python tracker <http://bugs.python.org/issue20359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations
Steve added the comment: Although surrounding the escapes with \x01 and \x02 worked to correctly remove the message while doing a reverse-i-search (thus preserving the original line), the input line measurement still appears to be incorrect as demonstated with the following actions: [steve@localhost ~]$ python Python 2.7.5 (default, Nov 12 2013, 16:18:42) [GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.ps1 = '\x01\033[32m>>> \033[0m\x02' >>> # on the next line, press the up arrow to get this line and then backspace, >>> over the entire prompt ... #<-- backspaced up until here ... ...again, not a big deal, just annoying when deleting word with a repeated 'alt+backspace' or ctrl+w -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue20359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20359] Having escape sequences (like color codes) in the sys.ps1 messes up readline's input line calculations
Steve added the comment: Hi Georg, Thanks again for the responses and your help. After a bit of research, I discovered the /reasons/ behind needing the \001 and \002 escapes. Thought I'd log the links here for posterity sake: - To color something in on a color capable terminal console you just need to use the "\033[m" escape sequence. This would be sufficient[1] - However readline messes up the line width calculation because it measures the escape sequences as a characters too. To avoid this you have to wrap the escape sequences within \001 and \002.[2] - On some terminal applications (like the one I am using - terminator[3]), if you add the \001 and \002 escapes to color text which is *not* interpreted by readline, (for instance if you have a single function to color text and you want to use it to color both your sys.ps1 and output text), the \001 and \002 codes will get printed out using a representation (like a unicode 'box'[4]). So, one would have to workaround that in the text coloring function. [1] http://en.wikipedia.org/wiki/ANSI_escape_code#Colors [2] bugs.python.org/issue17337/ and http://stackoverflow.com/questions/9468435/look-how-to-fix-column-calculation-in-python-readline-if-use-color-prompt [3] http://gnometerminator.blogspot.sg/p/introduction.html [4] http://en.wikipedia.org/wiki/Control_character#Display -- ___ Python tracker <http://bugs.python.org/issue20359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7479] os.lchmod is not present
New submission from steve : Reason for opening this bug: I am opening a bug because the documentation here: http://docs.python.org/library/os.html#os.lchmod Says that in python 2.6 there is a method os.lchmod() for changing the permissions of unix symbolic links, I am running Python 2.6 on several flavors of Linux, and non of them have os.lchmod(). My understanding is that one can not change the permissions of a sybolic link on Linux because the symlink basically 'inherits' the permissions of the file if points to. Is this ment to be used on other flavors of UNIX other than Linux? I am only really familiar with Linux, and have not played with man y other flavors on UNIX. Can other flavor change the permission of symbolic links? What I am Looking for from this bug report: === I would like to know what is happening with os.lchmod. If it is not suppose to be there, I would like it removed from the documentation. If it is mena for other flavors of unix, but not linux. I think it should be implemented as just a function that passes. Let me know what you think. Peace, Steve -- assignee: georg.brandl components: Documentation messages: 96249 nosy: bluegeek, georg.brandl severity: normal status: open title: os.lchmod is not present type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7479> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7479] os.lchmod is not present
steve added the comment: Thank you for you explanation of os.lchmod() Adding a note to the documentation would be very useful. I did search the internet for an answer before posting the bug, and I was only able to find forum posts of other people having the same issue. Thank you again, peace; Steve, -- ___ Python tracker <http://bugs.python.org/issue7479> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11176] give more meaningful argument names in argparse documentation
Steve added the comment: I came here to file a bug against the argparse documentation because reading through the documentation I didn't realize a good usecase for the `epilog` argument to the `ArgumentParser()` class until I started noticing that some commandline tools end with examples of usage. I found this bug and so thought it would be better to just leave a comment here instead. I glaced through the submitted patches and noticed that the pizza making example has `epilog="Remember: select a good combination to ensure maximum tastiness` ...which while good, still might not immediately convey the usefulness of the epilog parameter (just IMHO). I think, the example would be better served by something like: >>> pizza_parser = argparse.ArgumentParser( ... description='Make a pizza out of ingredients and toppings', ... epilog="""Examples: Create a Python Lovers pizza using the command:: ... ./makepizz.py spam ham eggs ... """) Of course this example would then also require passing a formatter_class argument to handle the wrapping ...but in essence the point of my comment is that the examples might be more useful if a 'real-world' usage is demonstrated. -- nosy: +lonetwin ___ Python tracker <http://bugs.python.org/issue11176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached
New submission from steve: I down loaded and tried to install version 3.4.2 on a Windows 7 64 bit system. 2 error messages came up saying that I had to stop two Windows systems tasks to allow the install to complete. Please see the attached screen print for details. What can I do to resolve this install problem ??? -- components: Windows files: Python_install-error-mgg.png messages: 234193 nosy: 20scanman, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached versions: Python 3.4 Added file: http://bugs.python.org/file37747/Python_install-error-mgg.png ___ Python tracker <http://bugs.python.org/issue23258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23258] Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached
steve added the comment: Thanks I killed the Intel task and the Python install worked without problems. There is almost no information on the web about what these Intel tasks do which made the Python install a little scary. Minor warning messages sometimes mask big problems. I'm amazed how comprehensive the Python programming language is. On Sat, Jan 17, 2015 at 3:39 PM, Steve Dower wrote: > > Steve Dower added the comment: > > You can close those applications, or ignore the message and continue, just > like the dialog says (if you ignore it, you may need to reboot for > installation to complete). You could also try doing a Just for Me > installation. > > Python is not trying to update those programs, which means those programs > are blocking Python. You should look for their documentation on how to > close them, or report this as a problem to them. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue23258> > ___ > -- title: Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached -> Cannot Install Python 3.4.2 on Windows 7 64 bit / screen print attached ___ Python tracker <http://bugs.python.org/issue23258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15443] datetime module has no support for nanoseconds
Steve added the comment: Hi, This issue is causing my organization problems. We are using python 2.7.9 with pyodbc 3.0.7 The application DB is SQL Server and they have started using Datetime2 (see: https://msdn.microsoft.com/en-us/library/bb677335.aspx?f=255&MSPPError=-2147217396) They did this to ensure that transactions timestamps are more unique, specially when data is bulk uploaded into the DB. Datetime2 supports to seven places. Our application is now getting timestamps that are truncated to 6 places, making them useless when comparing a timestamp >= to others in the db. This is a real world issue and we really need a fix. We are not able to migrate at the moment to python 3 due to other constraints. Any chance someone can take Matthieu's patch and retro fit it to 2.7.9 (if that makes sense)? -- nosy: +scoobydoo ___ Python tracker <http://bugs.python.org/issue15443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15443] datetime module has no support for nanoseconds
Steve added the comment: Although I don't know what I am doing (patching python), if someone could point me to the relevant files in 2.7.9 that need to be patched, I'm willing to see if I can do it. -- ___ Python tracker <http://bugs.python.org/issue15443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45582] Rewrite getpath.c in Python
Steve Dower added the comment: New changeset 3f398a77d37b5dfd51dabbc362d482a482fa885a by neonene in branch 'main': bpo-45582: Fix test_embed failure during a PGO build on Windows (GH-30014) https://github.com/python/cpython/commit/3f398a77d37b5dfd51dabbc362d482a482fa885a -- ___ Python tracker <https://bugs.python.org/issue45582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: I'm going to need a decent amount of time to learn all of these components, because I never use this OS, Tox, nor virtualenv :) I'll try and get to it, but don't hold your breath. Luckily, Modules/getpath.py is much easier to follow and modify than the old systems. If there's a pyvenv.cfg involved, base_executable should be calculated based on the "home" key in it. Previously, I don't think we calculated it at all on Linux - it was just sys.executable before site.py changes anything. On Windows, it was always intended to be "the executable that new venvs should be created with" so that venvs created from venvs would be based off the same install, rather than trying to chain. I have no idea what the correct path for that is in this context, so could do with some help. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43749] venv module does not copy the correct python exe
Steve Dower added the comment: We'd also need to update the launcher to launch the executable with its name, which it currently doesn't do. I was looking at this recently for some other reason. -- ___ Python tracker <https://bugs.python.org/issue43749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46048] embeddable distro cannot import modules
New submission from Steve Dower : The embeddable distro cannot import native modules. This is because the '.' entry in the ._pth file is incorrect parsed by the new getpath module (issue45582). -- assignee: steve.dower components: Interpreter Core messages: 408300 nosy: lukasz.langa, steve.dower priority: normal severity: normal stage: needs patch status: open title: embeddable distro cannot import modules type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46048] embeddable distro cannot import modules
Change by Steve Dower : -- keywords: +patch pull_requests: +28273 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30048 ___ Python tracker <https://bugs.python.org/issue46048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46048] embeddable distro cannot import modules
Steve Dower added the comment: New changeset 971ece8e1738b1107dda692cc44c6d8ddce384cd by Steve Dower in branch 'main': bpo-46048: Fix parsing of single character lines in getpath readlines() (GH-30048) https://github.com/python/cpython/commit/971ece8e1738b1107dda692cc44c6d8ddce384cd -- ___ Python tracker <https://bugs.python.org/issue46048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46048] embeddable distro cannot import modules
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46049] ._pth files untested on Linux
New submission from Steve Dower : Currently ._pth files are "enabled" for all platforms, but are only tested on Windows. Extend the tests in test_site to work on all platforms. -- assignee: steve.dower components: Interpreter Core messages: 408304 nosy: steve.dower priority: normal severity: normal stage: patch review status: open title: ._pth files untested on Linux type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46049] ._pth files untested on Linux
Change by Steve Dower : -- keywords: +patch pull_requests: +28276 pull_request: https://github.com/python/cpython/pull/30051 ___ Python tracker <https://bugs.python.org/issue46049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46049] ._pth files untested on Linux
Steve Dower added the comment: New changeset bfc59ed0a00106f5ba4a32a0c5b3dbe71d12665d by Steve Dower in branch 'main': bpo-46049: Fixes ._pth support on non-Windows (GH-30051) https://github.com/python/cpython/commit/bfc59ed0a00106f5ba4a32a0c5b3dbe71d12665d -- ___ Python tracker <https://bugs.python.org/issue46049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46049] ._pth files untested on Linux
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: What's the contents of the pyvenv.cfg in these cases? It looks like the first case is definitely wrong, because the base executable should not be in "venv_a2" (that's sys.executable), but I don't know where it should be on your system. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: > $ cat venv_a3/pyvenv.cfg > home = /home/ss/.pyenv/versions/3.11.0a3/bin > $ venv_a3/bin/python -c "import sys,os.path; print(e := > sys._base_executable); print(os.path.exists(e))" > /home/ss/.pyenv/versions/3.11.0a3/bin/python > True This is the intended behaviour, and yes it's changed from previous versions (but not on Windows, where it was always correct). The previous value was incorrect, hence it was marked as an internal field. If your venv doesn't have a "python" binary in the directory set as "home" in pyvenv.cfg (which by definition, according to Lib/venv/__init__.py, is dirname(sys.executable) ), then there's some other issue with venv on your platform. -- nosy: +vinay.sajip ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: I'm downgrading this from release blocker. If Vinay thinks there's a venv-related release blocker here he's welcome to raise the priority again, but I only see an intentional change to an internal value. Tools relying on internal fields will have to adapt for 3.11. -- priority: release blocker -> normal ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46056] Cannot use virtual environment on Windows 10 in corporate security settings
Steve Dower added the comment: If you execute "python -m venv --without-pip ..." to create, then as a workaround you can set the __PYVENV_LAUNCHER__ environment variable to the full path to the venv's python.exe and run the normal python3.10.exe. As Eryk mentioned, you'll need to run everything through "-m" instead of the script wrappers that pip would install. This includes "-m ensurepip", which should be able to install pip into the venv normally. Note that this is an undocumented/unsupported environment variable, and so it may change in later releases. But it should work fine throughout 3.10's lifetime (and it hasn't changed _yet_ in 3.11). -- ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46056] Cannot use virtual environment on Windows 10 in corporate security settings
Steve Dower added the comment: Also, if you see people discussing PEP 582, you might want to throw in a vote of support. It is intended to provide the benefits of a venv without needing to do tricks like we do for the current design, but it keeps being rejected for "not being sufficiently useful". Seems like in your case it would be very useful. That might help sway some of the opponents. -- ___ Python tracker <https://bugs.python.org/issue46056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14484] missing return in win32_kill?
Steve Dower added the comment: > Windows should have its own specific function. Either that or mimic it properly. Having a single function that requires different parameters based on OS is a very user-hostile design. If someone wants to shepherd it through the process, I'd support either making the typical POSIX values do sensible equivalents on Windows (as best possible), or adding a new function entirely and deprecating all use of the current one on Windows. Those are the only ways to lead people into writing code that works well on all platforms. (My *real* preference is that people stop trying to kill applications ;) and try to set up a safe communication channel instead, but I know it's often unavoidable. Having common parameters that do the Right Things on all platforms is next best.) -- ___ Python tracker <https://bugs.python.org/issue14484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: Is sys._base_executable correct without a venv? It should be the same as sys.executable in that case. venv calculates 'home' here: Lib/venv/__init__.py#L117 executable = sys._base_executable dirname, exename = os.path.split(os.path.abspath(executable)) context.executable = executable # not relevant to this bug context.python_dir = dirname# written as "home = ..." If the path doesn't exist later on, it's because it didn't exist in the first place. *That* could be the real bug. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: > But the value as it's calculated now seems to give a file that doesn't exist > - how can that be correct? Because we never actually use the executable referenced by the 'home' path in a pyvenv.cfg. It's only used as a starting point to locate a couple of entries in sys.path. So if the executable isn't there, it's no big deal. It shouldn't even matter in the nested-creation case, because we still don't execute it then. It's just how we end up with the same value for 'home' in any venvs created within a venv. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: > Because we never actually use the executable referenced by the 'home' path in > a pyvenv.cfg. This is actually not true on Windows or (I believe) some situations on macOS, where we need to use a redirecting launcher to actually launch the binary specified in this value. But on POSIX, because all the references are hardcoded in the binary, we can just copy the original around and it never loses track of its real home and never has to launch its original copy. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: > $ v311/bin/python -m venv 311-nested > Error: [Errno 2] No such file or directory: > '/private/tmp/bpo-46028/311-nested/bin/python' I assume /private/tmp/bpo-46028/311-nested/bin/python3.11 exists though? Probably that's the issue here - I don't know how else to get the real executable *name* other than copying from argv[0], and it isn't supposed to be necessary. You also have v311/bin/python3.11, right? If you use that one, does it work? I'm trying to narrow down where the base executable is actually being launched and why. -- title: 3.11.0a3: sys._base_executable is wrong, breaks venv - it wasn't under 3.11.0a2 -> 3.11.0a3: under tox, sys._base_executable is wrong ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: Or possibly that error is coming from the attempt to copy it? And since both executable and base_executable don't have the 3/3.x suffix, the copy is failing because the "real" binary does have the suffix. This could be corrected in getpath.py with a platform-specific quirk that searches for suffixed binaries for base_executable, but for performance reasons I think we'd prefer to have that check in venv so that it doesn't impact every single launch of CPython. The actual binary could also be added to pyvenv.cfg as another value - parsing that out in getpath.py is now considerably easier for someone to add than it used to be. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: Does the first venv's 'python' link to python3[.11]? If so, maybe _base_executable should be based on real_executable's filename rather than executable (that is, *after* resolving symlinks rather than before). I don't *think* that will cause any issues, and it shouldn't be any more expensive to compute. Only has to change for when a pyvenv.cfg is detected I think. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Change by Steve Dower : -- pull_requests: +28361 pull_request: https://github.com/python/cpython/pull/30143 ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Steve Dower added the comment: I posted a PR that shells out to the find_python script and captures its output to use during VS builds. Theoretically, this could save us from running it in build.bat, but I like having the detection and messages up front rather than buried deep in the build logs. -- ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Steve Dower added the comment: On Windows we automatically download a runtime if you don't have one, so this isn't such a big deal. You *do* need an internet connection to do this, of course, but that's the case for most of our external dependencies already. Plus I don't think we're even building the bootstrap interpreter on Windows yet? -- ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Change by Steve Dower : -- keywords: +patch pull_requests: +28362 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30144 ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: This PR *might* be a fix, but I think it's only partial. It isn't going to work if you've made a venv and copied "python3"->"python", for example. It still might be best solved by writing base_executable into pyvenv.cfg, and then simply reading it out. -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40915] multiple problems with mmap.resize() in Windows
Steve Dower added the comment: New changeset 6214caafbe66e34e84c1809abf0b7aab6791956b by neonene in branch 'main': bpo-40915: Avoid compiler warnings by fixing mmapmodule conversion from LARGE_INTEGER to Py_ssize_t (GH-30175) https://github.com/python/cpython/commit/6214caafbe66e34e84c1809abf0b7aab6791956b -- ___ Python tracker <https://bugs.python.org/issue40915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Steve Dower added the comment: New changeset 6fc91daf730c60b08b4b32cdce28ff26505a0622 by Steve Dower in branch 'main': bpo-46088: Automatically detect or install bootstrap Python runtime when building from Visual Studio (GH-30143) https://github.com/python/cpython/commit/6fc91daf730c60b08b4b32cdce28ff26505a0622 -- ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46088] Build hangs under Visual Studio in deepfreeze stage
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46088> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46106] OpenSSL 1.1.1m is now available
Steve Dower added the comment: Are we going to have to rush security releases for this one? Or can it wait (for me) until Monday? -- ___ Python tracker <https://bugs.python.org/issue46106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46123] _freeze_module on Windows can be built faster with no optimization
Steve Dower added the comment: New changeset 0b582a4a1b24472a35ed7fc973728ac9d595f123 by neonene in branch 'main': bpo-46123: Disable optimizations for _freeze_module.exe on MSVC for faster building (GH-30181) https://github.com/python/cpython/commit/0b582a4a1b24472a35ed7fc973728ac9d595f123 -- ___ Python tracker <https://bugs.python.org/issue46123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46123] _freeze_module on Windows can be built faster with no optimization
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46106] OpenSSL 1.1.1m is now available
Steve Dower added the comment: I've put up the builds for 1.1.1m (and double checked everything after last time - it's definitely "m" :) ), so anyone can do the PR to change Python itself. Otherwise I'll probably get time this week. -- ___ Python tracker <https://bugs.python.org/issue46106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46171] venv module produces spurious warning that location has moved
Steve Dower added the comment: There are plenty of other ways to get a venv through a potentially unexpected path (turns out I've been doing one for years), which is why I went with the general warning rather than limiting it to specific behaviours that are subject to change outside of our control. I'm not opposed to strengthening this check to ignore DOS encoded names, but I think it should remain for anything where the realised executable path isn't the same as what you'd assume from the requested path. Without being very aware of how your directories are all configured, it could be near impossible to diagnose, so the warning in the command-line tool is appropriate. -- nosy: +vinay.sajip ___ Python tracker <https://bugs.python.org/issue46171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46177] can't install launcher for all users
Steve Dower added the comment: This normally happens because you've already installed the launcher "just for me". You can't change that setting later. Open Add/Remove Programs and uninstall the Python Launcher first. Then you should be able to reinstall it for all users. -- ___ Python tracker <https://bugs.python.org/issue46177> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+
Steve Dower added the comment: Yep, it's a bug and should be fixed. I'm still not back coding yet, but I'll get to it once I am if nobody else gets there first. This is going to affect getpath.py in the native implementation, so it ought to be fixed there (and we need tests for this case, since it's apparently a gap). -- priority: normal -> release blocker ___ Python tracker <https://bugs.python.org/issue46208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46171] venv module produces spurious warning that location has moved
Steve Dower added the comment: My VHDX mounted in a directory is affected by this, and actually broke a couple of tools until I also mounted it as a drive. (Using a VHDX helps bypass a lot of filesystem related perf impacts on Windows, so it's worth the occasional broken tool.) I suspect (but haven't tested) that some file sharing handlers or attached devices could also hit it - thinking here of IoT devices that provide a filesystem-like interface. Either way, I don't think the warning is spurious, and while it's not particularly helpful for people who pass in 8.3 names that are then expanded (it shouldn't ever happen the other way), that's easily fixed on the user's side. (And tempfile, which clearly needs fixing.) I'm also *strongly against* warnings/errors that only occur based on a decision you made ages ago (or that someone else made for you), such as how you installed Python. Right now we have a warning that can be explained in exactly the same way on every platform and every circumstance, but Eryk's proposal/preference would suddenly make the case for the warning way too complex. Tutorials and teachers don't get to ignore it just because it only happens to some of their readers/students, and so we only make things worse for them by making it harder to understand. Better to have a simple, consistent message in this case. -- ___ Python tracker <https://bugs.python.org/issue46171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46226] User specific paths added to System PATH environment variable
Steve Dower added the comment: If you have them, can you share your install logs (look in %TEMP% for files starting with "Python"). If not, please share your install options. By default, this works fine. You have to make some specific modifications to the install options to do what you've done, such as choosing to install for all users and then overriding the install path to a per-user location. If you're installing just for yourself, the installer shouldn't even have the permissions required to modify system-wide environment variables. It's also possible that your machine has a special configuration to do this, in which case you'll need to speak with your administrator to find out why. We can't help with that - we just use standard MSIs and let the OS choose where things go. -- ___ Python tracker <https://bugs.python.org/issue46226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46217] 3.11 build failure on Win10: new _freeze_module changes?
Steve Dower added the comment: Good catch. We still support 8.1 for this release, so that flag will have to be taken out (and hopefully people won't be impacted by long path names here). -- ___ Python tracker <https://bugs.python.org/issue46217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+
Steve Dower added the comment: I'm happy with PR 30362 now - any other comments before we merge? -- ___ Python tracker <https://bugs.python.org/issue46208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+
Steve Dower added the comment: New changeset 9c5fa9c97c5c5336e60e4ae7a2e6e3f67acedfc7 by neonene in branch 'main': bpo-46208: Fix normalization of relative paths in _Py_normpath()/os.path.normpath (GH-30362) https://github.com/python/cpython/commit/9c5fa9c97c5c5336e60e4ae7a2e6e3f67acedfc7 -- ___ Python tracker <https://bugs.python.org/issue46208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46208] os.path.normpath change between 3.11.0a2 and 3.11.0a3+
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46287] UNC path normalisation issues on Windows
New submission from Steve Dower :
Taken from https://github.com/python/cpython/pull/30362#issuecomment-1006840632
For Windows, should there be tests for invalid UNC paths such as "//", "//..",
"//../..", "//../../..", "//server", "//server/..", and "//server/../.."? This
will help to ensure that future changes never allow an invalid path to be
normalized as a valid path.
Also, it's not a major problem that should prevent merging, but the way
repeated slashes are handled prior to the second component of a UNC path is
less than ideal:
>>> os.path.normpath('//spam///eggs')
'spameggs'
>>> os.path.normpath('//spam///eggs/..')
'spam'
This case isn't a valid UNC share, since it's just "//spam", without a share
component. However, the repeated slashes start the filepath part and should be
reduced to a single backslash. That's what the GetFullPathNameW() call does in
abspath():
>>> os.path.abspath('//spam///eggs')
'spam\\eggs'
>>> os.path.abspath('//spam///eggs/..')
'spam\\'
--
components: Windows
messages: 409903
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: UNC path normalisation issues on Windows
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46287>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46287] UNC path normalisation issues on Windows
Steve Dower added the comment:
My replies to Eryk's comment copied above:
Yes, always more tests :)
The behaviour of normpath has always been weird and/or incorrect around invalid
UNC paths.
For example, on 3.10, normpath("//spam///eggs/..") --> "spam". Originally,
the path was a file path (albeit with an invalid empty share name), and the
final path is just a machine name.
Currently on 3.11, normpath("//spam///eggs/..") --> "spam". This
doesn't match GetFullPathNameW, but at least it leaves the end of the path as a
file (with an empty share name).
I don't think it's necessarily obvious which is correct, though matching
GetFullPathNameW is certainly the easiest rule for us to use. Matching previous
Python versions is also reasonable, though given the input is invalid for its
domain we don't really have any obligation to preserve the result.
--
___
Python tracker
<https://bugs.python.org/issue46287>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Steve Dower added the comment: Are we enabling the build option they mention on the release page? Or is this only going to affect users who use the pragma? We should obviously do the upgrade, but that will determine how aggressively we ought to be messaging the issue. -- ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Steve Dower added the comment: We should definitely upgrade, but we probably don't have to trigger a fresh release of all branches for it, or make a big fuss about it being a special fix. That's all I was trying to establish. -- ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46217] 3.11 build failure on Win10: new _freeze_module changes?
Steve Dower added the comment: Only a newer WinSDK, which is not in any way a significant change to the resulting build and so isn't part of the "spec" as it were. But we'll remove the use of this flag once someone has the time to make a PR. (Remember to add the RM when you declare something a release blocker or the release may not be blocked.) -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue46217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45925] Upgrade macOS and Windows installers to use SQLite 3.37.2
Steve Dower added the comment: > Can you update the sources repo in the mean time? Done -- ___ Python tracker <https://bugs.python.org/issue45925> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry
Steve Dower added the comment: New changeset c9dc1f491e8edb0bc433cde73190a3015d226891 by Daniel in branch 'main': bpo-46297: Fix interpreter crash on startup with multiple PythonPaths set in registry (GH-30466) https://github.com/python/cpython/commit/c9dc1f491e8edb0bc433cde73190a3015d226891 -- ___ Python tracker <https://bugs.python.org/issue46297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry
Steve Dower added the comment: Thanks for the report and the PR! -- assignee: -> steve.dower ___ Python tracker <https://bugs.python.org/issue46297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46297] Python interpreter crashes on bootup with multiple PythonPaths set in registry
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46217] 3.11 build failure on Win10: new _freeze_module changes?
Change by Steve Dower : -- keywords: +patch pull_requests: +28676 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/30473 ___ Python tracker <https://bugs.python.org/issue46217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46217] 3.11 build failure on Win10: new _freeze_module changes?
Steve Dower added the comment: New changeset d81182b8ec3b1593daf241d44757a9fa68fd14cc by Steve Dower in branch 'main': bpo-46217: Revert use of Windows constant that is newer than what we support (GH-30473) https://github.com/python/cpython/commit/d81182b8ec3b1593daf241d44757a9fa68fd14cc -- ___ Python tracker <https://bugs.python.org/issue46217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46217] 3.11 build failure on Win10: new _freeze_module changes?
Change by Steve Dower : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41534] argparse : allow_abbrev behavior between 3.7 and 3.8
Steve Fox added the comment: Fundamentally the use of allow_abbrev=False is now broken (it is allowing abbreviations when already explicitly told not to) The use of a single - for all options is much older than -- and exists in my unix utilities and many programs have been written to follow this convention, these are now broken in 3.8+ "Changed in version 3.8: In previous versions, allow_abbrev also disabled grouping of short flags such as -vv to mean -v -v" Does not accurately describe the behavior change, it is more broadly injecting abbreviations when already told not to. -- nosy: +Fox214 ___ Python tracker <https://bugs.python.org/issue41534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46226] User specific paths added to System PATH environment variable
Steve Dower added the comment: Without logs or the ability to reproduce it, there's not much we can do. I ran the install and it put the variables in the right place, so it's not happening all the time. The install logs are usually detailed enough to see why decisions like this are made, but it'll almost certainly be because of something specific to your machine. If running the install again produces the same result, those logs will be helpful as well. I don't see us being able to make any product changes for this though. -- ___ Python tracker <https://bugs.python.org/issue46226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33125] Windows 10 ARM64 platform support
Steve Dower added the comment: Hi Tommy! Glad to have you join the discussion (I'm a huge fan of OBS Studio, and if the license wasn't incompatible with my employer, I'd be actively contributing :) ) Our challenge with the installer is the portability of Wix Toolset. I'm pretty sure our current version doesn't support ARM64, and they haven't released a newer version that does yet. It's possible that emulation will handle the main part of our installer, but AFAIK nobody has tested it to see whether it confuses the underlying installer service. (I can probably do that at some point, as I have access to some test machines now.) At the same time, any reason why OBS doesn't just include a copy of Python with it? It should be quite easy to include the embeddable runtime on Windows, which would then mean that you're able to ship the exact version necessary and have the paths preconfigured. (It *might* complicate installing 3rd party packages a bit, but you can always allow search paths to be set/PYTHONPATH to be respected, or the executable path overridden.) Possibly this is something you guys have already looked into, so if you know there's an issue I'd love to hear about it. Making it easy/easier to bundle Python with apps like OBS is one of my major focuses. -- ___ Python tracker <https://bugs.python.org/issue33125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46346] New compilation warnings on Windows
Steve Dower added the comment: Possibly related to Victor's change in issue46303? -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue46346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33125] Windows 10 ARM64 platform support
Steve Dower added the comment: PEP 514 is the way to find it on Windows (you should be able to look directly for your supported version, rather than enumerating to search). As far as I know, the best way to find it on macOS and Linux is to search PATH for "python3.X". Appreciate the size concerns. The Python runtime comes down to about 10MB with some basic tricks (already done on Windows in the embeddable distro), such as excluding the docs, test suite and zipping the standard library. It's possible with different tricks to do the same on other platforms, so you may even find the best balance for yourselves and your users is to repackage those and do a download-on-demand, rather than looking for a system installed Python. > as an installer, it should be the most forgotten part of python that usually > runs for once or twice. Oh I wish this were the case! Installers should be forgotten, but they need to be 100% reliable or people *really* notice :) But updating the installer build to target ARM64 while generating an x86 executable should be possible, it just hasn't been done yet. -- ___ Python tracker <https://bugs.python.org/issue33125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46303] _Py_stat and _Py_wstat using incorrect type for status argument
Steve Dower added the comment: > Microsoft provides stat and struct stat, but they prepend the names with an > underscore. They are also influenced by various compiler options to choose between 32-bit and 64-bit fields. This makes it impossible to use the standard names as part of an ABI, because we can't/don't enforce that the preprocessor definitions match. We should isolate all structures from libc/equivalent in our public API so that we can ensure compatibility. (FILE* was historically also an issue, but that was bad enough that Windows fixed it on their side. The rest of the C runtime library still bleeds everywhere, so we definitely don't want it or its semantics in our public API if avoidable.) -- title: Building Python with clang on Windows fails on _Py_stat(): struct stat is not defined -> _Py_stat and _Py_wstat using incorrect type for status argument ___ Python tracker <https://bugs.python.org/issue46303> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46362] os.path.abspath() needs more normalization on Windows
Steve Dower added the comment: One thing to be aware of is that Windows 11 has changed the rules around these files, so here's my results with 3.10: >>> for path in paths: ... print(os.path.abspath(path)) ... C:\CON C:\PRN C:\AUX \\.\NUL C:\COM1 C:\COM2 C:\COM3 C:\COM9 C:\LPT1 C:\LPT2 C:\LPT3 C:\LPT9 C:\foo But this shouldn't be an issue with the proposed (about to be merged) change. -- ___ Python tracker <https://bugs.python.org/issue46362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46362] os.path.abspath() needs more normalization on Windows
Steve Dower added the comment: New changeset d4e64cd4b0ea431d4e371f9b0a25f6b75a069dc1 by neonene in branch 'main': bpo-46362: Ensure ntpath.abspath() uses the Windows API correctly (GH-30571) https://github.com/python/cpython/commit/d4e64cd4b0ea431d4e371f9b0a25f6b75a069dc1 -- ___ Python tracker <https://bugs.python.org/issue46362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46362] os.path.abspath() needs more normalization on Windows
Steve Dower added the comment: Thanks for the patch! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46362] os.path.abspath() needs more normalization on Windows
Steve Dower added the comment: New changeset 71c0b859ae16ee748cbb050a1f4de93c04e04f83 by neonene in branch 'main': bpo-46362: Ensure abspath() tests pass through environment variables to subprocess (GH-30595) https://github.com/python/cpython/commit/71c0b859ae16ee748cbb050a1f4de93c04e04f83 -- ___ Python tracker <https://bugs.python.org/issue46362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44934] Windows installer: Append Python to PATH instead of prepending it
Steve Dower added the comment: New changeset c47c9e6589eb7a272cfe4d352eb87389eb20ec2f by bneuburg in branch 'main': bpo-44934: Add optional feature AppendPath to Windows MSI installer (GH-27889) https://github.com/python/cpython/commit/c47c9e6589eb7a272cfe4d352eb87389eb20ec2f -- ___ Python tracker <https://bugs.python.org/issue44934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44934] Windows installer: Append Python to PATH instead of prepending it
Steve Dower added the comment: Thanks for the PR! This is a good contribution, that wasn't trivial to do. It should be in Python 3.11 alpha 5, so please test it out and make sure it's behaving as you expect. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: New changeset 7407fe4c25ba0308d49e3e88e4a107ef32251cdc by Steve Dower in branch 'main': bpo-46028: Calculate base_executable by resolving symlinks in a venv (GH-30144) https://github.com/python/cpython/commit/7407fe4c25ba0308d49e3e88e4a107ef32251cdc -- ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46028] 3.11.0a3: under tox, sys._base_executable is wrong
Steve Dower added the comment: Merged my PR, but I want to leave this open in commit review for now - I'm not sure it deals with all the issues here, and probably not everything from the Discourse thread linked by Victor (though it might come close). -- stage: patch review -> commit review ___ Python tracker <https://bugs.python.org/issue46028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46434] pdb help fails with AttributeError when using Windows embeddable package
Steve Dower added the comment: The PR looks good. I assume you've started the CLA process, so once that clears we'll be fine to merge. -- versions: -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue46434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46438] Static linking _decimal module breaks test_freeze
New submission from Steve Dower : After applying this patch on Linux, test_freeze_simple_script (test.test_tools.test_freeze.TestFreeze) fails. diff --git a/Modules/Setup b/Modules/Setup index d3647ecb99..c41bcac453 100644 --- a/Modules/Setup +++ b/Modules/Setup @@ -135,7 +135,7 @@ PYTHONPATH=$(COREPYTHONPATH) #_contextvars _contextvarsmodule.c #_csv _csv.c #_datetime _datetimemodule.c -#_decimal _decimal/_decimal.c +_decimal _decimal/_decimal.c #_heapq _heapqmodule.c #_json _json.c #_lsprof _lsprof.c rotatingtree.c The stderr from the test is below. The rest of the output looks normal to me, but most of the build output is missing. --- STDERR --- gcc: error: Modules/_decimal/libmpdec/libmpdec.a: No such file or directory make: *** [Makefile:976: app] Error 1 -- components: Build messages: 410978 nosy: steve.dower priority: normal severity: normal status: open title: Static linking _decimal module breaks test_freeze versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44673] Embedded Python - local directories in pythonXX._pth
Steve Dower added the comment: I'm afraid not. The ._pth file is intended for embedding applications that have a static set of search paths. You may want to try adding a startup file (search for PYTHONSTARTUP) that modifies sys.path directly. Or alternatively if you rename the ._pth file to a regular .pth file, it should disable the isolation protection and use the more flexible algorithm, which *I believe* will resolve relative paths against the current directory rather than where the file lives. -- nosy: +steve.dower ___ Python tracker <https://bugs.python.org/issue44673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31582] Add _pth breadcrumb to sys.path documentation
Steve Dower added the comment: Need to make this happen, and it probably needs to be me (though I'm happy to review a contribution). We now handle ._pth files on all platforms as part of the Modules/getpath.py changes (which I hinted to in my previous comment from 5 years ago ;) ). -- versions: +Python 3.11 -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46434] pdb help fails with AttributeError when using Windows embeddable package
Steve Dower added the comment: See https://github.com/python/cpython/blob/b04dfbbe4bd7071d46c8688c2263726ea31d33cd/PC/layout/main.py#L256-L289 Basically, the .pyc files in the embeddable distro have been compiled with optimize=2, which is the equivalent of -OO. So yes, docstrings (and asserts) are expected to have been removed. It shouldn't be removing docstrings from other modules that you provide yourself. -- ___ Python tracker <https://bugs.python.org/issue46434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46434] pdb help fails with AttributeError when using Windows embeddable package
Steve Dower added the comment: > the existing check in `do_help` didn't catch this case because > https://docs.python.org/3/library/sys.html#sys.flags only reflects command > line flags, rather than whether or not it was actually optimised. Precisely. Your check is much more appropriate for what the actual issue is going to be, though keeping the existing check there means we can provide a more specific error message when we *know* that the user deliberately chose that behaviour. -- ___ Python tracker <https://bugs.python.org/issue46434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46427] Correct MSBuild's configuration for _freeze_module.exe
Steve Dower added the comment: This configuration is intentional. When cross-compiling, tools that are executed as part of the build need to be built for the tool platform, not the target platform. -- nosy: +steve.dower resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46427] Correct MSBuild's configuration for _freeze_module.exe
Steve Dower added the comment: Windows ARM64 devices all support x86 and x64 emulation, so while it's less than ideal performance-wise to use a non-native build for this step, it's hardly fatal. That step doesn't rely on the underlying architecture, just the current Python bytecode format (which is platform independent). Leaving the Platform blank is not acceptable. It needs to be set to the preferred tool architecture, which as it happens, is $(PreferredToolArchitecture). As I said, if you've hit a *real* issue around this, please describe it. There is no theoretical issue here, and as far as I'm aware, no practical issues either. -- ___ Python tracker <https://bugs.python.org/issue46427> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46452] Possible false detection of Windows LZMA library as a malware by Avast
Steve Dower added the comment: I don't think we've changed anything here in years, so I'd be very surprised if something new was in there. More likely somebody PyInstaller'd some malware and the scanners picked up a generic part of it as the signature. Reporting it as a false positive should let them compare against the original sample and correct it. -- ___ Python tracker <https://bugs.python.org/issue46452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
