5 ms·

I was really excited to see graphlib in stdlib (despite the very limited use so far), but wow is it me or that API is.... awful. I guess it's super focused on p

I was really excited to see graphlib in stdlib (despite the very limited use so far), but wow is it me or that API is.... awful. I guess it's super focused on parallel task processing but that has to be one of the least Pythonic and user-friendly APIs I've seen. Create a class, then call .prepare(), then loop over .is_active(), what the hell were they thinking? I was hoping to have a nice alternative to networkx, which is big and slow, but this is honestly a mess. Also is ZoneInfo basically stdlib version of pytz? Why not just put it under datetime.timezone like utc?

petters 4y ago
I guess they wanted to raise an exception if the graph has cycles, while at the same time still be able to use the object partially. Then the constructor can not raise. Also, you don't have to call is_active(), the object itself is convertible to bool. Not sure if that is an improvement. graphlib is definitely underwhelming at the moment. A standard Python vocabulary for graphs would be nice.
lifthrasiir 4y ago
> Also is ZoneInfo basically stdlib version of pytz? Why not just put it under datetime.timezone like utc? A good thing about Python is that pretty much every decision and rationale is documented by PEP, and this is no exception: https://peps.python.org/pep-0615/#using-datetime-zoneinfo-instead-of-zoneinfo https://peps.python.org/pep-0615/#using-datetime-zoneinfo-in... In short the heavy implementation of zoneinfo disfavors a nested module, since it is not a norm in Python that importing A doesn't automatically make A.B available as well.
- gorgoiler 4y ago
  I’ve only read the top level part of the PEP, but it sounds like they’d rather keep the Python source code clean than reuse `datetime.timezone`. They optimised for, what, 20 people instead of optimising for thousands. I am not impressed at all. “Optimising” here is quite a euphemism too. The omission of timezones from the standard library, alongside allowing timezone naive datetimes, has been a major implementation flaw for a long time.
  - lifthrasiir 4y ago
    I see where you come from, but a timezone database presents several challenging design problems to date and time libraries (I have written some popular date & time library in the past). One of such problems is to keep the database up to date, which is nothing but trivial. I'm very confident that the OS-level time zone data is the only database you can be reasonably sure that it's likely up to date, and different OSes expose (sometimes accidentally) different bits of data. Any other solutions are not very automated and tend to drift, I've seen systems where pytz or Java's TZUpdater neglected for a while. I hoped TZDIST [1] to be a thing, but it is not widespread enough, to say the least. In this sense PEP 615 is not exactly the solution but a stopgap; it essentially admits that we can't exactly solve this problem, but we can at least include the existing half-solution into the batteries. [1] https://www.rfc-editor.org/rfc/rfc7808.html https://www.rfc-editor.org/rfc/rfc7808.html
  - progval 4y ago
    Reusing datetime.timezone would not make sense. datetime.timezone represents fixed UTC offsets, while ZoneInfo objects represent IANA timezones (which generally don't have a fixed offset).
    - lifthrasiir 4y ago
      I believe GP wants something like `datetime.timezone.from_tzid("Etc/UTC")`, which is by itself a fine backward-compatible upgrade from the original interface.
      - Macha 4y ago
        I would disagree that this is a fine interface. It's not clear with the "Etc/UTC", but what is the offset of datetime.timezone.from_tzid("America/New_York")? You need a datetime to go with the TZ id to answer that question. And experience has shown "Just assume the current time" is a bit of a footgun.
        lifthrasiir 4y ago

petters 4y ago

I guess they wanted to raise an exception if the graph has cycles, while at the same time still be able to use the object partially. Then the constructor can not raise. Also, you don't have to call is_active(), the object itself is convertible to bool. Not sure if that is an improvement. graphlib is definitely underwhelming at the moment. A standard Python vocabulary for graphs would be nice.

lifthrasiir 4y ago

> Also is ZoneInfo basically stdlib version of pytz? Why not just put it under datetime.timezone like utc? A good thing about Python is that pretty much every decision and rationale is documented by PEP, and this is no exception: https://peps.python.org/pep-0615/#using-datetime-zoneinfo-instead-of-zoneinfo https://peps.python.org/pep-0615/#using-datetime-zoneinfo-in... In short the heavy implementation of zoneinfo disfavors a nested module, since it is not a norm in Python that importing A doesn't automatically make A.B available as well.

gorgoiler 4y ago
I’ve only read the top level part of the PEP, but it sounds like they’d rather keep the Python source code clean than reuse `datetime.timezone`. They optimised for, what, 20 people instead of optimising for thousands. I am not impressed at all. “Optimising” here is quite a euphemism too. The omission of timezones from the standard library, alongside allowing timezone naive datetimes, has been a major implementation flaw for a long time.
- lifthrasiir 4y ago
  I see where you come from, but a timezone database presents several challenging design problems to date and time libraries (I have written some popular date & time library in the past). One of such problems is to keep the database up to date, which is nothing but trivial. I'm very confident that the OS-level time zone data is the only database you can be reasonably sure that it's likely up to date, and different OSes expose (sometimes accidentally) different bits of data. Any other solutions are not very automated and tend to drift, I've seen systems where pytz or Java's TZUpdater neglected for a while. I hoped TZDIST [1] to be a thing, but it is not widespread enough, to say the least. In this sense PEP 615 is not exactly the solution but a stopgap; it essentially admits that we can't exactly solve this problem, but we can at least include the existing half-solution into the batteries. [1] https://www.rfc-editor.org/rfc/rfc7808.html https://www.rfc-editor.org/rfc/rfc7808.html
- progval 4y ago
  Reusing datetime.timezone would not make sense. datetime.timezone represents fixed UTC offsets, while ZoneInfo objects represent IANA timezones (which generally don't have a fixed offset).
  - lifthrasiir 4y ago
    I believe GP wants something like `datetime.timezone.from_tzid("Etc/UTC")`, which is by itself a fine backward-compatible upgrade from the original interface.
    - Macha 4y ago
      I would disagree that this is a fine interface. It's not clear with the "Etc/UTC", but what is the offset of datetime.timezone.from_tzid("America/New_York")? You need a datetime to go with the TZ id to answer that question. And experience has shown "Just assume the current time" is a bit of a footgun.
      - lifthrasiir 4y ago