[issue15069] Dictionary Creation Fails with integer key
New submission from Pat :
Attempting to import pyserial. In module serialposix.py a dict declaration
starting on line 64;
baudrate_constants = {
0: 000,
50: 001,
75: 002,
110: 003, ...etc
Traceback (most recent call last):
File "", line 1, in
File "serialposix.py", line 64
50: 001,
^
SyntaxError: invalid token
MacOSX 10.6.8 32bit x86 python 3.2.3 (v3.2.3:3d0686d90f55, Apr 10 2012,
11:09:56)
--
assignee: ronaldoussoren
components: Macintosh
files: serialposix.py
messages: 162805
nosy: p...@jegcpa.com, ronaldoussoren
priority: normal
severity: normal
status: open
title: Dictionary Creation Fails with integer key
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file26007/serialposix.py
___
Python tracker
<http://bugs.python.org/issue15069>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15141] IDLE horizontal scroll bar missing (Win-XPsp3)
New submission from Pat : There is no horizontal scroll bar at the bottom of the IDLE editor window. When a program line exceeds the window area, the window has to be widened, or text has to be manually selected beyond the window to see or edit that portion of the line. No major problem, just a minor inconvenience. Even with this bug, IDLE is still a great editor. Thank you. Pat -- components: IDLE messages: 163452 nosy: NyteHawk priority: normal severity: normal status: open title: IDLE horizontal scroll bar missing (Win-XPsp3) versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15141> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1082] platform system may be Windows or Microsoft since Vista
New submission from Pat LaVarre:
SUMMARY:
'Microsoft' is the platform.system() of Vista Windows, whereas 'Windows'
was the platform.system() of XP Windows, whoops.
STEPS TO REPRODUCE & ACTUAL RESULTS:
Run 2.5.1 Python in a Vista and see:
>>> import platform
>>> platform.system()
>>>
'Microsoft'
>>>
EXPECTED RESULTS:
>>> import platform
>>> platform.system()
'Windows'
>>>
WORKAROUND:
Write new Python source code like:
if platform.system() in ('Windows', 'Microsoft'):
if not (platform.system() in ('Windows', 'Microsoft')):
in place of obsolete Python source code like:
if platform.system() == 'Windows': # Microsoft
if platform.system() != 'Windows': # Microsoft
REGRESSION/ ISOLATION:
Seen by me in an Enterprise Vista. Indexed by Google as reported by
Martin v. Löwis (loewis) circa 2007-05-29 07:11 as:
http://mail.python.org/pipermail/patches/2007-June/022947.html
...
Patches item #1726668, was opened at 2007-05-28 03:23
On Microsoft Vista platform.system() returns 'Microsoft' and
platform.release() returns 'Windows'
Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and
platform.release() returns 'XP'.
This is problem was caused by a change in the output of the "ver"
command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP
[Version 5.1.2600]' In Microsoft Vista "ver" outputted 'Microsoft
Windows [Version 6.0.6000]'. The lack of the 3rd word before version
causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system
instead of 'Microsoft Windows'. This causes uname() to return the
incorrect values. Both system() and release() call uname().
NOTES:
There is no fixing all of this?
Cross-platform scripts actually will misbehave across the large
population that is 2.5 Python in Vista unless those scripts change to
implement something like the suggested workaround, that's now an
accomplished fact.
Question: Is it better to leave this feature as is, so that everyone
eventually learns to workaround it, or is it better to fix it late now
in 2007-09, so that many people never have to learn to workaround it?
Question: Why are we screen-scraping the Ver command, instead of calling
Win kernel32.getVersionEx? And how can any code for screen-scraping the
Ver command be in doubt about whether the platform.system underneath is
'Windows'?
--
components: Windows
messages: 55561
nosy: [EMAIL PROTECTED]
severity: major
status: open
title: platform system may be Windows or Microsoft since Vista
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1082>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1082] platform system may be Windows or Microsoft since Vista
Pat LaVarre added the comment:
I recommend we reject this first draft of the python-trunk-
vistaplatform.patch.
I reason as follows ...
ACTUAL RESULTS OF 2.5.1 PLUS PATCH IN VISTA WINDOWS:
>>> import platform
>>> ...
>>> platform.uname()
('Microsoft', '[redacted]', 'Windows', '6.0.6000', '', '')
>>> platform.system()
'Windows'
>>> platform.release()
'Windows'
>>>
EXPECTED RESULTS OF 2.5.1 PLUS PATCH IN VISTA WINDOWS:
>>> import platform
>>> ...
>>> platform.uname()
('Windows', '[redacted]', 'Vista', '6.0.6000', '', '')
>>> platform.system()
'Windows'
>>> platform.release()
'Vista'
>>>
ACTUAL RESULTS OF 2.5 IN SP2 XP WINDOWS:
>>> import platform
>>> ...
>>> platform.uname()
('Windows', '[redacted]', 'XP', '5.1.2600', '', '')
>>> platform.system()
'Windows'
>>> platform.release()
'XP'
>>>
DISCUSSION:
Four thoughts:
1.
I think we meant to write { unameInfo[2] == 'Windows' } where we wrote
{ unameInfo == 'Windows' } in this patch.
2.
To run the patch I created a copy of platform.py in the same folder and
applied the patch by hand. I redacted the host names by hand and elided
the { platform = ... } source line I wrote to let me run the patch in
place of the original.
3.
I think we should substitute a different kind of patch, a patch to
correct the platform.uname rather than a patch to redefine
platform.system and platform.version.
I'd like us to hold to such cross-platform invariants as:
( platform.system() == platform.uname()[0] )
( platform.system() == platform.uname()[2] )
Out on the web I see that we have documented these invariants. I quote:
""" 14.12.1 Cross Platform
uname()
... Returns a tuple of strings (system, node, release, version,
machine, processor) identifying the underlying platform.
""" 2007-09-17 fetch of http://docs.python.org/lib/node442.html
""" near http://docs.python.org/lib/module-platform.html
4.
I don't think we can totally fix this trouble in code: we have
distributed 2.5.1 to Vista too massively already now.
Specifically, I think we should also fix the doc to admit the hereafter
frequent need for people using Python to write code such as:
if not (platform.system() in ('Microsoft', 'Windows')):
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1082>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1082] platform system may be Windows or Microsoft since Vista
Pat LaVarre added the comment:
Works for me.
I tried python-trunk-vistaplatform-v2.patch in one sample of 2006-11
RTM Vista plus 2.5.1 Python plus this patch. I quote:
>>> import platform
>>> platform.uname()
('Windows', '[redacted]', 'Vista', '6.0.6000', '', '')
>>> platform.system()
'Windows'
>>> platform.version()
'6.0.6000'
>>>
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1082>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1082] platform system may be Windows or Microsoft since Vista
Pat LaVarre added the comment:
--- USAGE:
I agree we should let people in future write:
if not platform.system('Windows'):
rather than:
if not (platform.system() in ('Microsoft', 'Windows')):
now that our people can no longer rely on Python in Vista correctly
understanding the plain human intent of such code fragments as:
if platform.system() != 'Windows':
--- DRAFT SPEC:
platform.system(name = None) returns the system name if name is None,
else returns the system name if name is a well-known alias of the
system name, else returns None.
The string 'Mac OS X' is a well-known alias for the system 'Darwin'.
The string 'Windows' is a well-known alias for the system 'Microsoft'
in 2.5.1 Python on Vista.
The system name is itself a well-known alias of the system name. For
example, 'Darwin' is a well-known alias of the 'Darwin' system that is
sold as the kernel of 'Mac OS X'.
Etc.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1082>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1082] platform system may be Windows or Microsoft since Vista
Pat LaVarre added the comment:
Thanks for the cultural education of 2.5.1 isn't supposed to work, I
didn't know that.
Also I'm glad to hear this is fixed for 2.5.2 already.
Sorry I'm too new & ignorant to understand why you believe this is
fixed. I don't see that we already have a way to say things like:
if not platform.system('Linux'):
Do we have a way to say things like that?
My first Googles, tried here now at Mac OS X, give me useless
suggestions like:
>>> platform.platform(aliased=True)
'Darwin-9.0.0b5-i386-32bit'
>>> platform.system_alias(platform.system(), platform.release(),
platform.version())
('Darwin', '9.0.0b5', 'Darwin Kernel Version 9.0.0b5: Fri Aug 17
17:24:24 PDT 2007; root:xnu-1182~1/RELEASE_I386')
>>>
Practically speaking, I was getting by ok with:
if platform.system() != 'Windows':
Until that broke in Vista plus 2.5.1.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1082>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1611] doctest.testmod gets noisy if called more than once per SystemExit
New submission from Pat LaVarre:
SUMMARY:
Calling doctest.testmod more than once before SystemExit spews stderr
messages such as "*** DocTestRunner.merge: '__main__' in both testers;
summing outcomes"
STEPS TO REPRODUCE:
$ cat tttestmod.py
import doctest
doctest.testmod() # 1
doctest.testmod() # 2
doctest.testmod() # 3
$
ACTUAL RESULTS:
$ python ./tttestmod.py
*** DocTestRunner.merge: '__main__' in both testers; summing outcomes.
*** DocTestRunner.merge: '__main__' in both testers; summing outcomes.
$
EXPECTED RESULTS:
$ python ./tttestmod.py
$
WORKAROUND:
Filter stdout.write calls from doctest.py to squelch the noise.
REGRESSION/ ISOLATION:
$ python --version
Python 2.5.1
$
Also mentioned 2006-10 in comp.lang.python at DocTestRunner.merge
verbose,
i.e., http://groups.google.com/group/comp.lang.python/search?
group=comp.lang.python&q=DocTestRunner.merge+verbose
Not yet found in Bugs.python.org at DocTestRunner.
NOTES:
We can reasonably expect newbies to doctest random things
that need to be doctested more than once.
We can't reasonably expect newbies to know to how to filter doctest
stdout,
for example as below.
#!/usr/bin/env python
r""" ttestmod.py
Filter Doctest stdout a la http://wiki.python.org/moin/doctest
to call doctest.testmod more than once per SystemExit
without producing noise.
>>> import random
>>> import sys
>>>
>>> die = random.randint(1, 6)
>>> print >>sys.stderr, die
>>>
>>> die == 6
True
>>>
"""
import sys
class DocTestOutput:
def __init__(self, out = sys.stdout):
self.out = out
self.write = self.writeOut
self.quietly = False
def writeOut(self, bytes):
head = "*** DocTestRunner.merge: '__main__"
tail = "' in both testers; summing outcomes."
if bytes.startswith(head):
if bytes.endswith(tail):
self.quietly = True
if not self.quietly:
self.out.write(bytes)
if 0 <= bytes.find('\n'):
self.quietly = False
if __name__ == '__main__':
import doctest
sys.stdout = DocTestOutput()
doctest.testmod()
doctest.testmod()
--
components: Library (Lib)
messages: 58533
nosy: [EMAIL PROTECTED]
severity: normal
status: open
title: doctest.testmod gets noisy if called more than once per SystemExit
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1611>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38287] tempfile.TemporaryDirectory() should behave the same as a context manager as when used directly
New submission from Pat Gunn : Right now, when tempfile.TemporaryDirectory() is used as a context manager, the context variable is stringy, usable as a string containing the directory name it made. When used directly, it returns an object that does not coerce to a nice string, instead requiring the .name method to be called. I propose adding a __str__() to the class that causes it to serialise nicely into a string containing just the directory name, so the (in my view surprising) differences in behaviour are minimised. -- components: Library (Lib) messages: 353327 nosy: Pat Gunn priority: normal severity: normal status: open title: tempfile.TemporaryDirectory() should behave the same as a context manager as when used directly type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38287> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42328] ttk style.map function incorrectly handles the default state for element options.
New submission from Pat Thoyts :
When cloning a ttk style it is useful to copy an existing style and make
changes. We can copy the configuration and layout using:
style.layout('Custom.TEntry', **style.layout('TEntry'))
style.configure('Custom.TEntry', **style.configure('TEntry))
However, doing this with style.map can result in an exception. An example of
this occurs for any style that has a defined default state in the map eg the
TNotebook.Tab in the clam theme:
>>> style.map('TNotebook.Tab','background')
[('selected', '#dcdad5'), ('#bab5ab',)]
However, calling Tk directly:
>>> style.tk.call(style._name,"map","TNotebook.Tab","-background")
(, '#dcdad5', ,
'#bab5ab')
The second pair is defining the default state ('') to use color #bab5ab but
this is being mangled by the code that converts this into pythons response.
The culprit is ttk._list_from_statespec which treats the statespec with the
empty string as None and drops it and then returns the value in place of the
state and then puts in an empty value.
--
components: Tkinter
messages: 380798
nosy: patthoyts
priority: normal
severity: normal
status: open
title: ttk style.map function incorrectly handles the default state for element
options.
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue42328>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42328] ttk style.map function incorrectly handles the default state for element options.
Change by Pat Thoyts : -- keywords: +patch nosy: +Pat Thoyts nosy_count: 1.0 -> 2.0 pull_requests: +22138 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23241 ___ Python tracker <https://bugs.python.org/issue42328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32426] Tkinter.ttk Widget does not define wich option exists to set the cursor
Pat Thoyts added the comment: The Tk documentation for the acceptable cursor names is the cursors manual page. https://www.tcl.tk/man/tcl/TkCmd/cursors.htm Tk does not provide a way to get all these names in script. This should probably be closed. -- nosy: +patthoyts ___ Python tracker <https://bugs.python.org/issue32426> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42328] ttk style.map function incorrectly handles the default state for element options.
Pat Thoyts added the comment:
So if you look at the clamTheme.tcl file you can see the definition of the map
for the TNotebook.Tab style looks like the following:
ttk::style map TNotebook.Tab \
-padding [list selected {6 4 6 2}] \
-background [list selected $colors(-frame) {} $colors(-darker)] \
-lightcolor [list selected $colors(-lighter) {} $colors(-dark)] \
;
The vista theme uses these too on Windows.
So calling this from script we can see the resulting empty elements in tcl:
% ttk::style map TNotebook.Tab
-lightcolor {selected #eeebe7 {} #cfcdc8} -padding {selected {6 4 6 2}}
-background {selected #dcdad5 {} #bab5ab}
As I put in the bug, this gets mistranslated in python with the value for that
state map element getting put into the first element.
The simplest demonstration is that the following raises an exception:
import tkinter as tk
import tkinter.ttk as ttk
style = ttk.Style()
style.theme_use('clam')
style.map('Custom.TNotebook.Tab', **style.map('TNotebook.Tab'))
--
___
Python tracker
<https://bugs.python.org/issue42328>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
New submission from Pat Lynch : If I load a dll in ctypes, then delete that loaded DLL instance, the DLL is not unloaded until the script finishes and exits. I'm trying to write some unit tests in python to exercise that DLL where each test case loads a DLL, does some work, then unloads the DLL. Unfortunately the DLL only gets unloaded when the unit tests finish. I've tried forcing the garbage collector to run to get the DLL to unload. It did nothing... # load the DLL parser_dll = CDLL(dllpath) # do some work here # 'unload' the dll (or as close as I can get it to it) if (parser_dll): del parser_dll -- components: ctypes messages: 158433 nosy: plynch76 priority: normal severity: normal status: open title: Cannot unload dll in ctypes until script exits type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Pat Lynch added the comment: I should mention also, that this is mostly an issue for me on Win7 x64. It does behave 'slightly' better on WinXP x86. (I have the 64-bit version of python installed on Win7 x64 & the 32-bit version installed on WinXP) thanks, Pat. On 16 April 2012 14:09, Pat Lynch wrote: > > New submission from Pat Lynch : > > If I load a dll in ctypes, then delete that loaded DLL instance, the DLL > is not unloaded until the script finishes and exits. > > I'm trying to write some unit tests in python to exercise that DLL where > each test case loads a DLL, does some work, then unloads the DLL. > Unfortunately the DLL only gets unloaded when the unit tests finish. > > I've tried forcing the garbage collector to run to get the DLL to unload. > It did nothing... > > # load the DLL > parser_dll = CDLL(dllpath) > > # do some work here > > # 'unload' the dll (or as close as I can get it to it) > if (parser_dll): >del parser_dll > > -- > components: ctypes > messages: 158433 > nosy: plynch76 > priority: normal > severity: normal > status: open > title: Cannot unload dll in ctypes until script exits > type: enhancement > versions: Python 2.7 > > ___ > Python tracker > <http://bugs.python.org/issue14597> > ___ > -- ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Pat Lynch added the comment: thanks for the very quick response. Since LoadLibrary is called in the constructor, why can't FreeLibrary be called in the destructor? or at least expose a function to unload that calls FreeLibrary? http://msdn.microsoft.com/en-us/library/windows/desktop/ms683152%28v=vs.85%29.aspx thanks again, Pat. On 16 April 2012 14:30, R. David Murray wrote: > > R. David Murray added the comment: > > In general it is difficult to impossible to get Python2 to unload modules > before the interpreter shuts down. See issue 9072. I'm not savvy enough > with the C stuff to know if the fact that you loaded it via ctypes changes > anything, but I doubt it. > > Note that the implication of that issue is that if you could move to > Python3 there might be a way to do it, but that would indeed be an > enhancement as there is no direct support for it yet. > > -- > nosy: +r.david.murray > versions: +Python 3.3 -Python 2.7 > > ___ > Python tracker > <http://bugs.python.org/issue14597> > ___ > -- ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Pat Lynch added the comment: ok, that's fair enough if most usage of ctypes is from people accessing system libraries :) I wouldn't have thought my usage was that weird though (given the strength of using python for unit testing). In local tests, adding a function CDLL::ForceUnloadDll (which just calls FreeLibrary(self._handle)) seems to work well. I haven't done intensive testing though at this point. I could be missing something though. thanks, Pat. On 16 April 2012 14:45, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > In principle, it should be possible (but perhaps not desirable, see below) > to call FreeLibrary in a CDLL's __del__. However, since this would be a new > feature, it can't go into 2.7. Patches are welcome; make sure to support > both FreeLIbrary and dlclose. > > There is a general issue with closing/freeing DLLs: if they are still > referenced somewhere (e.g. in an atexit function, a C++ virtual method > table, or on the call stack of another thread), then a later access to the > code will crash the interpreter. In a typical DLL today (including all > Python extension modules), the likelihood of crashes is close to 100%. For > that reason, it's probably not a good idea to have ctypes auto-close DLLs; > instead, it should be an opt-in mechanism. > > For most ctypes uses, closing is irrelevant, since people typically access > system libraries that are independently loaded anyway, so closing them > would not have any effect. > > -- > nosy: +loewis > > ___ > Python tracker > <http://bugs.python.org/issue14597> > ___ > -- ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14597] Cannot unload dll in ctypes until script exits
Pat Lynch added the comment: Just to update:- I've run this pretty extensively on multiple systems (XP x86 & Win7 64-bit) and it appears to behave as expected (haven't checked it on Linux). I have that code being called in 100s of unit tests. For python 3.1, would it make sense to add it as a ForceUnload function?? - for safety bail out if handle was not None when passed into the constructor? i.e. if somebody has accessed an independently loaded DLL, they will pass in the handle when constructing the CDLL object. Disallow ForceUnload in that case. ForceUnload will only be allowed in cases where we created that type by passing in the path to the DLL. I'll be using this code as a local patch, so no rush to put it into 3.1 etc. thanks for all the info - much appreciated :) Pat. On 16 April 2012 15:04, Pat Lynch wrote: > > Pat Lynch added the comment: > > ok, that's fair enough if most usage of ctypes is from people accessing > system libraries :) > > I wouldn't have thought my usage was that weird though (given the strength > of using python for unit testing). > > In local tests, adding a function CDLL::ForceUnloadDll (which just calls > FreeLibrary(self._handle)) seems to work well. I haven't done intensive > testing though at this point. I could be missing something though. > > thanks, > Pat. > > On 16 April 2012 14:45, Martin v. Löwis wrote: > > > > > Martin v. Löwis added the comment: > > > > In principle, it should be possible (but perhaps not desirable, see > below) > > to call FreeLibrary in a CDLL's __del__. However, since this would be a > new > > feature, it can't go into 2.7. Patches are welcome; make sure to support > > both FreeLIbrary and dlclose. > > > > There is a general issue with closing/freeing DLLs: if they are still > > referenced somewhere (e.g. in an atexit function, a C++ virtual method > > table, or on the call stack of another thread), then a later access to > the > > code will crash the interpreter. In a typical DLL today (including all > > Python extension modules), the likelihood of crashes is close to 100%. > For > > that reason, it's probably not a good idea to have ctypes auto-close > DLLs; > > instead, it should be an opt-in mechanism. > > > > For most ctypes uses, closing is irrelevant, since people typically > access > > system libraries that are independently loaded anyway, so closing them > > would not have any effect. > > > > -- > > nosy: +loewis > > > > ___ > > Python tracker > > <http://bugs.python.org/issue14597> > > ___ > > > > -- > > ___ > Python tracker > <http://bugs.python.org/issue14597> > ___ > -- ___ Python tracker <http://bugs.python.org/issue14597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31616] Windows installer: Python binaries are user-writable
New submission from Pat K : This seems to affect different versions of Python Windows installer. The problem is when Python is installed for all users (requires elevation) its binaries and DLLs are shipped with writable permission for "Authenticated Users": PS C:\Python36> icacls python.exe python.exe BUILTIN\Administrators:(I)(F) NT AUTHORITY\SYSTEM:(I)(F) BUILTIN\Users:(I)(RX) NT AUTHORITY\Authenticated Users:(I)(M) ... This could be easily exploited for profit by a malicious user to hijack the interpreter or libraries of other users, including Administrator, possibly leading to the privilege escalation. -- components: Installation messages: 303200 nosy: Pat K priority: normal severity: normal status: open title: Windows installer: Python binaries are user-writable versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31616] Windows installer: Python binaries are user-writable
Pat K added the comment: Thank you for the explanation. I understand this is intentional. However user without such knowledge of inheritable permissions might want to default the installation directory to the old one (C:\PythonXX) and could easily run into this issue without knowing. IMHO extra security check or explicit warning wouldn't hurt here. Just my 5c. On 9/28/2017 1:09 PM, Eryk Sun wrote: > > Eryk Sun added the comment: > > The "(I)" flag in an icacls entry means it's inherited from the parent > directory. The installer doesn't override these inherited permissions. > Currently, it's your responsibility to do this if you install to a custom > directory such as C:\Python36. > > Starting with Python 3.5, a per-machine installation defaults to a > subdirectory of Program Files. This system directory only grants standard > users generic read and execute access for subdirectories and files. A > per-user installation defaults to the user's Programs directory (i.e. > %LocalAppData%\Programs). This directory grants full control to the user, > administrators, and the system. Other users have no access. > > -- > components: +Windows > nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware > type: -> enhancement > > ___ > Python tracker > <https://bugs.python.org/issue31616> > ___ > -- ___ Python tracker <https://bugs.python.org/issue31616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27309] Visual Styles support to tk/tkinter file and message dialogs
Pat Thoyts added the comment: As explained in the SO answer, in Tk on Windows the messagebox, file open dialog, save as dialog and in 8.6 up the font dialog are all system standard dialogs. Tk gets Windows to show the common dialog or messagebox and just wraps the Win32 API calls. As a result these dialogs are not themed using ttk as the various elements are not Tk controls at all. The theming control is therefore provided by Windows and is controlled at an application level by the use of an RT_MANIFST resource. This contains various chunk of XML and one of these is used to declare that theming may be applied by the Visual Styles API. The Tk executables include this bit of manifest but the python exe does not. You can test this out using the attached python.exe.manifest file. To allow this to work you have to remove the existing RT_MANIFEST resource from the python executable as an embedded resource overrides a sibling manifest file. I find the easiest way to work with this is to open the exe in Visual Studio and use the resources view to change the resource in place. You can copy the contents of the manifest file over the existing RT_MANIFEST resource or you can remove the embedded resource and let the system pick up the python.exe.manifest file from the same folder as python.exe. This is not dependent on Tk version. All versions of Tk since around 8.0 have delegated to the Win32 MessageBox and GetOpenFileName API calls. With the introduction of Window XP and the Visual Styles API Microsoft added this requirement to declare support for theming via manifests. So if you have the right manifest and theming is enabled on your system then Tk 8.4 and 8.3 will all show themed common dialogs and messageboxes. This does not affect OS X or X Windows. On X Windows Tk provides all these dialogs itself and so they use Tk widgets (or ttk widgets in more recent versions). On OS X I believe the messagebox and common dialogs are all system provided but it will have its own system for controlling that. In short, python needs to merge it this manifest with the manifest being put in place already. The Visual Studio 'mt' tool can do that if you want to merge manifests. -- nosy: +Pat Thoyts Added file: http://bugs.python.org/file43487/python.exe.manifest ___ Python tracker <http://bugs.python.org/issue27309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24767] can concurrent.futures len(Executor) return the number of tasks?
New submission from Pat Riehecky:
As a feature request, can the Executor respond to a len() request by showing
the number of non-finished/non-canceled items in the pool?
I would like a clean pythonic way of seeing how many items remain to be
executed and this seemed the way to go.
psudo-code:
myvar = list(range(1, 30))
pool = concurrent.futures.ThreadPoolExecutor(max_workers=2)
results = pool.map(myfunction, myvar)
for result in results:
print("waiting for " + str(len(pool)) + " tasks to finish")
--
components: Library (Lib)
messages: 247766
nosy: Pat Riehecky
priority: normal
severity: normal
status: open
title: can concurrent.futures len(Executor) return the number of tasks?
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue24767>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24767] can concurrent.futures len(Executor) return the number of tasks?
Pat Riehecky added the comment: works for me -- ___ Python tracker <http://bugs.python.org/issue24767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
New submission from Pat Le Cat: I use Python 3.4.1 x64 (binaries downloaded) under Windows 8.1 with mingw64 (GCC 4.9 using C++). All the other functions work fine. Excerpt: Py_SetPath(L"python34.zip"); wchar_t* pyPath = Py_GetPath(); Py_Initialize(); -- components: Build, Library (Lib), Windows messages: 220902 nosy: Pat.Le.Cat priority: normal severity: normal status: open title: Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath' type: compile error versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
Pat Le Cat added the comment: Okay I tried the exact same example code from your website on the MSVC-2013 (same OS) suite and got new errors with it and a strange warning. >>Warning: 1>c:\python34\include\pymath.h(22): warning C4273: 'round' : inconsistent dll linkage 1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round' >>Runtime crash: C:\Users\xxx\Documents\Visual Studio 2013\Projects\SnakesTest\x64\Release>SnakesTest.exe multiply multiply 3 2 Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' I linked with both the 'python3.lib' and the 'python34.lib' (what's the difference anyways?) with the same results. It looks to me as if the DLL doesn't contain all the same symbols as in the include file, or have you done some obscure compressing with the DLL maybe? But the "inconsistent dll linkage" seems to be the leading hint here. ADDENDUM: I forgot to mention that under mingw I do directly link to the python3.dll, since there is no python3.a libfile around and dlltool was unable to extract any symbols from the DLL. -- Added file: http://bugs.python.org/file35720/SnakesTest.cpp ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
Pat Le Cat added the comment: **Missing Python34.dll in installation** Okay it's getting more interesting. I downloaded Python 3.4 windows x64 binary and extracted the DLLs and suddenly I discovered that release 3.4.1 is missing the Python34.dll !! :-O Once I link against the python34.dll from mingw/gcc then it compiles fine :D (the 77kb from the python3.dll seemed too small anyhow ;) ) Now I have the similar error at runtime as with MSVC-2013: C:\Development\xxx\Testo1\Snakes\Release>Snakes.exe multiply multiply 3 2 Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' Now the question remains what "unicode" module python is complaining about?!? -- ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
Pat Le Cat added the comment: Update on mingw: When I comment out the Py_SetPath() function call, then the code runs up to the 4th test print and then crashes again, possibly at: "Py_XDECREF(pArgs)". So apart from the 'encoding' module that cannot be found there is still a crash. I installed Python 3.4.1 again for this. BTW: The multiply.py runs fine when called with "py -3" directly. >>Output: C:\Development\xxx\Testo1\Snakes\Release>Snakes.exe multiply multiply 3 2 Number of arguments 5 Will compute 3 times 2 Result: 6 ***Test1***Test2***Test3Will compute 3 times 2 ***Test4 -- ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
Pat Le Cat added the comment: Yes I'm sorry, this evolved as I investigated further. So the initial case has become this: Bug: Python 3.4 Windows installation contains python34.dll but does not install it. Both: python-3.4.1.amd64.msi and python-3.4.0.amd64.msi (maybe the 32bit too?) Negligence: Documentation should mention that to embed Python it is necessary to use python34.dll (at least under Windows) and that with MingW one can directly link to the DLL and doesn't need an .a file. -- ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] Py_SetPath() gives compile error: undefined reference to '__imp_Py_SetPath'
Pat Le Cat added the comment: Plus the MSVC-2013 compiler warning noted earlier of course: >>Warning: 1>c:\python34\include\pymath.h(22): warning C4273: 'round' : inconsistent dll linkage 1>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\math.h(516) : see previous definition of 'round' -- ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21825] Embedding-Python example code from documentation crashes
New submission from Pat Le Cat: When I comment out the Py_SetPath() function call (Line 56), then the code runs up to the 4th test print and then crashes again, possibly at: "Py_XDECREF(pArgs)" else it crashes at Py_Initalize. The same behavior can be observed under Python 3.4.0 and 3.4.1 and on both the MSVC and GCC compiler. BTW: The multiply.py runs fine when called with "py -3" directly. >>Output without Py_SetPath: C:\Development\xxx\Testo1\Snakes\Release>Snakes.exe multiply multiply 3 2 Number of arguments 5 Will compute 3 times 2 Result: 6 ***Test1***Test2***Test3Will compute 3 times 2 ***Test4 >>Output with Py_SetPath: C:\Development\xxx\Testo1\Snakes\Release>Snakes.exe multiply multiply 3 2 Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' **Dev-Environment: Windows 8.1 64bit, MSVC-2013 and MingW (installed with mingw-w64-install.exe downloaded in June 2014). **Microsoft Visual Studio Professional 2013: v12.0.30501.00 Update2 **GCC/G++ Version: C:\Development\xxx\Testo1\Snakes\Release>g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=C:/MingW64/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-4.9.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --targe t=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw490/x86_64-490-win32-seh-rt_v3-rev1/mingw64 --wi th-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=win32 --ena ble-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic -string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-cloog-version-check --dis able-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --dis able-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 - -with-libiconv --with-system-zlib --with-gmp=/c/mingw490/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/ c/mingw490/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw490/prerequisites/x86_64-w64-mingw32-sta tic --with-isl=/c/mingw490/prerequisites/x86_64-w64-mingw32-static --with-cloog=/c/mingw490/prerequisites/x86_ 64-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='x86_64-win32-seh-rev1, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw490/x86_64-490-wi n32-seh-rt_v3-rev1/mingw64/opt/include -I/c/mingw490/prerequisites/x86_64-zlib-static/include -I/c/mingw490/pr erequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw490/x86_64-490-win32-seh-rt_v3-re v1/mingw64/opt/include -I/c/mingw490/prerequisites/x86_64-zlib-static/include -I/c/mingw490/prerequisites/x86_ 64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw490/x86_64-490-win32-seh-rt_v3-rev1/mingw64/ opt/lib -L/c/mingw490/prerequisites/x86_64-zlib-static/lib -L/c/mingw490/prerequisites/x86_64-w64-mingw32-stat ic/lib' Thread model: win32 gcc version 4.9.0 (x86_64-win32-seh-rev1, Built by MinGW-W64 project) -- components: Build, Demos and Tools files: main.cpp messages: 221259 nosy: Pat.Le.Cat priority: normal severity: normal status: open title: Embedding-Python example code from documentation crashes type: crash versions: Python 3.4 Added file: http://bugs.python.org/file35724/main.cpp ___ Python tracker <http://bugs.python.org/issue21825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21825] Embedding-Python example code from documentation crashes
Pat Le Cat added the comment: Crash Error Window (pic) -- Added file: http://bugs.python.org/file35725/snakes_bug.jpg ___ Python tracker <http://bugs.python.org/issue21825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] python34.dll is not installed
Pat Le Cat added the comment: Ah it installs it in Windows/Sytem32 okay I had no clue, another undocumented behavior :) Still it is missing in the DLLs folder. And you haven't explained the warning under MSVC. And the documentation should be enhanced as I suggested to be more clear. -- ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] python34.dll is not installed
Pat Le Cat added the comment: Well? -- resolution: works for me -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21799] python34.dll is not installed
Pat Le Cat added the comment: Cheesas you are really making it hard by design to report things to Python. Maybe a bit more common sense could help the project, or should I file a new bug-report for that too? :-/ -- resolution: works for me -> rejected ___ Python tracker <http://bugs.python.org/issue21799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21825] Embedding-Python example code from documentation crashes
Pat Le Cat added the comment: I zipped the whole Lib directory into "pyLib34.zip" (into same dir as EXE) and copied all the .pyd files from the DLLs dir into the same dir as the EXE. -- ___ Python tracker <http://bugs.python.org/issue21825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21825] Embedding-Python example code from documentation crashes
Pat Le Cat added the comment: When working with the separately installed version of Python 3.4.1, which means by not using Py_SetPath() the embedding examples from your webpage work okay. So what's wrong with that function and why that allegedly missing module "encoding" that I cannot find anywhere but is obviously not missing when using the code without Py_SetPath()? Very confusing... -- ___ Python tracker <http://bugs.python.org/issue21825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
