Gitlab activity and input

[Andrew Hankinson]

Hi everyone,

A few things to be aware of, if you don't follow the GitLab activity:

 - I've fixed a bug that would occur if you were trying to iterate over subfields and it was, in fact, a control field. See: https://gitlab.com/pymarc/pymarc/-/merge_requests/205

 - I've opened up two new issues, and would love to hear from others about them. 

1. Indicators can be of any length, https://gitlab.com/pymarc/pymarc/-/issues/195 This comes with a draft Merge Request, here: https://gitlab.com/pymarc/pymarc/-/merge_requests/206

What this boils down to is that currently we allow a list to be passed for indicators, but since you cannot limit the length of a Python list, this means that the Field class will just blindly set the indicators to a list of arbitrary length. To fix this I'm proposing a new Named Tuple (similar to the new Subfield) that has only two slots, "first" and "second". This makes it obvious that you cannot set it to a list of any length. It also comes with a legacy handler that will attempt to coerce any lists of 2 elements to an Indicator tuple, and will raise a ValueError if it cannot. 

2. Tags can also be of any length, and can be non-numeric. https://gitlab.com/pymarc/pymarc/-/issues/196

Some concerns have been raised already on this one, since some flavours of MARC seem to allow non-numeric tags. However, it seems that these flavours also limit their length to three characters. This is not currently enforced in Pymarc. 

If you have any thoughts on either of these two issues, please chime in!

Cheers,

-Andrew

[Ed Summers]

> On Mar 29, 2024, at 8:45 AM, Andrew Hankinson <andrew.h...@gmail.com> wrote:
>
> If you have any thoughts on either of these two issues, please chime in!

It looks like the existing pymarc API for creating Field objects has been preserved, so a new major version will not be required? If this is the case then:

1. People will be able to upgrade to the latest version of pymarc without breaking their code.
2. People may encounter new ValueErrors if they are attempting to create a Field with more than 2 indicators (which they would probably want to know about anyway).

Thanks to Tomasz for the gentle reminder to pay attention to this issue in today’s code4lib python call.

//Ed

[Andrew Hankinson]

Yes, I made it backwards compatible in execution so that it didn't break existing code. However, the type annotation will now highlight it as a type mismatch if you try to pass in a list instead of the Indicators named tuple. I even wrote a test to make sure that passing a list worked.

I suspect that passing in more than two indicators would break things in other ways, once the API started being called. I didn't thoroughly test where, though.

> --
> You received this message because you are subscribed to the Google Groups "pymarc Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pymarc+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pymarc/58D2B4D6-653E-4421-81E3-48EEEEDAA6A8%40pobox.com.

[Ed Summers]

On Apr 30, 2024, at 4:11 PM, Andrew Hankinson <andrew.h...@gmail.com> wrote:

Yes, I made it backwards compatible in execution so that it didn't break existing code. However, the type annotation will now highlight it as a type mismatch if you try to pass in a list instead of the Indicators named tuple. I even wrote a test to make sure that passing a list worked.

Yes, thanks for adding the test for the existing style:

https://gitlab.com/pymarc/pymarc/-/blob/53ecf00d7b3ab88df9c9edb6d893a1c365ca8a3c/test/test_field.py#L75-84

I suspect that passing in more than two indicators would break things in other ways, once the API started being called. I didn't thoroughly test where, though. 

I guess we could move forward with these changes as a v5.2.0 and adjust as needed going forward if people encounter issues?

//Ed

[Ed Summers]

> On Apr 30, 2024, at 7:39 PM, Ed Summers <e...@pobox.com> wrote:
>
> I guess we could move forward with these changes as a v5.2.0 and adjust as needed going forward if people encounter issues?

Just in case anyone else wants to chime in I’ll give this a couple more days and merge/release v5.2.0 on Monday (2024-05-06).

//Ed

[Andrew Hankinson]

Should we add a field tag length check in 5.2.0 as well?

https://gitlab.com/pymarc/pymarc/-/issues/196

Since there have been concerns about numeric / non numeric, it’s best to skip that for now, but I’m assuming that all MARCs only allow a tag to be exactly three characters?

If so I can do a MR, but it won’t be until next week.

On 3 May 2024, at 18:43, Ed Summers <e...@pobox.com> wrote:



--
You received this message because you are subscribed to the Google Groups "pymarc Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pymarc+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pymarc/1AA0C4A6-6852-47D7-8933-3A33D034AA45%40pobox.com.

[Ed Summers]

> On May 4, 2024, at 1:25 AM, Andrew Hankinson <andrew.h...@gmail.com> wrote:
>
> Should we add a field tag length check in 5.2.0 as well?
>
> https://gitlab.com/pymarc/pymarc/-/issues/196
>
> Since there have been concerns about numeric / non numeric, it’s best to skip that for now, but I’m assuming that all MARCs only allow a tag to be exactly three characters?

Yes, three character tags seems like a safe thing. We can hold off on a release until that’s in place.

//Ed