[Python-ideas] Re: Create a @deprecated decorator (annotation)
Hi Sergei, I really thought your proposal was very good, in fact, it's quite complete with examples in libraries that I didn't even know implement a depreciation API. Thanks for the contribution. ___ 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/TGQVDHA4QWFSQYSJUUBERSTH4FJ76QDH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
On Fri, Jul 30, 2021 at 7:11 AM Leonardo Freua wrote: > > >>> First line of the body vs line before the declaration doesn't feel > >>> like it makes much difference to me. > > Usually, decorators or annotations are placed near the method signature, that > is, at the beginning where any reading begins, because it's easier to see > that method is deprecated or anything else that needs a decorator. > > Putting this information inside the method body, you end up putting > information that is not the method's responsibility to provide, this ends up > mixing with what the method actually does, it's more information to read in a > debug or in maintenance that the method will need to receive. Not to mention > the fact that sometimes depreciation messages can be longer than 2 lines. > > Most programming languages have some way of expressing depreciation, and it's > usually close to the method signature. > One advantage of language support for deprecation can be an "entry point only" warning - if a regular function calls a deprecated function, there's a warning, but if a deprecated function calls another deprecated function, there won't be. Whether this is worth implementing here is a separate question, but it would certainly be easier to do with a decorator than an explicit warn() call. 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/FRQXPFRFV72QXVEJ6PITFZ3LI74IP7DU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
Specially I'd like to be able to deprecate the `Callable[..., Iterable[T]]` type of contextlib.contextmanager See https://github.com/python/typeshed/pull/2773#issuecomment-458872741 On Thu, 29 Jul 2021, 22:00 Thomas Grainger, wrote: > I'd like to be able to specificy @deprecate on only some @overloads > > On Thu, 29 Jul 2021, 21:59 Paul Bryan, wrote: > >> I'm +1 on deprecation decorator, with some way to represent it so that it >> can be determined at runtime (e.g. dunder). >> >> >> On Thu, 2021-07-29 at 20:52 +, Leonardo Freua wrote: >> >> This is a good example of how using a decorator to express depreciation >> is much better and less polluting the method, as the depreciation message >> doesn't need to be in the method body. >> >> In my view, it would be interesting for Python to natively have the >> ability to annotate deprecated methods. >> ___ >> 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/BVYHXKUUCXD3D2JSSBEIEF2WR2PV2TLI/ >> 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/OSR6OAEHQRXT6FLQE25UHOIM37RFULFH/ >> 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/MCE3MXC27VZ2Y7VDVBXV4CCJ56FIHITC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
>>> First line of the body vs line before the declaration doesn't feel >>> like it makes much difference to me. Usually, decorators or annotations are placed near the method signature, that is, at the beginning where any reading begins, because it's easier to see that method is deprecated or anything else that needs a decorator. Putting this information inside the method body, you end up putting information that is not the method's responsibility to provide, this ends up mixing with what the method actually does, it's more information to read in a debug or in maintenance that the method will need to receive. Not to mention the fact that sometimes depreciation messages can be longer than 2 lines. Most programming languages have some way of expressing depreciation, and it's usually close to the method signature. I'm not proposing to do away with the way it is done today, but rather to expand the possibilities. There are times when the existence of just one decorator would make the code cleaner than inserting more information into the body of the method/function. Ps.: Relax Paul, you don't need to be afraid, this is just a proposal. Thanks for the contribution, good points raised. ___ 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/R4OS67MVBS6FYBGFTSEDFFC5NGCXLAQ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
I'd like to be able to specificy @deprecate on only some @overloads On Thu, 29 Jul 2021, 21:59 Paul Bryan, wrote: > I'm +1 on deprecation decorator, with some way to represent it so that it > can be determined at runtime (e.g. dunder). > > > On Thu, 2021-07-29 at 20:52 +, Leonardo Freua wrote: > > This is a good example of how using a decorator to express depreciation is > much better and less polluting the method, as the depreciation message > doesn't need to be in the method body. > > In my view, it would be interesting for Python to natively have the > ability to annotate deprecated methods. > ___ > 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/BVYHXKUUCXD3D2JSSBEIEF2WR2PV2TLI/ > 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/OSR6OAEHQRXT6FLQE25UHOIM37RFULFH/ > 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/SMPPDRDLJJMXWUSYS7NVFZ5VPFYKWNCC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
I'm +1 on deprecation decorator, with some way to represent it so that it can be determined at runtime (e.g. dunder). On Thu, 2021-07-29 at 20:52 +, Leonardo Freua wrote: > This is a good example of how using a decorator to express > depreciation is much better and less polluting the method, as the > depreciation message doesn't need to be in the method body. > > In my view, it would be interesting for Python to natively have the > ability to annotate deprecated methods. > ___ > 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/BVYHXKUUCXD3D2JSSBEIEF2WR2PV2TLI/ > 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/OSR6OAEHQRXT6FLQE25UHOIM37RFULFH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
This is a good example of how using a decorator to express depreciation is much better and less polluting the method, as the depreciation message doesn't need to be in the method body. In my view, it would be interesting for Python to natively have the ability to annotate deprecated methods. ___ 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/BVYHXKUUCXD3D2JSSBEIEF2WR2PV2TLI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
Perhaps another approach would be to make a more general purpose warning
decorator, that would give a warning when invoking a function or
instantiating a class. It could be used for deprecation notices, of course,
but has the potential for tooling to give other types of warnings, such as
using a thread unsafe call in a threading context.
On Thu, Jul 29, 2021 at 14:26 Sergei Lebedev
wrote:
> > Why would it be "interesting"? I don't see any practical advantage, and
> as soon as you need any form of logic you have to rewrite, so why bother?
>
> The advantage of having a declarative API for deprecations is tooling
> support. It is much easier to detect decorator application than to reliably
> infer whether a function/class emits (or raises) a DeprecationWarning.
>
> I started a similar thread [*] a few weeks ago, but have had no chance to
> reply properly since.
>
> Sergei
>
> [*]:
> https://mail.python.org/archives/list/python-ideas@python.org/thread/EABCXCALZFRDH7CKMUL4YHFBQFOBUWN7/
>
> On Thu, Jul 29, 2021 at 3:59 PM Paul Moore wrote:
>
>> On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
>> wrote:
>> >
>> > Would it be interesting to create a @deprecated decorator to avoid
>> adding warnings.warn("deprecation message", DeprecationWarning,
>> stacklevel=2) in methods body?
>>
>> I don't see the value personally.
>>
>> > Using the decorator approach to indicate depreciation would make the
>> methods cleaner (leaving only their responsibilities in the body) and would
>> be easier to identify, as the cue would be close to the method signature
>> and not mixed with the logic inside the body.
>>
>> First line of the body vs line before the declaration doesn't feel
>> like it makes much difference to me.
>>
>> > in some cases it will still be necessary to put warnings.warn (..)
>> inside the body of functions/methods because of some message display
>> condition, or we could also express the message display condition in the
>> decorator in @deprecated itself. But it would be interesting to have the
>> possibility of not putting this inside the method body. Even the decorator
>> can come from the notices module.
>>
>> Why would it be "interesting"? I don't see any practical advantage,
>> and as soon as you need any form of logic you have to rewrite, so why
>> bother?
>>
>> If you want this to get support, I think you need to argue the
>> benefits far more than you have so far...
>>
>> > Example:
>> >
>> > (Before)
>> >
>> > def check_metadata(self):
>> > """Deprecated API."""
>> > warn("distutils.command.register.check_metadata is deprecated, \
>> > use the check command instead", PendingDeprecationWarning)
>> > check = self.distribution.get_command_obj('check')
>> > check.ensure_finalized()
>> > check.strict = self.strict
>> > check.restructuredtext = 1
>> > check.run()
>> >
>> > (after)
>> >
>> > @deprecated("distutils.command.register.check_metadata is deprecated, \
>> > use the check command instead")
>> > def check_metadata(self):
>> > """Deprecated API."""
>> > check = self.distribution.get_command_obj('check')
>> > check.ensure_finalized()
>> > check.strict = self.strict
>> > check.restructuredtext = 1
>> > check.run()
>>
>> TBH, the decorator version makes it harder to see the function signature.
>>
>> -1 from me, I'm afraid.
>>
>> Disclaimer: I've never actually deprecated an API in my own code, so
>> my objections are mainly theoretical.
>>
>> Paul
>> ___
>> 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/6O7WJ3MLF3WEQ6XR7HEZPM6OBUZVY4PU/
>> 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/YAI2Y5S6AWYNGKUDALYSC5TK2374K7A3/
> 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/VNEM3JETYYX4R4RLBPD4X3GXMW7Q32F5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
> Why would it be "interesting"? I don't see any practical advantage, and
as soon as you need any form of logic you have to rewrite, so why bother?
The advantage of having a declarative API for deprecations is tooling
support. It is much easier to detect decorator application than to reliably
infer whether a function/class emits (or raises) a DeprecationWarning.
I started a similar thread [*] a few weeks ago, but have had no chance to
reply properly since.
Sergei
[*]:
https://mail.python.org/archives/list/python-ideas@python.org/thread/EABCXCALZFRDH7CKMUL4YHFBQFOBUWN7/
On Thu, Jul 29, 2021 at 3:59 PM Paul Moore wrote:
> On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
> wrote:
> >
> > Would it be interesting to create a @deprecated decorator to avoid
> adding warnings.warn("deprecation message", DeprecationWarning,
> stacklevel=2) in methods body?
>
> I don't see the value personally.
>
> > Using the decorator approach to indicate depreciation would make the
> methods cleaner (leaving only their responsibilities in the body) and would
> be easier to identify, as the cue would be close to the method signature
> and not mixed with the logic inside the body.
>
> First line of the body vs line before the declaration doesn't feel
> like it makes much difference to me.
>
> > in some cases it will still be necessary to put warnings.warn (..)
> inside the body of functions/methods because of some message display
> condition, or we could also express the message display condition in the
> decorator in @deprecated itself. But it would be interesting to have the
> possibility of not putting this inside the method body. Even the decorator
> can come from the notices module.
>
> Why would it be "interesting"? I don't see any practical advantage,
> and as soon as you need any form of logic you have to rewrite, so why
> bother?
>
> If you want this to get support, I think you need to argue the
> benefits far more than you have so far...
>
> > Example:
> >
> > (Before)
> >
> > def check_metadata(self):
> > """Deprecated API."""
> > warn("distutils.command.register.check_metadata is deprecated, \
> > use the check command instead", PendingDeprecationWarning)
> > check = self.distribution.get_command_obj('check')
> > check.ensure_finalized()
> > check.strict = self.strict
> > check.restructuredtext = 1
> > check.run()
> >
> > (after)
> >
> > @deprecated("distutils.command.register.check_metadata is deprecated, \
> > use the check command instead")
> > def check_metadata(self):
> > """Deprecated API."""
> > check = self.distribution.get_command_obj('check')
> > check.ensure_finalized()
> > check.strict = self.strict
> > check.restructuredtext = 1
> > check.run()
>
> TBH, the decorator version makes it harder to see the function signature.
>
> -1 from me, I'm afraid.
>
> Disclaimer: I've never actually deprecated an API in my own code, so
> my objections are mainly theoretical.
>
> Paul
> ___
> 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/6O7WJ3MLF3WEQ6XR7HEZPM6OBUZVY4PU/
> 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/YAI2Y5S6AWYNGKUDALYSC5TK2374K7A3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
MyPy has plans to support heterogenous tuple representation, it turns out. It is tracked here: https://github.com/python/mypy/issues/5152 - albeit not very actively. ___ 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/B7EKOADT427BZ5A4KP4NRVVNHSKPR5PL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
On Thu, 29 Jul 2021 at 15:39, Leonardo Freua
wrote:
>
> Would it be interesting to create a @deprecated decorator to avoid adding
> warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in
> methods body?
I don't see the value personally.
> Using the decorator approach to indicate depreciation would make the methods
> cleaner (leaving only their responsibilities in the body) and would be easier
> to identify, as the cue would be close to the method signature and not mixed
> with the logic inside the body.
First line of the body vs line before the declaration doesn't feel
like it makes much difference to me.
> in some cases it will still be necessary to put warnings.warn (..) inside the
> body of functions/methods because of some message display condition, or we
> could also express the message display condition in the decorator in
> @deprecated itself. But it would be interesting to have the possibility of
> not putting this inside the method body. Even the decorator can come from the
> notices module.
Why would it be "interesting"? I don't see any practical advantage,
and as soon as you need any form of logic you have to rewrite, so why
bother?
If you want this to get support, I think you need to argue the
benefits far more than you have so far...
> Example:
>
> (Before)
>
> def check_metadata(self):
> """Deprecated API."""
> warn("distutils.command.register.check_metadata is deprecated, \
> use the check command instead", PendingDeprecationWarning)
> check = self.distribution.get_command_obj('check')
> check.ensure_finalized()
> check.strict = self.strict
> check.restructuredtext = 1
> check.run()
>
> (after)
>
> @deprecated("distutils.command.register.check_metadata is deprecated, \
> use the check command instead")
> def check_metadata(self):
> """Deprecated API."""
> check = self.distribution.get_command_obj('check')
> check.ensure_finalized()
> check.strict = self.strict
> check.restructuredtext = 1
> check.run()
TBH, the decorator version makes it harder to see the function signature.
-1 from me, I'm afraid.
Disclaimer: I've never actually deprecated an API in my own code, so
my objections are mainly theoretical.
Paul
___
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/6O7WJ3MLF3WEQ6XR7HEZPM6OBUZVY4PU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Create a @deprecated decorator (annotation)
Hi,
I've been using https://pypi.org/project/Deprecated/ for quite some time
and I recommend it.
S.
On Thu, Jul 29, 2021 at 4:39 PM Leonardo Freua <
leonardo.batista.fr...@gmail.com> wrote:
> [Migrating from https://bugs.python.org/issue44701]
>
> Would it be interesting to create a @deprecated decorator to avoid adding
> warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in
> methods body?
>
> Using the decorator approach to indicate depreciation would make the
> methods cleaner (leaving only their responsibilities in the body) and would
> be easier to identify, as the cue would be close to the method signature
> and not mixed with the logic inside the body.
>
> in some cases it will still be necessary to put warnings.warn (..) inside
> the body of functions/methods because of some message display condition, or
> we could also express the message display condition in the decorator in
> @deprecated itself. But it would be interesting to have the possibility of
> not putting this inside the method body. Even the decorator can come from
> the notices module.
>
> Example:
>
> (Before)
>
> def check_metadata(self):
> """Deprecated API."""
> warn("distutils.command.register.check_metadata is deprecated, \
> use the check command instead", PendingDeprecationWarning)
> check = self.distribution.get_command_obj('check')
> check.ensure_finalized()
> check.strict = self.strict
> check.restructuredtext = 1
> check.run()
>
> (after)
>
> @deprecated("distutils.command.register.check_metadata is deprecated, \
> use the check command instead")
> def check_metadata(self):
> """Deprecated API."""
> check = self.distribution.get_command_obj('check')
> check.ensure_finalized()
> check.strict = self.strict
> check.restructuredtext = 1
> check.run()
> ___
> 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/62CTVNQ2GIS4B6WUBX23K4CCCK5MCGYL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ &
http://pydata.fr/
___
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/7CA3W455L7WDEIDHRMETHGH3HMOHMKUZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Create a @deprecated decorator (annotation)
[Migrating from https://bugs.python.org/issue44701]
Would it be interesting to create a @deprecated decorator to avoid adding
warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in
methods body?
Using the decorator approach to indicate depreciation would make the methods
cleaner (leaving only their responsibilities in the body) and would be easier
to identify, as the cue would be close to the method signature and not mixed
with the logic inside the body.
in some cases it will still be necessary to put warnings.warn (..) inside the
body of functions/methods because of some message display condition, or we
could also express the message display condition in the decorator in
@deprecated itself. But it would be interesting to have the possibility of not
putting this inside the method body. Even the decorator can come from the
notices module.
Example:
(Before)
def check_metadata(self):
"""Deprecated API."""
warn("distutils.command.register.check_metadata is deprecated, \
use the check command instead", PendingDeprecationWarning)
check = self.distribution.get_command_obj('check')
check.ensure_finalized()
check.strict = self.strict
check.restructuredtext = 1
check.run()
(after)
@deprecated("distutils.command.register.check_metadata is deprecated, \
use the check command instead")
def check_metadata(self):
"""Deprecated API."""
check = self.distribution.get_command_obj('check')
check.ensure_finalized()
check.strict = self.strict
check.restructuredtext = 1
check.run()
___
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/62CTVNQ2GIS4B6WUBX23K4CCCK5MCGYL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
On Thu, Jul 29, 2021 at 9:19 PM Joren Hammudoglu wrote: > > What about creating a dataclasses.datatuple decorator, that replaces > typing.NamedTuple, and offers the same (or restricted) interface as regular > dataclasses? This would make the distinction explicit between a mutable, > object-like dataclass, and the immutable, tuple-like named-/datatuple. With > this, we could also get rid of the fake-immutable frozen dataclasses. > In the same way, a dataclasses.datadict could replace typing.TypedDict, which > is very limited at this point anyway. > > So instead of trying to merge different concepts, let's use one create one > interface to rule them all. Because, after all: > "There should be one-- and preferably only one --obvious way to do it." > https://xkcd.com/927/ 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/NE463OYDFDPAGCX76X5WYBSYBIYQNESL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
What about creating a dataclasses.datatuple decorator, that replaces typing.NamedTuple, and offers the same (or restricted) interface as regular dataclasses? This would make the distinction explicit between a mutable, object-like dataclass, and the immutable, tuple-like named-/datatuple. With this, we could also get rid of the fake-immutable frozen dataclasses. In the same way, a dataclasses.datadict could replace typing.TypedDict, which is very limited at this point anyway. So instead of trying to merge different concepts, let's use one create one interface to rule them all. Because, after all: "There should be one-- and preferably only one --obvious way to do it." ___ 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/VJ7WPV6564BJQDNGQZXC5HPCT22SKNM4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
On Wed, Jul 28, 2021 at 11:58:37PM -, pa...@lexyr.com wrote: > To your dict argument: if there was a native Pythonic way to make a > frozen list, what would a tuple's purpose be then, if not just another > name for that? We do have a Pythonic way to make a frozen list. It is spelled "tuple". I know that people often say that lists are intended for homogeneous data like [1, 2, 3] and tuples are intended for heterogeneous data like (1, 2.0, "three") but that's not mandatory. -- 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/F3DWNIFUEUDSHD27UZN22YVDI37DHRFJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
On Thu, Jul 29, 2021 at 01:10:39AM -, pa...@lexyr.com wrote: > then much of > the problem (i.e., people that want to have a simple data object use > two incompatible things depending on which parts of the the Python doc > they read first) simply fades away. Why is that a problem? I can write notes with a pen or a pencil. Sometimes I *need* a pen, or I *need* a pencil. But most of the time I will choose whichever happens to come to mind at the time. No big deal. As far as I am concerned, the only problem here is that you are taking the "There should be one..." koan too seriously, and misinterpreting what it means. It does *not* mean "there shouldn't be more than one way to do two slightly different things". Dataclasses are not a special kind of object, they are a framework for automating a number of common methods used in class definitions. Dataclasses are just classes with a fancy meta-API to automate common methods. As such, you are right: with sufficient cleverness, we could probably develop a dataclass API to generate named tuples. But we already have an API to generate named tuples. In the history of Python, named tuples came first. But even if dataclasses had come first, we would still want named tuples. We would need an API to create them. Why do you care whether that API is spelled "@dataclass(...)" or "collections.namedtuple(...)"? -- 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/3YT7YWE4VYGZJTBPXU44X2YARJ2X46F5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
Good point. -- Eric > On Jul 29, 2021, at 3:18 AM, Thomas Grainger wrote: > > > But heterogeneous iteration would require typing changes > >> On Thu, 29 Jul 2021, 02:18 Eric V. Smith, wrote: >> In dataclasses, support for __slots__ is being added in 3.10. Adding >> optional support for iteration would be easy. >> >> -- >> Eric V. Smith >> On Jul 28, 2021, at 7:29 PM, Paul Bryan wrote: >>> >>> I'm with you; since dataclasses were introduced, namedtuple has not see any >>> use from me, though none of my uses have demanded ultra-high efficiency >>> either. >>> >>> I wonder how many users are currently relying on namedtuple __getitem__ >>> semantics though. that's functionality dataclasses do not (currently) have. >>> >>> Random thought I don't know the answer to: Any reason __slots__ can't be >>> used on a dataclass to improve efficiency? >>> >>> On Wed, 2021-07-28 at 22:22 +, pa...@lexyr.com wrote: [Migrating the discussion from https://bugs.python.org/issue44768.] PEP 20 says: > There should be one-- and preferably only one --obvious way to do it. There are two ways to create a simple named type to store data: collections.namedtuple and dataclasses.dataclass. I propose deprecating namedtuple. As far as the interface is concerned, the namedtuple is almost completely equivalent to a frozen dataclass - with some iterability syntactic sugar thrown in. I don't think there are use cases for namedtuple that would not be trivial to rewrite with dataclasses. As far as the implementation is concerned, the namedtuple is faster. If efficiency is a concern, why do we make our users decide? We can choose the most efficient one on the library's end. C++ does something similar with bool vectors - the library has a special case for where it would be more optimal to use a different data structure underneath. TL;DR: If dataclass is so good, why keep namedtuple around? ___ 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/UQRCDWMFNC5NRLLQCTYPOEGWJOIV7BGJ/ 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/4NOUPTLNNJJMM3XSN3WEK32NWRJDAVRD/ >>> 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/ESOIUHFM26SPCLP4VZCY7WETXJWFVBOC/ >> 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/XBIITMWUP5FZBXW3JJY2AYMYPNTO2MFH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
But heterogeneous iteration would require typing changes On Thu, 29 Jul 2021, 02:18 Eric V. Smith, wrote: > In dataclasses, support for __slots__ is being added in 3.10. Adding > optional support for iteration would be easy. > > -- > Eric V. Smith > > On Jul 28, 2021, at 7:29 PM, Paul Bryan wrote: > > > I'm with you; since dataclasses were introduced, namedtuple has not see > any use from me, though none of my uses have demanded ultra-high efficiency > either. > > I wonder how many users are currently relying on namedtuple __getitem__ > semantics though. that's functionality dataclasses do not (currently) have. > > Random thought I don't know the answer to: Any reason __slots__ can't be > used on a dataclass to improve efficiency? > > > On Wed, 2021-07-28 at 22:22 +, pa...@lexyr.com wrote: > > [Migrating the discussion from https://bugs.python.org/issue44768.] > > PEP 20 says: > > There should be one-- and preferably only one --obvious way to do it. > > > There are two ways to create a simple named type to store data: > collections.namedtuple and dataclasses.dataclass. I propose deprecating > namedtuple. > > As far as the interface is concerned, the namedtuple is almost completely > equivalent to a frozen dataclass - with some iterability syntactic sugar > thrown in. I don't think there are use cases for namedtuple that would not > be trivial to rewrite with dataclasses. > > As far as the implementation is concerned, the namedtuple is faster. If > efficiency is a concern, why do we make our users decide? We can choose the > most efficient one on the library's end. C++ does something similar with > bool vectors - the library has a special case for where it would be more > optimal to use a different data structure underneath. > > > TL;DR: If dataclass is so good, why keep namedtuple around? > ___ > 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/UQRCDWMFNC5NRLLQCTYPOEGWJOIV7BGJ/ > 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/4NOUPTLNNJJMM3XSN3WEK32NWRJDAVRD/ > 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/ESOIUHFM26SPCLP4VZCY7WETXJWFVBOC/ > 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/XXG2WNIZRDHXCLJHDAAHME5CKJV7ZMVF/ Code of Conduct: http://python.org/psf/codeofconduct/
