I was about to say you don't have to use types to well... just use them.

Buf if you're a noob then I'll try to explain:
use - in contrast with other languages like C++ or JS - only creates an alias, but doesn't actually import anything; In fact in Rust you don't need to import types from a crate at all to use them!

In other words: if you have to name a type - say to call an associated method like OnceCell::new() - then you'd need:

use std::cell::OnceCell;

...somewhere in the file/function

but if you're only calling a method that returns a OnceCell then no use is needed (or if you'd use the full name - std::cell::OnceCell::new() - then no use is needed also)

I was about to say you don't have to use types to well... just use them.

Buf if you're a noob then I'll try to explain: use - in contrast with other languages like C++ or JS - only creates an alias, but doesn't actually import anything; In fact in Rust you don't need to import types from a crate at all to use them!

In other words: if you have to name a type - say to call an associated method like OnceCell::new() - then you'd need:

use std::cell::OnceCell;

...somewhere in the file/function

but if you're only calling a method that returns a OnceCell then no use is needed (or if you'd use the full name - std::cell::OnceCell::new() - then no use is needed also)

Thanks for the feedback. I did so right before this comment 👍

This doesn't look good... those tests all expect PyStructTime to have 9 fields, as they very well should - docs say indices go up to (but not including) 9 - the problem here is that PyStructSequence has no way of marking fields to be skipped when unpacking
By which I mean: take the Traverse derive macro - you can give a field the #[pytraverse(skip)] attribute and that ignores it... but (unfortunately for you) PyStructSequence provides no such facility.

In other words the original comment from the issue is wrong - it won't be that easy to "just add" those fields (unfortunately)

@youknowone if I'm right and there's no way to mark a PyStructSequence field/s to not get unpacked I don't think you can solve this issue like the author is suggesting.

There isn't, right?

@youknowone if I'm right and there's no way to mark a PyStructSequence field/s to not get unpacked I don't think you can solve this issue like the author is suggesting.

There isn't, right?

I think you're right. I came to conclusion much slower though through messing around with the failing tests.

@JazzGlobal well... this is going to require major changes (completely restructuring the definition of PyStructTime) and unless you're up for that - and if you are then great, but it'll be a though one esp. if you're new to Rust - then I'm closing the PR.

So... are you up for it?

@JazzGlobal well... this is going to require major changes (completely restructuring the definition of PyStructTime) and unless you're up for that - and if you are then great, but it'll be a though one esp. if you're new to Rust - then I'm closing the PR.

So... are you up for it?

yeah I'll fiddle with this for a while longer.

@miviwi what are you doing? you don't close the PR. you can't do that.

@youknowone hold on... not closing anything yet, or now that JazzGlobal has spoken not at all 😅

Community is a bit more moderated since I last contributed lol. I'll look at some of the other Traverse implementations for hints on how I should do it for PyStructTime. Thanks guys!

@JazzGlobal Don't worry about it that much. We can solve things step by step, eventually. Nothing changed from the time you visited before.
I agree PyStructureSequence lacks of the feature. The related part is here. https://github.com/RustPython/RustPython/blob/main/derive-impl/src/pystructseq.rs#L5-L28

@JazzGlobal Personally I would first try just leaving PyStructTime as a PyStructSequence and addding the new fields as getter methods. Yes it'll be slower, but performance and timezones are sort of "opposites" anyway, so... it's worth a shot. Definitely seems easier than uprooting the whole struct

I am not getting how PyTraverse is related to this problem yet. I'd like to fix pystructseq side first.

@JazzGlobal Are you also interested in proc macro? Then the point will be the start point. Otherwise let me make some changes on PyStructSequence. I don't have a good idea how to change it right now though.

@youknowone not as the code is right now, but making the struct a Traversable (instead of a PyStructSequence) is the only way I could think up to keep those extra fields and be consistent with the docs (i.e. have the tests pass)

Maybe there is confusion. PyTraverse used only for GC. I hope I can solve it with PyStructSequence.

I am not getting how PyTraverse is related to this problem yet. I'd like to fix pystructseq side first.

@JazzGlobal Are you also interested in proc macro? Then the point will be the start point. Otherwise let me make some changes on PyStructSequence. I don't have a good idea how to change it right now though.

If utilizing Traverse is not an option then go for it.

@youknowone Should this be closed until that work in completed?

I don't think any PR need to be closed due to blocking issues. We always encounter unexpected blocking issues for numerous patches. We can fix them and come back to the original issue whenever we can. We can review unresolved opened PRs later. But not about unresolved closed PRs. So unclosed PRs are more helpful than closed PRs.

How about adding #[pystruct(skip)] to mark fields to ignore?

How about adding #[pystruct(skip)] to mark fields to ignore?

Do you mean #[pytraverse(skip)] ?

EDIT: Or would #[pystruct(skip)] be something new

Yes, adding a new attribute #[pystruct(<something>)]

pytraverse is only used for GC, so not here.

Yes, adding a new attribute #[pystruct(<something>)]

pytraverse is only used for GC, so not here.

I'm not familiar with Rust macros. Will pystruct("skip") essentially be the same thing implementation-wise as pytraverse?

Unfortunately, it now runs but still tm_gmtoff is not accessible.

@JazzGlobal It look long time, but finally added required support. Thank you for contributing. I am sorry if you felt inconvenience. Please don't worry to be moderated not by CoC but by code. Whenever everybody every code will be welcomed.

No problem at all. I like contributing to the project and it isn't about me. Thanks for your help in facilitating this!