I'll summarize by quoting only a small part, since most of the line of
argument is the same, with different examples.
On Mon, 11 Apr 2022 at 02:59, Christopher Barker <python...@gmail.com> wrote:
> Again, the behavior of some code should be clear and obvious to the person
> writing the code. If I write code such as:
>
> np.datetime64('2022-04-10T09:33:00')
>
> I should know exactly what I'm going to get (which I do now -- numpy fixed
> this a good while ago -- but in it's first implementation, it should
> literally provide a different result depending on the local computer's
> settings)
>
Yes, exactly. You, as application author, should know exactly what
you're going to get.
> That doesn't mean that:
>
> np.datetime64('2022-04-10T09:33:00', apply_locale_tz_offset=True)
>
> Isn't useful, it's just that it shouldn't be default, or even worse, should
> be a non-overridable default -- e.g. a "global context".
What if you have an intermediary library that calls on something else?
What if, say, numpy calls on the datetime module rather than doing the
parsing itself? Even if there were some way to make global config
changes, *the application* will still know what's happening - because
the application is the one that's in charge.
Libraries should not be making changes to application configs except
at the behest of the application.
Libraries should do things that are affected by application configs,
when they are working at the behest of the application.
When a library is doing its own thing, it should be independent of such configs.
This applies to system-wide things too; if you use os.sep anywhere, it
doesn't mean you don't know what will happen. It specifically means
that you DO know what will happen, and that you'll get the
OS-appropriate directory separator.
If you use os.sep and then assume that you're getting backslashes,
you're doing it wrong. If you use os.sep and then print it out for the
human to see, you're doing it right, and it'll probably be less
surprising than hard-coding slash or backslash.
>> > Again: practical use case with units:
>> Cool. The global repository that I suggest would be completely
>> independent, unless you choose to synchronize them. The registry that
>> you have would be used by your tools, and source code would use the
>> interpreter-wide ones. This is not a conflict. Of course, since you
>> have all the functionality already, it would make a lot of sense to
>> offer an easy way to register all of your library's units with the
>> system repository, thus making them all available; but that would be
>> completely optional to both you and your users.
>
>
> But if I did that, then one lib registering my units with the global
> repository might break some other lib's use of the global repository.
Then... libraries should not register units unless it's at the behest
of the application? That's exactly what I've been saying.
You might as well say that one lib adding something to sys.path might
break some other lib's changes to sys.path. We're not bothered by
that; we call that ill-behaved libraries.
> A global "default units" is fine, but then anyone wanting to override it
> should be working with a copy, not changing the same one that other packages
> might be using.
>
> Which I believe is exactly what pint does, for instance.
>
What does pint do if you want to have rules like "kilograms of mass
and kilograms of force should be interchangeable"? Or does it simply
mandate that they're not? I put it to you that these kinds of
conversion rules *belong to the application*, not to any library that
calls on pint.
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YC2RHQWQEB6LVBJ5QMPIZJBS2HWXNPEA/
Code of Conduct: http://python.org/psf/codeofconduct/
