[issue43122] Python Launcher doesn't open a terminal window
Kevin added the comment: Many thanks for notifying me that my issue is fixed in the latest updates. I will try to test this soon. Kevin Weidenbaum > On Jan 3, 2022, at 1:59 AM, Ned Deily wrote: > > > Change by Ned Deily : > > > -- > Removed message: https://bugs.python.org/msg409563 > > ___ > Python tracker > <https://bugs.python.org/issue43122> > ___ -- ___ Python tracker <https://bugs.python.org/issue43122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12172] IDLE crashes when I use F5 to run
New submission from Kevin :
Similar to bug issue 11431, my IDLE crashes (OS 10.6.7) when using F5, but
works fine or better when I click run module. However, unlike 11431, I have
downloaded, and I believe, correctly installed ActiveTcl 8.5.
Similar to Ned's suggestions in issue: 11431, here are the first two lines when
I launch my shell:
Python 3.2 (r32:88452, Feb 20 2011, 11:12:31)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Also, here is the response when I run Ned's suggested commands per issue number
11431. First Ned's commands:
import _tkinter, subprocess
print(subprocess.getoutput("otool -L " + _tkinter.__file__))
print(subprocess.getoutput("ls -l /Library/Frameworks/Tk.framework/Versions"))
The responses:
/bin/sh: otool: command not found
total 8
drwxr-xr-x 8 root admin 272 Feb 4 01:52 8.5
lrwxr-xr-x 1 root admin3 May 23 17:45 Current -> 8.5
Also, if it may help, when I click on the ActiveTCL application icon, a comodo
dragon icon application named tclvfse, I get a fatal error message of which I
took the following screen shot, attached.
My guess is that ActiveTcl 8.5 is partially installed, or flat out incorrectly
installed.
Any ideas? Thanks for your help/time.
Kevin
--
components: IDLE
files: Screen shot 2011-05-23 at 5.56.19 PM.png
messages: 136826
nosy: Kevin Ness
priority: normal
severity: normal
status: open
title: IDLE crashes when I use F5 to run
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file22102/Screen shot 2011-05-23 at 5.56.19
PM.png
___
Python tracker
<http://bugs.python.org/issue12172>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2652] 64 bit python memory leak usage
New submission from kevin <[EMAIL PROTECTED]>: For the code below.. memory usage keeps increasing continuously.. This does not happen in a 32-bit machine python build. i think it might be the datetime module where the problem might be.. linux kernel version (both on 32-bit and 64 bit machine) linux - 2.6.24.4-64.fc8 python version (both on 32-bit and 64 bit machine) Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) now = datetime.datetime.now() oneday = datetime.timedelta(days=1) def birthdaycompare(a, b): if a is None and b: return 1 if a and b is None: return -1 if a is None and b is None: return 0 if ahttp://bugs.python.org/file10051/data.log __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2652> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38058] Tutorial: 4.2. for Statements
New submission from Kevin : >>> # Measure some strings: ... words = ['cat', 'window', 'defenestrate'] >>> for w in words: ... print(w, len(w)) ... cat 3 window 6 defenestrate 12 If you need to modify the sequence you are iterating over while inside the loop (for example to duplicate selected items), it is recommended that you first make a copy. Iterating over a sequence does not implicitly make a copy. The slice notation makes this especially convenient: >>>>>> for w in words[:]: # Loop over a slice copy of the entire list. ... if len(w) > 6: ... words.insert(0, w) ... >>> words ['defenestrate', 'cat', 'window', 'defenestrate'] words is a tuple and is immutable -- assignee: docs@python components: Documentation messages: 351331 nosy: Derangedn00b, docs@python priority: normal severity: normal status: open title: Tutorial: 4.2. for Statements type: compile error versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38058] Tutorial: 4.2. for Statements
Change by Kevin : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35633] test_eintr fails on AIX since fcntl functions were modified
Kevin added the comment: FYI, the problem here is that AIX fcntl returns EACCES in the case that the lock is held and non-blocking behavior was requested: > The lockfx and lockf subroutines fail if one of the following is true: Item > > EACCESThe Command parameter is F_SETLK, the l_type field is F_RDLCK, > and the segment of the file to be locked is already write-locked by another > process. > EACCESThe Command parameter is F_SETLK, the l_type field is F_WRLCK, > and the segment of a file to be locked is already read-locked or write-locked > by another process. https://www.ibm.com/docs/en/aix/7.1?topic=l-lockfx-lockf-flock-lockf64-subroutine (Note the docs are a bit wonky referring to lockf/lockfx but talking about parameters and fields which apply to fcntl instead) The lockf/flock APIs provided by AIX handle this appropriately, mapping EACCES to EWOULDBLOCK, but while Python calls the libbsd flock API, it uses its own lockf implementation which calls fcntl directly: https://github.com/python/cpython/blob/main/Modules/fcntlmodule.c#L426 -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue35633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22377] %Z in strptime doesn't match EST and others
Kevin added the comment: With the introduction of PEP 0615 (https://www.python.org/dev/peps/pep-0615/) — Support for the IANA Time Zone Database in the Standard Library — should this be revisited to now leverage ZoneInfo to fully parse these time zone values in Python 3.9+ (or 3.11 with introduction of the feature if it is unreasonable to backport this)? -- nosy: +kkirsche ___ Python tracker <https://bugs.python.org/issue22377> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26651] Deprecate register_adapter() and register_converter() in sqlite3
Change by Kevin : -- nosy: +Strongbeard ___ Python tracker <https://bugs.python.org/issue26651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45858] Deprecate default converters in sqlite3
Change by Kevin : -- nosy: +Strongbeard ___ Python tracker <https://bugs.python.org/issue45858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43122] Python Launcher doesn't open a terminal window
New submission from Kevin : Machine: new MacBook Air with M1 chip, running Big Sur Downloaded: Python versions 2.7, 3.8, and 3.9 Situation: Programs run just fine IF I run them out of a terminal window (/usr/local/bin/python name-of-python-program). Also programs that use Tkinter windows and don't require a terminal window for input or output run properly. Problem: Can't launch programs by double-clicking on them. When I try, Python Launcher starts and displays its preferences and there is a microsecond flash of something on the screen that appears to descend into the program icon that was clicked on. Note: Playing with a shebang in the program made no difference. Everything works fine when the programs are opened and run in IDLE. -- messages: 386473 nosy: kjw priority: normal severity: normal status: open title: Python Launcher doesn't open a terminal window type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43122] Python Launcher doesn't open a terminal window
Kevin added the comment: William, Thanks for your comment. I assumed the same thing, but it goes by so fast I am never sure.. > On Feb 3, 2021, at 10:27 PM, William Pickard wrote: > > > William Pickard added the comment: > > That quick flash would be your terminal window if I have to guess (based on > no Mac experience, but Windows). > > -- > nosy: +WildCard65 > > ___ > Python tracker > <https://bugs.python.org/issue43122> > ___ -- ___ Python tracker <https://bugs.python.org/issue43122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: makexp_aix, parallel build (failures) and ld WARNINGS
Kevin added the comment: This seems to be a duplicate of https://bugs.python.org/issue19521 The PR for that one seems a little less hacky since it uses make rules to prevent duplication instead of lock files. -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40424] AIX: makexp_aix, parallel build (failures) and ld WARNINGS
Kevin added the comment: FYI, here's a patch we've been using with our builds on PASE (an AIX compatibility layer on the IBM i OS). It runs all the echos and nm in a sub-shell so that all the output appears as a continuous stream instead of 3 separate open/write/close events. There's still a race condition, but since it no longer appends, the last one in will win instead of the mixed result there is now. AFAICT, it gets created much earlier than it gets used so nothing _should_ be reading it while the writers are racing. At least it works for us on PASE with -j16 when building Python 3.6. -- Added file: https://bugs.python.org/file49234/python3-makexp_aix.patch ___ Python tracker <https://bugs.python.org/issue40424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41894] UnicodeDecodeError during load failure in non-UTF-8 locale
New submission from Kevin : If a native module fails to load, the dynload code will call PyUnicode_FromString on the error message to give back to the user. This can cause a UnicodeDecodeError if the locale is not a UTF-8 locale and the error message contains non-ASCII code points. While Linux systems almost always use a UTF-8 locale by default nowadays, AIX systems typically use non-UTF-8 locales by default. We encountered an issue where a customer did not have libbz2 installed, causing a load failure when bz2 tried to import _bz2 when running in an Italian locale: $ LC_ALL=it_IT python3 -c 'import bz2' Traceback (most recent call last): File "", line 1, in File "/QOpenSys/pkgs/lib/python3.6/bz2.py", line 21, in from _bz2 import BZ2Compressor, BZ2Decompressor UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 161: invalid continuation byte After switching to a UTF-8 locale, the problem goes away: $ LC_ALL=IT_IT python3 -c 'import bz2' Traceback (most recent call last): File "", line 1, in File "/QOpenSys/pkgs/lib/python3.6/bz2.py", line 21, in from _bz2 import BZ2Compressor, BZ2Decompressor ImportError:0509-022 Impossibile caricare il modulo /QOpenSys/pkgs/lib/python3.6/lib-dynload/_bz2.so. 0509-150 Il modulo dipendente libbz2.so non è stato caricato. 0509-022 Impossibile caricare il modulo libbz2.so. 0509-026 Errore di sistema: Un file o una directory nel nome percorso non esiste. 0509-022 Impossibile caricare il modulo /QOpenSys/pkgs/lib/python3.6/lib-dynload/_bz2.so. 0509-150 Il modulo dipendente /QOpenSys/pkgs/lib/python3.6/lib-dynload/_bz2.so non è stato caricato. While this conceivably affects any Unix-like platform, the only system I can recreate it on is AIX and IBM i PASE. As far as I can tell, on Linux you will always get something like "error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory". Even though there seems to be some translations in GLIBC, I have been unable to get them to be used on either Fedora or Ubuntu. -- components: Interpreter Core messages: 377713 nosy: kadler priority: normal severity: normal status: open title: UnicodeDecodeError during load failure in non-UTF-8 locale type: behavior versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41894] UnicodeDecodeError during load failure in non-UTF-8 locale
Change by Kevin : -- keywords: +patch pull_requests: +21490 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22466 ___ Python tracker <https://bugs.python.org/issue41894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41894] UnicodeDecodeError during load failure in non-UTF-8 locale
Kevin added the comment: Glad you were able to reproduce on Linux. I have since changed the PR to use PyUnicode_DecodeFSDefault based on review feedback. I was going to say that you will have to fight it out with @methane on GH, but I see that that's you. :D Would have been nice if you would have left the updated feedback there as well so people who aren't familiar would know it's one person adjusting their recommendation vs two different people with conflicting recommendations. The only issue I see with using backslashreplace is that users of non-UTF-8 locales would see message text that contains non-ASCII characters only as escape codes. eg, the message above would show "Il modulo dipendente libbz2.so non \xe8 stato caricato." instead of "Il modulo dipendente libbz2.so non è stato caricato." By using PyUnicode_DecodeFSDefault instead, the message should be properly decoded but any encoding errors (such as utf-8 paths, etc) would be handled by surrogateescape. I guess the question comes to: what's more important to be decoded, the message text or the path? -- ___ Python tracker <https://bugs.python.org/issue41894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41894] UnicodeDecodeError during load failure in non-UTF-8 locale
Kevin added the comment: Ok, so should I switch the PR back from PyUnicode_DecodeFSDefault? -- ___ Python tracker <https://bugs.python.org/issue41894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42029] Remove dynload_dl.c
New submission from Kevin : dynload_dl.c is no longer referenced anywhere in the code. It was used to support dynamic loading on IRIX 4 and DYNIX, but those platforms were dropped in https://github.com/cpython/cpython/commit/b9949dbe6c20537b7821f25fc1eeb4e7f3faabff. Considering that commit removes all references to dynload_dl, I suspect it was an oversight that it was not removed in that commit. -- components: Interpreter Core messages: 378586 nosy: kadler priority: normal severity: normal status: open title: Remove dynload_dl.c ___ Python tracker <https://bugs.python.org/issue42029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42029] Remove dynload_dl.c
Kevin added the comment: Sorry, the correct link is https://github.com/python/cpython/commit/b9949dbe6c20537b7821f25fc1eeb4e7f3faabff -- ___ Python tracker <https://bugs.python.org/issue42029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42029] Remove dynload_dl.c
Change by Kevin : -- keywords: +patch pull_requests: +21657 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22687 ___ Python tracker <https://bugs.python.org/issue42029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42030] Drop support for dynload_aix
New submission from Kevin : Python has supported using dynload_shlib (using dlopen) on AIX since https://github.com/python/cpython/commit/c19c5a62aef7dce0e8147655b0d2f087965fae75 in 2003. While I have not found a definitive timeline of when AIX gained support for dlopen, I have found references going back to at least 2000. Considering this is now 20 years later and all supported AIX versions support dlopen, I suspect nobody has used or tested this code path in quite some time. I propose removing this support under PEP 11. -- components: Interpreter Core messages: 378588 nosy: kadler priority: normal severity: normal status: open title: Drop support for dynload_aix ___ Python tracker <https://bugs.python.org/issue42030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42030] Drop support for dynload_aix
Change by Kevin : -- keywords: +patch pull_requests: +21685 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22717 ___ Python tracker <https://bugs.python.org/issue42030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42030] Drop support for dynload_aix
Kevin added the comment: I've opened a PR to disable support in 3.10 with removal in 3.11 according to the guidelines outline in PEP 11. Given the unlikeliness that anyone is actually still using this feature (and are possibly already broken by a bunch of other things), would it make more sense to do the removal in one go? I do see that systems without multithreading support were both unsupported and removed in 3.7, though I do not know the particulars of why that is the case since most other entries have a 1 version gap. -- ___ Python tracker <https://bugs.python.org/issue42030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42030] Drop support for dynload_aix
Kevin added the comment: Ok, I have updated the PR to remove it completely. -- ___ Python tracker <https://bugs.python.org/issue42030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40680] thread_cputime isn't supported by AIX5
Kevin added the comment: Does this need an update to PEP 11 documenting the drop of support? Also, I can submit changes to remove pre-AIX 6 dead code paths. Should I open a separate issue for that or reference this one? -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue40680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42087] Remove pre-AIX 6.1 dead code paths
New submission from Kevin : Follow on to https://bugs.python.org/issue40680. In there, it was decided that since AIX 5 and below doesn't support thread_cputime, support for it would be dropped and the issue was closed without removing any of the dead code paths and references. -- components: Interpreter Core messages: 379007 nosy: kadler priority: normal severity: normal status: open title: Remove pre-AIX 6.1 dead code paths ___ Python tracker <https://bugs.python.org/issue42087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40680] thread_cputime isn't supported by AIX5
Kevin added the comment: Ok, I've opened https://bugs.python.org/issue42087 -- ___ Python tracker <https://bugs.python.org/issue40680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42087] Remove pre-AIX 6.1 dead code paths
Change by Kevin : -- keywords: +patch pull_requests: +21785 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22830 ___ Python tracker <https://bugs.python.org/issue42087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17454] ld_so_aix not used when linking c++ (scipy)
Kevin added the comment: This was fixed by https://github.com/python/cpython/pull/10437 -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue17454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24501] configure does not find (n)curses in /usr/local/libs
Kevin added the comment: There error indicates it can't find ncurses.h configure:14223: xlc_r -c -qmaxmem=-1 -DSYSV -D_AIX -D_AIX71 -D_ALL_SOURCE -DFUNCPROTO=15 -O -I/usr/local/include -I/usr/include/ncursesw conftest.c >&5 "conftest.c", line 311.10: 1506-296 (S) #include file not found. Are you sure you don't need -I/usr/include/ncurses instead of -I/usr/include? -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue24501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24046] Incomplete build on AIX
Kevin added the comment: Looks like RAND_egd was made optional in https://bugs.python.org/issue21356 Can this issue be closed? -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue24046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24886] open fails randomly on AIX
Kevin added the comment: Given that the AIX bug has long been fixed and Python 2.7 is EOL we can probably close this bug. -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue24886> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42309] BUILD: AIX-64-bit segmentation fault
Kevin added the comment: I have not encountered this problem when building Python 3.10 on AIX and PASE with GCC 6.3. -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue42309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23023] ./Modules/ld_so_aix not found on AIX during test_distutils
Kevin added the comment: Is this issue still relevant? I can't find any current buildbot errors on AIX for this test. -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue23023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11188] test_time error on AIX
Change by Kevin : -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue11188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37009] Threading and THREAD_SAFE for AIX
Change by Kevin : -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue37009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37733] Fail to build _curses module of Python 3.7.4 on AIX 7.1 using gcc
Kevin added the comment: Both 3.6 and 3.7 are in security only mode so at this point, so if the issue is fixed in newer versions I think this issue could be closed. -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue37733> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35198] Build issue while compiling cpp files in AIX
Kevin added the comment: Just a friendly ping that there's a PR for this bug waiting to be reviewed. -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue35198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35198] Build issue while compiling cpp files in AIX
Kevin added the comment: Ah. We always compile with GCC, so would not have hit that particular problem. -- ___ Python tracker <https://bugs.python.org/issue35198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36744] functools.singledispatch: Shouldn't require a positional argument if there is only one keyword argument
New submission from Kevin :
Passing a single argument as a keyword argument to a function decorated with
@functools.singledispatch results in an error:
$ python
Python 3.7.2 (default, Feb 12 2019, 08:15:36)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from functools import singledispatch
>>> @singledispatch
... def f(x):
... pass
...
>>> f(x=1)
Traceback (most recent call last):
File "", line 1, in
File "/lib/python3.7/functools.py", line 821, in wrapper
raise TypeError(f'{funcname} requires at least '
TypeError: f requires at least 1 positional argument
I think it's reasonable to expect f(x=1) to do the same as f(1) in this case.
Since there is only one argument, it should be the one passed to dispatch().
Relevant code:
def wrapper(*args, **kw):
if not args:
raise TypeError(f'{funcname} requires at least '
'1 positional argument')
return dispatch(args[0].__class__)(*args, **kw)
https://github.com/python/cpython/blob/445f1b35ce8461268438c8a6b327ddc764287e05/Lib/functools.py#L819-L824
I think the wrapper method could use something like next(iter(d.values()))
instead of args[0] when there are no args, but exactly one keyword argument.
I am happy to make the change myself
--
components: Library (Lib)
messages: 341016
nosy: KevinG, rhettinger
priority: normal
severity: normal
status: open
title: functools.singledispatch: Shouldn't require a positional argument if
there is only one keyword argument
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue36744>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36744] functools.singledispatch: Shouldn't require a positional argument if there is only one keyword argument
Kevin added the comment: I have read issue33967 before posting this one. The error message was introduced there, but the behavior hasn't changed. The problem that issue33967 solves is that while singledispatch requires at least one positional argument, there was no explicit error message that told you that when you didn't pass any. What this issue is about, is that singledispatch could also work without positional arguments IF only one keyword argument is provided. -- ___ Python tracker <https://bugs.python.org/issue36744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31621] Pluralization typo in Language Reference section 7.12
New submission from Kevin : The documentation for the `global` statement contains the line: > CPython implementation detail: The current implementation does not enforce > some of these restriction [...] "restriction" should be "restrictions" since there is more than one of them. Attached is a copy of `simple_stmts.rst` with the proposed one-letter change. -- assignee: docs@python components: Documentation files: simple_stmts_pluralized.rst messages: 303266 nosy: docs@python, kms70847 priority: normal severity: normal status: open title: Pluralization typo in Language Reference section 7.12 versions: Python 3.6, Python 3.7 Added file: https://bugs.python.org/file47175/simple_stmts_pluralized.rst ___ Python tracker <https://bugs.python.org/issue31621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31621] Pluralization typo in Language Reference section 7.12
Kevin added the comment: Yes, I intend to make a PR shortly. -- ___ Python tracker <https://bugs.python.org/issue31621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31621] Pluralization typo in Language Reference section 7.12
Change by Kevin : -- keywords: +patch pull_requests: +3793 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue31621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31621] Pluralization typo in Language Reference section 7.12
Kevin added the comment: Ok, I've created a pull request, available at https://github.com/python/cpython/pull/3809. -- ___ Python tracker <https://bugs.python.org/issue31621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32451] python -m venv activation issue when using cygwin on windows
New submission from Kevin :
attempts from within cygwin:
1. The Posix way:
$ python -m venv taco
$ cd taco
$ source bin/activate
-bash: $'\r': command not found
-bash: Scripts/activate: line 4: syntax error near unexpected token `$'{\r''
'bash: Scripts/activate: line 4: `deactivate () {
2. The windows way:
$ python -m venv taco
$ cd taco
$ /full/path/to/venv/taco/scripts/activate.bat
$
3. the only solution from cygwin (still not 100% functional):
$ python -m venv taco
$ cd taco
$ cd Scripts
$ cmd
C:\taco\Scripts\> activate.bat
(taco) C:\taco\Scripts\>
HOWEVER. when running "pip freeze" in number 3 it returns the system packages
despite the "include-system-site-packages = False" in pyvenv.cfg
When #3 is run inside command prompt "pip freeze" returns nothing correctly.
Come on guys, please don't make me use command prompt or powershell.
--
messages: 309215
nosy: Kevin
priority: normal
severity: normal
status: open
title: python -m venv activation issue when using cygwin on windows
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32451>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31625] stop using ranlib
Kevin added the comment: AIX supports the -s flag: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.cmds1/ar.htm#ar__row-d3e27561 -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue31625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35198] Build issue while compiling cpp files in AIX
Change by Kevin : -- keywords: +patch pull_requests: +9711 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34373] test_time errors on AIX
Change by Kevin : -- nosy: +kadler ___ Python tracker <https://bugs.python.org/issue34373> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15065] strftime format string %F %T consistency problem
New submission from Kevin : When using %F and %T in strftime on Mac and Linux the function works as expected, but it fails on Windows. Although these format strings are not in the Python documentation, the inconsistent behavior should be noted or corrected. If possible, the %F and %T could be expanded in some way on Windows systems or cause a format string error on POSIX systems so that the function behaves the same way across platforms. -- messages: 162779 nosy: kfairbanks priority: normal severity: normal status: open title: strftime format string %F %T consistency problem type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue15065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28951] re.flags not documented in Module Contents as promised.
New submission from kevin: In the online documentation of module re (https://docs.python.org/3.5/library/re.html) under 6.2.1. Regular Expression Syntax for item (?aiLmsux) we are promised "The flags are described in Module Contents" but no description is found there. In fact a number of other references are found to flags, but no description of the individual flags. AFAICT the closest thing to a description is found at the original reference -- at least it gives a code and name for each one. -- assignee: docs@python components: Documentation messages: 283034 nosy: 4Dummies, docs@python priority: normal severity: normal status: open title: re.flags not documented in Module Contents as promised. type: enhancement versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue28951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28952] csv.Sniffer().sniff(0 returns a value without the "strict" attribute
New submission from kevin: In https://docs.python.org/3.5/library/csv.html#dialects-and-formatting-parameters the Dialect objects are described as supporting, among others, the Dialect.strict attribute, with a default value of False. However, the sniff() returns an object lacking this attribute entirely, not even with the value None. At least on my inputs, which I'd include but they have personnel information. I can redact it if required. -- components: Library (Lib) messages: 283041 nosy: 4Dummies priority: normal severity: normal status: open title: csv.Sniffer().sniff(0 returns a value without the "strict" attribute type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue28952> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28951] re.flags not documented in Module Contents as promised.
kevin added the comment: Ordinarily when I see a cross-reference like that "the flags are described in foo" I expect foo to have a heading "FLAGS" so I can tell I'm looking at what was promised. Not knowing much about flags, it was not clear to me that those scattered lines re.A through re.X were the promised descriptions. I didn't even notice them until now, partly because it's made more confusing by all the stuff that's out of alphabetic order. Or I think it is -- it's hard to tell because of things like re.S and re.DOTALL being together. My current guess is that the uppercase things come before lowercase, but those odd pairings are definitely messing with my mind. All of which is just to say it probably makes perfect sense to someone who's used to it, but it's hard on someone new to these docs, and I'm not even new to Python, just to the re module. On Mon, Dec 12, 2016 at 11:03 AM, R. David Murray wrote: > > R. David Murray added the comment: > > When I follow the link to module contents, I find a list of the flags with > their descriptions. (re.A, re.I, etc, etc). Perhaps you are confusing the > letters used in the regular expression to represent the flags with the > flags themselves? I'm not sure how we could make that clearer. > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue28951> > ___ > -- Kevin O'Gorman #define QUESTION ((bb) || (!bb)) /* Shakespeare */ Please consider the environment before printing this email. -- Added file: http://bugs.python.org/file45934/unnamed ___ Python tracker <http://bugs.python.org/issue28951> __ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28951] re.flags not documented in Module Contents as promised.
kevin added the comment: Well, my original problem is that I wanted to find out what the flags did and could not find any pointer in the table of contents. I think they deserve either really good cross-references, or a heading in the contents. And a non-confusing alphabetized list, if they're going to be mixed in with other module contents. On Sat, Dec 17, 2016 at 6:13 AM, R. David Murray wrote: > > R. David Murray added the comment: > > Making a 'flags' subheading in module contents would be reasonable. > Alternatively we could just drop that parenthetical, since the descriptions > for each flag are themselves cross-linked. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue28951> > ___ > -- Kevin O'Gorman #define QUESTION ((bb) || (!bb)) /* Shakespeare */ Please consider the environment before printing this email. -- Added file: http://bugs.python.org/file45940/unnamed ___ Python tracker <http://bugs.python.org/issue28951> __ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28951] re.flags not documented in Module Contents as promised.
kevin added the comment: Oh, and on the alphabetized list, I suggest NOT listing synonyms together, but just mark some as "synonym for X" and listing them all alphabetically (according to "en" collation, not "C" so upper- and lower-case sort together, not separately). On Sat, Dec 17, 2016 at 6:13 AM, R. David Murray wrote: > > R. David Murray added the comment: > > Making a 'flags' subheading in module contents would be reasonable. > Alternatively we could just drop that parenthetical, since the descriptions > for each flag are themselves cross-linked. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue28951> > ___ > -- Kevin O'Gorman #define QUESTION ((bb) || (!bb)) /* Shakespeare */ Please consider the environment before printing this email. -- Added file: http://bugs.python.org/file45941/unnamed ___ Python tracker <http://bugs.python.org/issue28951> __ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29027] 3.5.2 compile error from ssl related.
New submission from kevin:
Download the python version 3.5.2 source code from official web site.
Compile the python code by the following steps:
sudo ./configure
sudo make
sudo make install
but from make, I get the following errors:
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:2582:46: error: dereferencing
pointer to incomplete type ‘X509_STORE {aka struct x509_store_st}’
flags = X509_VERIFY_PARAM_get_flags(store->param);
^
/home/boot/tools/Python-3.5.2/Modules/_ssl.c: In function
‘_ssl__SSLContext_load_cert_chain_impl’:
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:2782:48: error: dereferencing
pointer to incomplete type ‘SSL_CTX {aka struct ssl_ctx_st}’
pem_password_cb *orig_passwd_cb = self->ctx->default_passwd_callback;
^
/home/boot/tools/Python-3.5.2/Modules/_ssl.c: In function
‘_ssl__SSLContext_cert_store_stats_impl’:
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:3443:20: error: dereferencing
pointer to incomplete type ‘X509_OBJECT {aka struct x509_object_st}’
switch (obj->type) {
^
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:3453:18: error: ‘X509_LU_PKEY’
undeclared (first use in this function)
case X509_LU_PKEY:
then I install the openssl by compiling download code,and the ssl can work, and
compile python code,the error still exists.
please help me check where I take a mistake.
Thanks a lot.
--
assignee: christian.heimes
components: SSL
messages: 283699
nosy: christian.heimes, kevin.zhai80
priority: normal
severity: normal
status: open
title: 3.5.2 compile error from ssl related.
type: compile error
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue29027>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29027] 3.5.2 compile error from ssl related.
kevin added the comment: Hi Christian, Thanks for your reply. The machine's information as following: Platform: x86_64; OS: ubuntu16.04; Compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609; Openssl version:OpenSSL 1.1.0c 10 Nov 2016. -- ___ Python tracker <http://bugs.python.org/issue29027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29027] 3.5.2 compile error from ssl related.
kevin added the comment: Hi Christian, This issue is resolved. Thanks a lot. -- resolution: not a bug -> fixed ___ Python tracker <http://bugs.python.org/issue29027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29064] Package numpy can't be used normally
New submission from kevin: I used package numpy,but encounter the following error: Traceback (most recent call last): File "rgbtoyuv.py", line 2, in import numpy as np File "/usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/__init__.py", line 163, in from . import random File "/usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/random/__init__.py", line 99, in from .mtrand import * ImportError: /usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/random/mtrand.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf I have download the numpy install package,and installed. Platform ubuntu16.04 x86_64 python version: 3.5.2 numpy version:1.11.2 and try to version:1.9.0 also,but installed failed. Please help me find the reason,thanks a lot. -- components: Library (Lib) messages: 283949 nosy: kevin.zhai80 priority: normal severity: normal status: open title: Package numpy can't be used normally type: resource usage versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue29064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29064] Package numpy can't be used normally
kevin added the comment: Hi Xiang， Thanks for your information. -- resolution: third party -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue29064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27058] Tkinter's canvas' dashed lines have incorrect segment lengths
New submission from Kevin: When creating a dashed line using `Canvas.create_line`. Minimal reproducing example: from Tkinter import * root = Tk() canvas = Canvas(root, width=100, height=30, bg="black") canvas.pack() canvas.create_line((0,10,100,10), dash=(20,), fill="red") canvas.create_line((0,20,100,20), dash=(20,20), fill="green") root.mainloop() Expected result: each line segment should be 20 pixels wide, separated by gaps 20 pixels wide. Actual result: each line segment is 18 pixels wide, separated by gaps 6 pixels wide. See attached file for screenshot. Additional information: this problem appears to only occur on Windows. The Stack Overflow Python chat room attempted to replicate this issue, starting around here: http://chat.stackoverflow.com/transcript/message/30645798#30645798. Users of Windows 7, 8, and 10 were able to replicate the incorrect segmenting behavior. Users of Linux had correct segment lengths. (some Windows & 2.7 users also noticed that their green line was 3 pixel segments with 3 pixel gaps, but this seems to be an independent bug which was already fixed somewhere between 2.7.2 and 2.7.10.) -- components: Tkinter, Windows files: output.PNG messages: 265868 nosy: kms70847, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Tkinter's canvas' dashed lines have incorrect segment lengths versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file42901/output.PNG ___ Python tracker <http://bugs.python.org/issue27058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27058] Tkinter's canvas' dashed lines have incorrect segment lengths
Kevin added the comment:
Ok, I've tried testing Serhiy's `canvas_dash.tcl` file, by running:
import Tkinter
root = Tkinter.Tk()
root.tk.eval("source canvas_dash.tcl")
root.mainloop()
(I'm not sure if this counts as "pure" Tcl/Tk. I don't have any experience in
using Tcl/Tk outside of Python. If there's a way to execute `canvas_dash.tcl`
straight from the command line, I'm willing to try, but after some cursory
research I couldn't figure out how to do it.)
The result is the same as before: 18 pixel segments, 6 pixel gaps.
--
___
Python tracker
<http://bugs.python.org/issue27058>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27058] Tkinter's canvas' dashed lines have incorrect segment lengths
Kevin added the comment: This problem appears to go deeper than Python. On the TK bug tracker, under the issue "-dashofset option doesnt work on ms windows build" (https://core.tcl.tk/tk/tktview?name=1055974fff), a commenter mentions: > On Windows, only certain dash patterns and no dash offsets are supported. Which implies that you can't create segments and gaps of arbitrary length ratios- you can only select from a limited collection of premade patterns. This comment from tkWinDraw.c (https://github.com/tcltk/tk/blob/master/win/tkWinDraw.c#L1188) supports this: > Below is a simple translation of serveral dash patterns to valid windows > pen types. Far from complete, but I don't know how to do it better. The code goes on to invoke CreatePen (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183509%28v=vs.85%29.aspx), which only allows for four different variations of dashed line styles. Conclusions: 1) It isn't Python's fault. 2) The guy who wrote the Tk code was aware of the limitation at the time, so it's arguably not a bug. So, this issue ought to be closed; not much we can do, except perhaps petition the popular Tkinter reference websites to put up a warning label on their descriptions of the `dash` keyword argument. -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue27058> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46085] OrderedDict iterator allocates di_result unnecessarily
New submission from Kevin Shweh : The OrderedDict iterator caches a di_result tuple for use with iter(od.items()). It's *supposed* to only do that for the items() case, but the code does if (kind & (_odict_ITER_KEYS | _odict_ITER_VALUES)) to test for this case. This is the wrong test. It should be if ((kind & _odict_ITER_KEYS) && (kind &_odict_ITER_VALUES)) The current test allocates di_result for key and value iterators as well as items iterators. -- components: Library (Lib) messages: 408616 nosy: Kevin Shweh priority: normal severity: normal status: open title: OrderedDict iterator allocates di_result unnecessarily type: resource usage versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46085] OrderedDict iterator allocates di_result unnecessarily
Kevin Shweh added the comment: Almost - C's weird bitwise operator precedence means it has to be parenthesized as if ((kind & _odict_ITER_ITEMS) == _odict_ITER_ITEMS) -- ___ Python tracker <https://bugs.python.org/issue46085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32658] Metacharacter (\) documentation suggestion
Kevin Raeder added the comment: Sure! Thanks for paying attention to my suggestion. Kevin On Fri, Jan 21, 2022 at 10:42 AM mike mcleod wrote: > > mike mcleod added the comment: > > I would like to help with this issue. Is that acceptable? > > -- > nosy: +mikecmcleod > > ___ > Python tracker > <https://bugs.python.org/issue32658> > ___ > -- ___ Python tracker <https://bugs.python.org/issue32658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
New submission from Kevin Shweh :
This code in Thread._wait_for_tstate_lock:
try:
if lock.acquire(block, timeout):
lock.release()
self._stop()
except:
if lock.locked():
# bpo-45274: lock.acquire() acquired the lock, but the function
# was interrupted with an exception before reaching the
# lock.release(). It can happen if a signal handler raises an
# exception, like CTRL+C which raises KeyboardInterrupt.
lock.release()
self._stop()
raise
has a bug. The "if lock.locked()" check doesn't check whether this code managed
to acquire the lock. It checks if *anyone at all* is holding the lock. The lock
is almost always locked, so this code will perform a spurious call to
self._stop() if it gets interrupted while trying to acquire the lock.
Thread.join uses this method to wait for a thread to finish, so a thread will
spuriously be marked dead if you interrupt a join call with Ctrl-C while it's
trying to acquire the lock. Here's a reproducer:
import time
import threading
event = threading.Event()
def target():
event.wait()
print('thread done')
t = threading.Thread(target=target)
t.start()
print('joining now')
try:
t.join()
except KeyboardInterrupt:
pass
print(t.is_alive())
event.set()
Interrupt this code with Ctrl-C during the join(), and print(t.is_alive()) will
print False.
--
components: Library (Lib)
messages: 413106
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: Thread spuriously marked dead after interrupting a join call
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46726>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
Kevin Shweh added the comment: Issue 45274 was a subtly different issue. That was a problem that happened if the thread got interrupted *between* the acquire and the release, causing it to *not* release the lock and *not* perform end-of-thread cleanup. The fix for that issue caused this issue, which happens if the thread gets interrupted *during* the acquire, in which case it *does* release the lock (that someone else is holding) and *does* perform end-of-thread cleanup even though it's not supposed to do either of those things. -- ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
Kevin Shweh added the comment: The PR you submitted doesn't work, unfortunately. It essentially reintroduces issue 45274. If this line: if locked := lock.acquire(block, timeout): gets interrupted between the acquire and the assignment, locked is still False. That's rare, but so is an interruption between the acquire and the release, which is the original form of issue 45274. -- ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46722] Different behavior for functiools.partial between inspect.isfunction() and other inspect.is*function()
Kevin Shweh added the comment: Frankly, it doesn't make sense that isgeneratorfunction or iscoroutinefunction unwrap partials at all. The original justification for making them do that back in https://bugs.python.org/issue34890 was invalid - the original argument was that isfunction unwraps partials, but it doesn't, and I don't think it ever did. isfunction is supposed to be a very specific check for Python function objects. It rejects all sorts of other callables, like sum (a built-in function), super (a type), or method objects (which wrap functions in a very similar way to partial). Having it be a check for *either* a Python function object *or* a partial object wrapping a Python function object seems to just make it less useful. ------ nosy: +Kevin Shweh ___ Python tracker <https://bugs.python.org/issue46722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46774] Importlib.metadata.version picks first distribution not latest
New submission from Kevin Kirsche : When using importlib.metadata.version with tools such as poetry which may install the current package one or more times, importlib.metadata.version is not deterministic in returning the latest version of the package, instead returning the first one located. As it's unclear if this behavior is desired by importlib, I'm creating this issue to determine if this is intentional behavior or a bug. I have opened the following poetry issue: * https://github.com/python-poetry/poetry/issues/5204 I have also created the following reproduction repository for the installation issue: https://github.com/kkirsche/poetry-remove-untracked When the after is modified to return the version, it returns the first one found (e.g. if you go 3.0.0 -> 3.0.1 -> 3.0.2, each would be installed and the library would return 3.0.0 to the caller) Thank you for your time and consideration. I apologize if this is not something that requires action by the Python team. I'd be open to trying to submit a PR, but want to verify whether this is intentional or not. -- components: Library (Lib) messages: 413375 nosy: kkirsche2 priority: normal severity: normal status: open title: Importlib.metadata.version picks first distribution not latest type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46774] Importlib.metadata.version picks first distribution not latest
Change by Kevin Kirsche : -- nosy: +kkirsche ___ Python tracker <https://bugs.python.org/issue46774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45991] Improve ambiguous docstrings in pkgutil
Kevin Hock added the comment: At best it is ambiguous, with the class being confused with Str being called Path. Looking up "AttributeError: 'PosixPath' object has no attribute 'startswith'" gives a lot of results for similar issues, so I think the wording could be improved. -- ___ Python tracker <https://bugs.python.org/issue45991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45991] Improve ambiguous docstrings in pkgutil
Kevin Hock added the comment: > Maybe instead a note could be put in the Pathlib doc noting functions that > accept path arguments might not accept Path objects? My concern with that is that someone using `pkgutil` wouldn't see it. However, I can see the argument that fixing the 'source' is better than each use. I'm not sure how wide-spread these kind of issues are to weigh in on how many 'uses' there are. If that makes sense. >Should pkgutil call os.fspath() in this case? I really like that idea. (I haven't contributed to CPython before, so I'll let someone else weigh in on if that is standard practice.) -- ___ Python tracker <https://bugs.python.org/issue45991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1060] zipfile cannot handle files larger than 2GB (inside archive)
New submission from Kevin Ar18:
Summary:
If you have a zip file that contains a file inside of it greater than
2GB, then the zipfile module is unable to read that file.
Steps to Reproduce:
1. Create a zip file several GB in size with a file inside of it that is
over 2GB in size.
2. Attempt to read the large file inside the zip file. Here's some
sample code:
import zipfile
import re
dataObj = zipfile.ZipFile("zip.zip","r")
for i in dataObj.namelist():
if(i[-1] == "/"):
print "dir"
else:
fileName = re.split(r".*/",i,0)[1]
fileData = dataObj.read(i)
Result:
Python returns the following error:
File "...\zipfile.py", line 491, in read bytes =
self.fp.read(zinfo.compress_size)
OverflowError: long it too large to convert to int
Expected Result:
It should copy the data into the variable fileData...
I'll try to post more info in a follow-up.
--
components: Library (Lib)
messages: 55444
nosy: Kevin Ar18
severity: normal
status: open
title: zipfile cannot handle files larger than 2GB (inside archive)
type: compile error
versions: Python 2.6
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1060>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1060] zipfile cannot handle files larger than 2GB (inside archive)
Kevin Ar18 added the comment: Here's another bug report that talks about a 2GB file limit: http://bugs.python.org/issue1189216 The diff offered there does not solve the problem; actually it's possible that the diff may not have anything to do with fixing the problem (though I'm not certain), but may just be a readability change. I tried to program a solution based on other stuff I saw/read on the internet, but ran into different problems I took the line: bytes = self.fp.read(zinfo.compress_size) and made it read a little bit at a time and add the result to bytes as it went along. This was really slow (as it had to add the result to the larger and larger bytes string each time); I tried with a list, but I couldn't find how to join the list back together into a string when done (similar to the javascript join() method). However, even with the list method, I ran into an odd "memory error," as it looped through into the higher numbers, that I have no idea why it was happening, so I gave up at that point. Also, I have no idea if this one line in the zipfile module is the only problem or if there are others that will pop up once you get that part fixed. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1060> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1060] zipfile cannot handle files larger than 2GB (inside archive)
Kevin Ar18 added the comment: Just some thoughts In posting about this problem elsewhere, it has been argued that you shouldn't be copying that much stuff into memory anyways (though there are possible cases for a need for that). However, the question is what should the zipfile module do. At the very least it should account for this 2GB limitation and say it can't do it. However, how it should interact with the programmer is another question. In one of the replies, I am told that strings have a 2GB limitation, which means the zipfile module can't be used in it's current form, even if fixed. Does this mean that the zipfile module needs to add some additional methods for incrementally getting data and writing data? Or does it mean that programmers should be the ones to program an incremental system when they need it... Or? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1060> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1060] zipfile cannot handle files larger than 2GB (inside archive)
Kevin Ar18 added the comment: So, just add an error to the module (so it won't crash)? BTW, is Python 2.6 ready for use? I could use that feature now. :) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1060> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1060] zipfile cannot handle files larger than 2GB (inside archive)
Kevin Ar18 added the comment: Maybe a message that says that strings on 32-bit CPUs cannot handle more than 2GB of data; use the stream instead? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1060> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1232] %f prints the wrong 6 decimal places
New submission from Kevin McKiou: >>> print "price is: %f" % 5.1234567 price is: 5.123457 I was testing the statement about "prints to 6 decimal places". Sure enough, it printed only 6 decimal places, but it skipped over the 6th decimal place and printed the 7th. I am using Python version 2.5.1 and IDLE version 1.2.1 -- components: Interpreter Core messages: 56218 nosy: kmckiou severity: major status: open title: %f prints the wrong 6 decimal places type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1232> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1232] %f prints the wrong 6 decimal places
Kevin McKiou added the comment: Martin, Oops. Sorry about that. Hey, I even tried it with more decimals. It never occurred to me it was rounding. I thought it was simply printing a certain number of decimals. Hmmm...looking at my C manual...by golly, printf does round. Thanks, - Kevin Kevin McKiou +1 630 979 2577 [EMAIL PROTECTED] __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1232> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1311] os.path.exists(os.devnull) regression on windows
Kevin Dwyer added the comment:
I tried this under Python 2.3.3, 2.5.1 (native) and 2.3.4 (cygwin). The
operating system is Windows 2000 SP4.
C:\Python23>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> print os.path.exists('nul')
True
C:\Python25>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> print os.path.exists('nul')
False
$ python
Python 2.3.4 (#1, Jun 13 2004, 11:21:03)
[GCC 3.3.1 (cygming special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> print os.path.exists('nul')
True
So there does seem to be a change in behaviour at 2.5.
--
nosy: +kdwyer
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1311>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1311] os.path.exists(os.devnull) regression on windows
Kevin Dwyer added the comment:
Ok, it seems that Python 2.5 implements two new functions
Py_GetFileAttributesExA and Py_GetFileAttributesExW in posixmodule.c
within the #ifdef MS_WINDOWS block that may return
ERROR_INVALID_PARAMETER to os.stat, which will percolate WindowsError up
to os.exists():
In both functions we find:
static BOOL WINAPI
Py_GetFileAttributesExA(LPCSTR pszFile,
GET_FILEEX_INFO_LEVELS level,
LPVOID pv)
{
BOOL result;
LPWIN32_FILE_ATTRIBUTE_DATA pfad = pv;
/* First try to use the system's implementation, if that is
available and either succeeds to gives an error other than
that it isn't implemented. */
check_gfax();
if (gfaxa) {
result = gfaxa(pszFile, level, pv);
if (result || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED)
return result;
}
/* It's either not present, or not implemented.
Emulate using FindFirstFile. */
if (level != GetFileExInfoStandard) {
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
...
static BOOL WINAPI
Py_GetFileAttributesExW(LPCWSTR pszFile,
GET_FILEEX_INFO_LEVELS level,
LPVOID pv)
{
BOOL result;
LPWIN32_FILE_ATTRIBUTE_DATA pfad = pv;
/* First try to use the system's implementation, if that is
available and either succeeds to gives an error other than
that it isn't implemented. */
check_gfax();
if (gfaxa) {
result = gfaxw(pszFile, level, pv);
if (result || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED)
return result;
}
/* It's either not present, or not implemented.
Emulate using FindFirstFile. */
if (level != GetFileExInfoStandard) {
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
...
I'm neither a C nor a win32api programmer - can anyone explain the
purpose of this code?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1311>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1337] Tools/msi/msi.py does not work with PCBuild8
New submission from Kevin Watters: The msi.py script for creating an Windows MSI installer from a Python source tree has hardcoded values for "PCBuild." The newer MSVC 2005 build directory is "PCBuild8" and has a slightly different structure. msi.py needs to be changed to be able to work with a 2005-built Python tree as well. -- components: Build messages: 56791 nosy: kevinwatters severity: normal status: open title: Tools/msi/msi.py does not work with PCBuild8 type: rfe versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1337> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1320] PCBuild8 Solution Support Changes
Kevin Watters added the comment: This patch did not work for me. After running build_ssl.bat, the last couple lines of my console are: cl /Fotmp32dll\cfb_enc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D DSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENS SL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto\ des\cfb_enc.c cfb_enc.c cl /Fotmp32dll\ofb64ede.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN - DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPEN SSL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto \des\ofb64ede.c ofb64ede.c cl /Fotmp32dll\enc_read.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN - DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -DBN_ASM -DMD5_ASM -DSHA1_ASM -DRMD160_ASM -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPEN SSL_NO_MDC2 -DOPENSSL_NO_KRB5 -D_WINDLL -DOPENSSL_BUILD_SHLIBCRYPTO -c .\crypto \des\enc_read.c enc_read.c .\crypto\des\enc_read.c(150) : error C2220: warning treated as error - no 'objec t' file generated .\crypto\des\enc_read.c(150) : warning C4996: 'read' was declared deprecated C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\io.h(329) : see de claration of 'read' Message: 'The POSIX name for this item is deprecated. Instead, use the I SO C++ conformant name: _read. See online help for details.' .\crypto\des\enc_read.c(172) : warning C4996: 'read' was declared deprecated C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\io.h(329) : see de claration of 'read' Message: 'The POSIX name for this item is deprecated. Instead, use the I SO C++ conformant name: _read. See online help for details.' NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\c l.EXE"' : return code '0x2' Stop. Executing ms\ntdll.mak failed 2 -- nosy: +kevinwatters __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1320> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12629] HTMLParser silently stops parsing with malformed attributes
New submission from Kevin Stock : Given the input '', HTMLParser only detects the opening x tag, and then stops parsing. Ideally this should behave like the case '' which raises an error and then can continue parsing the close x tag. -- components: Library (Lib) files: test.py messages: 141051 nosy: teoryn priority: normal severity: normal status: open title: HTMLParser silently stops parsing with malformed attributes type: behavior versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22745/test.py ___ Python tracker <http://bugs.python.org/issue12629> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12629] HTMLParser silently stops parsing with malformed attributes
Kevin Stock added the comment: A workaround is to call close() after feed(), which I supposed I should have done anyways. However, this does not resolve the issue that the two cases behave so differently. The code that causes the difference is lines 351-355 of parser.py, which also has a misleading comment stating it detects the / in a /> ending (which is actually done at 334). -- ___ Python tracker <http://bugs.python.org/issue12629> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12932] dircmp does not allow non-shallow comparisons
New submission from Kevin Smith : While filecmp.cmp and filecmp.cmpfiles allow a shallow option to be specified to invoke a more involved comparison of files, filecmp.dircmp does not. It is limited to shallow-only comparisons. This could be solved quite easily by adding a shallow keyword option to dircmp then changing the phase3 method to the following. def phase3(self): # Find out differences between common files xx = cmpfiles(self.left, self.right, self.common_files, self.shallow) self.same_files, self.diff_files, self.funny_files = xx -- components: Library (Lib) messages: 143692 nosy: kesmit priority: normal severity: normal status: open title: dircmp does not allow non-shallow comparisons type: feature request versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue12932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9770] curses.isblank function doesn't match ctype.h
New submission from Kevin Thibedeau : The isblank() function defined in curses.ascii is incorrect and doesn't match the output from C's isblank() from ctype.h Incorrect definition: def isblank(c): return _ctoi(c) in (8,32) Should be: def isblank(c): return _ctoi(c) in (9,32) This most likely affects all versions of Python, not just 2.7. -- components: Library (Lib) messages: 115544 nosy: kevinpt priority: normal severity: normal status: open title: curses.isblank function doesn't match ctype.h type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9770> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
New submission from Kevin Hunter : Should Python enable a way for folks to inform the OS of MADV_MERGEABLE memory? I can't speak for other OSs, but Linux added the ability for processes to inform the kernel that they have memory that will likely not change for a while in 2.6.32. This is done through the madvise syscall with MADV_MERGEABLE. http://www.kernel.org/doc/Documentation/vm/ksm.txt After initial conversations in IRC, it was suggested that this would be difficult in the Python layer, but that the OS doesn't care what byte page it's passed as "mergeable". Thus when I, as an application programmer, know that I have some objects that will be around "for awhile", and that won't change, I can let the OS know that it might be beneficial to merge them. I suggest this might be a library because it may only be useful for certain projects. -- components: Library (Lib) messages: 117317 nosy: hunteke priority: normal severity: normal status: open title: Allow memory sections to be OS MERGEABLE type: feature request ___ Python tracker <http://bugs.python.org/issue9942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Kevin Hunter added the comment: My first thought is "Why is the reference counter stored with the object itself?" I imagine there are very good reasons, however, and this is not an area in which I have much mastery. Answering the question as best I can: I don't know how the reference counter is implemented in CPython, but if it's just a field in a struct, then madvise could be sent the memory location starting with the byte immediately following the reference counter. If there's more to it than that, I'll have to back off with "I don't know." I'm perhaps embarrassed that I'm not at all a Python developer, merely a Python application developer. I have a few Python projects that are memory hungry, that at first glance I believe to be creating MERGEABLE objects. -- ___ Python tracker <http://bugs.python.org/issue9942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Kevin Hunter added the comment: > Well, first, this would only work for large objects. [...] > Why do you think you might have such duplication in your workload? Some of the projects with which I work involve multiple manipulations of large datasets. Often, we use Python scripts as "first and third" stages in a pipeline. For example, in one current workflow, we read a large file into a cStringIO object, do a few manipulations with it, pass it off to a second process, and await the results. Meanwhile, the large file is sitting around in memory because we need to do more manipulations after we get results back from the second application in the pipeline. "Graphically": Python Script A->External App->Python Script A read large data process data more manipulations Within a single process, I don't see any gain to be had. However, in this one use-case, this pipeline is running concurrently with a number of copies with slightly different command line parameters. -- ___ Python tracker <http://bugs.python.org/issue9942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Kevin Hunter added the comment: > Why do you read it into a cStringIO? A cStringIO has the same interface > as a file, so you could simply operate on the file directly. In that particular case, because it isn't actually a file. That workflow was my attempt at simplification to illustrate a point. I think the point is moot however, as I've gotten what I needed from this feature request/discussion. Not one, but three Python developers seem opposed to the idea, or at least skeptical. That's enough to tell me that my first-order supposition that Python objects could be MERGEABLE is not on target. Cheers. -- ___ Python tracker <http://bugs.python.org/issue9942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10102] mktime adding an hour in April (naive struct)?
New submission from Kevin Barnhart : Just starting to dabble in the world of time and datetime objects. I was converting an array of datetime objects to an array of floats via mktime to do some data analysis. I have ran into an issue where mktime seems to be adding an hour on April 6, 2003. Attached is an example script which I used to create the below output: Python version: (2, 6, 5, 'final', 0) Epoch: time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0) First datetime: 2003-04-06 02:58:17 Second datetime: 2003-04-06 03:13:17 Is first datetime prior to second?: True First datetime, time struct: time.struct_time(tm_year=2003, tm_mon=4, tm_mday=6, tm_hour=2, tm_min=58, tm_sec=17, tm_wday=6, tm_yday=96, tm_isdst=-1) Second datetime, time struct: time.struct_time(tm_year=2003, tm_mon=4, tm_mday=6, tm_hour=3, tm_min=13, tm_sec=17, tm_wday=6, tm_yday=96, tm_isdst=-1) Is first time struct prior to second?: True First timestamp generated by mktime: 1049623097.0 Second timestamp generated by mktime: 1049620397.0 Is first timestamp less than second timestamp?: False First recovered datetime: 2003-04-06 03:58:17 Second recovered datetime: 2003-04-06 03:13:17 Is first recovered prior to second recovered?: False Is first recovered datetime same as original?: False Is second recovered datetime same as original?: True -- files: mktimeissue.py messages: 118662 nosy: barnburnr priority: normal severity: normal status: open title: mktime adding an hour in April (naive struct)? type: behavior Added file: http://bugs.python.org/file19232/mktimeissue.py ___ Python tracker <http://bugs.python.org/issue10102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10102] mktime adding an hour in April (naive struct)?
Kevin Barnhart added the comment: Wow. Should have caught that. Thanks for the response. Kevin -- ___ Python tracker <http://bugs.python.org/issue10102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10107] Quitting IDLE on Mac doesn't save unsaved code
Kevin Walzer added the comment:
Try something like this:
root.createcommand('::tk::mac::Quit', )
This will map whatever function IDLE calls to prompt the user to save data
before closing, to the Apple quit event.
--
nosy: +wordtech
___
Python tracker
<http://bugs.python.org/issue10107>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10107] Quitting IDLE on Mac doesn't save unsaved code
Kevin Walzer added the comment: Ronald--I think it works with both 8.4 and 8.5. -- ___ Python tracker <http://bugs.python.org/issue10107> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7978] SocketServer doesn't handle syscall interruption
Changes by Kevin Chen : -- nosy: +kchen ___ Python tracker <http://bugs.python.org/issue7978> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting "build_ext --libraries" take more than one lib
Palm Kevin added the comment: This one is really annoying. Could you please consider fixing this one for the next release? (=lightweight change) -- nosy: +palm.kevin ___ Python tracker <http://bugs.python.org/issue1326113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326113] Letting "build_ext --libraries" take more than one lib
Palm Kevin added the comment: I applied the patch proposed by slanger. This one is working. Now, I'm executing this instruction to build my extension: "%pythonRoot%\python.exe" setup.py build_ext --include-dirs "C:\MyApp\include" --library-dir "C:\MyApp\lib" --libraries "myLib1 myLib2" If I don't use the patch, then the error I get is 'unresolved external symbol _xxx referenced in function _abc'. Which is quite normal since I can only point to one library... -- ___ Python tracker <http://bugs.python.org/issue1326113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
