[issue38732] Adding relp support as a new logging handler
New submission from Marco : Hello, a pyrelp module was released to send messages over RELP to a RELP server, such as rsylog: https://github.com/mathias-nyman/pyrelp https://github.com/rsyslog/librelp It should be very useful the possibility to add this feature as a logging handler. A SyslogHandler already exists, but it support only normal TCP. You could add the RELP support. Thank you to consider this. -- components: Extension Modules messages: 356178 nosy: falon priority: normal severity: normal status: open title: Adding relp support as a new logging handler type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38732> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39628] msg.walk memory leak?
New submission from Marco : Hello, if I write ``` msg = email.message_from_bytes(...) for part in msg.walk(): content_type = part.get_content_type() if not part.get_content_maintype() == 'multipart': filename = part.get_filename(None) attachment = part.get_payload(decode=True) ``` if the mime parts are more than one, then the memory increases at each iteration and will never be released. -- components: email messages: 361959 nosy: barry, falon, r.david.murray priority: normal severity: normal status: open title: msg.walk memory leak? type: resource usage versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue39628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39628] msg.walk memory leak?
Marco added the comment: uhm, no. I can no more reproduce this. I was wrong. Sorry for the noise. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Pyhon 2.6 makes .pyc/.pyo bytecode files executable
Marco added the comment: I attach a patch to correct this little bug. Bye ;) -- nosy: +markon Added file: http://bugs.python.org/file14049/import_patch.c ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite
Marco added the comment: It seems Python is using a default mask to compile modules. If you open a file b.py as "r", and you import it from a.py, you can see that b.pyc is: -rwxr-xr-x 1 marco marco9 24 mag 16:17 a.py -r--r--r-- 1 marco marco 10 24 mag 16:17 b.py -rw-r--r-- 1 marco marco 122 24 mag 16:46 b.pyc If you try to run a.py: -rwxr-xr-x 1 marco marco9 24 mag 16:17 a.py -r-xr-xr-x 1 marco marco 10 24 mag 16:17 b.py you'll get: -rw-r--r-- 1 marco marco 122 24 mag 16:49 b.pyc as you can see, there is a default "mode" to create compiled modules... -- nosy: +markon ___ Python tracker <http://bugs.python.org/issue6074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Marco added the comment: TO georg.brandl: I remembered that Windows wasn't POSIX compliant, but...I thought they used the same sys/stat.h constants. I was wrong :P TO loewis: ok, I've added a new patch. Since I've never written any code for Windows, can you check if it works fine now? I've added a simple #ifdef WINDOWS,... -- keywords: +patch Added file: http://bugs.python.org/file14069/import_patch2.patch ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Changes by Marco : Removed file: http://bugs.python.org/file14069/import_patch2.patch ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Changes by Marco : Added file: http://bugs.python.org/file14070/import_patch2.patch ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Marco added the comment: TO loewis: this new patch works fine. I've removed the first #endif. thank you ;) -- Added file: http://bugs.python.org/file14072/import_patch2.patch ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Changes by Marco : Removed file: http://bugs.python.org/file14049/import_patch.c ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Changes by Marco : Removed file: http://bugs.python.org/file14070/import_patch2.patch ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite
Marco added the comment: Which version are you using? I've seen the source code of import.c (2.5 and 2.6) and it seems that in the 2.6 some bugfixes/features have been added. However, I've just used the version 2.7 and it works fine (as 2.6, since they have the same code (at least in import.c), until now). bye -- ___ Python tracker <http://bugs.python.org/issue6074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6074] .pyc files created readonly if .py file is readonly, python won't overwrite
Marco added the comment: TO pdsimanyi: chmod it's not appropriate to change the permissions as you made: 0666 et voilà. However, I don't understand if it can be a problem since you're using Cygwin (and Bash under Windows) or not. I think this because Windows is not POSIX compliant and under Windows the permissions are different than the others under *NIX-like platforms (POSIX compliant). Maybe in these days I can check the permissions on Windows. -- ___ Python tracker <http://bugs.python.org/issue6074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Marco added the comment: hmm.. the problem is that Windows doesn't support well permissions as all the other POSIX compliant OSs ... I've searched for a solution on the web, and I've found a complete answer on: http://stackoverflow.com/questions/592448/c-how-to-set-file-permissions-cross-platform The patch doesn't work well since it only checks for User's permissions so it works well for that. Maybe using the Windows API you can change the permissions as you want. But since I don't know them, I can't help anymore :( -- ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Marco added the comment: Thank you David.. sorry for my errors :) but this is my first patch :P I've recompiled py2.6 and it works fine on my Debian. As you can see: -rwxr-xr-x 1 marco marco81822 30 set 2008 setup.py ./python -c "import setup" -rw-r--r-- 1 marco marco42156 23 giu 09:58 setup.pyc However, the version 2.5 doesn't have this "bug" and I've not recompiled it. -- ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable
Marco added the comment: Thank you for your report :P Otherwise I really didn't know how solve it, thank you :P However, on *NIX-like systems it can work well; but can someone try it on Windows? Since I know that only NTFS (and versions >= XP) supports permissions, if a user have a FATfs (or Win98, 95,..) I think it raises error. -- ___ Python tracker <http://bugs.python.org/issue6070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29685] test_gdb failed
New submission from Marco:
make test output
studio@linux:~/Python-3.6.0> ./python -m test -v test_gdb
== CPython 3.6.0 (default, Mar 1 2017, 15:51:48) [GCC 4.8.5]
== Linux-4.4.49-16-default-x86_64-with-SuSE-42.2-x86_64 little-endian
== hash algorithm: siphash24 64bit
== cwd: /home/studio/Python-3.6.0/build/test_python_32667
== encodings: locale=UTF-8, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0,
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0,
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_gdb
test test_gdb crashed -- Traceback (most recent call last):
File "/home/studio/Python-3.6.0/Lib/test/libregrtest/runtest.py", line 152,
in runtest_inner
the_module = importlib.import_module(abstest)
File "/home/studio/Python-3.6.0/Lib/importlib/__init__.py", line 126, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 978, in _gcd_import
File "", line 961, in _find_and_load
File "", line 950, in _find_and_load_unlocked
File "", line 655, in _load_unlocked
File "", line 678, in exec_module
File "", line 205, in _call_with_frames_removed
File "/home/studio/Python-3.6.0/Lib/test/test_gdb.py", line 46, in
gdb_version, gdb_major_version, gdb_minor_version = get_gdb_version()
File "/home/studio/Python-3.6.0/Lib/test/test_gdb.py", line 43, in
get_gdb_version
raise Exception("unable to parse GDB version: %r" % version)
Exception: unable to parse GDB version: ''
test_gdb failed
1 test failed:
test_gdb
Total duration: 31 ms
Tests result: FAILURE
--
components: Tests
messages: 288760
nosy: MarcoC
priority: normal
severity: normal
status: open
title: test_gdb failed
type: compile error
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue29685>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26953] Failed building wheel for greenlet
Changes by Marco : -- components: Installation nosy: marcoconte_008 priority: normal severity: normal status: open title: Failed building wheel for greenlet versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue26953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26953] Failed building wheel for greenlet
New submission from Marco: I have tried to install bpython on Linux with this result studio@linux:/usr/bin> pip install bpython ... ... Running setup.py bdist_wheel for greenlet ... error greenlet.h:8:20: fatal error: Python.h: No such file or directory #include ^ compilation terminated. error: command 'gcc' failed with exit status 1 How can I fix this error ? MC -- ___ Python tracker <http://bugs.python.org/issue26953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Marco Pagliaricci added the comment: Andrew, many thanks for your time, solving this issue. I think your solution is the best to fix this little problem and I agree with you on backporting. My Best Regards, and thanks again. Marco On Thu, Feb 17, 2022 at 10:29 AM Andrew Svetlov wrote: > > Andrew Svetlov added the comment: > > I have a pull request for the issue. > It doesn't use `Future.set_exception()` but creates a new CancelledError() > with propagated message. > The result is the same, except raised exceptions are not comparable by > `is` check. > As a benefit, `_cancelled_exc` works with the patch, exc.__context__ is > correctly set. > > The patch is not backported because it changes existing behavior a little. > I'd like to avoid a situation when third-party code works with Python > 3.11+, 3.10.3+, and 3.9.11+ only. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue45390> > ___ > -- ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13254] maildir.items() broken
New submission from marco ghidinelli :
since python 2.7.2
maildir.items() doesn't return anything:
>>> from mailbox import Maildir
>>> x = Maildir('test')
>>> x.items()
[]
untils something was written on the maildir.
>>> x.add('bubu')
'1319447613.M259111P6097Q1.deeppurple'
>>> x.items()
[('1319447013.M913187P6096Q1.deeppurple', ), ('1319447613.M259111P6097Q1.deeppurple', )]
--
components: Library (Lib)
messages: 146283
nosy: marco.ghidinelli
priority: normal
severity: normal
status: open
title: maildir.items() broken
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue13254>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13254] maildir.items() broken
marco ghidinelli added the comment: i verified now, and the 2.7.1 version is ok, the bug is present since the 2.7.2 -- ___ Python tracker <http://bugs.python.org/issue13254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13254] maildir.items() broken
marco ghidinelli added the comment: 3.1 is ok 3.2.2 is affected -- ___ Python tracker <http://bugs.python.org/issue13254> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13506] IDLE sys.path does not contain Current Working Directory
New submission from Marco Scataglini :
The IDLE shell sys.path does not contains any entry for the Current Working
Directory ('' or '.' or '.\'); without it, when changing the CWD with
os.chdir(), the shell cannot find, execute or import scripts or module in it.
I can start the standard Python interactive shell and os.chdir to any dev or
test directories and import or call scripts and modules, or I can cd first to
any of those directories from any shell (sh, batch, cmd.com), then start Python
interactive shell and import or call scripts and modules, because there is the
CWD available in the sys.path as ''.
I tried to manually add it to IDLE:
from cli by calling idle.py or idle.pyw with "-cimport
sys;sys.path.insert(0,"");del sys"
or by making a IDLESTARTUP.py script
import sys
sys.path.insert(0,"")
del sys
and setting the IDLESTARTUP env var pointing at it
but these work in adding the CWD to sys.path only for the first run (start) of
IDLE shell; but when it get restarted (ex.: the Shell/Restart Shell toolbar
option) the CWD get reset without the CWD entry, and again it has the same
problem
I also tried to cd from shell (sh, bash, cmd.com) first and then start IDLE and
it worked for importing and calling modules and scripts in the specific
dev/test directory, but it failed to import or call other standard scripts that
actually are in the sys.path (ex.: win32ui).
This is needed to use IDLE to develop and test new scripts and modules not yet
ready to be included into the standard libraries and paths, so momentarily
modifying the path as above that also does not survive restarts made within the
application, or permanently modifying the path statically to include any dev
and test dir by adding the absolute path(s ) to env var PYTHONPATH are both not
correct way.
And anyway it is not consistent with the behavior of the standard Python
interactive shell that includes the CWD in sys.path (as '' right at the
beginning), therefore os.chdir('to any non in sys.path dirs') works correctly
in contrast with IDLE shell behavior... and who knows what else it breaks.
I am not an expert on python environment, but I have 20+ years professional
experience in many other high profile QA dev and testing project (just Google
me), so I just thing it should be fixed, since I see this problem since 2008
and I know others that have the same issue for long time before that.
I assure you inconsistency in IDLE and Python like that separate production
products from hack toys and I know for a fact are alienating both novices and
veterans, because first it makes it difficult to use IDLE for basic learning
and second, because it get you skeptical to trust the rest of Python will
behave differently and correctly for main development, since its main IDE
distributed with the language does not.
If there is anything that I don't see just let me know,
thanks.
--
components: IDLE
messages: 148636
nosy: MarcoScataglini
priority: normal
severity: normal
status: open
title: IDLE sys.path does not contain Current Working Directory
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13506>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13506] IDLE sys.path does not contain Current Working Directory
Changes by Marco Scataglini : -- nosy: +kbk ___ Python tracker <http://bugs.python.org/issue13506> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13506] IDLE sys.path does not contain Current Working Directory
Marco Scataglini added the comment: ... I think it could be fixed by adding sys.path.insert(0,"") on the # process sys.argv and sys.path: section in PyShell.py after (~about) line 1383 sys.path.insert(0, dir) sys.path.insert(0,"")<HERE # check the IDLE settings configuration (but command line overrides) (Unified diff/patch file attached) -- Added file: http://bugs.python.org/file23816/PyShell.py - Udiff ___ Python tracker <http://bugs.python.org/issue13506> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13506] IDLE sys.path does not contain Current Working Directory
Marco Scataglini added the comment:
At first I did no see the difference on preserving the existing correct
behavior and fixing the issue between the two patches... and I thought less is
more, so mine was better...
But, I checked again and by:
"... running a python script will have sys.path include the absolute path to
the script..." (Roger meant) instead of CWD ("").
I can see the reasoning for it and since that IS the standard Python behavior
it should be also transposed to IDLE.
So yes, Roger (serwy) patch presents a more accurate correction.
+1
--
___
Python tracker
<http://bugs.python.org/issue13506>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2057] difflib: add patch capability
Marco Scataglini added the comment: I agree with Anatoly that it should be an easy way to create and apply Unified Diff Patches within Python. Also issue 2142 should get fixed, as proposed, but also include the fix at least on 2.7 not only on 3.x -- nosy: +marco ___ Python tracker <http://bugs.python.org/issue2057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13586] Replace selected not working/consistent with find
New submission from Marco Scataglini : Entering the Replace dialog (by ctrl+h or from Edit/Replace... menu) with a selection does not auto-magically have the selected text in the find field. This is not consistent with the other find functions (ctrl+f: Find...; alt+F3: Find in Files...; ctrl+F3: Find Selection) where the highlighted text automatically entered in the find field. -- components: IDLE messages: 149276 nosy: marco priority: normal severity: normal status: open title: Replace selected not working/consistent with find type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13586> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13586] IDLE: Replace selected not working/consistent with find
Marco Scataglini added the comment: Win 7 Pro 32bit. -- ___ Python tracker <http://bugs.python.org/issue13586> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13586] IDLE: Replace selected not working/consistent with find
Marco Scataglini added the comment: To check on 3.2 I installed a fresh Python 3.2.1.1 on Win7 x86 32bit and it has the same problem. So this issues is valid on 2.7.2.1 and 3.2.1.1 I --dry-run Roger patch on both 2.7 and 3.2 with no errors or warnings messages and after patching it fixes the issue on both versions. -- versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue13586> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13506] IDLE sys.path does not contain Current Working Directory
Marco Scataglini added the comment: I test Roger patch on 2.7.2.1 and 3.2.1.1 fresh installs on Win7 Pro 32bit and I confirm it is fixing the issue and it also keeps the existing correct behavior. - Note: - I had to apply the patch with GNU patch: Tortoise is not patching my local files (PyShell.py 2.7 and 3.2), probably because my files were not the same then the patch was diff against; both of mine are release install not SVN. Tortoise AFAIK will accept only exact patch where GNU try to use same "smart" matching. In fact GNU patch succeeded with messages: patching file PyShell.py Hunk #1 succeeded at 372 with fuzz 2 (offset 7 lines). Hunk #2 succeeded at 410 (offset 7 lines). Hunk #3 succeeded at 438 (offset 7 lines). Hunk #4 succeeded at 487 with fuzz 2 (offset 3 lines). Hunk #5 succeeded at 837 (offset 2 lines). Hunk #6 succeeded at 987 (offset 2 lines). Hunk #7 succeeded at 1190 (offset 2 lines). -- ___ Python tracker <http://bugs.python.org/issue13506> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13586] IDLE: Replace selected not working/consistent with find
Marco Scataglini added the comment: To follow on Terry thought, I think find dialog box should stay open when 'Find' button is pressed, since there is a 'close' button to close it. That would also be a more accepted behavior similar to all the other editors I know. And on silly UI design notes: The 'close' button should be at the bottom instead of the top (and have a capital C) ctrl+f 'Find' button should say 'Find Next' like most other editors and also since that is what it does. -- ___ Python tracker <http://bugs.python.org/issue13586> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open
New submission from Marco Scataglini :
Found text does not show at all highlighted on some text colors (like green and
orange) when using the find button in the replace dialog box when box is
open/visible.
Then when dialog box is closed it will highlight the found text in black on
gray like 'selected' and not in white on black 'found' highlighting color
scheme.
Using F3, to find text, highlights in black on gray like 'selected' and not in
white on black 'found' highlighting color scheme
Also using CTRL+f to find text seems to follow the same improper behavior, just
less noticeable since as soon as find button is pressed, the dialog box is
closed and the found text is shown, but if the dialog box would not close the
text would not be shown with any highlighting at all ('found' nor 'selected'
highlighting).
To test the last behavior I used the find_keep_open.patch to prevent CTRL+f
Find Dialog box to close after pressing find button.(issue13586)
Note:
Color scheme highlighting setting can be seen in IDLE Preferences pane under
the Highlighting tab by going to Options/Configure IDLE...
--
components: IDLE
messages: 149811
nosy: marco
priority: normal
severity: normal
status: open
title: IDLE: Find(ed) text is not highlighted while dialog box is open
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue13630>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13586] IDLE: Replace selected not working/consistent with find
Marco Scataglini added the comment: Thank you Roger find_keep_open.patch works, but now that brings me to issue13630 that I thought was existing, and now this confirms it. -- ___ Python tracker <http://bugs.python.org/issue13586> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open
Marco Scataglini added the comment: Well I checked 'SearchBar' IDLE extension and is not bad... has some minor bugs, nothing major just very very minor quirky behavior, but nothing that seems to impair functionality AFAIK. It should be cleaned up and added to release in place of the existing non-functional one. Just my 2c, of course. -- ___ Python tracker <http://bugs.python.org/issue13630> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13654] IDLE: Freezes and/or crash on SyntaxWarning... is used prior to global declaration
New submission from Marco Scataglini :
Writing the following code in the IDLE module/scriptneditor and then running it
(F5) will momentarily freeze without giving the expected warning message
("SyntaxWarning: name 'GLOBAL1' is used prior to global declaration") and it
will crash all IDLE windows instances if ran multiple times after it.
--
start code snippet:
--
GLOBAL1=10
def test_chnge_val_1(a=1):
##global GLOBAL1
b=GLOBAL1
print GLOBAL1, b
global GLOBAL1
GLOBAL1 += a
b= 100
print GLOBAL1, b
if __name__ == '__main__':
test_chnge_val_1()
end code snippet:
The desired behavior is to not crash but run the code with output and shoot the
expected message to STOUT/shell console like regular python shell would.
-
Notes:
-
issue_global_crash.py code-file attached.
--
components: IDLE
files: issue_global_crash.py
messages: 150125
nosy: marco
priority: normal
severity: normal
status: open
title: IDLE: Freezes and/or crash on SyntaxWarning... is used prior to global
declaration
versions: Python 2.7
Added file: http://bugs.python.org/file24082/issue_global_crash.py
___
Python tracker
<http://bugs.python.org/issue13654>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9830] Python 2.7 x64 not properly installed on Windows 7 (registry)
New submission from Marco Buccini : I've just installed Python 2.7 x86-64, on my 64-bit Windows 7, then I've tried to install some packages - such as setuptools and pyside - but a message during the installation said something like "Cannot find Python2.7 in the windows registry". So I've removed the 64-bit version of Python, then I've installed that one of 32-bit and, as expected, it works fine. I've also tried to search on google to see if it's a Python bug or not, but I've found only this unreachable link: http://bugs.python.org/setuptools/issue2 Do you confirm this bug? -- components: Installation messages: 116083 nosy: markon priority: normal severity: normal status: open title: Python 2.7 x64 not properly installed on Windows 7 (registry) type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue9830> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8639] Allow callable objects in inspect.getargspec
Marco Mariani added the comment:
I second this, I depend on this monkeypatch for my turbogears projects, where I
use callable objects as error handlers:
def getargspec(func):
if getattr(func, '__call__') and not isfunction(func) and not
ismethod(func):
func = func.__call__
if ismethod(func):
func = func.im_func
if not isfunction(func):
raise TypeError('arg is not a Python function')
args, varargs, varkw = getargs(func.func_code)
return args, varargs, varkw, func.func_defaults
but I suppose 2.7 is locked to this change so I propose it for 3.x
--
nosy: +marco.mariani
versions: +Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue8639>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8398] Modules with a dot in the filename don't load
New submission from marco stamazza : On my windows Xp system running Python 2.6 (from the (x,y) package) I tried to load a module named "GetMy.com_MOD.py". I kept receiving the error Traceback (most recent call last): File "D:\Docs\Futures-Strategy\StCHF\Test\GetMy.com_2.py", line 6, in import GetMy.com_MOD ImportError: No module named GetMy.com_MOD Until I removed the dot renaming it to GetMycom_MOD.py, which works very nicely. Maybe the search should be smart enough to look for the last word after a dot to determine if the module exists or not? Many thanks guys, Python rocks. marco -- components: Interpreter Core messages: 103127 nosy: giunghi severity: normal status: open title: Modules with a dot in the filename don't load type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8398> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type
Marco Barisione added the comment: This is particularly annoying if you are using `Annotated` with a dataclass. For instance: ``` from __future__ import annotations import dataclasses from typing import Annotated, get_type_hints @dataclasses.dataclass class C: v: Annotated[int, "foo"] v_type = dataclasses.fields(C)[0].type print(repr(v_type)) # "Annotated[int, 'foo']" print(repr(get_type_hints(C)["v"])) # print(repr(eval(v_type))) # typing.Annotated[int, 'foo'] ``` In the code above it looks like the only way to get the `Annotated` so you get get its args is using `eval`. The problem is that, in non-trivial, examples, `eval` would not be simple to use as you need to consider globals and locals, see https://peps.python.org/pep-0563/#resolving-type-hints-at-runtime. -- nosy: +barisione ___ Python tracker <https://bugs.python.org/issue39442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39442] from __future__ import annotations makes dataclasses.Field.type a string, not type
Marco Barisione added the comment: Actually, sorry I realise I can pass `include_extras` to `get_type_hints`. Still, it would be nicer not to have to do that. -- ___ Python tracker <https://bugs.python.org/issue39442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37587] JSON loads performance improvement for long strings
Marco Paolini added the comment:
I also confirm Inada's patch further improves performance!
All my previous benchmarks were done with gcc and PGO optimizations performed
only with test_json task... maybe this explains the weird results?
I tested the performance of new master 69f37bcb28d7cd78255828029f895958b5baf6ff
with *all* PGO task reverting my original patch:
iff --git a/Modules/_json.c b/Modules/_json.c
index 112903ea57..9b63167276 100644
--- a/Modules/_json.c
+++ b/Modules/_json.c
@@ -442,7 +442,7 @@ scanstring_unicode(PyObject *pystr, Py_ssize_t end, int
strict, Py_ssize_t *next
if (d == '"' || d == '\\') {
break;
}
-if (d <= 0x1f && strict) {
+if (strict && d <= 0x1f) {
raise_errmsg("Invalid control character at", pystr, next);
goto bail;
}
... and surprise...
Mean +- std dev: [69f37bcb28d7cd78255828029f895958b5baf6ff] 5.29 us +- 0.07 us
-> [69f37bcb28d7cd78255828029f895958b5baf6ff-patched] 5.11 us +- 0.03 us: 1.04x
faster (-4%)
should we revert my original patch entirely now? Or am I missing something?
--
___
Python tracker
<https://bugs.python.org/issue37587>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37587] JSON loads performance improvement for long strings
Marco Paolini added the comment: also worth noting escape sequences for non-ascii characters are slower, even when encoded length is the same. python -m pyperf timeit -s 'import json;' -s 'c = "€"; s = json.dumps(c * (2**10 // len(json.dumps(c)) - 2))' 'json.loads(s)' -o nonascii2k.json python -m pyperf timeit -s 'import json;' -s 'c = "a"; s = json.dumps(c * (2**10 // len(json.dumps(c)) - 2))' 'json.loads(s)' -o ascii2k.json Mean +- std dev: [ascii2k] 2.59 us +- 0.04 us -> [nonascii2k] 9.98 us +- 0.12 us: 3.86x slower (+286%) -- ___ Python tracker <https://bugs.python.org/issue37587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37587] JSON loads performance improvement for long strings
Marco Paolini added the comment: ops sorry here's the right commands python -m pyperf timeit -s 'import json;' -s 'c = "a"; s = json.dumps(c * (2**10 // (len(json.dumps(c)) - 2)))' 'json.loads(s)' -o ascii2k.json python -m pyperf timeit -s 'import json;' -s 'c = "€"; s = json.dumps(c * (2**10 // (len(json.dumps(c)) - 2)))' 'json.loads(s)' -o nonascii2k.json Mean +- std dev: [ascii2k] 3.69 us +- 0.05 us -> [nonascii2k] 12.4 us +- 0.1 us: 3.35x slower (+235%) -- ___ Python tracker <https://bugs.python.org/issue37587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37587] JSON loads performance improvement for long strings
Marco Paolini added the comment: ujson (https://github.com/esnme/ultrajson) instead is faster when decoding non-ascii in the same example above, so it is likely there is room for improvement... -- ___ Python tracker <https://bugs.python.org/issue37587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity
Marco Sulla added the comment:
@scoder:
1. the fact that == does not traverse the Element is IMHO unpythonic and
non-standard. A trivial example:
>>> a = {1: {2: 3}}
>>> b = {1: {2: 3}}
>>> a == b
True
You can have a dictionary complicated as you want, but if they have the same
structure, the two dictionaries will be always equals, even if their id are
not.
I think that no one could say to remove this dictionary feature and simply
check the ids, leaving the deep comparison to the user, without raising a
rebellion :)
2. the fact that SubElement seems a constructor is not an implementation
detail. It's misleading and confusing, since a programmer expects that it will
return an object of type SubElement, while there's no SubElement class. This is
peculiar. I can be wrong, but I never encountered such a bizarre naming in the
standard library. IMHO SubElement should be deprecated and it should call
`subElement()`, a simply copy of the old SubElement
3. I'm not suggesting to remove fromstringlist and tostringlist, but that they
could be deprecated and simply call fromstring and tostring, that should use
duck typing for doing what fromstringlist and tostringlist did.
--
___
Python tracker
<https://bugs.python.org/issue37792>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity
Marco Sulla added the comment: @rhettinger: "Deprecating [...] just cause disruption to existing, deployed code" How? Deprecating is used just to maintain intact the already existing code... "Please do not go down of the path of making yourself the arbiter of what is Pythonic or standard. The other core devs in this conversation are highly experienced. Insulting them or the Fredrik Lundh's existing API won't help matters" I'm not insulting anyone, I just said *IMHO* it's not pythonic. I think the example of a tree created with a simple dictionary is a clear signal that Python, in the Guido's mind, was created with the intention that equality should check the content of the objects and not just the ids, as Java, for example, does, even for objects that must be traversed to see if they are equal to another one. The fact you can check if two objects are equal using simply == is, _IMHO_, more elegant, simple and useful. The fact that == checks the ids is not useful at all, since I can do it with id(elem1) == id(elem2). So what's the purpose of == ? -- ___ Python tracker <https://bugs.python.org/issue37792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37918] What about an enum for open() modes?
New submission from Marco Sulla : As title. I just created it: https://pastebin.com/pNYezw2V I think it could be useful to have a more descriptive way to declare a file open mode. Many languages has an enum for this. Maybe open(), os.fdopen(), os.popen() and pathlib.Path.open() can just accept also an OpenMode enum as mode parameter, without the need to write OpenMode.append.value, for example, but just OpenMode.append. As an alternative, OpenMode could be a namedtuple. I don't know in which module should be put. In `builtins`, `os` or `pathlib`? -- components: Library (Lib) messages: 350203 nosy: Marco Sulla priority: normal severity: normal status: open title: What about an enum for open() modes? versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue37918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity
Marco Sulla added the comment: Thanks, but telling the truth: 1. I just not use SubElement, even if it's more convenient. I just create an Element and I append to the parent one. It's much more clear IMHO 2. I do not use `fromstring` and all its friends. It was just a suggestion 3. I already copy/pasted from SO a function that serialize the Element. I do not want to waste time to do something that will be not used as `Element.__eq__()` implementation, as IMHO should be. See ya. -- ___ Python tracker <https://bugs.python.org/issue37792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37918] What about an enum for open() modes?
Marco Sulla added the comment: Mh. No one is interested? -- ___ Python tracker <https://bugs.python.org/issue37918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37918] What about an enum for open() modes?
Marco Sulla added the comment: Excuse me, but this is not a bug report, but a feature request. Indeed there's the possibility to submit also enhancements, not only bugs, as in all bug reporting board worthy of respect. You see the Type select with "Enhancement" option selected? -- resolution: not a bug -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue37918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37918] What about an enum for open() modes?
Marco Sulla added the comment: Well, I'll discuss it in python-ideas. Let me do the testament before... :D @serhiy.storchaka thank you for the StrEnum tip, but no PyPi package please. It has no sense to add an addional package only for having an enum that should be built-in as in all other languages. And at most I'll do it myself, thank you ;) -- ___ Python tracker <https://bugs.python.org/issue37918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37918] What about an enum for open() modes?
Marco Sulla added the comment: @vstinner Note that I wrote about os.fdopen(), not os.open(). -- ___ Python tracker <https://bugs.python.org/issue37918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36232] Improve error message on dbm.open
Change by Marco Rougeth : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38569] Unknown distribution option: 'license_files'
New submission from Marco Sulla : I tried to add to `setuptools.setup()` the argument license_files. It works, but I get this warning: /usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'license_files' I suppose the warning can be removed. -- components: Distutils messages: 355262 nosy: Marco Sulla, dstufft, eric.araujo priority: normal severity: normal status: open title: Unknown distribution option: 'license_files' type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38592] Add pt-br to the language switcher at the Python docs website
New submission from Marco Rougeth : The translation of the Python docs for Brazilian Portuguese is at around 20%. The Brazilian community have been working hard on it for the past 2 years, and as discussed with Julien, we believe this is a good moment to add the pt-br language switcher. -- messages: 355384 nosy: rougeth priority: normal severity: normal status: open title: Add pt-br to the language switcher at the Python docs website ___ Python tracker <https://bugs.python.org/issue38592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38592] Add pt-br to the language switcher at the Python docs website
Change by Marco Rougeth : -- keywords: +patch pull_requests: +16454 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16924 ___ Python tracker <https://bugs.python.org/issue38592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38642] python3.7.3 seems to cause add-apt-repository to rejct or not find gi library
New submission from Marco Ippolito :
Following the indications found here:
https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository
I was trying to install Docker Engine in Ubuntu 18.04.02 Server Edition.
The first installation's steps went fine but I encountered this error message:
(base) marco@pc:~$ sudo add-apt-repository \
> "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
> $(lsb_release -cs) \
> stable"
Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 11, in
from softwareproperties.SoftwareProperties import SoftwareProperties,
shortcut_handler
File "/usr/lib/python3/dist-packages/softwareproperties
/SoftwareProperties.py", line 67, in
from gi.repository import Gio
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in
from . import _gi
ImportError: cannot import name '_gi' from 'gi' (/usr/lib/python3/dist-
packages/gi/__init__.py)
But import gi in python3 works fine:
(base) marco@pc:~$ python3
Python 3.7.3 (default, Mar 27 2019, 22:11:17)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>>
After changing the first line of /usr/bin/add-apt-repository in order to point
to 3.6 version : #!/usr/bin/python3.6 everything went fine:
(base) marco@pc:~$ sudo add-apt-repository \
>"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
>$(lsb_release -cs) \
>stable"
Hit:1 http://gb.archive.ubuntu.com/ubuntu bionic InRelease
Get:2 https://download.docker.com/linux/ubuntu bionic InRelease [64.4 kB]
Get:3 http://gb.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7
kB]
Get:4 http://gb.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6
kB]
Get:5 https://download.docker.com/linux/ubuntu bionic/stable amd64
Packages [9594 B]
Get:6 http://gb.archive.ubuntu.com/ubuntu bionic-updates/universe i386
Packages [985 kB]
Get:7 http://gb.archive.ubuntu.com/ubuntu bionic-updates/universe amd64
Packages [1017 kB]
Hit:8 http://apt.postgresql.org/pub/repos/apt bionic-pgdg InRelease
Hit:9 http://ppa.launchpad.net/certbot/certbot/ubuntu bionic InRelease
Get:10 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7
kB]
Fetched 2328 kB in 11s (217 kB/s)
Reading package lists... Done
(base) marco@pc:~$ sudo apt-get update
Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:2 http://apt.postgresql.org/pub/repos/apt bionic-pgdg InRelease
Hit:3 http://gb.archive.ubuntu.com/ubuntu bionic InRelease
Hit:4 http://gb.archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:5 http://gb.archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:6 http://ppa.launchpad.net/certbot/certbot/ubuntu bionic InRelease
Hit:7 https://download.docker.com/linux/ubuntu bionic InRelease
Reading package lists... Done
(base) marco@pc:~$ sudo apt-get install docker-ce docker-ce-cli
containerd.io
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
aufs-tools cgroupfs-mount pigz
The following NEW packages will be installed
aufs-tools cgroupfs-mount containerd.io docker-ce docker-ce-cli pigz
0 to upgrade, 6 to newly install, 0 to remove and 0 not to upgrade.
Need to get 85.6 MB of archives.
After this operation, 384 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
So it seems that python3.7.3 has something which causes add-apt-repository to
reject/not find gi library
--
messages: 355714
nosy: Marco Ippolito
priority: normal
severity: normal
status: open
title: python3.7.3 seems to cause add-apt-repository to rejct or not find gi
library
type: compile error
versions: Python 3.7
___
Python tracker
<https://bug
[issue38592] Add pt-br to the language switcher at the Python docs website
Change by Marco Rougeth : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38677] Arraymodule initialization error handling improvements
New submission from Marco Paolini : Module two-phase initialization does not report errors correctly to the import machinery -- components: Extension Modules messages: 355913 nosy: mpaolini priority: normal severity: normal status: open title: Arraymodule initialization error handling improvements type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38677] Arraymodule initialization error handling improvements
Change by Marco Paolini : -- keywords: +patch pull_requests: +16552 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17039 ___ Python tracker <https://bugs.python.org/issue38677> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals
Marco Sulla added the comment: If I can say my two cents: 1. I preferred that the default behaviour of multi-line was to dedent. But breaking old code, even if for a little percentage of code, IMHO is never a good idea. Py2->Py3 should have proved it. 2. ``` remembers me too much the Markdown for add a code block, not a text block 3. yes, the new prefix is really useless, because it's significant only for multiline strings. Anyway, if this solution is accepted, I propose `t` for `trim`. -- nosy: +Marco Sulla ___ Python tracker <https://bugs.python.org/issue36906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals
Marco Sulla added the comment:
Anyway there's something strange in string escaping and `inspect.cleandoc()`:
>>> a = """
... \nciao
... bello
... \ ciao
... """
>>> print(inspect.cleandoc(a))
ciao
bello
\ ciao
>>> print("\ ciao")
\ ciao
I expected:
>>> print(inspect.cleandoc(a))
ciao
bello
ciao
>>> print("\ ciao")
ciao
--
___
Python tracker
<https://bugs.python.org/issue36906>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals
Marco Sulla added the comment: Excuse me for the spam, but against make it the default behavior I have a simple consideration: what will expect a person that reads the code, that doesn't know Python? IMHO it expects that the string is *exactly* like it's written. The fact that it will be de-dented it's a bit surprising. For readability and for not breaking old code, I continue to be in favor of a letter before the multi-string. Maybe `d`, for de-dent, it's more appropriate than `t`, since it does not only trim the string. But probably there's a better solution than the letter. -- ___ Python tracker <https://bugs.python.org/issue36906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals
Marco Sulla added the comment: When Python started to emulate the other languages? Who cares about what other languages do? Python uses `raise` instead of `throw`, even if `throw` is much more popular in the most used languages, only because `raise` in English has more sense. And IMHO a newbie that see a multi-string in the code does not read the documentation. It's evident that is a multi-string. And it expects that it acts as in English or any other written language, that is the text is *that* one that (s)he read. On the contrary, if (s)he reads d""" Marco Sulla """ maybe (s)he thinks "this must be something different", and read the docs. -- ___ Python tracker <https://bugs.python.org/issue36906> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44585] csv library does not correctly interpret some files
New submission from Marco E. :
The CSV library does not correctly interpret files in the following format
(test.csv):
"A" ,"B" ,"C"
"aa","bbb",""
"a" ,"bb" ,"ccc"
"" ,"b" ,"cc"
This program:
import csv
from pathlib import Path
def main():
with Path('test.csv').open('rt') as csv_file:
csv.register_dialect('my_dialect', quotechar='"', delimiter=',',
quoting=csv.QUOTE_ALL, skipinitialspace=True)
reader = csv.DictReader(csv_file, dialect='my_dialect')
for row in reader:
print(row)
if __name__ == '__main__':
main()
produces the following output:
{'A ': 'aa', 'B ': 'bbb', 'C': ''}
{'A ': 'a ', 'B ': 'bb ', 'C': 'ccc'}
{'A ': ' ', 'B ': 'b ', 'C': 'cc'}
this instead is the expected result:
{'A': 'aa', 'B': 'bbb', 'C': ''}
{'A': 'a', 'B': 'bb', 'C': 'ccc'}
{'A': '', 'B': 'b', 'C': 'cc'}
why?
Thank you,
Marco
--
components: Library (Lib)
messages: 397139
nosy: voidloop
priority: normal
severity: normal
status: open
title: csv library does not correctly interpret some files
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44585>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39940] Micro-optimizations to PySequence_Tuple()
Marco Sulla added the comment: Close it, I have no time now :-( -- resolution: -> later stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue39940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44921] dict subclassing is slow
New submission from Marco Sulla :
I asked on SO why subclassing dict makes the subclass much slower in some
operations. This is the answer by Monica
(https://stackoverflow.com/a/59914459/1763602):
Indexing and in are slower in dict subclasses because of a bad interaction
between a dict optimization and the logic subclasses use to inherit C slots.
This should be fixable, though not from your end.
The CPython implementation has two sets of hooks for operator overloads. There
are Python-level methods like __contains__ and __getitem__, but there's also a
separate set of slots for C function pointers in the memory layout of a type
object. Usually, either the Python method will be a wrapper around the C
implementation, or the C slot will contain a function that searches for and
calls the Python method. It's more efficient for the C slot to implement the
operation directly, as the C slot is what Python actually accesses.
Mappings written in C implement the C slots sq_contains and mp_subscript to
provide in and indexing. Ordinarily, the Python-level __contains__ and
__getitem__ methods would be automatically generated as wrappers around the C
functions, but the dict class has explicit implementations of __contains__ and
__getitem__, because the explicit implementations
(https://github.com/python/cpython/blob/v3.8.1/Objects/dictobject.c) are a bit
faster than the generated wrappers:
static PyMethodDef mapp_methods[] = {
DICT___CONTAINS___METHODDEF
{"__getitem__", (PyCFunction)(void(*)(void))dict_subscript,METH_O |
METH_COEXIST,
getitem__doc__},
...
(Actually, the explicit __getitem__ implementation is the same function as the
mp_subscript implementation, just with a different kind of wrapper.)
Ordinarily, a subclass would inherit its parent's implementations of C-level
hooks like sq_contains and mp_subscript, and the subclass would be just as fast
as the superclass. However, the logic in update_one_slot
(https://github.com/python/cpython/blob/v3.8.1/Objects/typeobject.c#L7202)
looks for the parent implementation by trying to find the generated wrapper
methods through an MRO search.
dict doesn't have generated wrappers for sq_contains and mp_subscript, because
it provides explicit __contains__ and __getitem__ implementations.
Instead of inheriting sq_contains and mp_subscript, update_one_slot ends up
giving the subclass sq_contains and mp_subscript implementations that perform
an MRO search for __contains__ and __getitem__ and call those. This is much
less efficient than inheriting the C slots directly.
Fixing this will require changes to the update_one_slot implementation.
Aside from what I described above, dict_subscript also looks up __missing__ for
dict subclasses, so fixing the slot inheritance issue won't make subclasses
completely on par with dict itself for lookup speed, but it should get them a
lot closer.
As for pickling, on the dumps side, the pickle implementation has a dedicated
fast path
(https://github.com/python/cpython/blob/v3.8.1/Modules/_pickle.c#L4291) for
dicts, while the dict subclass takes a more roundabout path through
object.__reduce_ex__ and save_reduce.
On the loads side, the time difference is mostly just from the extra opcodes
and lookups to retrieve and instantiate the __main__.A class, while dicts have
a dedicated pickle opcode for making a new dict. If we compare the disassembly
for the pickles:
In [26]: pickletools.dis(pickle.dumps({0: 0, 1: 1, 2: 2, 3: 3, 4: 4}))
0: \x80 PROTO 4
2: \x95 FRAME 25
11: }EMPTY_DICT
12: \x94 MEMOIZE(as 0)
13: (MARK
14: KBININT10
16: KBININT10
18: KBININT11
20: KBININT11
22: KBININT12
24: KBININT12
26: KBININT13
28: KBININT13
30: KBININT14
32: KBININT14
34: uSETITEMS (MARK at 13)
35: .STOP
highest protocol among opcodes = 4
In [27]: pickletools.dis(pickle.dumps(A({0: 0, 1: 1, 2: 2, 3: 3, 4: 4})))
0: \x80 PROTO 4
2: \x95 FRAME 43
11: \x8c SHORT_BINUNICODE '__main__'
21: \x94 MEMOIZE(as 0)
22: \x8c SHORT_BINUNICODE 'A'
25: \x94 MEMOIZE(as 1)
26: \x93 STACK_GLOBAL
27: \x94 MEMOIZE(as 2)
28: )EMPTY_TUPLE
29: \x81 NEWOBJ
30: \x94 MEMOIZE(as 3)
31: (MARK
32: KBININT10
34: KBININT10
36: KBININT11
38: KBININT11
40: KBININT12
42: KBININT12
44: K
[issue44921] dict subclassing is slow
Marco Sulla added the comment: Since my knowledge of this is very poor, I informed Monica about the issue. I'm quite sure that if there's a way to turn lemons into lemonade :) -- ___ Python tracker <https://bugs.python.org/issue44921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44921] dict subclassing is slow
Marco Sulla added the comment: I not finished my phrase. I'm sure that if there's a way to turn lemons into lemonade, she is **MUCH** more skilled than me to find one. -- ___ Python tracker <https://bugs.python.org/issue44921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44921] dict subclassing is slow
Marco Sulla added the comment: Since probably Monica are taking her holidays, I try to decipher her answer. Probably, the more problematic function spotted by Monica is update_one_slot. I re-quote her sentence: update_one_slot looks for the parent implementation by trying to find the generated wrapper methods through an MRO search. dict doesn't have generated wrappers for sq_contains and mp_subscript, because it provides explicit __contains__ and __getitem__ implementations. Instead of inheriting sq_contains and mp_subscript, update_one_slot ends up giving the subclass sq_contains and mp_subscript implementations that perform an MRO search for __contains__ and __getitem__ and call those. This is much less efficient than inheriting the C slots directly. The solution for Monica is to change the behaviour of update_one_slot for these cases (no wrappers, C slots directly). I don't know the implications of this change... -- ___ Python tracker <https://bugs.python.org/issue44921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
New submission from Marco Pagliaricci : I've spotted a little bug in how asyncio.CancelledError() exception is propagated inside an asyncio.Task. Since python 3.9 the asyncio.Task.cancel() method has a new 'msg' parameter, that will create an asyncio.CancelledError(msg) exception incorporating that message. The exception is successfully propagated to the coroutine the asyncio.Task is running, so the coroutine successfully gets raised an asyncio.CancelledError(msg) with the specified message in asyncio.Task.cancel(msg) method. But, once the asyncio.Task is cancelled, is impossible to retrieve that original asyncio.CancelledError(msg) exception with the message, because it seems that *a new* asyncio.CancelledError() [without the message] is raised when asyncio.Task.result() or asyncio.Task.exception() methods are called. I have the feeling that this is just wrong, and that the original message specified in asyncio.Task.cancel(msg) should be propagated even also asyncio.Task.result() is called. I'm including a little snippet of code that clearly shows this bug. I'm using python 3.9.6, in particular: Python 3.9.6 (default, Aug 21 2021, 09:02:49) [GCC 10.2.1 20210110] on linux -- components: asyncio files: task_bug.py messages: 403294 nosy: asvetlov, pagliaricci.m, yselivanov priority: normal severity: normal status: open title: asyncio.Task doesn't propagate CancelledError() exception correctly. type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file50328/task_bug.py ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Marco Pagliaricci added the comment:
OK, I see your point.
But I still can't understand one thing and I think it's very confusing:
1) if you see my example, inside the job() coroutine, I get correctly
cancelled with an `asyncio.CancelledError` exception containing my message.
2) Now: if I re-raise the asyncio.CancelledError as-is, I lose the message,
if I call the `asyncio.Task.exception()` function.
3) If I raise a *new* asyncio.CancelledError with a new message, inside the
job() coroutine's `except asyncio.CancelledError:` block, I still lose the
message if I call `asyncio.Task.exception()`.
4) But if I raise another exception, say `raise ValueError("TEST")`, always
from the `except asyncio.CancelledError:` block of the job() coroutine, I
*get* the message!
I get `ValueError("TEST")` by calling `asyncio.Task.exception()`, while I
don't with the `asyncio.CancelledError()` one.
Is this really wanted? Sorry, but I still find this a lot confusing.
Shouldn't it be better to return from the `asyncio.Task.exception()` the
old one (containing the message) ?
Or, otherwise, create a new instance of the exception for *ALL* the
exception classes?
Thank you for your time,
My Best Regards,
M.
On Thu, Oct 7, 2021 at 10:25 AM Thomas Grainger
wrote:
>
> Thomas Grainger added the comment:
>
> afaik this is intentional https://bugs.python.org/issue31033
>
> --
> nosy: +graingert
>
> ___
> Python tracker
> <https://bugs.python.org/issue45390>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue45390>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Marco Pagliaricci added the comment:
Chris,
I'm attaching to this e-mail the code I'm referring to.
As you can see, in line 10, I re-raise the asyncio.CancelledError exception
with a message "TEST".
That message is lost, due to the reasons we've talked about.
My point is that, if we substitute that line 10, with the commented line
11, and we comment the line 10, so we raise a ValueError("TEST") exception,
as you can see, the message "TEST" is NOT LOST.
I just find this counter-intuitive, and error-prone.
AT LEAST should be very well specified in the docs.
Regards,
M.
On Sat, Oct 9, 2021 at 2:51 PM Chris Jerdonek
wrote:
>
> Chris Jerdonek added the comment:
>
> > 2) Now: if I re-raise the asyncio.CancelledError as-is, I lose the
> message,
> if I call the `asyncio.Task.exception()` function.
>
> Re-raise asyncio.CancelledError where? (And what do you mean by
> "re-raise"?) Call asyncio.Task.exception() where? This isn't part of your
> example, so it's not clear what you mean exactly.
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue45390>
> ___
>
--
Added file: https://bugs.python.org/file50333/task_bug.py
___
Python tracker
<https://bugs.python.org/issue45390>
___import asyncio
async def job():
print("job(): START...")
try:
await asyncio.sleep(5.0)
except asyncio.CancelledError as e:
print("job(): CANCELLED!", e)
#raise asyncio.CancelledError("TEST")
raise ValueError("TEST")
print("job(): DONE.")
async def cancel_task_after(task, time):
try:
await asyncio.sleep(time)
except asyncio.CancelledError:
print("cancel_task_after(): CANCELLED!")
except Exception as e:
print("cancel_task_after(): Exception!", e.__class__.__name__,
e)
task.cancel("Hello!")
async def main():
task = asyncio.create_task(job())
# RUN/CANCEL task.
try:
await asyncio.gather(task, cancel_task_after(task, 1.0))
except asyncio.CancelledError as e:
print("In running task, we encountered a cancellation!
Excpetion message is: ", e)
except Exception as e:
print("In running task, we got a generic Exception:",
e.__class__.__name__, e)
# GET result.
try:
result = task.result()
except asyncio.CancelledError as e:
print("Task has been cancelled, exception message is: ", e)
except Exception as e:
print("Task raised generic exception", e.__class__.__name__, e)
else:
print("Task result is: ", result)
if __name__=="__main__":
asyncio.run(main())
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Marco Pagliaricci added the comment:
Chris,
ok, I have modified the snippet of code to better show what I mean.
Still here, the message of the CancelledError exception is lost, but if I
comment line 10, and uncomment line 11, so I throw a ValueError("TEST"),
that "TEST" string will be printed, so the message is not lost.
Again, I just find this behavior very counter-intuitive, and should be VERY
WELL documented in the docs.
Thanks,
M.
On Sat, Oct 9, 2021 at 3:06 PM Chris Jerdonek
wrote:
>
> Chris Jerdonek added the comment:
>
> I still don't see you calling asyncio.Task.exception() in your new
> attachment...
>
> --
>
> ___
> Python tracker
> <https://bugs.python.org/issue45390>
> ___
>
--
Added file: https://bugs.python.org/file50334/task_bug.py
___
Python tracker
<https://bugs.python.org/issue45390>
___import asyncio
async def job():
print("job(): START...")
try:
await asyncio.sleep(5.0)
except asyncio.CancelledError as e:
print("job(): CANCELLED!", e)
raise asyncio.CancelledError("TEST")
#raise ValueError("TEST")
print("job(): DONE.")
async def cancel_task_after(task, time):
try:
await asyncio.sleep(time)
except asyncio.CancelledError:
print("cancel_task_after(): CANCELLED!")
except Exception as e:
print("cancel_task_after(): Exception!", e.__class__.__name__,
e)
task.cancel("Hello!")
async def main():
task = asyncio.create_task(job())
# RUN/CANCEL task.
try:
await asyncio.gather(task, cancel_task_after(task, 1.0))
except asyncio.CancelledError as e:
try:
task_exc = task.exception()
except BaseException as be:
task_exc = be
print("In running task, we encountered a cancellation!
Excpetion message is: ", e)
print(" ^ Task exc is:", task_exc.__class__.__name__,
task_exc)
except Exception as e:
print("In running task, we got a generic Exception:",
e.__class__.__name__, e)
# GET result.
try:
result = task.result()
except asyncio.CancelledError as e:
print("Task has been cancelled, exception message is: ", e)
except Exception as e:
try:
task_exc = task.exception()
except BaseException as be:
task_exc = be
print("Task raised generic exception", e.__class__.__name__, e)
print(" ^ Task exc is:", task_exc.__class__.__name__, task_exc)
else:
print("Task result is: ", result)
if __name__=="__main__":
asyncio.run(main())
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37295] Possible optimizations for math.comb()
Change by Marco Cognetta : -- keywords: +patch nosy: +mcognetta nosy_count: 6.0 -> 7.0 pull_requests: +27293 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29020 ___ Python tracker <https://bugs.python.org/issue37295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
New submission from Marco Sulla :
Sometimes I’m lazy and I would test code copy - pasted from internet or from
other sources directly in the interpreter, in interactive mode. But if the code
contains completely blank lines, the copy - paste fails. For example:
def f():
print("Marco")
print("Sulla")
does not work, but
def f():
print("Marco")
print("Sulla")
yes. Notice that in a script the first code block is perfectly valid and works.
This does not happen with Jupiter console, aka IPython. Jupiter implements
bracketed paste mode, so it distinguish between normal input and pasted input.
Jupyter offers also:
- autoindent
- save code blocks in one history entry: this way, if you write a function, for
example, and you press the up key, the whole function will be loaded, and not
its last line.
- auto-reloading of modules. It should be disabled by default and enabled by a
flag, and could auto-reload a module if its code changes.
- save code to console. All the code written in the current interactive session
could be saved to the clipboard. It could be triggered by F12.
- history: it could be a new built-in function. if called without parameters,
it could show the history, with lines numbered. If called with a number, it
will paste the corresponding history line to the console
- pretty printing and source inspection. IMHO pprint.pprint() and
inspect.getsource() are so useful in interactive mode that could be added to
builtins.
- syntax coloring. It should be disabled by default, and could be enabled by a
flag or a config.
- bracket matching. See above.
I think that implementing all of this in CPython is really hard. I suppose that
maybe many things are not possible for compatibility between platforms, or
can't be available everywhere, like syntax coloring.
--
components: Demos and Tools
messages: 356248
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Slowly introduce a subset of Jupyter console (IPython) features into
CPython command line interactive mode
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue38747>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
Marco Sulla added the comment: Well, maybe too much feature requests in a single report. I'll report them separately, with more rationale. -- ___ Python tracker <https://bugs.python.org/issue38747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
Marco Sulla added the comment: Steven: currently I'm developing `frozendict` as part of CPython. About IDLE, IDLE can't be used on a server without a GUI. Furthermore, I *really* hope that IDLE is simply a GUI wrapper of REPL, with some additional features. -- ___ Python tracker <https://bugs.python.org/issue38747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
Marco Sulla added the comment: @Eryk: why a C extension apart and not a patch to `readline`? -- ___ Python tracker <https://bugs.python.org/issue38747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38747] Slowly introduce a subset of Jupyter console (IPython) features into CPython command line interactive mode
Marco Sulla added the comment: @Terry: > Jupyter Console is, I read, QT based Nope. It's shell based by default. You can open it also as a QT app, like IDLE, but by default `jupyter console` is via terminal. > they must use "‘magic’ commands" entered after the '>>>' prompt > instead of code. Guido specifically vetoed the idea Indeed I'm against too, and I wrote it. And if you read my proposals, I do not suggest any magic word > the answer to that proposal would be to use a PYTHONSTARTUP module > with code such as "import pprint as _; pprint = _.pprint" I know this, but it should be the default behaviour, IMHO. I mean, you can invoke `help()` in REPL but also in a `.py`. It makes no sense, but you can do it and you have not to import a separate module before. > The console feeds pasted lines *1 at a time* to interactive Python This is fixed by many terminal editors, like `vi`, with bracketed paste mode, as I wrote. > When REPL sends a prompt, everything up to and including a prompt is > somehow marked read-only. A workaround could be simulate input by user. Ugly but effective. > Syntax-coloring [...] requires full screen editing ??? > [Syntax-coloring] also needs to be configurable This could be IMHO delayed, or not implemented at all. If you don't like the colors, you can always not use it :D It will suffice that the colors will be as much as possible readable also by the majority of color-blind person. -- ___ Python tracker <https://bugs.python.org/issue38747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: I'm in favor of a `math.total_ordering` function, but IMHO sorting functions should emit a warning if they contains an unorderable objects. This can be done easily: I suppose the sorting function checks if the objects of the iterable are minor that another object. And soon or later, this check will be done for all objects in the iterable. What I propose is simply to add a flag `all_orderables`, true by default. After the current object a is checked against the object b, if `all_orderables` is true, another check will be performed: `a >= b`? If this return false, `all_orderables` will be set to false. At the end of sorting, if `all_orderables` is false, a warning will be emitted. This way, no old code will break, but developers will be informed of the problem. Because "Errors should never pass silently" :) -- nosy: +Marco Sulla ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: Excuse me, a little errata: > After the current object a is checked against the object b, if > `all_orderables` is true [...] must be change to > After the current object a is checked against the object b, ***if the check > returns false and*** if `all_orderables` is true [...] -- ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: Excuse me, but have you, Dickinson and Peters, read how I propose to check if the object is orderable or not? I explained it in a very detailed way, and this does not change the float comparison. And does not need to check first if the iterable it totally preordered. Can you please read my post? -- ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: Anyway, Java by default puts NaNs at the end of the iterable: https://onlinegdb.com/SJjuiXE0S -- ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: > No idea what "are minor that another object" could possibly mean. Oh my god... a < b? > I don't know what purpose would be served by checking ">=" too Well, it's very simple. Since the sorting algorithm checks if a < b, if this check fails, I propose to check also a >= b. If this is false too, the iterable contains an unorderable object. From this point, the check will never done again, an unorderable object is sufficient to raise the warning. The check a >= b is *not* for ordering the iterable, is only for checking if the elements are orderable or not, and raise the warning. Furthermore, I suppose that if someone is sure that its iterable is unorderable-free and want a fine-grained boost to speed, a flag can added. If true, sorting will not use the algorithm with the check, but the old algorithm. > You haven't addressed any of the points he (Dickinson) raised Dickinson said you have to check for total preorder. If you have understood my idea, this is not needed at all. -- ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: Excuse me, I had an epiphany. NaN returns False for every comparison. So in teory any element of the iterable should result minor that NaN. So NaN should treated as the highest element, and should be at the end of the sorted result! Indeed this is the behavior in Java. NaNs are in the end of the sorted iterator. On the contrary, Python sorting does not move the NaN from its position. Why? -- ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment:
marco@buzz:~$ python3.9
Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01)
[GCC 9.2.1 20190909] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as Dec, BasicContext as Bctx
>>> a = Dec("1981", Bctx)
>>> b = Dec("nan", Bctx)
>>> a.max(b)
Decimal('1981')
>>> b.max(a)
Decimal('1981')
>>> Bctx.max(a, b)
Decimal('1981')
>>> Bctx.max(b, a)
Decimal('1981')
--
___
Python tracker
<https://bugs.python.org/issue36095>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36095] Better NaN sorting.
Marco Sulla added the comment: Excuse me, ignore my previous post. -- ___ Python tracker <https://bugs.python.org/issue36095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11986] Min/max not symmetric in presence of NaN
Marco Sulla added the comment:
marco@buzz:~$ python3.9
Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01)
[GCC 9.2.1 20190909] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as Dec, BasicContext as Bctx
>>> a = Dec("1981", Bctx)
>>> b = Dec("nan", Bctx)
>>> a.max(b)
Decimal('1981')
>>> b.max(a)
Decimal('1981')
>>> Bctx.max(a, b)
Decimal('1981')
>>> Bctx.max(b, a)
Decimal('1981')
`Decimal` completely adheres to IEEE 754 standard.
There's a very, very simple and generic solution for builtin min and max:
_sentinel = object()
def max(*args, key=None, default=_sentinel):
args_len = len(args)
if args_len == 0:
if default is _sentinel:
fname = max.__name__
raise ValueError(f"{fname}() expected 1 argument, got 0")
return default
elif args_len == 1:
seq = args[0]
else:
seq = args
it = iter(seq)
vmax = next(it, _sentinel)
if vmax is _sentinel:
if default is _sentinel:
fname = max.__name__
raise ValueError(f"{fname}() arg is an empty sequence")
return default
first_comparable = False
if key is None:
for val in it:
if vmax < val:
vmax = val
first_comparable = True
elif not first_comparable and not val < vmax :
# equal, or not comparable object, like NaN
vmax = val
else:
fmax = key(vmax)
for val in it:
fval = key(val)
if fmax < fval :
fmax = fval
vmax = val
first_comparable = True
elif not first_comparable and not fval < fmax:
fmax = fval
vmax = val
return vmax
This function continues to give undefined behavior with sets... but who
calculates the "maximum" or "minimum" of sets?
--
nosy: +Marco Sulla
___
Python tracker
<https://bugs.python.org/issue11986>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39516] ++ does not throw a SyntaxError
New submission from Marco Sulla : Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01) [GCC 9.2.1 20190909] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 1 ++ 2 3 This is probably because the interpreter reads: 1 + +2 1. ++ could be an operator in future. Probably not. Probably never. But you never know. 2. A space between an unary operator and the object should not be allowed 3. the first expression is clearly unreadable and hard to understand, so completely unpythonic -- components: Interpreter Core messages: 361159 nosy: Marco Sulla priority: normal severity: normal status: open title: ++ does not throw a SyntaxError type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39516] ++ does not throw a SyntaxError
Marco Sulla added the comment: > This is not a bug No one said it's a bug. It's a defect. > This has been part of Python since version 1 There are many things that was part of Python 1 that was removed. > `++` should never be an operator in the future, precisely because it already > has a meaning today This is not a "meaning". `++` means nothing. Indeed >>> 1++ File "", line 1 1++ ^ SyntaxError: invalid syntax > The first expression is not "unreadable". The fact that you were able to read > it and diagnose it [...] The fact I understood it it's because I'm a programmer with more than 10 years of experience, mainly in Python. And I discovered this defect by acccident, because I wanted to write `a += b` and instead I wrote `a ++ b`. And when happened, I didn't realized why it didn't raised a SyntaxError or, at least, a SyntaxWarning. I had to take some minutes to realize the problem. So, in my "humble" opinion, it's *highly* unreadable and surprising. -- ___ Python tracker <https://bugs.python.org/issue39516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39516] ++ does not throw a SyntaxError
Marco Sulla added the comment: > `++` isn't special Indeed the problem is that no error or warning is raised if two operators are consecutive, without a space between. All the cases you listed are terribly unreadable and hardly intelligible. Anyway I do not agree `++` is not special: > you should know that this example is a syntax error because you are missing > the right hand operand, not because `++` has no meaning But you should know that in a *lot* of other popular languages, `++` and `--` are unary operators, so it's particularly surprisingly to see that they *seems* to work in Python, even if they *seems* to be a binary operator. This is completely confusing and messy. Frankly, I'm not a PEP 8 orthodox at all. I think that you can write `a+b`. It's not elegant, it's a bit less readable that `a + b`, but it's not the end of the world. But you should *not* be allowed to write `a+-b` without at least a warning, because `+-` seems a binary operator. And you should not be able to write `a+ -b` too, with the interpreter that acts like Ponzio Pilato, because what's this? Is it an unary `+` or an unary `-`? We know the unary is the `-`, `a+` has no sense. but for someone that does not know Python, __it's not readable__. So, IMHO, the interpreter should at least raise a warning if the syntax is not: `a + -b` for any combination of binary and unary operators. -- ___ Python tracker <https://bugs.python.org/issue39516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39516] ++ does not throw a SyntaxError
Marco Sulla added the comment: > this is the sort of thing that is usually best suited to be reported by > linters, not the Python runtime. TL;DR: if you write something like `a -- b`, it's quite extraordinary that you really wanted to write this. You probably wanted to write `a - -b` or, more probably, `a -= b`. So the parser is **masking a potential subtle bug**, that can cause hours of stressing debugging, because probably the program will run without problem but gives you a wrong result, or will throw an exception but in a completely different point. Long version: Normally I agree, but not in this case. PEP 8 defines line guides for writing a more readable code. They are not mandatory because: 1. there are cases in which is more readable if you not follow PEP 8 (for example, using `\` with long `with` statements) 2. there are cases in which the rule is not followed because of using it in fast tests (as for from module import *) 3. sometimes is simply not possible to follow PEP 8 (for example, many classes can easily implement __eq__, but implementing all the other comparison operators many times is simply not possible) 4. sometimes the recommendation can't be followed, because it's not what you want to achive (for example, sometimes you need to check the exact class of an object and use `type(a) == SomeClass` instead of `isinstance(a, SomeClass)`) 5. there are cases that PEP 8 does not work. For example, bool(numpy.ndarray) does not work, you must do len(numpy.ndarray) 6. sometimes, it's simply a matter of style. One prefers a style, another one prefer another style That said, none of these valid border cases can be applied to this case: 1. `a+-b` can be NEVER more readable than `a + -b` 2. `a++b` is clearly faster because you have to write... 2 spaces less. Well, I think that you'll never write a ton of binary operators followed by a unary one, so I suppose two little blank spaces does not slow down you too much :-D 3. it's always possible to separate `a * -b`, for example 4. if you write something like `a -- b`, it's quite extraordinary that you really wanted to write this. You probably wanted to write `a - -b` or, more probably, `a -= b`. So the parser is **masking a potential subtle bug**, that can cause hours of stressing debugging, because probably the program will run without problem but gives you a wrong result, or will throw an exception but in a completely different point. 5. See 3 6. this is IMHO not a matter of style. Writing `a ++ b` is simply ugly, **much** unreadable and prone to errors. -- ___ Python tracker <https://bugs.python.org/issue39516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39695] Failed to build _uuid module, but libraries was installed
New submission from Marco Sulla : When I first done `make` to compile Python 3.9, I did not installed some debian development packages, like `uuid-dev`. So `_uuid` module was not built. After installed the debian package I re-run `make`, but it failed to build `_uuid` module. I had to edit manually `Modules/_uuidmodule.c` and remove all the `#ifdef` directives and leave only `#include ` Maybe `HAVE_UUID_UUID_H` and `HAVE_UUID_H` are created at `configure` phase only? -- components: Build messages: 362309 nosy: Marco Sulla priority: normal severity: normal status: open title: Failed to build _uuid module, but libraries was installed type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39695> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39696] Failed to build _ssl module, but libraries was installed
New submission from Marco Sulla : Similarly to enhancement request #39695, I missed to install the debian package with the include files for SSL, before compiling Python 3.9. After installed it, `make` continued to not find the libraries and skipped the creation of module _ssl. Searching on internet, I found that doing: make clean ./configure etc make works. Maybe the SSL library check is done only at configure phase? -- components: Build messages: 362311 nosy: Marco Sulla priority: normal severity: normal status: open title: Failed to build _ssl module, but libraries was installed type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39697] Failed to build with --with-cxx-main=g++-9.2.0
New submission from Marco Sulla :
I tried to compile Python 3.9 with:
CC=gcc-9.2.0 ./configure --enable-optimizations --with-lto
--with-cxx-main=g++-9.2.0
make -j 2
I got this error:
g++-9.2.0 -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
-flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g -std=c99
-Wextra -Wno-unused-result -Wno-unused-parameter
-Wno-missing-field-initializers -Werror=implicit-function-declaration
-fvisibility=hidden -fprofile-generate -I./Include/internal -I. -I./Include
-DPy_BUILD_CORE -o Programs/_testembed.o ./Programs/_testembed.c
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’
is not valid for C++
cc1plus: warning: command line option ‘-std=c99’ is valid for C/ObjC but not
for C++
sed -e "s,@EXENAME@,/usr/local/bin/python3.9," < ./Misc/python-config.in
>python-config.py
LC_ALL=C sed -e 's,\$(\([A-Za-z0-9_]*\)),\$\{\1\},g' < Misc/python-config.sh
>python-config
gcc-9.2.0 -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3
-Wall-flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g
-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter
-Wno-missing-field-initializers -Werror=implicit-function-declaration
-fvisibility=hidden -fprofile-generate -I./Include/internal -I. -I./Include
-DPy_BUILD_CORE \
-DGITVERSION="\"`LC_ALL=C git --git-dir ./.git rev-parse --short HEAD`\""
\
-DGITTAG="\"`LC_ALL=C git --git-dir ./.git describe --all --always
--dirty`\"" \
-DGITBRANCH="\"`LC_ALL=C git --git-dir ./.git name-rev --name-only
HEAD`\"" \
-o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
In file included from ./Include/internal/pycore_atomic.h:15,
from ./Include/internal/pycore_gil.h:11,
from ./Include/internal/pycore_pystate.h:11,
from ./Programs/_testembed.c:10:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/stdatomic.h:40:9: error:
‘_Atomic’ does not name a type
I suppose simply `Programs/_testembed.c` is a C source file and must not be
compiled with g++
PS: as a workaround, `--with-cxx-main=gcc-9.2.0` works, but probably it's not
optimal.
--
components: Build
messages: 362313
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: Failed to build with --with-cxx-main=g++-9.2.0
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39697>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39698] asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers
New submission from Marco Sulla :
Python 3.9.0a3+ (heads/master-dirty:f2ee21d858, Feb 19 2020, 23:19:22)
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.sleep(-1)
Traceback (most recent call last):
File "", line 1, in
ValueError: sleep length must be non-negative
>>> import asyncio
>>> async def f():
... await asyncio.sleep(-1)
... print("no exception")
...
>>> asyncio.run(f())
no exception
I think that also `asyncio.sleep()` should raise `ValueError` if the argument
is less than zero.
--
components: asyncio
messages: 362314
nosy: Marco Sulla, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.sleep() does not adhere to time.sleep() behavior for negative
numbers
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39698>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39698] asyncio.sleep() does not adhere to time.sleep() behavior for negative numbers
Marco Sulla added the comment: > I recall very many cases in third-party libraries and commercial applications Source? -- ___ Python tracker <https://bugs.python.org/issue39698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
