[issue40508] IDLE won't open
Change by Louis : -- components: macOS files: IDLE.app.zip nosy: Louis, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: IDLE won't open type: performance versions: Python 3.6 Added file: https://bugs.python.org/file49120/IDLE.app.zip ___ Python tracker <https://bugs.python.org/issue40508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40508] IDLE won't open
New submission from Louis : Hi, I cannot open IDLE. When i try and open it from finder it says that the file could not be opened. When I try and open it from the dock, it bounces once and then nothing else happens. When i try and open it from terminal, it says that there is a bad cpu type in the executable. -Louis -- ___ Python tracker <https://bugs.python.org/issue40508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40508] IDLE won't open
Louis added the comment: Mac OS Catalina 10.15.4 -- ___ Python tracker <https://bugs.python.org/issue40508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40508] IDLE won't open
Louis added the comment: Thank You for your reply -Louis -- ___ Python tracker <https://bugs.python.org/issue40508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38477] magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7
New submission from Louis Huemiller : Have created a program that by brute force determines all reachable states of a 2-by-2 MagicCube, sometimes referred to as a 2x2 Rubick's cube. On one of my servers, which is described in the attached file 20191011b_configuration, this program takes 19520.03 seconds to execute under Python2.7.15+, while under 3.8.0rc1 it takes 21887.53 seconds. This program is taking 12.13% longer to execute with 3.8.0rc1 versus 2.7.15+. The exact versions of Python as reported by sys.version are: 2.7.15+ (default, Oct 7 2019, 17:39:04) [GCC 7.4.0] 3.8.0rc1 (default, Oct 1 2019, 21:48:24) [GCC 7.4.0] Used the following script to execute this program under Python 2.7, 3.6, 3.7, and 3.8: mkdir -p ./results echo " git log " > ./results/20191011b_configuration git log -n4 >> ./results/20191011b_configuration echo "" >> ./results/20191011b_configuration echo " uname " >> ./results/20191011b_configuration uname -a >> ./results/20191011b_configuration echo "" >> ./results/20191011b_configuration echo " lsb_release " >> ./results/20191011b_configuration lsb_release -a >> ./results/20191011b_configuration echo "" >> ./results/20191011b_configuration echo " lshw " >> ./results/20191011b_configuration sudo lshw >> ./results/20191011b_configuration make clean make ./target/permutations2x2 > \ ./results/20191011b_magiccube2x2_permutations_cxx_unordered_map 2>&1 python3.8 ./permutations2x2 > \ ./results/20191011b_magiccube2x2_permutations_python3.8.0rc1 2>&1 python3.7 ./permutations2x2 > \ ./results/20191011b_magiccube2x2_permutations_python3.7 2>&1 python3.6 ./permutations2x2 > \ ./results/20191011b_magiccube2x2_permutations_python3.6 2>&1 python2.7 ./permutations2x2 > ./results/20191011b_magiccube2x2_permutations_python2.7 2>&1 Doing egrep "^# Total_Time:" on each of the output files, shows that the various executions took the following amount of time: cxx_unordered_map:# Total_Time: 1098.25 python2.7:# Total_Time: 19520.03 python3.6:# Total_Time: 19562.28 python3.7:# Total_Time: 17012.67 python3.8.0rc1:# Total_Time: 21887.53 Under Python2.7 and Python3.6 the program ran in approximately the same amount of time, while under Python3.7 it ran 12.8% faster than execution with Python2.7. Finally, the python3.8.0rc1 execution is noticeably slower than all the other executions, at 12.1% lower than Python2.7 and 28.6% slower than Python3.7. The source for the magic_cube2x2 program is available under gist.github.com at: https://gist.github.com/lhuemill/f1273291e5f5e85e4b42e5c7614e60ef This program creates a fairly large dictionary of 88.179840M entries. Each entry has a key of a string of length 29 and a value string of with a maximum length of 22 characters. A quick back-of-the-envelope calculation shows that this dictionary would use approximately 9GB of memory, but for some reason, all of the Python executions use approximately 22.6GB of memory. Even the C++ version is using 20.2GB when the permutations are stored in an unordered_map and 20.55GB when stored in a map. Quite surprising that the C++ is using over twice the expected amount of memory. CAUTION: When executing this program with less than the needed amount of physical memory, be careful that swap is not backed by a flash device. Doing so will likely cause a significant amount of I/O to the flash device and likely quickly wear it out. -- files: 20191005b_configuration messages: 354682 nosy: Louis Huemiller priority: normal severity: normal status: open title: magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7 type: performance versions: Python 3.8 Added file: https://bugs.python.org/file48660/20191005b_configuration ___ Python tracker <https://bugs.python.org/issue38477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38477] magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7
Louis Huemiller added the comment: Attached is a chart, which shows the results from the runs mentioned in the initial post. This chart was produced through the use of: ../permutations2x2_chart_results \ -f ./20191011b_chart.svg \ C++unordered_map:./20191011b_magiccube2x2_permutations_cxx_unordered_map \ Python2.7:./20191011b_magiccube2x2_permutations_python2.7 \ Python3.6:./20191011b_magiccube2x2_permutations_python3.6 \ Python3.7:./20191011b_magiccube2x2_permutations_python3.7 \ Python3.8.0rc1:./20191011b_magiccube2x2_permutations_python3.8.0rc1 The permutations2x2_chart_results program is present in the gist.github repository mentioned in the initial post. -- Added file: https://bugs.python.org/file48664/20191011b_chart.svg ___ Python tracker <https://bugs.python.org/issue38477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38477] magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7
Louis Huemiller added the comment: Each of the Python runs mentioned in the initial post took around 4 hours to execute. Although not as accurate, the issue can be demonstrated in less than 5 minutes through the use of: # If needed use the following to install Python3.8.0rc1 $ apt-get update $ sudo apt-get upgrade $ sudo add-apt-repository ppa:deadsnakes/ppa $ sudo apt update $ sudo apt install python3.8 # Use Python3.7 to produce baseline. $ python3.7 permutations2x2 --max_depth 6 | egrep "^# Total_Time" # Perform Python3.8.0rc1 execution python3.8 permutations2x2 --max_depth 6 | egrep "^# Total_Time" When I did this on my server the Python3.7 execution produced: # Total_Time: 62.46 While the Python3.8.0rc1 execution produced: # Total_Time: 79.72 By running the program with "--max_depth 6" specified, the program only traversed through permutations that are up to 6 moves from the initial position. Although much less than running through an unlimited number of moves, the above run still showed the Python3.8.0rc1 run as 26.7% ((79.72 - 62.46) / 62.46) slower than the Python3.7 execution. Which is close to the 28.6% reduction in performance seen from runs with unlimited depth of moves. -- ___ Python tracker <https://bugs.python.org/issue38477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38477] magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7
Louis Huemiller added the comment: Thank you for looking into the potential issue. Instead of getting Python3.8 from ppa:deadsnakes/ppa, I downloaded the source from: https://www.python.org/ftp/python/3.8.0/Python-3.8.0rc1.tgz Then did the following to build and install it: $ cd /usr/src $ sudo tar xzf ~/Python-3.8.0rc1.tgz $ cd Python-3.8.0rc1/ $ sudo ./configure --enable-optimizations $ sudo apt-get install zlib1g-dev $ sudo -H make altinstall Then re-running the magiccube2x2 permutations with a max_depth of 6 I obtained: $ python3.7 permutations2x2 --max_depth 6 | egrep "^# Total_Time" # Total_Time: 61.90 $ python3.8 permutations2x2 --max_depth 6 | egrep "^# Total_Time" # Total_Time: 82.45 Unfortunately, this still shows the Python3.8 execution as significantly slower, in this case 33.2% slower. Not sure of the cause, but perhaps I wasn't completely successful at removing the prior installation from ppa:deadsnakes/ppa. I removed it through the use of: $ sudo apt remove python3.8 $ sudo add-apt-repository -r ppa:deadsnakes/ppa $ shutdown -r now Next step I will completly re-install this server and then only install Python3.8 from https://www.python.org/ftp/python/3.8.0/Python-3.8.0rc1.tgz. -- ___ Python tracker <https://bugs.python.org/issue38477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38477] magiccube2x2 permutations 28% slower with Python 3.8.0rc1 vs 3.7
Louis Huemiller added the comment: Reinstalled the server I'd been using for this issue, with Ubuntu 18.04.3 LTS Server amd64. This installation already came with Python3.6.8. Downloaded and installed Python3.7.3 and 3.8.0 from: https://www.python.org/ftp/python/3.7.3/Python-3.7.3.tgz https://www.python.org/ftp/python/3.8.0/Python-3.8.0.tgz The installation process was somewhat complicated, with several to be discovered prerequisites. Used "apt install" to install the following needed dependencies: build-essential checkinstall libreadline-gplv2-dev libncursesw5-dev libssl-dev libsqlite3-dev tk-dev libgdbm-dev libc6-dev libbz2-dev zlib1g-dev libffi-dev Then was able to do the following to build and install the downloaded Python3.7.3 and 3.8.0: $ sudo ./configure --enable-optimizations $ sudo -H make altinstall Then downloaded a clone of my magiccube2x2 repository and obtained the following results: $ python3.6 ./permutations2x2 --max_depth 6 | egrep "^# Total_Time:" # Total_Time: 69.02 $ python3.7 ./permutations2x2 --max_depth 6 | egrep "^# Total_Time:" # Total_Time: 84.52 $ python3.8 ./permutations2x2 --max_depth 6 | egrep "^# Total_Time:" # Total_Time: 83.14 In this case the runtimes under both of the Python versions that I downloaded the source for and built are significantly slower than the run with python3.6, which came already as part of Ubuntu 18.04.3. Instead of using the version of python3.7.3 that I built, was able to do: $ sudo apt install python3.7 to get one that had already been built for Ubuntu. Doing this allowed the following result: $ /usr/bin/python3.7 ./permutations2x2 --max_depth 6 \ | egrep "^# Total_Time:" # Total_Time: 62.39 Which is better than even the Python3.6 result. Unfortunately, there is not currently a pre-built Ubuntu package for Python3.8 and the one from ppa:deadsnakes/ppa, I already know has the performance issue. I did some searching on wiki.python.org and I was unable to find any instructions for how to build python from the source. Perhaps the instructions are already there but I was unable to find them. Perhaps this issue should be re-opened as a documentation error. I could really use instructions on how to built a performance version of Python and I suspect several others could also use this. For example, I'd like to pass that information to the maintainers of the deadsnakes repository. -- ___ Python tracker <https://bugs.python.org/issue38477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34434] Removal of kwargs for built-in types not covered with "changed in Python" note in documentation
Change by Louis Sautier : -- nosy: +sbraz nosy_count: 7.0 -> 8.0 pull_requests: +28201 pull_request: https://github.com/python/cpython/pull/29976 ___ Python tracker <https://bugs.python.org/issue34434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42114] Documentation of ctypes.CDLL does not correspond to code
Change by Louis Sautier : -- keywords: +patch nosy: +sbraz nosy_count: 1.0 -> 2.0 pull_requests: +28202 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29976 ___ Python tracker <https://bugs.python.org/issue42114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43136] multiprocessing.Queue.get(block=False) can raise queue.Empty on non-empty queue
New submission from Louis Sautier :
Hello,
I have noticed that when multiple processes try to simultaneously get items
from a multiprocessing queue with block=False, it will raise queue.Empty even
though there are still items in it.
Adding a multiprocessing lock around calls to Queue.get fixes the problem.
Please consider the attached reproducer script and its output:
$ ./queue_test.py
using processes
2021-02-05T12:48:21.742728 worker 0 got 0, queue size was 100
2021-02-05T12:48:21.743702 worker 1 got 1, queue size was 99
2021-02-05T12:48:21.744059 worker 2 got 2, queue size was 98
2021-02-05T12:48:21.745352 worker 3 got 3, queue size was 97
2021-02-05T12:48:22.743905 worker 1 queue is EMPTY, size was 96
2021-02-05T12:48:22.744064 worker 0 got 4, queue size was 96
2021-02-05T12:48:22.746525 worker 3 queue is EMPTY, size was 95
2021-02-05T12:48:22.749573 worker 2 got 5, queue size was 95
2021-02-05T12:48:23.744474 worker 0 got 6, queue size was 94
2021-02-05T12:48:23.750728 worker 2 got 7, queue size was 93
2021-02-05T12:48:24.745852 worker 0 got 8, queue size was 92
2021-02-05T12:48:24.751827 worker 2 got 9, queue size was 91
[…]
I have been able to reproduce this problem with Python 2.7 and 3.5 through 3.9
(3.10 untested).
When using threads and queue.Queue instead of their multiprocessing
counterparts, the problem is not present ("./queue_test.py thread" → no
spurious exceptions until the queue is actually empty).
--
components: Library (Lib)
files: queue_test.py
messages: 386525
nosy: sbraz
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.get(block=False) can raise queue.Empty on
non-empty queue
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49791/queue_test.py
___
Python tracker
<https://bugs.python.org/issue43136>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43136] multiprocessing.Queue.get(block=False) can raise queue.Empty on non-empty queue
Change by Louis Sautier : -- nosy: +mdk ___ Python tracker <https://bugs.python.org/issue43136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37139] Inconsistent behavior of email.header.decode_header
New submission from Louis Abraham : Hi, (this is my first issue btw) I think <https://docs.python.org/3/library/email.header.html#email.header.decode_header> has a broken behavior. It returns a list of `(decoded_string, charset)` pairs. However, `decoded_string` can be either a string or bytes. I have no preference but it should really be of one type. -- messages: 344392 nosy: louis.abra...@yahoo.fr priority: normal severity: normal status: open title: Inconsistent behavior of email.header.decode_header ___ Python tracker <https://bugs.python.org/issue37139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37139] Inconsistent behavior of email.header.decode_header
Louis Abraham added the comment: Indeed, this is exactly the same (I should have researched more, my bad). The problem is that I'm using mailbox.Maildir which uses the Compat32 API. Do you think I should create an issue for Maildir to support the new EmailMessage API? -- ___ Python tracker <https://bugs.python.org/issue37139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36038] ^ used in inaccurate example in regex-howto
New submission from Louis Michael : at https://docs.python.org/3/howto/regex.html#regex-howto and https://docs.python.org/3.8/howto/regex.html#regex-howto https://docs.python.org/3.7/howto/regex.html#regex-howto https://docs.python.org/3.6/howto/regex.html#regex-howto https://docs.python.org/3.5/howto/regex.html#regex-howto https://docs.python.org/3.4/howto/regex.html#regex-howto https://docs.python.org/2.7/howto/regex.html#regex-howto The following paragraph seems to have a small issue: " You can match the characters not listed within the class by complementing the set. This is indicated by including a '^' as the first character of the class; '^' outside a character class will simply match the '^' character. For example, [^5] will match any character except '5'. " ^ does not simply match ^ outside a character class since is a special character that represents the start of the string. I think the paragraph should read: You can match the characters not listed within the class by complementing the set. This is indicated by including a '^' as the first character of the class; '^' will act differently outside a character class as explained later. For example, [^5] will match any character except '5'. -- assignee: docs@python components: Documentation messages: 335953 nosy: docs@python, eric.araujo, ezio.melotti, louism, mdk, willingc priority: normal severity: normal status: open title: ^ used in inaccurate example in regex-howto type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35584] Wrong statement about ^ in howto/regex.rst
Change by Louis Michael : -- keywords: +patch pull_requests: +11968 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30395] deadlocked child process after forking on pystate.c's head_mutex
New submission from Louis Brandy: A forked process (via os.fork) can inherit a locked `head_mutex` from its parent process and will promptly deadlock in this stack (on my linux box): Child Process (deadlocked): #0 0x7f1a4da82e3c in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f1a4c2964e0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205 #1 0x7f1a4da82e3c in do_futex_wait (sem=sem@entry=0x7f1a4c2964e0, abstime=0x0) at sem_waitcommon.c:111 #2 0x7f1a4da82efc in __new_sem_wait_slow (sem=0x7f1a4c2964e0, abstime=0x0) at sem_waitcommon.c:181 #3 0x7f1a4da82fb9 in __new_sem_wait (sem=) at sem_wait.c:29 #4 0x7f1a4de4c605 in PyThread_acquire_lock_timed (lock=0x7f1a4c2964e0, microseconds=-1, intr_flag=0) at Python/thread_pthread.h:352 #5 0x7f1a4de4c4b4 in PyThread_acquire_lock (lock=, waitflag=waitflag@entry=1) at Python/thread_pthread.h:556 #6 0x7f1a4dd59e08 in _PyThreadState_DeleteExcept (tstate=0x7f19f2301800) at Python/pystate.c:483 #7 0x7f1a4dd46af4 in PyEval_ReInitThreads () at Python/ceval.c:326 #8 0x7f1a4dd78b0b in PyOS_AfterFork () at ./Modules/signalmodule.c:1608 The parent process has a race between one thread calling `os.fork` (and holding the GIL) and another (in our case C++) thread trying to use PyGILState_Ensure. PyGILState_Ensure will grab the head_mutex before it tries to get the GIL. So if a fork happens in this critical section, the child process will get the locked head_mutex. The path from PyGILState_Ensure -> head_mutex looks like this: #0 new_threadstate (interp=0x7fb5fd483d80, init=init@entry=1) at Python/pystate.c:183 #1 0x7fb5ff149027 in PyThreadState_New (interp=) at Python/pystate.c:250 #2 0x7fb5ff006ac7 in PyGILState_Ensure () at Python/pystate.c:838 Possible fix? A simple fix would be to, inside PyOS_AfterFork, reset/unlock pystate.c's head_mutex if it's already locked. Unclear if this is related to: https://bugs.python.org/issue28812 -- components: Interpreter Core messages: 293906 nosy: Louis Brandy priority: normal severity: normal status: open title: deadlocked child process after forking on pystate.c's head_mutex versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30395] deadlocked child process after forking on pystate.c's head_mutex
Louis Brandy added the comment: Thanks to everyone jumping in. I need no convincing that mixing forks and threads isn't just a problem but a problem factory. Given that the rest of this code seems to try to avoid similar deadlocks with similar mutexes, I figured we'd want to include this mutex to make a best-effort at being safe here. That made it worth reporting. To be sure, I still believe that the application code that led us here needs deeper fixes to address the fork/thread problems. -- ___ Python tracker <http://bugs.python.org/issue30395> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32304] Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code
Louis Lecaroz added the comment: Hi, First of all, thank you so much for having fixed this bug, I checked in 3.5 & it seems that this fix needs to be also backport in 3.5 branch & certainly others branches (like 3.4) ? Thx in advance for your coming feedback Best regards Louis -- nosy: +llecaroz versions: +Python 3.4, Python 3.5 ___ Python tracker <https://bugs.python.org/issue32304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33241] Tooltip not display with macOS 64-bit installer 3.6.5 but work with macOS 64-bit/32-bit installer
Change by Louis Martin : -- components: Tkinter nosy: louis-martin priority: normal severity: normal status: open title: Tooltip not display with macOS 64-bit installer 3.6.5 but work with macOS 64-bit/32-bit installer versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33241] Tooltip not display with macOS 64-bit installer 3.6.5 but work with macOS 64-bit/32-bit installer
New submission from Louis Martin :
Tested with :
from appJar import gui
with gui() as app:
app.label('hello world', tip="help me")
app.addLabel("l1", "text")
app.setLabelTooltip("l1", "more help")
--
___
Python tracker
<https://bugs.python.org/issue33241>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32304] Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code
New submission from Louis Lecaroz : Hi, .tar.gz files can end with x0d bytes or whatever you want When running setup.py sdist upload, depending on the project, the .tar.gz file, as said can sometimes end with x0d. When doing the upload, the line https://github.com/python/cpython/blob/master/Lib/distutils/command/upload.py#L162 (if value and value[-1:] == b'\r') will remove the ending char of the .tar.gz generating a 400 response error from the server like: Upload failed (400): Digests do not match, found: 09f23b52764a6802a87dd753009c2d3d, expected: 972b8e9d3dc8cf6ba6b4b1ad5991f013 error: Upload failed (400): Digests do not match, found: 09f23b52764a6802a87dd753009c2d3d, expected: 972b8e9d3dc8cf6ba6b4b1ad5991f013 As this line is generic & run on all key/values, I clearly understand that this check was initially written to eliminate certainly some issues on values in text format. But the mistake here, is that you are also changing the content of the 'content' key which contains the .tar.gz as value, and because you remove the ending 0D, you change the .tar.gz content to be uploaded. As consequence, the server will return a 400 error about a wrong digest/crc. I was able to make the code working with all .tar.gz files by changing this line to: if value and value[-1:] == '\r' and not key=='content': With a such fix, the .tar.gz content will not see its ending \r to be removed & the computed CRC from the server will be the same as computed by md5(content).hexdigest() in upload.py -- components: Distutils messages: 308205 nosy: dstufft, eric.araujo, llecaroz priority: normal severity: normal status: open title: Upload failed (400): Digests do not match on .tar.gz ending with x0d binary code type: security versions: Python 2.7, Python 3.5, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue32304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34434] Removal of kwargs for built-in types not covered with "changed in Python" note in documentation
Change by Louis Sautier : -- keywords: +patch pull_requests: +8320 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18660] os.read behavior on Linux
New submission from Louis RIVIERE: A call to os.read that used to work on older Linux kernel, doesn't anymore with newer Linux kernel. As a workaroud we can use libc.read (ctypes) instead of os.read. But I feel like os.read should work, as it used to. The code (and comments) can be seen here : http://code.activestate.com/recipes/576375-low-level-inotify-wrapper/ -- components: IO messages: 194461 nosy: dugres priority: normal severity: normal status: open title: os.read behavior on Linux type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue18660> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18660] os.read behavior on Linux
Louis Riviere added the comment: Thanks Benjamin ! I should have known that "Python doesn't break things" :) -- ___ Python tracker <http://bugs.python.org/issue18660> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5088] optparse: inconsistent default value for append actions
Louis Deflandre added the comment: Hello, Tell me if the issue is too old to deserve comments anymore. But I would like to challenge the conclusion made in this issue. The message msg9944 stated "Think of the default as the initial list" but it is inconsistent with the proper meaning of default which can be defined as : "a preselected option adopted by a computer program or other mechanism WHEN NO ALTERNATIVE IS SPECIFIED" (http://www.wordreference.com/definition/default - Oxford Dictionary). The "initial list" conclusion seems to me more implementation oriented than really user oriented -- nosy: +louis.deflandre ___ Python tracker <http://bugs.python.org/issue5088> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7434] general pprint rewrite
Louis Riviere added the comment: I've made a Pretty Printer and I'd like to know if anybody thinks it could of some help here. (I do) It's easily extensible and customizable to support any type in any way. https://github.com/louis-riviere-xyz/prettypy.git -- nosy: +dugres ___ Python tracker <http://bugs.python.org/issue7434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27536] Convert readme to markdown
New submission from Louis Taylor: Since the move to github is happening, the readme should probably be changed to markdown in order to render nicer on the github web interface. Issue 27476 introduced a .github folder, so it seems that preemptive changes for the migration are okay. -- files: readme-to-markdown.patch keywords: patch messages: 270604 nosy: louis.taylor priority: normal severity: normal status: open title: Convert readme to markdown type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file43763/readme-to-markdown.patch ___ Python tracker <http://bugs.python.org/issue27536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27536] Convert readme to markdown
Louis Taylor added the comment: Oh, that's a very good point. Patch updated. -- Added file: http://bugs.python.org/file43764/readme-to-rst.patch ___ Python tracker <http://bugs.python.org/issue27536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27536] Convert readme to reStructuredText
Changes by Louis Taylor : -- title: Convert readme to markdown -> Convert readme to reStructuredText ___ Python tracker <http://bugs.python.org/issue27536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24728] Build fails when threads are disabled
New submission from Louis Dassy: If threads are disabled using --without-threads, the build of Python/pythonrun.c will fail because PyGILState_GetThisThreadState() is undefined. I've attached the trivial fix, modeled after 29f51c4ae11a. -- components: Interpreter Core files: without_threads.patch keywords: patch messages: 247430 nosy: louis.dassy priority: normal severity: normal status: open title: Build fails when threads are disabled type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file40030/without_threads.patch ___ Python tracker <http://bugs.python.org/issue24728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24784] Build fails --without-threads
New submission from Louis Dassy: Build of default branch fails using --without-threads. I added the WITH_THREAD check around PyGILState_Check -- components: Build files: without-threads.patch keywords: patch messages: 247921 nosy: berker.peksag, louis.dassy, python-dev priority: normal severity: normal status: open title: Build fails --without-threads type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file40114/without-threads.patch ___ Python tracker <http://bugs.python.org/issue24784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25434] Fix typo in whatsnew/3.5
New submission from Louis Sautier: Hi, I noticed a typo in the doc for What’s New In Python 3.5, here's a patch. -- assignee: docs@python components: Documentation files: fixtypo.patch keywords: patch messages: 253155 nosy: docs@python, omelette priority: normal severity: normal status: open title: Fix typo in whatsnew/3.5 versions: Python 3.5 Added file: http://bugs.python.org/file40811/fixtypo.patch ___ Python tracker <http://bugs.python.org/issue25434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
New submission from David Jean Louis :
Hi,
I'm the author of the polib python module, incidentally (after a bug report in
polib:
https://bitbucket.org/izi/polib/issue/27/polib-doesnt-check-unescaped-quote)
I've found that the eval() in Tools/i18n/msgfmt.py allows arbitrary code
execution, someone could create a malicious po entry like this:
msgid "owned!"
msgstr "" or __import__("os").popen("rm -rf /")
As this is an "internal tool" used by developers, maybe it is not very
important, but given that people may reuse this script for generating mo files,
I think this needs to be fixed, I'm adding a patch for this issue.
Regards,
--
David
--
components: Demos and Tools
files: msgfmt.py.diff
keywords: patch
messages: 146678
nosy: izi
priority: normal
severity: normal
status: open
title: the script Tools/i18n/msgfmt.py allows arbitrary code execution via po
files
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23566/msgfmt.py.diff
___
Python tracker
<http://bugs.python.org/issue13301>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
David Jean Louis added the comment: I'm adding an updated patch that also handles unescaped double quote at the beginning of the string. -- versions: +Python 2.6, Python 3.1, Python 3.4 Added file: http://bugs.python.org/file23567/msgfmt.py.diff.update1.diff ___ Python tracker <http://bugs.python.org/issue13301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13301] the script Tools/i18n/msgfmt.py allows arbitrary code execution via po files
David Jean Louis added the comment: Hmm, I missed your previous message, indeed, unescaping is not handled by this patch, sorry about that. Here's how it is handled in polib: https://bitbucket.org/izi/polib/src/dbafdc621bf4/polib.py#cl-206 -- ___ Python tracker <http://bugs.python.org/issue13301> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4216] subprocess.Popen hangs at communicate() when child exits
Louis-Dominique Dubeau <[EMAIL PROTECTED]> added the comment:
I'm running python 2.5.2 on Ubuntu 8.10.
I believe I've also encountered the problem reported here. The scenario
in my case was the following:
1. Python process A uses subprocess.Popen to create another python
process (B). Process B is created with stdout=PIPE and stderr=PIPE.
Process A communicates with process B using communicate().
2. Python process B, starts a ssh process (process C) which is invoked
to open a new control socket in master mode. Process C is started
without pipes so it gets its std{in,out,err} from process B. Process C
is going to run for a long time. That is, it will run until a command
is sent to the control socket to close the ssh connexion.
3. Process B does not wait for process C to end, so it ends right away.
4. Python process A remains stuck in communicate() until process C (ssh)
dies even though process B has ended already.
Analysis:
The reason for this is that process C (ssh) gets its stdout and stderr
from process B. But process C keeps both stdout and stderr opened until
it is terminated. So process A does not get an EOF on the pipes it
opened for communicating with process B until process C ends.
The set of conditions which will trigger the effect is not outlandish.
However, it is specific enough that testing by executing "pwd" or "ls
-l", or "echo blah" or any other simple command won't trigger it.
In my case, I fixed the problem by changing the code of process B to
invoke process C with stdout and stderr set to PIPE and close those
pipes as soon as process B is satisfied that process C is started
properly. In this way, process A does not block.
(FYI, process A in my case is the python testing tool nosetests. I use
nosetests to test a backup script written in python and that script
invokes ssh.)
It seems that in general subprocess creators might have two needs:
1. Create a subprocess and communicate with it until there is no more
data to be passed to its stdin or data to be read from its std{out,err}.
2. Create a subprocess and communicate with it *only* until *this*
process dies. After it is dead, neither stdout nor stderr are of any
interest.
Currently, need 1 is addressed by communicate() but not need 2. In my
scenario above, I was able to work around the problem by modifying
process B but there are going to be cases where process B is not
modifiable (or at least not easily modifiable). In those cases, process
A has to be able to handle it.
--
nosy: +lemur
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4216>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41109] subclasses of pathlib.PurePosixPath never call __init__ or __new__
Louis-Vincent Boudreault added the comment:
Path.__new__ should not call _from_parts because it breaks the specialization
by directly using object.__new__.
This is why `_from_parts` has to be duplicated in each subclass's `__new__`.
My suggestion (first draft) is to do the parsing of arguments inside an
`__init__` in the Path class hierarchy
and deprecate `_from_parts`.
```
class PurePath:
def __new__(cls, *args):
if cls is PurePath:
cls = PureWindowsPath if os.name == 'nt' else PurePosixPath
super().__new__(cls, *args) # Here we remove call to from_parts
def __init__(self, *args):
# We should have an __init__ in the hierarchy.
drv, root, parts = self._parse_args(args) # this would get the proper
_flavour.
self._drv = drv
self._root = root
self._parts = parts
...
class Path(PurePath):
def __new__(cls, *args, **kwargs):
if cls is Path:
cls = WindowsPath if os.name == 'nt' else PosixPath
# REMOVE THIS LINE: self = cls._from_parts(args, init=False) #
if not self._flavour.is_supported:
raise NotImplementedError("cannot instantiate %r on your system"
% (cls.__name__,))
return super().__new__(cls, *args, **kwargs) # Use super
```
I don't know what is the purpose of `_init` and if it could be replaced by an
extra keyword argument in __init__.
The class method `_from_parts` would become deprecated since the argument
parsing would be now handled by `__init__`.
By using __init__ and avoid the direct call to `object.__new__` we would
respect class specialization and custom class could be implemented intuitively.
--
nosy: +louis-vincent.boudre
___
Python tracker
<https://bugs.python.org/issue41109>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41109] subclasses of pathlib.PurePosixPath never call __init__ or __new__
Louis-Vincent Boudreault added the comment: This is not true, because the classmethod use the library shortcuts the class mro order, to prevent infinite loop inthe __new__. However, it was using __init__ before hand, we would Not have this issue Le jeu. 13 août 2020 à 15:27, Jeffrey Kintscher a écrit : > > Jeffrey Kintscher added the comment: > > Adding __init__() to PurePath complicates things and doesn't provide any > benefit. A subclass that calls super.__init__() ends up invoking > object.__init__(), which is perfectly fine. > > I was able to find a solution by calling type(self)() instead of > object.__new__() in most cases. I am working on a PR. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue41109> > ___ > -- ___ Python tracker <https://bugs.python.org/issue41109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41109] subclasses of pathlib.PurePosixPath never call __init__ or __new__
Louis-Vincent Boudreault added the comment: This is not true, because the classmethod used the library shortcuts the class mro order, this is to prevent infinite loop inthe __new__. However, If it was using __init__ before hand, we would Not have this issue Le jeu. 13 août 2020 à 15:31, Louis-Vincent Boudreault < lv.boudreaul...@gmail.com> a écrit : > This is not true, because the classmethod use the library shortcuts the > class mro order, to prevent infinite loop inthe __new__. However, it was > using __init__ before hand, we would > Not have this issue > > > Le jeu. 13 août 2020 à 15:27, Jeffrey Kintscher > a écrit : > >> >> Jeffrey Kintscher added the comment: >> >> Adding __init__() to PurePath complicates things and doesn't provide any >> benefit. A subclass that calls super.__init__() ends up invoking >> object.__init__(), which is perfectly fine. >> >> I was able to find a solution by calling type(self)() instead of >> object.__new__() in most cases. I am working on a PR. >> >> -- >> >> ___ >> Python tracker >> <https://bugs.python.org/issue41109> >> ___ >> > -- ___ Python tracker <https://bugs.python.org/issue41109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33451] Start pyc file lock the file
New submission from Jean-Louis Tamburini : Python v3.6.4:d48eceb Windows 10.0.16299 I search on Internet and I don't find why Python Interpreter (v3.6.4) do that. With python 2.7, I don't have this "problem". When I launch script like : c:\Python364\python.exe compile.py While the execution, I can rename/modify the file "compile.py". But, when I compile the file to .pyc (with py_compile with an another script), and I launch the pyc like : c:\Python364\python.exe dummy.pyc While the execution, I CAN'T rename/modify the file because is locked by Python Interpreter. It's normal ? -- components: Interpreter Core messages: 316330 nosy: Jean-Louis Tamburini priority: normal severity: normal status: open title: Start pyc file lock the file type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue33451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33451] Start pyc file lock the file
Jean-Louis Tamburini added the comment: Same for python v3.6.5:f59c0932b4 -- Added file: https://bugs.python.org/file47592/dummy.py ___ Python tracker <https://bugs.python.org/issue33451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20032] asyncio.Future.set_exception() creates a reference cycle
Jean-Louis Fuchs added the comment: Just to let you know I hit this problem in my code, simplified version: https://gist.github.com/ganwell/ce3718e5119c6e7e9b3e Of course it is only a problem because I am a ref-counting stickler. -- nosy: +Jean-Louis Fuchs ___ Python tracker <http://bugs.python.org/issue20032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
