[issue34895] Mark optional stdlib modules in documentation
New submission from Marcus : Some stdlib modules have external build time dependencies and will be automatically disabled if the dependencies can't be met (cf. detect_modules() in setup.py). >From a user's perspective there is no reason to assume that the presence of a >stdlib module may not be relied upon. See also the discussion on python-ideas >(https://mail.python.org/pipermail/python-ideas/2018-October/054008.html). A rather simple to implement debugging aid would be to add a note to the affected modules' documentation, stating that these modules may not be available on all systems. -- assignee: docs@python components: Documentation messages: 327065 nosy: docs@python, of4tvziy priority: normal severity: normal status: open title: Mark optional stdlib modules in documentation type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34895] Mark optional stdlib modules in documentation
Marcus added the comment:
My concern is that certain missing build-time dependencies do not stop the
build but trigger an easy to miss message at the end of the build stage (only).
Also the end user doesn't get to see this. At the same time these modules are
sort of expected to be part of a complete Python distribution.
Two issues I see with this: 1. By omission, the distributor might inadvertently
create an incomplete distribution. 2. The enduser, running a script (possibly
created elsewhere) receives a standard “ModuleNotFoundError” and is left in the
dark about its origin as the documentation seems to confirm that the affected
module ought to be available.
$ grep -F missing.append setup.py
missing.append('spwd')
missing.append('readline')
missing.append('_ssl')
missing.append('_hashlib')
missing.append('_sqlite3')
missing.append('_dbm')
missing.append('_gdbm')
missing.append('nis')
missing.append('_curses')
missing.append('_curses_panel')
missing.append('zlib')
missing.append('zlib')
missing.append('zlib')
missing.append('_bz2')
missing.append('_lzma')
missing.append('_elementtree')
missing.append('ossaudiodev')
missing.append('_tkinter')
missing.append('_uuid')
All modules in the above list are potentially affected, although some
(ossaudiodev, nis) might be considered platform specific. Arguably
availablility some of these modules could be perhaps turned into build-time
requirements with opt-out mechanics.
In any case a hint to the end user debugging such issues would be rather
helpful and a big timesaver (see initial report).
--
___
Python tracker
<https://bugs.python.org/issue34895>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28518] execute("begin immediate") throwing OperationalError
Changes by Marcus : -- nosy: +callidomus ___ Python tracker <http://bugs.python.org/issue28518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26784] regular expression problem at umlaut handling
New submission from Marcus:
Working with this example string "E-112233-555-11 | Bläh - Bläh" with the
following code leeds under python 2.7.10 (OSX) to an exception whereas the same
code works under python 3.5.1 (OSX).
s = "E-112233-555-11 | Bläh - Bläh"
expr = re.compile(r"(?P[A-Z]{1}-[0-9]{0,}(-[0-9]{0,}(-[0-9]{0,})?)?)?(( [|]
)?(?P[\s\w]*)?)? - (?P[\s\w]*)?",re.UNICODE)
res = re.match(expr,s)
a = (res.group('p'), res.group('a'), res.group('j'))
print(a)
When I change the first umlaut in "Bläh" from ä to ü it works as expected on
python 2 and 3. A change from ä to ö however leeds to a crash again.
Ideas?
--
messages: 263567
nosy: arbyter
priority: normal
severity: normal
status: open
title: regular expression problem at umlaut handling
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue26784>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26784] regular expression problem at umlaut handling
Marcus added the comment: Thx for your explanation. You explained why [\s\w] didn't match for "ä". In my situation it didn't matches for the first "ä" but the second time I used [\s\w] in the same regex it matched at the second "ä". What's the explanation for this? -- ___ Python tracker <http://bugs.python.org/issue26784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26784] regular expression problem at umlaut handling
Marcus added the comment: When I replace the first "ä" with a random letter the untouched expression has not problems to match the second word which contains also an "ä" s = "E-112233-555-11 | Bläh - Bläh" #untuched string s = "E-112233-555-11 | Bloh - Bläh" #string where the first ä is replaced by an "o" -- ___ Python tracker <http://bugs.python.org/issue26784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9639] urllib2's AbstractBasicAuthHandler is limited to 6 requests
New submission from Marcus Huewe : It seems that commit r81636 broke urllib2's AbstractBasicAuthHandler because the "retried" attribute isn't reset on success. Therefore it's limited to 6 requests. The attached patch should fix this problem. -- components: Library (Lib) files: urllib2-AbstractBasicAuthHandler_reset_attr.diff keywords: patch messages: 114336 nosy: mhuewe priority: normal severity: normal status: open title: urllib2's AbstractBasicAuthHandler is limited to 6 requests type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file18574/urllib2-AbstractBasicAuthHandler_reset_attr.diff ___ Python tracker <http://bugs.python.org/issue9639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11896] Save on Close fails in IDLE, from Linux system
New submission from marcus harris : Under some circumstances, which I will detail later down the note, if I click File --> Close without explicitly saving, and without running the module with Run --> Run Module , then the last changes I made to the file do not get saved. The save dialogue pop-up does appear, and I do select YES--- I want to save before closing--- but when I re-open the file (IDLE or vi) the changes are not there... as though the save binding did not work, or like there was some timing glitch that prevented the save somehow before the edit window closed down. The error is not solid, in that, if the file is larger (significantly) then the File --> Close (select Yes on the dialogue) does work... ?? The work around is to do either 1) run the module, or 2) explicitly click File --> Save. The alleged bug can be reproduced on both of my primary desk machines, Linux systems, using IDLE on 2.6, 2.7, and 3.2/ These are the instructions for reproducing this little snag: 1) Open a new edit window with File --> New Window 2) Enter the following code on the first two lines: def testfunc(): return None 3) Click File --> Save( testit.py ) 4) Click File --> Close 5) Open the file with File --> Recent Files ( select testit.py ) 6) Use the edit window to place these three lines above testfunc: # comment block ## 7) ClickFile --> Close 8) When the Save on Close dialogue appears select "Yes" 9) Re-open the file with File --> Recent Files ( select testit.py ) 10) The comment block will not be there... didn't save. Running on Ubuntu 9.10 (all updates) Tk 8.5.x reproduced on built-in 2.6 & compiled from sources... 2.7 & 3.2 kind regards, m harris -- components: IDLE, Library (Lib), Tkinter messages: 134194 nosy: marcus777, terry.reedy priority: normal severity: normal status: open title: Save on Close fails in IDLE, from Linux system type: behavior versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue11896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11896] Save on Close fails in IDLE, from Linux system
marcus harris added the comment: Terry Reedy was not able to reproduce this snag on an XP system; however, suggested there might be a real save on close error on the linux side... also requested to be place on the nosy list... -- ___ Python tracker <http://bugs.python.org/issue11896> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3802] smtpd.py __getaddr insufficient handling
New submission from Marcus CM <[EMAIL PROTECTED]>:
The __getaddr does not handle certain valid MAIL FROM well :
For eg,
<[EMAIL PROTECTED]> SIZE= AUTH=<>
would result in a mismatch of bracket handling.
Suggested fix is :-
def __getaddr(self, keyword, arg):
address = None
keylen = len(keyword)
if arg[:keylen].upper() == keyword:
address = arg[keylen:].strip()
if not address:
pass
# Marcus fix :
i = address.count("<")
ii = address.count(">")
if i != ii :
address = None
return address
# Marcus remark : bug if : <[EMAIL PROTECTED]> SIZE=6092 AUTH=<>
elif address[0] == '<' and address[-1] == '>' and address !
= '<>':
# Addresses can be in the form <[EMAIL PROTECTED]> but
watch out
# for null address, e.g. <>
if address.count("<") == 1 :
address = address[1:-1]
return address
--
messages: 72763
nosy: [EMAIL PROTECTED]
severity: normal
status: open
title: smtpd.py __getaddr insufficient handling
versions: Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3802>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4253] Maildir dumpmessage on
New submission from Marcus CM <[EMAIL PROTECTED]>:
When using maildir on windows, the maildir._dump_message erronously
added "\r\n" to "\r\r\n" : in mailbox.py
target.write(buffer.read().replace('\n', os.linesep))
--
components: Library (Lib)
messages: 75463
nosy: [EMAIL PROTECTED]
severity: normal
status: open
title: Maildir dumpmessage on
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4253>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17558] gdb debugging python frames in optimised interpreters
Marcus Cobden added the comment: Is there anyone who could take a look at this? I'd rather it not bit-rot into oblivion. I know the code quality is rather poor, but I can fix that. -- ___ Python tracker <http://bugs.python.org/issue17558> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15278] UnicodeDecodeError when readline in codecs.py
Marcus Gröber added the comment:
I came across this today as well. A short way of summarizing this error seems
to be:
Reading a file using readline (or "for line in file") fails, if the following
two conditions are true:
• A codec (e.g. UTF-8) for a multi-byte encoding is used, and
• The first line of the file is at least 73 bytes long, and contains a
multi-byte-sequence that starts before offset 72, and ends after offset 72
At least for UTF-8 input files, it may be possible to work around this by
opening the input file without a codec, and then applying decode("utf-8") to
each line.
--
nosy: +Marcus.Gröber
___
Python tracker
<http://bugs.python.org/issue15278>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20915] Add "pip" section to experts list in devguide
Marcus Smith added the comment: ok, add me. -- nosy: +Marcus.Smith ___ Python tracker <http://bugs.python.org/issue20915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19749] test_venv failure on AIX: 'module' object has no attribute 'O_NOFOLLOW'
Marcus Smith added the comment: There's a new PR to fix this in the pip 1.5.X branch: https://github.com/pypa/pip/pull/1344 -- nosy: +Marcus.Smith ___ Python tracker <http://bugs.python.org/issue19749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19407] PEP 453: update the "Installing Python Modules" documentation
Marcus Smith added the comment: "Legacy version". nice. btw, "http://packaging.python.org/en/latest/tutorial.html#creating-and-using-virtual-environments"; will certainly end up including "pyvenv" command examples as well. currently just mentioned in a footnote. like I mentioned on distutils-sig, I still hope to submit a patch to move critical content from the legacy pages to library/distutils.rst at some point. also, btw, maybe you can fix this page real quick? http://www.python.org/documentation/. not sure what repo/team is managing this, but it's referencing the old HHGTP. -- ___ Python tracker <http://bugs.python.org/issue19407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19407] PEP 453: update the "Installing Python Modules" documentation
Marcus Smith added the comment: about the hhgtp link, logged here: https://github.com/python/pythondotorg/issues/268 (and already fixed) also, pyvenv is more prominent now in PUG as of latest changes (see https://github.com/pypa/python-packaging-user-guide/pull/35) -- ___ Python tracker <http://bugs.python.org/issue19407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27415] BaseEventLoop.create_server does not accept port=None
New submission from Marcus Cobden: With the most recent 3.4 bugfix, calling create_server with port=None stopped working. This also affects 3.5, and I would imagine also 3.6, but haven't checked that. Test case: import asyncio; l = asyncio.get_event_loop(); l.run_until_complete(l.create_server(lambda: None, host='0.0.0.0', port=None)) Expected result: a socket object Broken result: "TypeError: an integer is required (got type NoneType)" -- components: asyncio messages: 269507 nosy: gvanrossum, haypo, mcobden, yselivanov priority: normal severity: normal status: open title: BaseEventLoop.create_server does not accept port=None versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue27415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27415] BaseEventLoop.create_server does not accept port=None
Marcus Cobden added the comment: I should add that port=0 is an acceptable workaround -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue27415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27415] regression: BaseEventLoop.create_server does not accept port=None
Changes by Marcus Cobden : -- title: BaseEventLoop.create_server does not accept port=None -> regression: BaseEventLoop.create_server does not accept port=None ___ Python tracker <http://bugs.python.org/issue27415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17558] gdb debugging python frames in optimised interpreters
New submission from Marcus Cobden: I've made some tweaks to the libpython.py util functions to better pick up python frames when using a normal python interpreter. It's not by any means perfect, but it works on my ubuntu-shipped python interpreter (with debugging symbols installed, but not running the debug interpreter). It works by finding the top frame via the thread state struct, and then going up the frame stack, comparing the stack pointer to a stack pointer in the C context. I'd appreciate some feedback/advice :) https://gist.github.com/leth/5254239/revisions -- components: Demos and Tools messages: 185337 nosy: mcobden priority: normal severity: normal status: open title: gdb debugging python frames in optimised interpreters type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17558> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27415] regression: BaseEventLoop.create_server does not accept port=None
Marcus Cobden added the comment: Still doesn't work in Python 3.4.5; I can confirm it's fixed in Python 3.5.2. -- resolution: works for me -> status: closed -> open versions: -Python 3.5 ___ Python tracker <http://bugs.python.org/issue27415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27415] regression: BaseEventLoop.create_server does not accept port=None
Marcus Cobden added the comment: Ah thanks, that's fair. It seems a shame since this regression was introduced to 3.4 by a security/bugfix release. Since there's a workaround it's not a big deal. -- ___ Python tracker <http://bugs.python.org/issue27415> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15018] Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix
New submission from Marcus von Appen : If CPython is built and installed with additional CPPFLAGS and/or LDFLAGS on a posix platform, those flags are not passed to C extension modules, leaving users (in the worst case) lost without the ability to build and install C extension modules, if the flags are important for detecting include files or linking. Example: * Python shall be built with GNU pthreads (--with-pth) * The pth libs are not installed in any default location, CPP and LD know about, but somewhere else (e.g. /usr/local/lib/pth/ and /usr/local/include/pth/) * Appropriate CPPFLAGS="-I/usr/local/include/pth" and LDFLAGS="-L/usr/local/lib/pth" are defined in the environment for the build. Python gets built and installed. Result in /wherever/pythonX.X/config/Makefile: ... OPT= BASECFLAGS= -fno-strict-aliasing CFLAGS= $(BASECFLAGS) -pipe $(OPT) $(EXTRA_CFLAGS) ... CPPFLAGS= -I. -IInclude -I$(srcdir)/Include -I/usr/local/include/pth LDFLAGS=-L/usr/local/lib/pth ... Invocation of python-config --cflags: # python-config --cflags -I/whereever/include/pythonX.X -I/whereever/include/pythonX.X -fno-strict-aliasing -pipe Invocation of python-config --ldflags: # python-config --ldflags -L/whereever/lib/pythonX.X/config -lpth -lutil -lm -lpythonX.X So far, so problematic. Since Python.h incorporates pth.h, compiling something without defining the necessary CPPFLAGS manually will fail. Same for linking. The issue is *not* limited to --with-pth, but to any CPPFLAGS/LDFLAGS settings that are necessary to get CPython to work on the target platform. One might argue that CPPFLAGS should go to CFLAGS, but that contradicts the purpose of CPPFLAGS and CFLAGS. At least for posix-alike platforms (those for which _init_posix() is called in distutils/sysconfig.py), it is necessary that both, python-config as well as the distutils internals add the appropriate CPPFLAGS. It might be argued that one should use CFLAGS instead of CPPFLAGS for such important additional flags, but what shall be done with LDFLAGS then? -- assignee: eric.araujo components: Build, Distutils, Extension Modules messages: 162405 nosy: eric.araujo, marcusva, tarek priority: normal severity: normal status: open title: Incomplete Python LDFLAGS and CPPFLAGS used for extension modules on posix type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue15018> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16283] ctypes.util.find_library does not find all DLLs anymore
New submission from Marcus von Appen: ctypes.util.find_library does not seem to be able to find certain libraries in Python3.3 on Win32 platforms anymore, if the library suffix is omitted. For some reason, os.path.isfile() in ctypes.util.find_library returns False in those cases. Please try out the attached test script. This produces the following output on a Windows 7 x64 system for me (given that a OpenAL32.dll is installed): C:\>c:\Python27-x64\python.exe ct_test.py Python build: 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll C:\>c:\Python31-x64\python.exe ct_test.py Python build: 3.1.4 (default, Jun 12 2011, 14:16:16) [MSC v.1500 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll C:\>c:\Python32-x64\python.exe ct_test.py Python build: 3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': C:\Windows\system32\OpenAL32.dll C:\>c:\Python33-x64\python.exe ct_test.py Python build: 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] Path 'C:\Windows\system32' exists in $PATH: True File 'C:\Windows\system32\OpenAL32.dll' exists: True ctypes says for 'OpenAL32.dll': C:\Windows\system32\OpenAL32.dll ctypes says for 'OpenAL32': None -- components: ctypes files: ct_test.py messages: 173315 nosy: marcusva priority: normal severity: normal status: open title: ctypes.util.find_library does not find all DLLs anymore type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file27618/ct_test.py ___ Python tracker <http://bugs.python.org/issue16283> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20397] distutils --record option does not validate existance of byte-compiled files
New submission from Marcus von Appen: Using the --record argument with distutils' install command currently assumes that all .py files can be compiled (and optimized) successfully. If this is not the case for whatever reason, you end up with invalid entries in the record list. install_lib._bytecode_filenames() should verify, if the file could be created successfully (by e.g. checking for its existence) or the util.byte_compile() function should return a value that indicates, if the byte-compiled (or optimized) file could be created, so that the subsequent call to _bytecode_filenames() receives a list with valid entries. The issue can be recreated with e.g. http://pypi.python.org/pypi/Products.PasswordResetTool, which will create invalid entries for skins/PasswordReset/pwreset_constructURL.py, which acts as template/fragment. -- components: Distutils messages: 209320 nosy: marcusva priority: normal severity: normal status: open title: distutils --record option does not validate existance of byte-compiled files type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue20397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18008] python33-3.3.2 Parser/pgen: Permission denied
Marcus von Appen added the comment: This is a FreeBSD-specific problem with the Python 3.3 port. Using pmake (BSD's make implementation) leads to random errors on either generating pgen or executing pgen. This seems to happen since Python 3.3.1 randomly and is quite hard to reproduce. Switching to GNU make seems to solve the issue, but makes me wonder, if Python (from now on) relies on GNU make. -- nosy: +marcusva status: pending -> open ___ Python tracker <http://bugs.python.org/issue18008> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46710] Install launcher for all users on the domain
New submission from Marcus Fillipe Groetares Rocha Siqueira : In Python 3.9.6 (64 bits) Windows Installer, the first page show a checkbox for "install launcher for all users (recommended)", but i'd like to now why the box is not currently allowed to check. In "customize installation" option, exist other "Install for all users" options and its not working also. I tried to install with my local admin account and with my AD Admin account as well. can somebody help me please? -- components: Windows files: Sem título.jpg messages: 412997 nosy: marcus.siqueira, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Install launcher for all users on the domain type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file50617/Sem título.jpg ___ Python tracker <https://bugs.python.org/issue46710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46710] Install launcher for all users on the domain
Marcus Fillipe Groetares Rocha Siqueira added the comment: Thanks Steve, it worked. Hava a nice day :) -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
