[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
[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 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
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: KBININT13
46: KBININT1
[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
[issue36964] `python3 -m venv NAME`: virtualenv is not portable
Marco Sulla added the comment: The PR will probably be rejected... you can do something like this: 1. in the venv on our machine, do `pip freeze`. This gives you the whole list of installed dependencies 2. download all the packages using `pip download` 3. copy all the packages on the cloud, create the venv and install them using `pip install $PATH_TO_PACKAGE` -- ___ Python tracker <https://bugs.python.org/issue36964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: I did PGO+LTO... --enable-optimizations --with-lto -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: Well, actually Serhiy is right, it does not seem that the macro benchs did show something significant. Maybe the code can be used in other parts of CPython, for example in _pickle, where dicts are loaded. But it needs also to expose, maybe internally only, dictresize() and DICT_NEXT_VERSION(). Not sure it's something desirable. There's something that I do not understand: the speedup to unpack_sequence. I checked the pyperformance code, and it's a microbench for: a, b = some_sequence It should *not* be affected by the change. Anyway, I run the bench other 10 times, and the lowest value with the CPython code without the PR is not lower than 67.7 ns. With the PR, it reaches 53.5 ns. And I do not understand why. Maybe it affects the creation of the dicts with the local and global vars? -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: Well, following your example, since split dicts seems to be no more supported, I decided to be more drastic. If you see the last push in PR 22346, I do not check anymore but always resize, so the dict is always combined. This seems to be especially good for the "unpack_sequence" bench, even if I do not know what it is: | chaos | 132 ms | 136 ms | 1.03x slower | Significant (t=-18.09) | | crypto_pyaes| 136 ms | 141 ms | 1.03x slower | Significant (t=-11.60) | | float | 133 ms | 137 ms | 1.03x slower | Significant (t=-16.94) | | go | 276 ms | 282 ms | 1.02x slower | Significant (t=-11.58) | | logging_format | 12.3 us | 12.6 us| 1.02x slower | Significant (t=-9.75) | | logging_silent | 194 ns | 203 ns | 1.05x slower | Significant (t=-9.00) | | logging_simple | 11.3 us | 11.6 us| 1.02x slower | Significant (t=-12.56) | | mako| 16.5 ms | 17.4 ms| 1.05x slower | Significant (t=-17.34) | | meteor_contest | 116 ms | 120 ms | 1.04x slower | Significant (t=-25.59) | | nbody | 158 ms | 166 ms | 1.05x slower | Significant (t=-12.73) | | nqueens | 107 ms | 111 ms | 1.03x slower | Significant (t=-11.39) | | pickle_pure_python | 631 us | 619 us | 1.02x faster | Significant (t=6.28) | | regex_compile | 206 ms | 214 ms | 1.04x slower | Significant (t=-24.24) | | regex_v8| 28.4 ms | 26.7 ms| 1.06x faster | Significant (t=10.92) | | richards| 87.8 ms | 90.3 ms| 1.03x slower | Significant (t=-10.91) | | scimark_lu | 165 ms | 162 ms | 1.02x faster | Significant (t=4.55) | | scimark_sor | 210 ms | 215 ms | 1.02x slower | Significant (t=-10.14) | | scimark_sparse_mat_mult | 6.45 ms | 6.64 ms| 1.03x slower | Significant (t=-6.66) | | spectral_norm | 158 ms | 171 ms | 1.08x slower | Significant (t=-29.11) | | sympy_expand| 599 ms | 619 ms | 1.03x slower | Significant (t=-21.93) | | sympy_str | 376 ms | 389 ms | 1.04x slower | Significant (t=-23.80) | | sympy_sum | 233 ms | 239 ms | 1.02x slower | Significant (t=-14.70) | | telco | 7.40 ms | 7.61 ms| 1.03x slower | Significant (t=-10.08) | | unpack_sequence | 70.0 ns | 56.1 ns| 1.25x faster | Significant (t=10.62) | | xml_etree_generate | 108 ms | 106 ms | 1.02x faster | Significant (t=5.52) | | xml_etree_iterparse | 133 ms | 130 ms | 1.02x faster | Significant (t=11.33) | | xml_etree_parse | 208 ms | 204 ms | 1.02x faster | Significant (t=9.19) | -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42141] Speedup various dict inits
Marco Sulla added the comment: Well, after a second thought I think you're right, there's no significant advantage and too much duplicated code. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42141] Speedup various dict inits
Marco Sulla added the comment: The fact is that, IMHO, PGO will "false" the results, since it's quite improbable that in the test battery there's a test of creation of a dict from another dict with an hole. It seems to me that the comparison between the normal builds are more significant. -- ___ Python tracker <https://bugs.python.org/issue42141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42141] Speedup various dict inits
Marco Sulla added the comment: Note that this time I've no slowdown in the macro bench, since I used normal builds, not optimized ones. I suppose an optimized build will show slowdown because the new functions are not in the test battery. -- ___ Python tracker <https://bugs.python.org/issue42141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42141] Speedup various dict inits
Marco Sulla added the comment: I'm quite sure I not invented the wheel :) but I think it's a good improvement: | pathlib | 35.8 ms | 35.1 ms| 1.02x faster | Significant (t=13.21) | | scimark_monte_carlo | 176 ms | 172 ms | 1.02x faster | Significant (t=9.48) | | scimark_sor | 332 ms | 325 ms | 1.02x faster | Significant (t=11.96) | | telco | 11.0 ms | 10.8 ms| 1.03x faster | Significant (t=8.52) | | unpickle_pure_python| 525 us | 514 us | 1.02x faster | Significant (t=19.97) | | xml_etree_process | 132 ms | 129 ms | 1.02x faster | Significant (t=17.59) | -- components: +Interpreter Core type: -> performance versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue42141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42141] Speedup various dict inits
New submission from Marco Sulla :
The PR #22948 is an augmented version of #22346. It speeds up also the creation
of:
1. dicts from other dicts that are not "perfect" (combined and without holes)
2. fromkeys
3. copies of dicts with many holes
4. dict from keywords, as in #22346
A sample bench:
python -m pyperf timeit --rigorous "dict(o)" -s """
from uuid import uuid4
def getUuid():
return str(uuid4())
o = {getUuid():getUuid() for i in range(1000)}
delkey = getUuid()
o[delkey] = getUuid()
del o[delkey]
"""
.
Before #22948:
Mean +- std dev: 35.9 us +- 0.6 us
After:
Mean +- std dev: 26.4 us +- 0.4 us
--
messages: 379540
nosy: Marco Sulla
priority: normal
pull_requests: 21865
severity: normal
status: open
title: Speedup various dict inits
___
Python tracker
<https://bugs.python.org/issue42141>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: I commented out sqlalchemy in the requirements.txt in the pyperformance source code, and it worked. I had also to skip tornado: pyperformance run -r -b,-sqlalchemy_declarative,-sqlalchemy_imperative,-tornado_http -o ../perf_master.json This is my result: pyperformance compare perf_master.json perf_dict_init.json -O table | grep Significant | 2to3| 356 ms | 348 ms | 1.02x faster | Significant (t=7.28) | | fannkuch| 485 ms | 468 ms | 1.04x faster | Significant (t=9.68) | | pathlib | 22.5 ms | 22.1 ms | 1.02x faster | Significant (t=13.02) | | pickle_dict | 29.0 us | 30.3 us | 1.05x slower | Significant (t=-92.36) | | pickle_list | 4.55 us | 4.64 us | 1.02x slower | Significant (t=-10.87) | | pyflate | 735 ms | 702 ms | 1.05x faster | Significant (t=6.67) | | regex_compile | 197 ms | 193 ms | 1.02x faster | Significant (t=2.81) | | regex_v8| 24.5 ms | 23.9 ms | 1.02x faster | Significant (t=17.63) | | scimark_fft | 376 ms | 386 ms | 1.03x slower | Significant (t=-15.07) | | scimark_lu | 154 ms | 158 ms | 1.03x slower | Significant (t=-12.94) | | sqlite_synth| 3.35 us | 3.21 us | 1.04x faster | Significant (t=17.65) | | telco | 6.54 ms | 7.14 ms | 1.09x slower | Significant (t=-8.51) | | unpack_sequence | 58.8 ns | 61.5 ns | 1.04x slower | Significant (t=-19.66) | It's strange that some benchmarks are slower, since the patch only do two additional checks to dict_vectorcall. Maybe they use many little dicts? @methane: > Would you implement some more optimization based on your PR to demonstrate > your idea? I already done them, I'll do a PR. -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment:
@Mark.Shannon I tried to run pyperformance, but wheel does not work for Python
3.10. I get the error:
AssertionError: would build wheel with unsupported tag ('cp310', 'cp310',
'linux_x86_64')
--
___
Python tracker
<https://bugs.python.org/issue41835>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: @methane: well, to be honest, I don't see much difference between the two pulls. The major difference is that you merged insertdict_init in dict_merge_init. But I kept insertdict_init separate on purpose, because this function can be used in other future dedicated function on creation time only. Furthermore it's more simple to maintain, since it's quite identical to insertdict. -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: Another bench: python -m pyperf timeit --rigorous "dict(ihinvdono='doononon', gowwondwon='nwog', bdjbodbob='nidnnpn', nwonwno='vndononon', dooodbob='iohiwipwgpw', doidonooq='ndwnnpnpnp', fndionqinqn='ndjboqoqjb', nonoeoqgoqb='bdboboqbgoqeb', jdnvonvoddo='nvdjnvndvonoq', njnvodnoo='hiehgieba', nvdnvwnnp='wghgihpa', nvfnwnnq='nvdknnnqkm', ndonvnipnq='fndjnaobobvob', fjafosboab='ndjnodvobvojb', nownwnojwjw='nvknnndnow', niownviwnwnwi='nownvwinvwnwnwj')" Result without pull: Mean +- std dev: 486 ns +- 8 ns Result with pull: Mean +- std dev: 328 ns +- 4 ns I compiled both with optimizations and lto. Some arch info: python -VV Python 3.10.0a1+ (heads/master-dirty:dde91b1953, Oct 22 2020, 14:00:51) [GCC 10.1.1 20200718] uname -a Linux buzz 4.15.0-118-generic #119-Ubuntu SMP Tue Sep 8 12:30:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.5 LTS -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41901] Added some explaining to pickle errors.
Marco Sulla added the comment: I closed it for this reason: https://github.com/python/cpython/pull/22438#issuecomment-702794261 -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41901] Added some explaining to pickle errors.
Marco Sulla added the comment: I do not remember the problem I had, but when I experimented with frozendict I get one of these errors. I failed to understand the problem so I added the additional info. Maybe adding an assert in debug mode? It will be visible only to devs. -- ___ Python tracker <https://bugs.python.org/issue41901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41901] Added some explaining to pickle errors.
New submission from Marco Sulla : All pickle error messages in typeobject.c was a generic "cannot pickle 'type' object". Added some explaining for every individual error. -- components: Interpreter Core messages: 377747 nosy: Marco Sulla priority: normal pull_requests: 21494 severity: normal status: open title: Added some explaining to pickle errors. type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
Marco Sulla added the comment: > `dict(**o)` is not common use case. Could you provide some other benchmarks? You can do python -m timeit -n 200 "dict(key1=1, key2=2, key3=3, key4=4, key5=5, key6=6, key7=7, key8=8, key9=9, key10=10)" or with pyperf. In this case, since the dict is little, I observed a speedup of 25%. -- ___ Python tracker <https://bugs.python.org/issue41835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41835] Speed up dict vectorcall creation using keywords
New submission from Marco Sulla :
I've done a PR that speeds up the vectorcall creation of a dict using keyword
arguments. The PR in practice creates a insertdict_init(), a specialized
version of insertdict. I quote the comment to the function:
Same to insertdict but specialized for inserting without resizing and for dict
that are populated in a loop and was empty before (see the empty arg).
Note that resizing must be done before calling this function. If not
possible, use insertdict(). Furthermore, ma_version_tag is left unchanged, you
have to change it after calling this function (probably at the end of a loop).
This change speeds up the code up to a 30%. Tested with:
python -m timeit -n 2000 --setup "from uuid import uuid4 ; o =
{str(uuid4()).replace('-', '') : str(uuid4()).replace('-', '') for i
in range(1)}" "dict(**o)"
--
components: Interpreter Core
messages: 377318
nosy: Marco Sulla, inada.naoki
priority: normal
pull_requests: 21398
severity: normal
status: open
title: Speed up dict vectorcall creation using keywords
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41835>
___
___
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()
New submission from Marco Sulla : This is a little PR with some micro-optimizations to the PySequence_Tuple() function. Mainly, it simply add a support variable new_n_tmp_1 instead of reassigning newn multiple times. -- components: Interpreter Core messages: 363974 nosy: Marco Sulla priority: normal pull_requests: 18296 severity: normal status: open title: Micro-optimizations to PySequence_Tuple() type: performance versions: Python 3.9 ___ 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
[issue39842] partial_format()
Marco Sulla added the comment: @Eric V. Smith: that you for your effort, but I'll never use an API marked as private, that is furthermore undocumented. -- ___ Python tracker <https://bugs.python.org/issue39842> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39842] partial_format()
Marco Sulla added the comment:
> What would "{} {}".partial_format({}) return?
`str.partial_format()` was proposed exactly to avoid such tricks.
> It is not possible to implement a "safe" variant of str.format(),
> because in difference to Template it can call arbitrary code
If you read the documentation of `Template.safe_substitute()`, you can read
also this function is not safe at all.
But Python, for example, does not implement private class attributes. Because
Python is for adult and consciousness people, no?
--
___
Python tracker
<https://bugs.python.org/issue39842>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39848] Warning: 'classifiers' should be a list, got type 'tuple'
Change by Marco Sulla : -- resolution: -> duplicate stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python.org/issue39848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers)
Marco Sulla added the comment: This is IMHO broken. 1. _ensure_list() allows strings, because, documentation says, they are split in finalize_options(). But finalize_options() does only split keywords and platforms. It does _not_ split classifiers. 2. there's no need that keywords, platforms and classifiers must be a list. keywords and platforms can be any iterable, and classifiers can be any non text-like iterable. Indeed, keywords are written to file using ','.join(), and platforms and classifiers are written using DistributionMetadata._write_list(). They both accepts any iterable, so I do not understand why such a strict requirement. -- nosy: +Marco Sulla ___ Python tracker <https://bugs.python.org/issue19610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39842] partial_format()
Marco Sulla added the comment: > Do you have some concrete use case for this? Yes, for EWA: https://marco-sulla.github.io/ewa/ Since it's a code generator, it uses templates a lot, and much times I feel the need for a partial substitution. In the end I solved with some ugly tricks. Furthermore, if the method exists in the stdlib for `string.Template`, I suppose it was created because it was of some utility. -- ___ Python tracker <https://bugs.python.org/issue39842> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39848] Warning: 'classifiers' should be a list, got type 'tuple'
New submission from Marco Sulla : I got this warning. I suppose that `distutils` can use any iterable. -- components: Distutils messages: 363354 nosy: Marco Sulla, dstufft, eric.araujo priority: normal severity: normal status: open title: Warning: 'classifiers' should be a list, got type 'tuple' versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39820] Bracketed paste mode for REPL
Marco Sulla added the comment: IMHO such a feature is useful for sysops that does not have a graphical interface, as Debian without an X. That's why vi is (unluckily) very popular also in 2020. IDLE can't be used in this cases. Windows users can't remotely login without a GUI, so the feature for such platforms can be not implemented, since there's builtin solutions (IDLE) -- ___ Python tracker <https://bugs.python.org/issue39820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39842] partial_format()
New submission from Marco Sulla :
In `string` module, there's a very little known class `Template`. It implements
a very simple template, but it has an interesting method: `safe_substitute()`.
`safe_substitute()` permits you to not fill the entire Template at one time. On
the contrary, it substitute the placeholders that are passed, and leave the
others untouched.
I think it could be useful to have a similar method for the format
minilanguage. I propose a partial_format() method.
=== WHY I think this is useful? ===
This way, you can create subtemplates from a main template. You could want to
use the template for creating a bunch of strings, all of them with the same
value for some placeholders, but different values for other ones. This way you
have *not* to reuse the same main template and substitute every time the
placeholders that does not change.
`partial_format()` should act as `safe_substitute()`: if some placeholder
misses a value, no error will be raised. On the contrary, the placeholder is
leaved untouched.
Some example:
>>> "{} {}".partial_format(1)
'1 {}'
>>> "{x} {a}".partial_format(a="elephants")
'{x} elephants'
>>> "{:-f} and {:-f} nights".partial_format(1000)
'1000 and {:-f} nights'
------
components: Interpreter Core
messages: 363317
nosy: Marco Sulla
priority: normal
severity: normal
status: open
title: partial_format()
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39842>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39820] Bracketed paste mode for REPL
Marco Sulla added the comment: Excuse me, but my original "holistic" proposal was rejected and it was suggested to me to propose only relevant changes, and one for issue. Now you say exactly the contrary. I feel a bit confused. PS: yes, I can, and I use, IPython. But IMHO IPython does too much things and its design is not very pythonic. Bracketed paste mode is a good feature, and I think REPL will be much more useful if it implements it. On the contrary, if you don't think IPython is good, pythonic and essential, I suppose there's no problem to substitute REPL with IPython in CPython core itself. -- nosy: +eryksun, steven.daprano, terry.reedy ___ Python tracker <https://bugs.python.org/issue39820> ___ ___ 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
Marco Sulla added the comment: I agree with Pablo Galindo Salgado: https://bugs.python.org/issue35912#msg334942 The "quick and dirty" solution is to change MAINCC to CC, for _testembed.c AND python.c (g++ fails with both). After that, _testembed.c and python.c should be changed so they can be compiled with a c++ compiler, and a system test should be added. Anyway, I found the original patch: https://bugs.python.org/file6816/cxx-main.patch In the original patch, the README contained detailed information. I think these informations could be restored, maybe in ./configure --help Anyway, I have a question. In README, it's stated: There are platforms that do not require you to build Python with a C++ compiler in order to use C++ extension modules. E.g., x86 Linux with ELF shared binaries and GCC 3.x, 4.x is such a platform. All x86 platforms? Also x86-64? And what does it means "Linux with ELF"? It means that Linux has shared libraries or that Python is compiled with --enable-shared? And what it means gcc 3 and 4? It means gcc 3+? -- ___ 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
[issue39820] Bracketed paste mode for REPL
Marco Sulla added the comment: Please read the message of Terry J. Reed: https://bugs.python.org/issue38747#msg356345 I quote the relevant part below > Skipping the rest of your post, I will just restate why I closed this > issue. > > 1. It introduces too many features not directly related. The existing > unix-only completions uses two modules. I suspect some of the other > features would also need new modules. (But Marco, please don't rush > to immediately open 8 new issues.) -- ___ Python tracker <https://bugs.python.org/issue39820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39820] Bracketed paste mode for REPL
Marco Sulla added the comment: > Is this even possible in a plain text console? Yes. See Jupyter Console (aka IPython). -- ___ Python tracker <https://bugs.python.org/issue39820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39820] Bracketed paste mode for REPL
New submission from Marco Sulla : I suggest to add an implementation of bracketed paste mode in the REPL. Currently if you, for example, copy & paste a piece of Python code to see if it works, if the code have a blank line without indentation and the previous and next line are indented, REPL raises an error. If you create a .py, paste the same code and run it with the python interpreter, no error is raised, since the syntax is legit. Bracketed paste mode is implemented in many text editors, as vi. -- components: Interpreter Core messages: 363109 nosy: Marco Sulla priority: normal severity: normal status: open title: Bracketed paste mode for REPL type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39820> ___ ___ 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
Marco Sulla added the comment: Furthermore, I have not understood a think: if I understood well, --with-cxx-main is used on _some_ platforms that have problems with C++ extensions. What platforms? Is there somewhere a unit test for testing if Python compiled on one of these platforms with -with-cxx-main= works, and if a C++ extension works with this build? -- ___ 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
[issue39697] Failed to build with --with-cxx-main=g++-9.2.0
Marco Sulla added the comment: Okay... if I have understood well, the problem is with C++ Extensions. Some questions: 1. does this problem exists yet? 2. if yes, maybe Python have to wrap the python.c and _testembed.c so they can also be compiled with a C++ compiler? 3. --with-cxx-main is not somewhat misleading? There's no documentation, and I interpreted it as "the _main_ compiler for C++", while it means "the compiler for main()". Should I suggest (maybe in another issue) to deprecate it and use --with-mainfun-compiler ? -- ___ 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
[issue39813] test_ioctl skipped -- Unable to open /dev/tty
Marco Sulla added the comment: OS: Lubuntu 18.04.4 Steps to reproduce: sudo apt-get install git libbz2-dev liblzma-dev uuid-dev libffi-dev libsqlite3-dev libreadline-dev libssl-dev libgdbm-dev libgdbm-compat-dev tk-dev libncurses5-dev git clone https://github.com/python/cpython.git cd cpython CC=gcc-9 CXX=g++-9 ./configure --enable-optimizations --with-lto make -j 4 make test marco@buzz:~/sources/cpython_test$ python3.9 Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01) [GCC 9.2.1 20190909] on linux -- ___ Python tracker <https://bugs.python.org/issue39813> ___ ___ 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
Marco Sulla added the comment: Mmmm... wait a moment. It seems the behavior is intended: https://bugs.python.org/issue1324762 I quote: The patch contains the following changes: [...] 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). [...] If --with-cxx-main= is on the configure command line, then MAINCC=. Honestly I have _no idea_ why this change was made. Unluckily, the link to the discussion is broken. -- nosy: +cludwig ___ 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
[issue39697] Failed to build with --with-cxx-main=g++-9.2.0
Marco Sulla added the comment: https://github.com/python/cpython/pull/18721 -- ___ 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
[issue39697] Failed to build with --with-cxx-main=g++-9.2.0
Change by Marco Sulla : -- keywords: +patch pull_requests: +18079 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18721 ___ 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
[issue39697] Failed to build with --with-cxx-main=g++-9.2.0
Marco Sulla added the comment: The problem is here: Programs/_testembed.o: $(srcdir)/Programs/_testembed.c $(MAINCC) -c $(PY_CORE_CFLAGS) -o $@ $(srcdir)/Programs/_testembed.c `MAINCC` in my Makefile is `g++-9`. Probably, MAINCC is set to the value of ``--with-cxx-main`, if specified. I replaced `MAINCC` with `CC` at this line, and it works. -- ___ 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
[issue39813] test_ioctl skipped -- Unable to open /dev/tty
New submission from Marco Sulla : During `make test`, I get the error in the title. (venv_3_9) marco@buzz:~/sources/cpython_test$ ll /dev/tty crw-rw-rw- 1 root tty 5, 0 Mar 1 15:24 /dev/tty -- components: Tests messages: 363063 nosy: Marco Sulla priority: normal severity: normal status: open title: test_ioctl skipped -- Unable to open /dev/tty type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39788] Exponential notation should return an int if it can
Marco Sulla added the comment: > >>> int(1e100) > 1159028911097599180468360808563945281389781327557747838772170381060813469985856815104 . Oh my God... I'm just more convinced than before :-D > Ya, this change will never be made - give up gracefully :-) Well, even if it's Tim Peters himself that ask it to me :-) I can't. -- ___ Python tracker <https://bugs.python.org/issue39788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39788] Exponential notation should return an int if it can
Marco Sulla added the comment: All the examples you mentioned seems to me to fix code, instead of breaking it. About 1e300**1, it's not a bug at all. No one can stop you to full your RAM in many other ways :-D About conventions, it does not seems to me that Python cares about other languages very much, if it's more natural for normal people to expect a result instead of a consolidated one among devs. See `1 / 2 == 0.5`, for example. > But by your own feature request, this would return an int and your "feature" would bite you You're citing the *optional* extra to the original idea. We can agree it is not a good addition at all. I continue to think that nE+m, where n and m are integers, should return an integer. If this can break old code, I'm the first to think it should not be implemented, but I don't see any problem (yet). -- ___ Python tracker <https://bugs.python.org/issue39788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39788] Exponential notation should return an int if it can
Marco Sulla added the comment: Sorry, but I can't figure out what code can break this change. Integers are implicitly converted to floats in operations with floats. How can this change break old code? > if you are worried about the performance No, I'm worried about the expectations of coders. Personally, I expected that 1E2 returned a integer. And this is not true. If I wanted a float, I'd wrote 1.0E2 . The fact the exponential notation returns always a float is really misleading, IMHO. -- ___ Python tracker <https://bugs.python.org/issue39788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39788] Exponential notation should return an int if it can
New submission from Marco Sulla : (venv_3_9) marco@buzz:~/sources/python-frozendict$ python 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. >>> a = 1E9 >>> type(a) IMHO if the exponent is positive, and the "base number" (1 in the example) is an integer, the result should be an integer. Optionally, also if the "base number" has a number of decimal places <= the exponent, the result should be an integer. Example: 1.25E2 == 125 If the user wants a float, it can write 1.2500E2 == 125.0 -- components: Interpreter Core messages: 362918 nosy: Marco Sulla priority: normal severity: normal status: open title: Exponential notation should return an int if it can type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39784] Tuple comprehension
New submission from Marco Sulla : I think a tuple comprehension could be very useful. Currently, the only way to efficiently create a tuple from a comprehension is to create a list comprehension (generator comprehensions are more slow) and convert it with `tuple()`. A tuple comprehension will do exactly the same thing, but without the creation of the intermediate list. IMHO a tuple comprehension can be very useful, because: 1. there are many cases in which you create a list with a comprehension, but you'll never change it later. You could simply convert it with `tuple()`, but it will require more time 2. tuples uses less memory than lists 3. tuples can be interned As syntax, I propose (* expr for x in iterable *) with absolutely no blank character between the character ( and the *, and the same for ). Well, I know, it's a bit strange syntax... but () are already taken by generator comprehensions. Furthermore, the * remembers a snowflake, and tuples are a sort of "frozenlists". -- components: Interpreter Core messages: 362888 nosy: Marco Sulla priority: normal severity: normal status: open title: Tuple comprehension versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39784> ___ ___ 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 also distinctly remember seeing code (and writing such code myself) that > performs computation on timeouts and does not care if the end value goes > below 0. This is not a good statistics. Frankly we can't measure the impact of the change from these considerations. And furthermore, `asyncio.sleep()` is used often, testing and mocking apart? I doubt it. > we always try to have a very good explanation "why" we want to bother > ourselves and users to break backwards compat. Coherence and unhide mistakes are *very* strong points. That said, I'm not so much interested in practice. Do as you wish. The problem is I always considered Python a very elegant programming language, and this behavior is not elegant at all. But, hey, amen. -- ___ 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
Change by Marco Sulla : -- resolution: not a bug -> rejected ___ 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
[issue34396] Certain methods that heap allocated subtypes inherit suffer a 50-80% performance penalty
Marco Sulla added the comment: I asked why on StackOverflow, and an user seemed to find the reason. The problem for him/her is in `update_one_slot()`. `dict` implements directly `__contains__()` and `__getitem__()`. Usually, `sq_contains` and `mp_subscript` are wrapped to implement `__contains__()` and `__getitem__()`, but this way `dict` is a little faster. The problem is that `update_one_slot()` searches for the wrappers. If it does not find them, it does not inherit the `__contains__()` and `__getitem__()` of the class, but create a `__contains__()` and `__getitem__()` functions that do an MRO search and call the superclass method. This is why `__contains__()` and `__getitem__()` of `dict` subclasses are slower. Is it possible to modify `update_one_slot()` so that, if no wrapper is found, the explicit implementation is inherited? SO answer: https://stackoverflow.com/a/59914459/1763602 -- components: +C API -Interpreter Core nosy: +Marco Sulla versions: +Python 3.9 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue34396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39754] update_one_slot() does not inherit sq_contains and mp_subscript if they are explictly declared
Change by Marco Sulla : -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39754] update_one_slot() does not inherit sq_contains and mp_subscript if they are explictly declared
New submission from Marco Sulla : I noticed that `__contains__()` and `__getitem__()` of subclasses of `dict` are much slower. I asked why on StackOverflow, and an user seemed to find the reason. The problem for him/her is that `dict` implements directly `__contains__()` and `__getitem__()`. Usually, `sq_contains` and `mp_subscript` are wrapped to implement `__contains__()` and `__getitem__()`, but this way `dict` is a little faster, I suppose. The problem is that `update_one_slot()` searches for the wrappers. If it does not find them, it does not inherit the `__contains__()` and `__getitem__()` of the class, but create a `__contains__()` and `__getitem__()` functions that do an MRO search and call the superclass method. This is why `__contains__()` and `__getitem__()` of `dict` subclasses are slower. Is it possible to modify `update_one_slot()` so that, if no wrapper is found, the explicit implementation is inherited? SO answer: https://stackoverflow.com/a/59914459/1763602 -- components: C API messages: 362662 nosy: Marco Sulla priority: normal severity: normal status: open title: update_one_slot() does not inherit sq_contains and mp_subscript if they are explictly declared type: performance versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39754> ___ ___ 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
Marco Sulla added the comment: I think in this case the error is more trivial: simply `Programs/_testembed.c` is compiled with g++ but it should be compiled with gcc. Indeed, there are much gcc-only options in the compilation of `Programs/_testembed.c`, and g++ complains about them: > 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++ -- ___ 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
Marco Sulla added the comment: I see that many breaking changes was done in recent releases. I get only the ones for `asyncio` in Python 3.8: https://bugs.python.org/issue36921 https://bugs.python.org/issue36373 https://bugs.python.org/issue34790 https://bugs.python.org/issue32528 https://bugs.python.org/issue34687 https://bugs.python.org/issue32314 So I suppose the ship isn't sailed yet. Passing a negative number to a function that should sleep the task for x seconds is a mistake. And mistakes should never pass silently. Furthermore, coherence matters. It's really confusing that two functions in two builtin modules that are quite identical have a different behavior. IMHO, deprecating and then removing support for negative argument in `asyncio.sleep()` is very much less breaking compared to issues #36921 and #36373 . -- type: -> behavior ___ 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
[issue39695] Failed to build _uuid module, but libraries was installed
Marco Sulla added the comment: Ah, well, this is not possible. I was banned from the mailing list. I wrote my "defense" to conduct...@python.org in date 2019-12-29, and I'm still waiting for a response... -- ___ 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
[issue39695] Failed to build _uuid module, but libraries was installed
Marco Sulla added the comment: Well, the fact is, basically, for the other libraries you have not to re-run `configure`. You have to install only the missing C libraries and redo `make`. This works, for example, for zlib, lzma, ctypes, sqlite3, readline, bzip2. Furthermore, it happened to me that I re-run `configure` without a `make clean` before: the `make` process stopped because configuration was changed, and I have to do a `make clean`. A big waste of time. -- ___ 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
[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
[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
[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
[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
[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
[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
[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 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
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
[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
[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
[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, 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: > 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: 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: 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: 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: 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
[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
[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: 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: 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
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
[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
[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:
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: 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
[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
[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
[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: 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: 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
[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?
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: @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
[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
New submission from Marco Sulla : Currectly, even if two `Element`s elem1 and elem2 are different objects but the tree is identical, elem1 == elem2 returns False. The only effective way to compare two `Element`s is ElementTree.tostring(elem1) == ElementTree.tostring(elem2) Furthermore, from 3.8 this could be not true anymore, since the order of insertion of attributes will be preserved. So if I simply wrote a tag with two identical attributes, but with different order, the trick will not work anymore. Is it so much complicated to implement an __eq__ for `Element` that traverse its tree? PS: some random remarks about xml.etree.ElementTree module: 1. why `fromstring` and `fromstringlist` separated functions? `fromstring` could use duck typing for the main argument, and `fromstringlist` deprecated. 2. `SubElement`: why the initial is a capital letter? It seems the constructor of a different class, while it's a factory function. I'll change it to `subElement` and deprecate `SubElement` -- components: Library (Lib) messages: 349230 nosy: Marco Sulla priority: normal severity: normal status: open title: xml.etree.ElementTree.Element.__eq__ does compare only objects identity versions: Python 3.9 ___ 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
[issue37791] Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()`
New submission from Marco Sulla : I propose to mark as deprecated the parameters `ignore_errors` and `onerror` of `shutil.rmtree()`, and raise a warning if used. The reason is I feel them unpythonic. For emulating `ignore_errors=True`, the code can be written simply with a `try-except` that passes by default all `OSError`s . The `ignore_errors=True, onerror=myHandler` case can written simply with a `try-except` that handles `OSError`s. And in the handle can be code or a call to an handler with the same paramaters `myHandler` accept. -- components: +Library (Lib) title: Propose to deprecate ignore_errors, -> Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` type: -> enhancement versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue37791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37791] Propose to deprecate ignore_errors,
Change by Marco Sulla : -- nosy: Marco Sulla priority: normal severity: normal status: open title: Propose to deprecate ignore_errors, ___ Python tracker <https://bugs.python.org/issue37791> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36964] `python3 -m venv NAME`: virtualenv is not portable
Marco Sulla added the comment: > I don't like the idea of changing what VIRTUAL_ENV gets set to when I > believe you should recreate the virtual environment as necessary and > risk surprising people who expect VIRTUAL_ENV to function as it does > today and has for years. (Talking to the wind) Well, didn't you have software tests? -- ___ Python tracker <https://bugs.python.org/issue36964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36964] `python3 -m venv NAME`: virtualenv is not portable
Marco Sulla added the comment: Please Mr. Cannon, can you read my last posts? I think they are not describing a mad idea, but something reasonable. -- nosy: +brett.cannon ___ Python tracker <https://bugs.python.org/issue36964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
