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 --
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
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
>>> 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
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
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,
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.
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
> 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
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
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
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
[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
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,
>
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
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
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
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
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
19 matches
Mail list logo
