[issue42233] GenericAlias does not support union type expressions
Dávid Nemeskey added the comment: @kj Sorry, for some reason, I thought the that issue affected Union as well, but I have just re-tested it and found that it works. -- ___ Python tracker <https://bugs.python.org/issue42233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42233] GenericAlias does not support union type expressions
Dávid Nemeskey added the comment: Guys, any chance the fix will land in 3.9? It is affected as well. -- nosy: +nemeskeyd ___ Python tracker <https://bugs.python.org/issue42233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45271] Add a 'find' method (a'la str) to list
Change by Dávid Nemeskey : -- type: -> enhancement ___ Python tracker <https://bugs.python.org/issue45271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45271] Add a 'find' method (a'la str) to list
New submission from Dávid Nemeskey : There is an unjustified asymmetry between `str` and `list`, as far as lookup goes. Both have an `index()` method that returns the first index of a value, or raises a `ValueError` if it doesn't exist. However, only `str` has the `find` method, which returns -1 if the value is not in the string. I think it would make sense to add `find` to `list` as well. For starters, it would make the API between the two sequence types more consistent. More importantly (though it depends on the use-case), `find` is usually more convenient than `index`, as one doesn't have to worry about handling an exception. As a bonus, since `list` is mutable, it allows one to write code such as if (idx := lst.find(value)) == -1: lst.append(value) call_some_function(lst[idx]) , making the method even more useful as it is in `str`. -- messages: 402497 nosy: nemeskeyd priority: normal severity: normal status: open title: Add a 'find' method (a'la str) to list ___ Python tracker <https://bugs.python.org/issue45271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39816] More descriptive error message than "too many values to unpack"
Dávid Nemeskey added the comment:
+1. When starting out, I always got confused about this message ("too many
values to unpack? Does that mean my function returned too many items, which
could not be unpacked into the expected number? Oh no, the opposite...").
Also, please note that the stack trace usually shows the offending line (e.g.
x, y, z = fn(...)), so it is easy to see how many values are _expected_. It
would be even more helpful to (also) show how many we _got_.
--
nosy: +nemeskeyd
___
Python tracker
<https://bugs.python.org/issue39816>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43306] Error in multiprocessing.Pool's initializer doesn't stop execution
New submission from Dávid Nemeskey : There is an inconsistency in how multiprocessing.Pool handles exceptions thrown in the workers: - exceptions raised by the mapped function stop execution right away - exceptions raised in an initializer are ignored and the pool continues spawning new workers indefinitely, each of them failing. I believe the behavior should be the same in both cases, and of the two, the first one is preferable (especially since that's what people are used to). The documentation doesn't cover how exceptions are handled in pools, either. -- assignee: docs@python components: Documentation, Library (Lib) messages: 387577 nosy: docs@python, nemeskeyd priority: normal severity: normal status: open title: Error in multiprocessing.Pool's initializer doesn't stop execution type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43306> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42956] Easy conversion between range and slice
Dávid Nemeskey added the comment: s/to different/two different/ -- ___ Python tracker <https://bugs.python.org/issue42956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42956] Easy conversion between range and slice
New submission from Dávid Nemeskey : It would be nice if there was an easy way to convert a range to a slice and vice versa. At least superficially the two are almost the same(*), yet if one wants to convert a slice to a range, he has to go through hoops to avoid potential errors, ending up with code such as: s = slice(1, 10, 2) r = range(s.start or 0, s.stop, s.step or 1) It would be much nicer if the range and slice functions had a signature that accepts the other, which would simplify the above to just r(s). (*) I don't know the implementation details, but is it even important to have to different objects for effectively the same concept? Cannot these two just be merged? -- messages: 385184 nosy: nemeskeyd priority: normal severity: normal status: open title: Easy conversion between range and slice type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36664] argparse: parser aliases in subparsers stores alias in dest variable
Dávid Nemeskey added the comment: I ran into the same problem. I know of the set_defaults() method, in fact, that is what I have always been using. But why was dest added if not to provide a better solution? I agree that changing it would _perhaps_ break some code, so I agree that this issue cannot be "fixed" for Python 3.7 (and probably 3.8). But what about 3.9 or 4.0? BTW much higher profile backward-incompatible changes do happen in Python; take PEP 563 (https://www.python.org/dev/peps/pep-0563/), for instance. -- nosy: +nemeskeyd ___ Python tracker <https://bugs.python.org/issue36664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35786] get_lock() method is not present for Values created using multiprocessing.Manager()
Dávid Nemeskey added the comment: OK, actually: trying to create a multiprocessing.Value object and sharing it between a Pool of processes results in "RuntimeError: Synchronized objects should only be shared between processes through inheritance". So the only way seems to be through a Manager, but its Value() is of a different class? -- ___ Python tracker <https://bugs.python.org/issue35786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35786] get_lock() method is not present for Values created using multiprocessing.Manager()
Dávid Nemeskey added the comment: Nothing in the documentation says that multiprocessing.Value and the object returned by manager.Value() is any different. Nor is it clear why they should be. It is perfectly understandable to expect that manager.Value() is actually of type multiprocessing.Value. It is also a valid assumption that the "canonical" way to acquire such objects are from a Manager, not directly. An example that reinforces this assumption is that of the Queue class, which HAS to be created through a Manager, lest we get "RuntimeError: Queue objects should only be shared between processes through inheritance". In conclusion, I think this is definitely a valid issue. What I am not so sure about is if it is (just) an issue in the documentation or the API itself. -- nosy: +nemeskeyd versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue35786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36271] '_io.TextIOWrapper' object has no attribute 'mode'
Dávid Nemeskey added the comment: Note that this is not the same as GZipFile.mode, which is 1 or 2 (READ or WRITE), instead of the more informative "[raw][bt ]". -- ___ Python tracker <https://bugs.python.org/issue36271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36271] '_io.TextIOWrapper' object has no attribute 'mode'
New submission from Dávid Nemeskey : TextIOWrapper objects returned by gzip.open() or bz2.open() do not have the 'mode' data member. Those returned by io.open() do. It would be nice if it did. -- components: Library (Lib) messages: 337745 nosy: nemeskeyd priority: normal severity: normal status: open title: '_io.TextIOWrapper' object has no attribute 'mode' versions: Python 3.5, Python 3.7 ___ Python tracker <https://bugs.python.org/issue36271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30471] "as" keyword in comprehensions
Dávid Nemeskey added the comment: The truth is, I was thinking about going to the list, but according to PEP 42 (https://www.python.org/dev/peps/pep-0042/), this space was one of the places new features could be requested: """ Note This PEP has been rejected as obsolete. All new feature requests should either go to the Python bug tracker [1] or the python-ideas [2] mailing list. The rest of this document is retained for historical purposes only. """ Going to the list, then. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30471] "as" keyword in comprehensions
New submission from Dávid Nemeskey:
Currently, the "as" keyword in supported in import and with statements to bind
an object to a name. I think it would be nice to have the same functionality in
list/dict/etc. comprehensions as well.
Rationale: as I understand, comprehensions are preferred over map/filter +
lambdas for creating modified versions of sequences (etc.) in Python. They are
indeed useful for replacing map, filter, or map(filter); however, filter(map)
is currently not supported. This is not an unusual use-case, as the two
examples below show. It is also evident that they are very wordy with lambdas,
and could be much clearer with comprehensions:
with open(file) as inf:
lines = list(filter(lambda l: l, map(lambda line: line.strip(), inf)))
items = dict(filter(lambda kv: kv[1] > 5,
map(lambda kv: kv[0], len(kv[1]), d.items(
Currently the only way to do this with comprehensions are:
with open(file) as inf:
lines = [l for l in (line.strip() for line in inf) if l]
items = {k: v for k, v in ((k, len(v)) for k, v in d.items()) if v > 5)}
, or
items = {k: len(v) for k, v in d.items() if len(v) > 5}
The first option is as unwieldy and unreadable as the code with lambdas, while
the second is ineffective as it calls len() twice (and of course here len() is
just a placeholder for a potentially heavy operation).
I propose to allow the "as" keyword in comprehensions as well to bind the
result of an operation in the output expression to a name that could be used in
the optional predicate. In other words, provide a let-like functionality. Like
so:
with open(file) as inf:
lines = [line.strip() as l for line in inf if l]
items = {(k, len(v) as lenv) for k, v in d.items() if lenv > 5}
--
messages: 294446
nosy: nemeskeyd
priority: normal
severity: normal
status: open
title: "as" keyword in comprehensions
type: enhancement
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30471>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
