[issue24416] Have date.isocalendar() return a structseq instance

[Baptiste Mispelon]

Baptiste Mispelon  added the comment:

(Apologies if this isn't the right place and/or time for this kind of negative 
feedback. I'm open to suggestions for a more appropriate venue)

I found it disheartening that my work on this ticket has been erased.

While I understand that other contributors have worked a lot more on this than 
I have, I did put in a non-negligible amount of work into this ticket.
>From creating the original issue to taking a first stab at writing a patch 
>(including several rounds of back and forth with core developers).

It would have been nice to have been credited in the commit message for example.

As-is, it gives me the impression that the only things this project values are 
pure code contributions.

I couldn't find documentation about how this projects credits contributors.
If it's standard practice not to credit non-code contributions or non-merged 
code contributions then I humbly suggest you reconsider this practice.
>From my perspective it really discourages me from making further contributions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Petr Viktorin]

Petr Viktorin  added the comment:

This broke compilation with mingw; see https://bugs.python.org/issue40777

--
nosy: +petr.viktorin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

This is now merged, thanks for the debate and opinions offered everyone, and 
thanks to Dong-hee for the implementation!

The way we did the implementation, a pickle/unpickle cycle on the result of 
.isocalendar() will return a plain tuple. Despite the fact that I suggested it, 
I recognize that this is a /weird thing to do/, and I'm sorta banking on the 
fact that in all likelihood no one is relying on pickling and unpickling the 
result of .isocalendar() returning anything but a tuple (since, currently, 
that's already what it does, regardless of what the input type was).

I suppose we'll have to see if it causes problems in the beta period, and I'll 
keep a close eye on it.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:


New changeset 1b97b9b0ad9a2ff8eb5c8f2e2e7c2aec1d13a330 by Paul Ganssle in 
branch 'master':
bpo-24416: Return named tuple from date.isocalendar() (GH-20113)
https://github.com/python/cpython/commit/1b97b9b0ad9a2ff8eb5c8f2e2e7c2aec1d13a330


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Change by Paul Ganssle :


--
pull_requests: +19420
pull_request: https://github.com/python/cpython/pull/20113

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Dong-hee Na]

Change by Dong-hee Na :


--
pull_requests: +17118
pull_request: https://github.com/python/cpython/pull/17651

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

The current state of the PR doesn't hinge on the pure Python implementation, we 
went with a very simple tuple subclass to keep the two more closely in sync and 
because we don't need any of the additional functionality that namedtuple 
brings, but if it were any more complicated than what we did we probably would 
have just gone with a namedtuple.

The only thing that's holding things up now is that we're working out a way to 
maintain the ability to pickle the object without making the class public. This 
is not really a hard requirement, but I'd like to give it an honest effort 
before calling it a day and just relying on "it's not in __all__, therefore 
it's not public." (I should note that we can only take that approach after 
issue #38155 is resolved, which is another reason for the delay).

In any case, the bulk of the conversation on the implementation has been taking 
place on GH-15633, sorry for the split discussion location, folks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Tim Peters]

Tim Peters  added the comment:

I agree with Raymond here:  using collections.namedtuple is fine in the pure 
Python version.  Since Raymond checked in doc changes to purge the phrase 
"struct sequences" (thanks again for that!), it's consistent with everything 
else now for the new datetime docs to say that this function returns a "named 
tuple" (the docs are now clear that there may be more than one implementation 
of such a thing, and that the only things you can _rely_ on are that they 
support named element access in addition to tuple methods).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

It's okay for the pure python equivalent to use collections.namedtuple so long 
as the C code uses structseq. As Serhiy points out, there is no need to 
reinvent the wheel.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

namedtuple is much faster now that four years ago. New namedtuple type 
creation, instantiating a namedtuple object, access to its members -- all this 
is times faster. It is still slower than tuple in some aspects, because tuples 
are everywere and the interpreter has special optimizations for tuples. But 
date.isocalendar() is not used in such performance critical code.

The size of pickles will grow, the time of pickling and unpickling will 
increase, and old Python versions will not be able to unpickle a new type by 
default. But I do not think that instances of this type will be pickled in 
large numbers so it will has a global effect, and the problem with 
compatibility can be solved with some hacks. If anybody pickles them at all.

It was not clear whether adding a new type will give any benefit in real code. 
Thanks to Paul for his investigations.

The only thing that makes this case unique is that we have two implementations 
of the datetime module. Therefore we will need either add two implementation of 
a new named tuple type (which are different in details) or import the Python 
implementation into the C code. This increases the cost of the implementation 
and maintaining.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee: rhettinger -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

[Paul Ganssle]
> "grab a single component" use is overwhelmingly the common case,
> I think it's worth it in the end.

Dong-hee Na, you can now go ahead with the patch.  

The relevant function is date_isocalendar() located in Modules/_datetime.c.  
Model the structseq code after the PyFloat_GetInfo() function in 
Objects/floatobject.h.

When you have a PR with a doc update and tests, please request my review and I 
help you wrap it up.

Ask questions here if you get stuck.  Good luck!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

I have compiled both versions with optimizations on, looks like the gap gets a 
bit smaller (percentage-wise) after that:

   benchmark|  master (ns)  |  PR 15633 (ns)  |  Δ (%)
+---+-+--
call only (datetime)| 73 (±3)   | 92.3 (±7)   |   26
constructor + call (datetime)   |228 (±9)   | 260 (±16)   |   14
timedelta + call (datetime) |108 (±5)   | 128 (±9)|   18

If this were something fundamental like a performance regression in building a 
tuple or constructing a dictionary or something I'd be concerned, but this just 
reinforces my feeling that, on balance, this is worth it, and that we are 
probably not going to need a "fast path" version of this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

I haven't had time to try this with an optimized build, I have done a few more 
benchmarks using a standard build, I'm seeing almost a 50% regression on 
isocalendar() calls, but the picture is a little rosier if you consider the 
fact that you need to construct a `date` or `datetime` object in the first 
place and anyone concerned with performance will likely be making exactly one 
`isocalendar()` call per datetime object. The common case is that they 
construct the datetime with a datetime literal or something equivalent. The 
"worst case scenario" is that they construct a single "seed" datetime and then 
construct many new datetimes with faster operations like adding a timedelta.

I have compared the following cases:

call only: -s 'import datetime; dt = datetime.datetime(2019, 1, 1)' 
'dt.isocalendar()'
constructor + call: -s 'import datetime' 'dt = datetime.datetime(2019, 1, 1); 
dt.isocalendar()'
timedelta + call: -s 'import datetime; dt = datetime.datetime(2019, 1, 1); td = 
timedelta(days=1)' '(dt + td).isocalendar()'


The results are summarized below, the most likely real practical impact on 
performance-sensitive "hot loops" would be a 29% performance regression *if* 
isocalendar() is the bottleneck:


   benchmark|  master (ns)  |  PR 15633 (ns)  |  Δ (%)
+---+-+--
call only (datetime)|349 (±14)  | 511 (±22)   |   46
constructor + call (datetime)   |989 (±48)  |1130 (±50)   |   14
timedelta + call (datetime) |550 (±14)  | 711 (±22)   |   29


The numbers for `datetime.date` are basically similar:

   benchmark|  master (ns)  |  PR 15633 (ns)  |  Δ (%)
+---+-+--
call only (date)|360 (±18)  | 530 (±41)   |   47
constructor + call (date)   |824 (±17)  | 975 (±29)   |   18
timedelta + call (datetime) |534 (±20)  | 685 (±24)   |   28


This is a bit disheartening, but I think the fact that these performance 
sensitive situations are rare and the "grab a single component" use is 
overwhelmingly the common case, I think it's worth it in the end.

If there are significant complaints about the performance regression, we may be 
able to create a variant method similar to the way that `chain` has 
`chain.from_iterables`, something like `dt.isocalendar.as_tuple()` for the 
performance-sensitive folks. That said, that's very YAGNI, we should not do 
that unless someone comes forward with a real use case that will be adversely 
affected here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Tim Peters]

Change by Tim Peters :


--
assignee:  -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

[Tim Peters]
> I favor making this a structseq

If there are no further objections to upgrading isocalendar() to return a 
structseq, I would like to take the issue back so I can supervise  Dong-hee Na 
writing a patch and then help bring it fruition.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Tim Peters]

Tim Peters  added the comment:

I favor making this a structseq, primarily based on Paul's attempt to find 
actual use cases, which showed that named member access would be most useful 
most often.  I have no intuition for that myself, because while I wrote the 
original functions here, I've never used them and never will ;-)  But if I ever 
did, I'd probably want the ISO week number, and would appreciate not having to 
remember which meaningless index means "week".

Don't care about moving pickles to older versions.

Don't care about the putative speed hit - it's still measured in nanoseconds, 
so can still create over a million per second.  In apps with a large number of 
dates, they're typically not _calculated_, but read up from a relatively 
snail-like database or network connection.  I doubt anyone would notice if 
`.isocalendar()` got 10x slower.

Note:  I'm unassigning myself, because I have nothing else to say :-)

--
assignee: tim.peters -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[STINNER Victor]

STINNER Victor  added the comment:

> It seems to affect performance.

Oh ok. So this change makes .isocalendar() slower and breaks the backward 
compatibility on the serialization. I'm not longer sure that it's worth it.

I defer the decision the datetime module maintainers: Alexander Beloposky and 
Paul Ganssle.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Dong-hee Na]

Dong-hee Na  added the comment:

@vstinner

Here is the new benchmark with you suggested.
It seems to affect performance.

== Baseline == 
Mean +- std dev: 134 ns +- 2 ns

== PR 15633 ==
Mean +- std dev: 174 ns +- 5 ns

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[STINNER Victor]

STINNER Victor  added the comment:

"""
./python.exe -m timeit -r11 -s 'import datetime' -s 'a = 
datetime.datetime.now().isocalendar()'
5000 loops, best of 11: 8.72 nsec per loop

Let me know if the benchmark code is not appropriate
"""

Hum wait, this benchmark measures the performance of the pass opcode... That's 
why it's so fast :-) -s 'a = datetime.datetime.now().isocalendar()' is run 
exactly once for the whole benchmark, not at each benchmark iteration...

I suggest you this microbenchmark instead:

./python.exe -m pyperf timeit -s 'import datetime; dt = 
datetime.datetime.now()' 'dt.isocalendar()'

For example, on my Fedora 30 with Python 3.7.4, I get:

Mean +- std dev: 108 ns +- 4 ns

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Tal Einat]

Tal Einat  added the comment:

> Would it be possible to tell pickle to serialize .isocalendar() as a tuple, 
> and deserialize it from a tuple to a structseq?

The former is possible but that latter is not: If the object is pickled as a 
tuple, it will always be unpickled as a simple tuple. To customize unpickling, 
the serialized data must include the name of the class to use, and that class 
will never exist in earlier Python versions. I don't think there's a way around 
this.

However, I find Raymond's note very convincing, in that we should likely not 
let the unpickling issue get in the way of this improvement:

> FWIW, most things in Python that return a structseq previously returned a 
> tuple (for example, time.localtime() and sys.version_info).
>
> This is not an unprecedented upgrade to improve the repr and provide access 
> by field name in addition to positional access.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[STINNER Victor]

STINNER Victor  added the comment:

The main blocker issue (if we decide to accept this feature) is the pickle 
serialization issue.


Serhiy Storchaka:
> No, it is not fully backwards-compatible. First, if pickle a namedtuple, it 
> can't be unpickled in previous versions.

Would it be possible to tell pickle to serialize .isocalendar() as a tuple, and 
deserialize it from a tuple to a structseq? I'm thinking at __getstate__ and 
__setstate__ methods, but I'm not sure how to use them.


Serhiy Storchaka:
> Second, namedtuple is slower and larger than tuple, so it shouldn't be used 
> in memory or performance critical code.

vstinner@apu$ python3
Python 3.7.4 (default, Jul  9 2019, 16:32:37) 
>>> import sys
>>> s=sys.version_info
>>> t=tuple(s)
>>> sys.getsizeof(t), sys.getsizeof(s)
(96, 96)
>>> type(s)


Hum, structseq and tuple seem to have exactly the same memory footprint: only 
the type is larger, not instances.

According to msg350986, the performance to instanciate a new object is exactly 
the same between tuple and structseq.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Change by Raymond Hettinger :


--
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Paul, you're a new core dev.  Please don't take issues away from the assignee.  
Please try to learn from more seasoned core devs.  Don't argue with everything 
they say and demand they give you justifications.

I asked Tim to opine on this because 1) he is one of the principal authors of 
the datetime module, 2) he was party to previous decisions to upgrade from 
tuples to struct seq, 3) he has a good deal of common sense and knows what is 
important, and 4) he's far more senior than me, so there is a chance you might 
listen to him (my comments don't seem to carry any weight with you).

--
assignee: p-ganssle -> tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

In an effort to get a sense of how useful this would actually be, I did a code 
search for `.isoformat()` on github. I saw a few doctests that will break (if 
they're even being run) if we make this change, but I also found that the 
*vast* majority of uses of `isocalendar` seem to be people pulling out a single 
component of it, like:  `return datetime.datetime.now().isocalendar()[1]`.

That is not the kind of usage pattern I was envisioning when I said that this 
was a marginal improvement, a *lot* of this code could be made considerably 
more readable with named fields. If indeed the performance is similar or the 
same and this won't impact consumers of the pure python version of the module 
unduly (I checked in #pypy and they think that it shouldn't be more than a 
minor irritation if anything), then I am changing my -1 to a +1.

--
assignee: tim.peters -> p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

> What IS unprecedented is having a C function bend over backwards to return an 
> instance of collections.namedtuple().  

Is this an issue that anyone is currently insisting upon? From what I can tell 
the current implementation uses a structseq and none of my objections had to do 
with the properties of a structseq.

> ISTM the cross-version pickling issue is minor red herring.  We've cheerfully 
> upgraded tuples to structseqs on a number of occasions and it hasn't been an 
> issue.

I generally agree with this - it is nice to not break this compatibility when 
there's no good reason to do so, but pickling data in one version of Python and 
unpickling it in another is not something that's supported by the pickle module 
anyway.

> Tim, would you please weigh in on this so we can put this to bed, either 
> closing the request because we're too meek to make any change, 
upgrading to structseq to provide the requested functionality, or twisting our 
code in weird ways to have a C function become dependent on a pure python 
module.

I must take some umbrage at this framing of the question. I don't even know 
where meekness comes into it - adding *any* new functionality brings support 
burdens and additional code complexity and changes to code that's been stable 
for a long time like `dateutil.isocalendar` is particularly likely to cause 
breakages if only because of the time people have had to start relying on the 
specific implementation. I have merely asked for a justification and an 
argument other than your subjective judgement that this is a nice improvement.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

What IS unprecedented is having a C function bend over backwards to return an 
instance of collections.namedtuple().  

The only case I know of is with functools.lru_cache() and it was done there 
because we didn't really have a choice -- there was a pre-existing pure python 
API that already used collections.namedtuple().

ISTM the cross-version pickling issue is minor red herring.  We've cheerfully 
upgraded tuples to structseqs on a number of occasions and it hasn't been an 
issue.

Tim, would you please weigh in on this so we can put this to bed, either 
closing the request because we're too meek to make any change, 
upgrading to structseq to provide the requested functionality, or twisting our 
code in weird ways to have a C function become dependent on a pure python 
module.

--
assignee: rhettinger -> tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, most things in Python that return a structseq previously returned a tuple 
(for example, time.localtime() and sys.version_info).

This is not an unprecedented upgrade to improve the repr and provide access by 
field name in addition to positional access.

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Dong-hee Na]

Dong-hee Na  added the comment:

@vstinner

== baseline ==
./python.exe -m timeit -r11 -s 'import datetime' -s 'a = 
datetime.datetime.now().isocalendar()'
5000 loops, best of 11: 8.73 nsec per loop

== proposed ==
./python.exe -m timeit -r11 -s 'import datetime' -s 'a = 
datetime.datetime.now().isocalendar()'
5000 loops, best of 11: 8.72 nsec per loop

Let me know if the benchmark code is not appropriate

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[STINNER Victor]

STINNER Victor  added the comment:

> By contrast, returning a plain tuple from `isocalendar()` is the easier *and* 
> more performant thing to do, and given that any benefits seem marginal I'm 
> against the switch.

Does someone have benchmark numbers? If we go with structseq, creating a new 
instance should be almost as efficient as creating a tuple, no?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Paul Ganssle]

Paul Ganssle  added the comment:

> Dong-hee Na, if you want to make a fresh PR for this and bring it to 
> fruition, I would be happy to review and apply it.

It seems premature to say that you will accept a PR for this when there's no 
consensus for actually adding the feature, and it would be good to probably 
work out if it's even desirable before asking contributors to do more work on 
it.

It seems like it would be better to argue the point of *why* you think a 
structseq actually solves the problem here. Is a struct sequence more backwards 
compatible than a namedtuple? Less? Is it as performant? Will it make it easier 
or harder to maintain compatibility between the C and pure Python 
implementations of the datetime module?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24416] Have date.isocalendar() return a structseq instance

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Why close this?  Having isocalendar() return a structseq instance would be a 
nice improvement.  It is what structseq was designed for.

Dong-hee Na, if you want to make a fresh PR for this and bring it to fruition, 
I would be happy to review and apply it.

I'm changing the title to structseq.  It was a distractor to mention 
collections.namedtuple() at all -- that would have been more appropriate for 
pure python code.

--
assignee: belopolsky -> rhettinger
title: Return a namedtuple from date.isocalendar() -> Have date.isocalendar() 
return a structseq instance

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com