Stories with Tag Type Hints

• Whenever – typed and DST-safe datetimes for Python

  permalink

  Posted: 2025-04-13 09:12:19

  Verbose tl;dr

  Whenever is a Python library providing a Whenever type for representing date and time values in a more robust and intuitive way than native Python types. It's particularly focused on handling Daylight Saving Time (DST) transitions correctly and consistently, avoiding ambiguities and errors common with other approaches. Whenever objects store datetimes as UTC timestamps internally, but allow users to interact with them in local time using a specified timezone. They offer convenient methods for performing date and time arithmetic, comparisons, and formatting, while transparently managing DST transitions behind the scenes. This simplifies working with recurring events or schedules that span DST changes, eliminating the need for complex manual adjustments. The library aims to provide a clear and dependable way to manage date and time information across different timezones and DST rules.

  The Python library whenever introduces a new approach to handling datetimes, specifically designed to address the complexities and ambiguities often associated with time zones and Daylight Saving Time (DST) transitions. It aims to provide a robust and intuitive way to represent and manipulate points in time, regardless of the user's current locale or the vagaries of time zone rules.

  Central to whenever is the concept of "typed datetimes." This means that datetime objects are not simply naive representations of a date and time, but are explicitly tagged with a specific time zone or UTC offset. This typing eliminates ambiguity about the intended moment in time, ensuring consistent calculations and comparisons, especially across different time zones. Moreover, whenever distinguishes between "wall clock times" and "absolute times." A wall clock time refers to the time displayed on a clock in a specific location, which can be affected by DST transitions. An absolute time, on the other hand, represents a fixed point on the timeline, independent of any time zone or DST. This distinction allows whenever to handle DST transitions gracefully, preventing errors that can occur when switching between standard time and DST.

  whenever provides several key features:

  • Explicit Time Zone Handling: Datetimes are always associated with a specific time zone, either by name (e.g., "America/New_York") or by a fixed UTC offset. This ensures clarity and avoids ambiguity in calculations.
  • DST Safety: The library is explicitly designed to handle DST transitions correctly, preventing errors that can arise from ambiguous or non-existent times during these transitions. It can accurately represent and calculate times during the "fall back" transition when the clock moves back an hour.
  • Intuitive API: whenever offers a simplified and consistent API for working with typed datetimes, making it easier to perform common operations such as time zone conversions, comparisons, and arithmetic.
  • Serialization: The library supports serialization of typed datetimes to and from various formats, ensuring that the time zone information is preserved. This is crucial for storing and exchanging datetime data.
  • Interoperability with other libraries: whenever integrates with existing datetime libraries like pendulum and pytz, allowing developers to leverage its features while working within familiar environments.

  By combining typed datetimes with a clear distinction between wall clock and absolute times, whenever aims to provide a more robust and reliable foundation for handling datetime data in Python, particularly in applications where accurate and unambiguous timekeeping is essential. It addresses the shortcomings of traditional datetime handling by explicitly addressing time zone complexities and DST transitions.

  • Python
  • DateTime
  • Date
  • time
  • Library
  • module
  • DST
  • daylight saving time
  • TimeZone
  • typed
  • Type Hints
  • Static Typing
  • mypy

  Summary of Comments ( 61 )
  https://news.ycombinator.com/item?id=43671308

  Verbose tl;dr

  Hacker News users generally praised the whenever library for its focus on type safety and handling of daylight saving time (DST), which are common pain points in Python's datetime handling. Several commenters expressed interest in its approach using tagged unions for representing different kinds of time specifications. Some raised questions about the practical implications of whenever's immutability, particularly concerning performance in tight loops and modification of existing datetime objects. The discussion also touched upon alternatives like pendulum and arrow, with some users suggesting whenever offered a fresh perspective on a persistent problem. A few commenters expressed skepticism about the library's complexity and the potential for over-engineering, preferring simpler solutions where possible.

  The Hacker News post about Whenever, a library for typed and DST-safe datetimes in Python, has generated a moderate amount of discussion, with a focus on existing solutions and the specific problems Whenever aims to address.

  Several commenters point towards existing libraries and built-in functionalities in Python that already address some of the issues Whenever tackles. One commenter highlights the zoneinfo module introduced in Python 3.9, suggesting it provides similar timezone handling capabilities. Another mentions the Pendulum library as a potential alternative that offers user-friendly datetime manipulation. A third points out that the datetime objects in Python already store timezone information, questioning the necessity of a new library.

  There's a discussion about the complexities of timezone handling in general. One commenter emphasizes the inherent difficulty of working with timezones and DST, suggesting that a comprehensive solution is challenging to achieve. Another adds to this by mentioning the "local time" ambiguity during DST transitions, where a specific time can exist twice or not at all, highlighting a common pain point.

  The core value proposition of Whenever, namely its type safety, is also discussed. One user expresses appreciation for the static typing aspect, which can help prevent errors related to timezone handling at compile time. This resonates with another commenter who also sees value in the type hints provided by the library.

  Finally, some commenters express skepticism about the library's usefulness. One suggests that using UTC consistently and only converting to local time for display purposes is a simpler approach. This sentiment is echoed by another who advocates for sticking with UTC and formatting time zones on output as a more straightforward solution.

• Astral – "We're building a new static type checker for Python"

  permalink

  Posted: 2025-01-29 17:56:51

  Verbose tl;dr

  Astral is a new static type checker being developed for Python that aims to be faster and more ergonomic than existing options like MyPy. It leverages a new type inference algorithm designed for performance and boasts features like auto-completion, goto-definition, and an improved developer experience. The project is still early in development but claims significant speed improvements, with a goal of being at least 5x faster than MyPy on real-world codebases. Astral also intends to offer seamless integration with existing Python tooling and provide enhanced support for popular libraries like NumPy and Pandas.

  Charlie Marsh, developer of the Ruff linter for Python, has announced on Twitter the development of a new static type checker for Python called "Astral." This project aims to not just be another type checker in the already existing ecosystem, which includes MyPy, Pyright, and others, but to significantly advance the state of the art in Python type checking. Marsh highlights several key areas where Astral aims to differentiate itself and push boundaries:

  • Performance: Astral is being built with a strong emphasis on speed and efficiency, aiming to outperform existing type checkers, making the type checking process less disruptive to the development workflow. This focus on performance is a core design principle of the project.

  • Type Inference: Astral is designed to have advanced type inference capabilities. This means it will be able to automatically deduce the types of variables and expressions in more complex and nuanced situations, requiring fewer explicit type annotations from the developer while still providing the benefits of static typing.

  • Improved Error Messages: User experience is a key consideration. Astral aims to provide more helpful and informative error messages than existing tools. This will aid developers in understanding and resolving type errors more quickly and efficiently.

  • New Type System Features: Astral is not just focused on performance and usability improvements within the existing Python type system. It also aims to explore and implement new features within the type system itself. This suggests the possibility of introducing novel type checking concepts or extending the expressiveness of type annotations in Python.

  Marsh positions Astral not as a mere incremental improvement, but as a potential paradigm shift in how type checking is performed in Python. The tweet emphasizes the project's ambitious goals and suggests it is a significant undertaking aimed at substantially improving the developer experience and capabilities of static typing in the Python language. He invites interested developers to follow him for updates on the project's progress.

  • Python
  • Static Typing
  • Type Checker
  • Astral
  • Programming Languages
  • Software Development
  • compiler design
  • Typing
  • Type Hints
  • static analysis

  Summary of Comments ( 53 )
  https://news.ycombinator.com/item?id=42868576

  Verbose tl;dr

  Hacker News users discuss Astral's potential, drawing parallels to MyPy but with a focus on performance. Some express skepticism about static typing in Python, questioning its necessity and impact on the language's flexibility. Others are interested in Astral's approach to gradual typing and its ability to handle complex codebases. Performance improvements over MyPy are frequently mentioned as a key benefit. Several commenters inquire about specific features, such as handling metaclasses and integration with existing tools. Overall, there's a mix of cautious optimism and interest in seeing how Astral develops.

  The Hacker News post titled "Astral – 'We're building a new static type checker for Python'" generated a moderate discussion with a mix of skepticism, cautious optimism, and technical inquiries. Several commenters expressed concern over the perceived complexity and slow adoption of type hinting in Python, citing their own experiences or anecdotal evidence. One user recounted their frustration with the type checker mypy getting bogged down on large code bases, highlighting performance as a potential barrier. Another user questioned the value proposition of yet another type checker, given the existing options.

  Some commenters expressed interest in Astral's specific features, particularly its incremental checking capabilities and the potential for improved performance compared to existing tools. They hoped that these features might address some of the existing pain points associated with static typing in Python. There was also a brief discussion on the merits of different approaches to type checking, including the potential benefits of a ground-up rewrite like Astral compared to iterative improvements on existing tools.

  Several users asked clarifying questions about Astral's implementation details, like its relationship with the Python runtime and whether it introduces any runtime dependencies. The author of the post engaged with these inquiries, providing further context and addressing specific concerns. They clarified that Astral aims to be a drop-in replacement for mypy and discussed the trade-offs involved in supporting different Python versions.

  Overall, the sentiment was cautiously optimistic, with many commenters expressing interest in seeing how Astral evolves but remaining somewhat skeptical until real-world performance and usability can be demonstrated. The discussion did not delve into highly technical details but rather focused on the high-level goals, potential benefits, and common concerns surrounding static typing in Python.