[Python-ideas] Means of avoiding accidental import of/from an Implicit Namespace Package
More than once, I've had bugs that were hard to track down because I was accidentally using an implicit namespace without realizing it. The last time this happened, it was a typo, and my init file was named `_init__.py` instead of `__init__.py`. The init file imported from sub-modules, including 1 with a class that was supposed be be registered via an `__init_subclass__` callback that was not happening. I'm sure that implicit namespace packages are here to stay, and I imagine I will actually want to use them on purpose at some point, but it would be nice if we could come up with a straightforward way to avoid the accidental usages. One idea that comes to mind is to add a new built-in context manager within which the importing of a purely implicit namespace raises an exception. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/V7QU3IDGKITJ3J4FL7G6YAFKIXM44IC2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions
Serhiy Storchaka writes: > The advantage is that you cannot accidentally turn a function into a > generator by adding "yield". Can't mypy catch this? > Asynchronous functions are more reliable. "async" is mandatory, and if > you do not await the result of an asynchronous function call you will > get a loud warning. "yield" is mandatory in generators, and it should be possible to detect if a generator is called other than in an iteration context (and possibly we would want to special-case functions like 'dir', 'help', and 'type' for this purpose). As far as the signature goes, I would suppose -> GeneratorType (or GeneratorType[T] if you know the type of object to be yielded) would clue folks in, and mypy could warn if it were missing. Sure, you would like to have the guarantees of mandatory syntax, but (unless I'm missing something) we can do this now. Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RIUSDPCUVATHQD3HF6XYYSNZZ4FCR26R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions
01.06.22 16:59, Chris Angelico пише: On Wed, 1 Jun 2022 at 23:55, Serhiy Storchaka wrote: The advantage is that you cannot accidentally turn a function into a generator by adding "yield". If the result of the call is ignored (it is expected to be None), this bug can live a long time. It is a common issue: test containing yield always passes. Since 3.11 the unittest module emits a warning if a test method returns not None, but it will not solve all problems: the test can call helpers, and if they are generators, the call is virtually no-op. This error can also occur in non-test code. That might be nice, but without a massive backward compatibility break (or another keyword for non-generator functions), it can't happen. Is there any advantage to being able to declare that it must be a generator (as opposed to simply returning a generator object)? The advantage is not in the ability to declare that it must be a generator, but in the ability to declare that it must not be a generator (and this should be the default). Of course it is a massive backward compatibility break, and the transition should be very slow and careful. First introduce a new optional syntax for generator functions, after 4 or 5 years (when all maintained Python versions support the new syntax) start to emit a quiet warning for a generator function with old syntax, after few more years make it more loud, and finally, after yet more years, an error. In between, third-party linters can start complaining about old syntax, first these warnings will be disable by default. It all will take 8-10 years or more. Or we can just break the world in Python 4.0 (but this is not the plan). ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RXYPZKGRHFXOHG45XZS64YBTEXV4Z7YL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions
On 6/1/2022 9:59 AM, Chris Angelico wrote:
On Wed, 1 Jun 2022 at 23:55, Serhiy Storchaka wrote:
31.05.22 16:21, Chris Angelico пише:
On Tue, 31 May 2022 at 23:00, Aaron L via Python-ideas
wrote:
After getting used to writing async functions, I’ve been wanting use a similar
syntax to declare generator functions.
What's the advantage? You can just use normal function syntax to
define them, and it works correctly. Do you need the ability to
declare that it's a generator even without any yields in it?
The advantage is that you cannot accidentally turn a function into a
generator by adding "yield". If the result of the call is ignored (it is
expected to be None), this bug can live a long time. It is a common
issue: test containing yield always passes. Since 3.11 the unittest
module emits a warning if a test method returns not None, but it will
not solve all problems: the test can call helpers, and if they are
generators, the call is virtually no-op. This error can also occur in
non-test code.
That might be nice, but without a massive backward compatibility break
(or another keyword for non-generator functions), it can't happen. Is
there any advantage to being able to declare that it must be a
generator (as opposed to simply returning a generator object)?
Serhiy explains the issues above, and I've been bitten by it.
def fn():
# Do something with side effects, or maybe mutating parameters.
print("foo")
yield 3
fn() # Called for the side effects, but not iterated over. It does not
print "foo".
I agree that the compatibility issues are large and tricky.
Eric
Maybe I just don't work on the right sorts of codebases.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XBY4IPN6FDJCCBDZWIRQLTISEICD6PA2/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GUVQXC3IT45PUBPW3OFE7A2KRDJKV4MV/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions
On Wed, 1 Jun 2022 at 23:55, Serhiy Storchaka wrote: > > 31.05.22 16:21, Chris Angelico пише: > > On Tue, 31 May 2022 at 23:00, Aaron L via Python-ideas > > wrote: > >> After getting used to writing async functions, I’ve been wanting use a > >> similar syntax to declare generator functions. > > > > What's the advantage? You can just use normal function syntax to > > define them, and it works correctly. Do you need the ability to > > declare that it's a generator even without any yields in it? > > The advantage is that you cannot accidentally turn a function into a > generator by adding "yield". If the result of the call is ignored (it is > expected to be None), this bug can live a long time. It is a common > issue: test containing yield always passes. Since 3.11 the unittest > module emits a warning if a test method returns not None, but it will > not solve all problems: the test can call helpers, and if they are > generators, the call is virtually no-op. This error can also occur in > non-test code. That might be nice, but without a massive backward compatibility break (or another keyword for non-generator functions), it can't happen. Is there any advantage to being able to declare that it must be a generator (as opposed to simply returning a generator object)? Maybe I just don't work on the right sorts of codebases. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XBY4IPN6FDJCCBDZWIRQLTISEICD6PA2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Opt-in “iter def” and/or “gen def” syntax for generator functions
31.05.22 16:21, Chris Angelico пише: On Tue, 31 May 2022 at 23:00, Aaron L via Python-ideas wrote: After getting used to writing async functions, I’ve been wanting use a similar syntax to declare generator functions. What's the advantage? You can just use normal function syntax to define them, and it works correctly. Do you need the ability to declare that it's a generator even without any yields in it? The advantage is that you cannot accidentally turn a function into a generator by adding "yield". If the result of the call is ignored (it is expected to be None), this bug can live a long time. It is a common issue: test containing yield always passes. Since 3.11 the unittest module emits a warning if a test method returns not None, but it will not solve all problems: the test can call helpers, and if they are generators, the call is virtually no-op. This error can also occur in non-test code. Asynchronous functions are more reliable. "async" is mandatory, and if you do not await the result of an asynchronous function call you will get a loud warning. I think it is a time to apply the same approach to generator functions. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HMZN43AEMLOWXHCMITMMU5QHHJLPEPYY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Typescript-Like Notational Shortcuts
On the theme of the addition of pip operators to indicate union, I was wondering what people think of using the following shortcuts for type hints. * type[] be a short-hand for List[type] * [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3] * similar ideas for dictionaries and callables with (perhaps with javascript-like arrow notations?) I just think something like this would be easier to read. For example, a lot of functions that return tuples generally are immediately unpacked when it's used, so I think this is a more clear and concise way of stating that this is that it returns three elements: an element of type1, an element of type2 and an element of type3. In other words, the fact that it's a tuple does not matter much. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GLDHYVUQVKQ5MPBCAS4SUU36JWGJZNWF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python array multiplication for negative values should throw an error
fjwillemsen--- via Python-ideas writes: > Of course, such bugs do not occur solely due to the lack of a > raised errors on negative multiplication: in this case, a > combination of a faulty assumption on the programmers' part and > Python's lack of strict typing. I'll take that bait: did mypy miss this? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BGNQTUXUGCGERMVZUAYZJIQQKOULRHGH/ Code of Conduct: http://python.org/psf/codeofconduct/
