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, 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
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
I like this idea! It's true that deprecating the namedtuple we lose important
semantics of order - however, if its use as a weaker dataclass is explicitly
discouraged in the documentation, then much of the problem (i.e., people that
want to have a simple data object use two incompatible things
I frequently use each of namedtuples and data classes in contexts where the
other one would not be appropriate. Yes, I also sometimes use an object
where either would serve... In those cases, mostly SimpleNamespace would
likewise be fine. So would a one line class definition.
On Wed, Jul 28,
On Thu, Jul 29, 2021 at 10:00 AM wrote:
>
> I'm with you on the backwards-compatibility front. Changing Python fast and
> for no particular reason incurs a big cost. Is the reason good enough to
> justify removing a chunk of the interface? Good question.
>
Answer: Almost never. Case in point:
>From https://death.andgravity.com/namedtuples linked to above by Titus:
> pairs of things, like HTTP headers (a dict is not always appropriate,
since
> the same header can appear more than once, and the order does matter in
some cases)
To me, this is a perfect case of behavior that namedtuples
I'm with you on the backwards-compatibility front. Changing Python fast and for
no particular reason incurs a big cost. Is the reason good enough to justify
removing a chunk of the interface? Good question.
To your dict argument: if there was a native Pythonic way to make a frozen
list, what
It's not actually that, although that's a good point you are making. I found
myself using both of them not because one is more useful in certain cases and
the other in others in small and niche ways. Both of the times I just used the
latest one that came to mind. The fact that two different
I've thing I still use NamedTuple for is when I want type safe
heterogeneous iterable unpacking, which is only possible for tuples (and
NamedTuple) eg I'd like to be able to express both:
tx, rx = trio.MemoryChanel[int]()
And:
with trio.MemoryChannel[int]() as channel:
n.start_soon(worker,
On Thu, Jul 29, 2021 at 9:37 AM wrote:
>
> I was writing some code the other day, and it needed a quick-and-dirty data
> structure definition for a set of related variables. I looked back at other
> code to try be consistent, and found that I used dataclasses in some parts
> and namedtuples in
I was writing some code the other day, and it needed a quick-and-dirty data
structure definition for a set of related variables. I looked back at other
code to try be consistent, and found that I used dataclasses in some parts and
namedtuples in others. Both seemed the right thing to do at the
On Thu, Jul 29, 2021 at 9:28 AM 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__
>
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)
Hi, I ran across this nice article a few days ago -
https://death.andgravity.com/namedtuples
which provides some answers as to why you might consider using named tuples.
best,
—titus
> On Jul 28, 2021, at 3:22 PM, pa...@lexyr.com wrote:
>
> [Migrating the discussion from
On Thu, Jul 29, 2021 at 9:07 AM 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
21 matches
Mail list logo
