[Python-ideas] Re: Allow Annotated annotation in dataclass
Hey Paul, Thanks for the response. That makes sense since moving it doesn't add any new functionality. ___ 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/QWGNB7AQHGRSQZDJWCVZSWWNFUPLKQZ2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Allow Annotated annotation in dataclass
Haven't seen a reply to this yet, so I'll start the bidding at 2¢.
Generally, I like the idea of using Annotated in this fashion. I'm
currently using it for expressing validation rules and hints about how
parameters are handled in HTTP requests. Handy!
If = field(...) weren't already established, I'd say it should be as an
annotated value instead of an assignment. Since = field(...) pattern is
well established, I'm not so sure what the value would be of changing
this in dataclass now.
Paul
On Sat, 2021-04-03 at 20:57 +, brianmar...@gmail.com wrote:
> typing.Annotated could be used to build dataclasses. Using Annotated
> will allow libraries to add functionality to a dataclass without
> having to change dataclass creation or behavior. The example below
> shows how a dataclass could be implemented. It continues the example
> of struct2 shown in pep593. From a dataclass point of view, the
> Sample and AnnotatedSample would be equivalent.
>
> ```python
> @dataclass
> class Sample:
> a: int
> b: int
> c: int = field(default=5)
> d: int = 10
> e: int = field(default=10)
>
>
> @packed
> @dataclass
> class AnnotatedSample:
> a: Annotated[int, ctype("I")]
> b: int
> c: Annotated[int, field(default=5), ctype("I")]
> d: Annotated[int, ctype("h")] = 10
> e: Annotated[int, ctype("h")] = field(default=10)
>
> out_bytes = struct2.pack(AnnotatedSample())
> ```
> When parsing the Annotated parameters, the dataclass decorator will
> only look at the type parameter and ```field``` parameter if present.
> If not Annotated, it falls back to existing behavior.
>
> Let me know what you think.
> Thanks!
> ___
> 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/TI4ZHEJSP5NWPO4NHR2EKNZQYLZMGR2J/
> 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/7MDAK2NUFUCMVDYDV3NG3FI2QZFA6AA3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
> On Apr 5, 2021, at 4:43 AM, Shreyan Avigyan wrote: > > Yes you are right. But isn't informing people about a change the work of > PEP? I mean this is kind of a major change because we're trying to change the > error message and/or the type. If the type is not changed then no PEP is > required but if the type is changed then there comes a maybe. What should be > the perfect solution? There’s no need for a new exception type. What code would catch this new exception? Just update the text of the existing exception, and update the documentation if need be. There’s no need for a PEP. Many, many changes are made without PEPs. Just open an issue on bugs.python.org and create a PR. Eric ___ 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/VNI6QEUXWKOAZ6M75ZZIW7IFUXJ7QF5Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
On Mon, Apr 5, 2021 at 7:02 PM Shreyan Avigyan wrote: > > OkSo the text will be changed. > > I've already used the issue tracker to describe this change. I'm yet to > receive confirmation from there. I'll submit the PR as soon as I receive > confirmation. Thanks a lot everyone. > Sounds like a plan! :) Thanks for helping to improve Python. 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/QJE3OOWB55RCYCV5AMYOR3SEGTRTYOTO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
Got it. Thanks. On Mon, Apr 5, 2021 at 2:24 PM Eric V. Smith wrote: > > > On Apr 5, 2021, at 4:43 AM, Shreyan Avigyan > wrote: > > > > Yes you are right. But isn't informing people about a change the work > of PEP? I mean this is kind of a major change because we're trying to > change the error message and/or the type. If the type is not changed then > no PEP is required but if the type is changed then there comes a maybe. > What should be the perfect solution? > > There’s no need for a new exception type. What code would catch this new > exception? Just update the text of the existing exception, and update the > documentation if need be. > > There’s no need for a PEP. Many, many changes are made without PEPs. Just > open an issue on bugs.python.org and create a PR. > > Eric > ___ 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/PSPTM73FBEF6AK5QQGDRIO7BZVDJ27NS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
OkSo the text will be changed. I've already used the issue tracker to describe this change. I'm yet to receive confirmation from there. I'll submit the PR as soon as I receive confirmation. Thanks a lot everyone. With Regards ___ 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/KBLLX4FXYVX7CXLYRNAGVBSNWKUJVT3L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
On Mon, Apr 5, 2021 at 6:41 PM Shreyan Avigyan wrote: > > Yes you are right. But isn't informing people about a change the work of PEP? > I mean this is kind of a major change because we're trying to change the > error message and/or the type. If the type is not changed then no PEP is > required but if the type is changed then there comes a maybe. What should be > the perfect solution? > IMO there's no need to change the type of the exception; ModuleNotFoundError is fine here. Changing the text is a fairly simple thing, so it can be discussed with a simple tracker issue. Any program that attempts to import curses, and has a fallback if that fails, would continue to work correctly after this change. ChrisA (PEP editor) ___ 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/LNSFEL5WV7QA4VAWF3FLTPEWPVJMAUNU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
Yes you are right. But isn't informing people about a change the work of PEP? I mean this is kind of a major change because we're trying to change the error message and/or the type. If the type is not changed then no PEP is required but if the type is changed then there comes a maybe. What should be the perfect solution? ___ 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/J3UTLI56TUMMDVOPSO27PDGIZLKWZDA5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
On 04/04/2021 19:05, Shreyan Avigyan wrote:
When importing the curses module, be it on Windows or Darwin or UNIX-based OS
or any other platform, if the _curses module is not found then just a
ModuleNotFoundError is raised. But this error is not very informational in case
of _curses module. Since the curses module is packaged with the Python
interpreter itself at first it may seem, to beginners especially, that the
Python interpreter was not installed correctly and then they would go searching
for an answer for about 4-5 days.
We know that curses library is not installed on windows by default and may or
may not be present on other operating systems. Most UNIX system have ncurses or
other curses library installed by default.
Python errors have a reputation of being very informational. I would like to submit a PR
to modify the curses module a little bit by declaring a BaseException class and raising
that Exception with the message "_curses module not found. Make sure a curses
library is installed" or some kind of message like that.
But before I do that I would like to take advice from experienced developers
about somethings. Is this change in the exception, raised when _curses module
is not found, acceptable by the Python Community? If it is then should a draft
PEP be submitted or should a PR be directly submitted to
https://github.com/python/cpython?
I don't think this requires a new exception type. The point about
BaseException being a worse choice than ModuleNotFoundError has already
been made.
The stdlib curses module depends on _curses that may not be present,
which is a flaw in my view, and obviously it has taken some research to
find the reason. Your complaint is either against the documentation of
the curses module
(https://docs.python.org/3/library/curses.html#module-curses), for not
telling you sooner, or against the text of the curses module itself.
The how-to (https://docs.python.org/3/howto/curses.html#curses-howto)
does mention the problem and provides pointers to fix it, but
incorrectly states that it is the curses module itself that will not be
found, not the inner _curses. So that may sow additional confusion. I
expect the reasons for this inaccuracy are in the change history.
In curses, the author could have wrapped the specific import in
try-except to raise a more informative ModuleNotFoundError:
try:
from _curses import *
except ModuleNotFoundError:
raise ModuleNotFoundError("_curses! If only this were not a pesky Windows
machine!")
Or something better you choose.
Either the documentation fixes or the code change would make a sensible
PR, I think. Or why not addess all three? (It's surely not a PEP.)
Jeff Allen
___
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/VST2TULO3ACN47LTQKRNSE2PJE4ECYRB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Change the exception type and message raised when _curses is not found
OkA CursesNotFoundError derived from ModuleNotFoundError is okNow should a draft PEP be submitted or should a PR be directly submitted to https://github.com/python/cpython? ___ 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/WFAAHYKNZCRMCZZNV2WFLKK6IGZR/ Code of Conduct: http://python.org/psf/codeofconduct/
