[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

I actually really like some variation on `@with type S`, or some other variation that has a keyword, because that makes it much easier for someone newly encountering one of these syntax constructs to search to figure out what it does. If you didn't already know what the square brackets did,

[Python-Dev] Re: Having Sorted Containers in stdlib?

I think Richard's point was two-fold: People usually don't want or need this kind of thing /except/ when they have some very specific performance requirements, in which case they probably want to also be very specific about the kind of container they are using rather than using an abstract

[Python-Dev] Re: The list.sort(reverse=True) method not consistent with description

You are re-assigning the list on line 4 here, not displaying it. I get the answer you expect when using the `itemgetter(0)` key: IPython 7.28.0, on CPython 3.9.7 (default, Aug 31 2021 13:28:12) >>> import operator >>> from operator import itemgetter >>> L = [(1, 'a'), (2, 'b'), (1, 'c'), (2,

[Python-Dev] Re: In support of PEP 649

It seems evident that the problems with PEP 563 have been well-known at least to pydantic for several years, as you can see in the issue Samuel Colvin linked: https://github.com/samuelcolvin/pydantic/issues/2678 That said, while I do think that "please contact upstream when you see a problem

[Python-Dev] Re: In support of PEP 649

I should point out that "accept PEP 649" and "break pydantic" are not the only options here. The thing that will break pydantic is the end of PEP 563's deprecation period, not a failure to implement PEP 649. Other viable options include: - Leave PEP 563 opt-in until we can agree on a solution to

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

Considering the people involved and the nature of the list, I suspect that adding a new @python.org mailing list would be better than discourse. In my experience, it's very difficult to just follow a single topic on the discourse, and most people complain that the e-mail integration is not great.

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

for distro packagers, but as I don't meet the description I don't know how useful it would be for me to opine on the form it should take. Best, Paul On 11/16/20 10:45 AM, Miro Hrončok wrote: > On 11/16/20 4:10 PM, Paul Ganssle wrote: >>> Maybe it would make sense to create a

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

t’s what I was going to suggest. I’m not doing any Debian or Ubuntu work >> these days, but Matthias Klose should be watching both lists, and should be >> able to handle the Debuntu stack. > >> -Barry >> >>> On Nov 16, 2020, at 07:45, Miro Hrončok wrote: >>

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

On 11/16/20 9:57 AM, Filipe Laíns wrote: > In Arch Linux, tzdata is a dependency of glibc, which is part of the > base[1] package that should be present on every installation. So, there > is no action necessary :) > We could make it an explicit dependency, but that it not necessarily > required,

[Python-Dev] Distro packagers: PEP 615 and the tzdata dependency

Hi all, One part of PEP 615 (IANA time zones) that I expected to be easily overlooked (a point about which I seem to have been right) is the recommendation that starting with Python 3.9, distros should add a dependency on the system time zone data to the Python package. Quoting the PEP: > Python

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 9/4/20 12:45 PM, Stefan Krah wrote: > Since distutils does not change, why remove it? It is a lot of work > for people with little gain. If we don't remove it, we should at least freeze the bug component so that people cannot report bugs in distutils. Triaging these bugs alone is a decent

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 9/4/20 12:22 PM, Paul Moore wrote: > I believe that's correct. My main concern here is that removing > distutils from the stdlib won't have made that problem any better, it > will simply have transferred the responsibility onto the setuptools > maintainers. While I assume that they are

[Python-Dev] Re: Function suggestion: itertools.one()

I would think that you can use tuple unpacking for this?     single_element, = some_iterator Will attempt to unpack the some_iterator into single_element and fail if single_element doesn't have exactly 1 element. It also has the added benefit that it works for any number of elements: one, two =

[Python-Dev] datetime module refactoring: folder vs parallel private modules

Hi all, I was hoping to get some feedback on a proposed refactoring of the datetime module that should dramatically improve import performance. The datetime module is implemented more or less in full both in pure Python and in C; the way that this is currently achieved

[Python-Dev] Re: Flexible assignment targets

I think that creating a "matching assignment" operator is unnecessary at this point. I think the original point of bringing this up as part of PEP 622 is to try to suggest that the syntax for binding a value not be incompatible with a future version of Python where that same syntax can be used for

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

I'm on the fence about using a separate function vs. a keyword argument (I think there is merit to both), but one thing to note about the separate function suggestion is that it makes it easier to write backwards compatible code that doesn't rely on version checking. With `itertools.zip_strict`,

[Python-Dev] PEP 615 (zoneinfo) implementation ready for review

Hey all, The feature freeze is coming up on us fast, and the PEP 615 implementation is more or less ready to be integrated into the standard library (may need one or two little tweaks, but it's well past the "minimum viable product" stage). Normally I'd wait longer for someone to volunteer for

[Python-Dev] Re: Issues with import_fresh_module

No worries, I actually seem to have solved the immediately pressing problem that was blocking PEP 615 by doing this: @functools.lru_cache(1) def get_modules():     import zoneinfo as c_module     py_module = import_fresh_module("zoneinfo", blocked=["_czoneinfo"])     return py_module, c_module

[Python-Dev] Re: Issues with import_fresh_module

included in the PR) include tests that have the C and pure Python version running side-by-side, which would be hard to achieve with subinterpreters. On 5/6/20 4:51 PM, Nathaniel Smith wrote: > On Wed, May 6, 2020 at 7:52 AM Paul Ganssle wrote: >> As part of PEP 399, an idiom for testi

[Python-Dev] Issues with import_fresh_module

As part of PEP 399 , an idiom for testing both C and pure Python versions of a library is suggested making use if import_fresh_module. Unfortunately, I'm finding that this is not amazingly robust. We have this issue: https://bugs.python.org/issue40058,

[Python-Dev] Re: Moving tzdata into the python organization

All right, I've got one yay and zero nays, so I've moved this over to: https://github.com/python/tzdata On 4/29/20 12:48 PM, Barry Warsaw wrote: > No objections here. > > -Barry > >> On Apr 29, 2020, at 06:05, Paul Ganssle wrote: >> >> Signed PGP part >> Hi

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 4/30/20 4:47 PM, raymond.hettin...@gmail.com wrote: > Would either of the existing solutions work for you? > > class X: > def __init__(self, name): > self.name = name > > @cached_property > def title(self): > print("compute title once") > return self.name.title()

[Python-Dev] Moving tzdata into the python organization

Hi all, PEP 615 specifies that we will add a first party tzdata package . I created this package at pganssle/tzdata , but I believe the final home for it should be python/tzdata. Are there any

[Python-Dev] Re: killing static types (for sub-interpreters?)

I don't know the answer to this, but what are some examples of objects where you never change the refcount? Are these Python objects? If so, wouldn't doing something like adding the object to a list necessarily change its refcount, since the list implementation only knows, "I have a reference to

[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo

> In every use-case that I've ever had, and every one that I can > imagine, I've not cared about the difference between "US/Eastern" and > "America/New_York". In fact, if ZoneInfo("US/Eastern") returned > something that had a name of "America/New_York", I would be fine with > that. Similarly,

[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo

> In every use-case that I've ever had, and every one that I can > imagine, I've not cared about the difference between "US/Eastern" and > "America/New_York". In fact, if ZoneInfo("US/Eastern") returned > something that had a name of "America/New_York", I would be fine with > that. Similarly,

[Python-Dev] Further PEP 615 Discussion: Equality and hash of ZoneInfo

A few weeks ago, I submitted PEP 615 to the steering council for a decision. There's been a decent amount of discussion there with some very good questions. I think they are mostly resolved (though I'm happy to have other people look over the

[Python-Dev] Re: PEP 615: Support for IANA Time Zones in the Standard Library

rth (mostly in Australia/New Zealand/Pacific Islands), so I am planning on submitting this to the steering council as soon as possible and hoping that I've given them enough notice to look at it. If anyone else was planning on commenting, please do head over to the discourse ASAP. Thanks! Paul O

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

I imagine it's an implementation detail of which ones depend on __getitem__. The only methods that would be reasonably amenable to a guarantee like "always returns the same thing as __getitem__" would be (l|r|)strip(), split(), splitlines(), and .partition(), because they only work with subsets

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

I've said a few times that I think it would be good if the behavior were defined /in terms of __getitem__/'s behavior. If the rough behavior is this: def removeprefix(self, prefix):     if self.startswith(prefix):     return self[len(prefix):]     else:     return self[:] Then you can

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

> And we *have* to decide that it returns a plain str instance if called > on a subclass instance (unless overridden, of course) since the base > class (str) won't know the signature of the subclass constructor. > That's also why all other str methods return an instance of plain str > when called

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

] > > Such code makes my "micro-optimizer hearth" bleeding since I know that > Python is stupid and calls len() at runtime, the compiler is unable to > optimize it (sadly for good reasons, len name can be overriden) :-( > > => line.cutprefix("prefix") is more efficie

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

I don't see any rationale in the PEP or in the python-ideas thread (admittedly I didn't read the whole thing, I just Ctrl + F-ed "subclass" there). Is this just for consistency with other methods like .casefold? I can understand why you'd want it to be consistent, but I think it's misguided in

[Python-Dev] Requesting review on PEP 615 C Extension Reference Implementation

Hi all, The past few weeks I've been working on adding a C extension to the reference implementation for PEP 615 (Support for the IANA Time Zone Database in the Standard Library - PEP link ), but I've had some trouble inducing anyone to review the code

[Python-Dev] PEP 615: Support for IANA Time Zones in the Standard Library

Greetings! Last year at the Language Summit, I proposed to add additional concrete time zones to the standard library <https://pyfound.blogspot.com/2019/05/paul-ganssle-time-zones-in-standard.html> . After much work and much more procrastination, I now have now put together my first pr

[Python-Dev] Re: PEP 584: Add Union Operators To dict

On 2/6/20 4:23 PM, Serhiy Storchaka wrote: > It would create an exception of two rules: > > 1. Operators on subclasses of builtin classes do not depend on > overridden methods of arguments (except the corresponding dunder > method). `list.__add__` and `set.__or__` do not call copy() and >

[Python-Dev] Re: PEP 584: Add Union Operators To dict

Hi Brandt, very nice PEP. I have two questions here. First: > - The proposal in its current form is very easy to wrap your head around: "|" > takes dicts, "|=" takes anything dict.update does. I see this asymmetry between the | and |= mentioned a few times in the PEP, but I don't see any

[Python-Dev] Re: Announcing the new Python triage team on GitHub

I think it's fine for triagers to have the close permission, and there's actually a good reason to give it to them, which is that often the easiest way to trigger a new CI run is to close and re-open a PR. It will be very helpful for triagers to be able to do this to fix intermittent build

[Python-Dev] Re: What is a public API?

FWIW, I actually like the idea - though not strongly enough to really campaign for it. My reasoning is that I think that both the current "consenting adults" policy and possibly more importantly the fact that we are implicitly supporting private interfaces by our reluctance to changing them has

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

It seems that the issue that originally caused compatibility issues was that `__debug__` statements were being optimized away, which was apparently desirable from coverage's point of view. It's not clear to me, but it seems that this may also impact what bytecode is generated when Python is run in

[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures

I'm not one of the people who ever shipped pre-cythonized code, but I think at this point it should be pretty safe to ship just your .pyx files and not the generated C files - at least if your reason for shipping the C code was "it will be hard for people to pip install things". For /other/

Re: [Python-Dev] Adding a toml module to the standard lib?

As someone involved in the packaging side of this, I think while we'd eventually /appreciate/ a TOML parser in the standard library, I agree with Victor that there's no rush, for two reasons: 1. setuptools and pip have a decent number of dependencies that we vendor /anyway/, so vendoring one more

Re: [Python-Dev] Adding a tzidx cache to datetime

> From Marc-Andre Lemburg, I understand that Paul's PR is a good > compromise and that other datetime implementations which cannot use > tzidx() cache (because it's limited to an integer in [0; 254]) can > subclass datetime or use a cache outside datetime. One idea that we can put out there

Re: [Python-Dev] Adding a tzidx cache to datetime

make it possible, it would be possible to have an > external cache implemented with weakref.WeakSet to clear old entries > when a datetime object is detroyed. > > What do you think of adding a private "_cache" attribute which would > be an arbitrary Python object? (None by default) &g

[Python-Dev] Adding a tzidx cache to datetime

Greetings all, I have one last feature request that I'd like added to datetime for Python 3.8, and this one I think could use some more discussion, the addition of a "time zone index cache" to the /datetime/ object. The rationale is laid out in detail in bpo-35723

[Python-Dev] datetime.fromisocalendar

Greetings, Some time ago, I proposed adding a `.fromisocalendar` alternate constructor to `datetime` (bpo-36004 ), with a corresponding implementation (PR #11888 ). I advertised it on datetime-SIG some time ago but

[Python-Dev] Adding shlex.join?

Hey all, I've been reviewing old "awaiting review" PRs recently, and about a week ago I found PR #7605 , adding shlex.join(), with a corresponding bug at bpo-22454 . The PR's implementation is simple and seems

Re: [Python-Dev] bpo-36558: Change time.mktime() return type from float to int?

I already chimed in on the issue, but for the list, I'll boil my comments down to two questions: 1. For anyone who knows: when the documentation refers to "compatibility with `.time`", is that just saying it was designed that way because .time returns a float (i.e. for /consistency/ with

Re: [Python-Dev] Remove tempfile.mktemp()

I'm not sure the relationship with mkdir and mktemp here. I don't see any uses of tempfile.mktemp in pip or setuptools, though they do use os.mkdir (which is not deprecated). Both pip and setuptools use pytest's tmpdir_factory.mktemp() in their test suites, but I believe that is not the same

Re: [Python-Dev] datetime.timedelta total_microseconds

On 2/26/19 7:03 PM, Chris Barker via Python-Dev wrote: > This thread petered out, seemingly with a consensus that we should > update the docs -- is anyone doing that? > I don't think anyone is, I've filed a BPO bug for it: https://bugs.python.org/issue3613 > > -- I am a physical scientist, I

Re: [Python-Dev] datetime.timedelta total_microseconds

> On Fri, 15 Feb 2019 at 04:15, Alexander Belopolsky > wrote: >> >> >> On Thu, Feb 14, 2019 at 9:07 AM Paul Ganssle wrote: >>> I don't think it's totally unreasonable to have other total_X() methods, >>> where X would be days, hours, minutes and microse

Re: [Python-Dev] datetime.timedelta total_microseconds

I'm still with Alexander on this. I see functions like total_X as basically putting one of the arguments directly in the function name - it should be `total_duration(units)`, not `total_units()`, because all of those functions do the same thing and only differ in the units they use. But

Re: [Python-Dev] datetime.timedelta total_microseconds

wrote: > > > On Thu, Feb 14, 2019 at 9:07 AM Paul Ganssle <mailto:p...@ganssle.io>> wrote: > > I don't think it's totally unreasonable to have other total_X() > methods, where X would be days, hours, minutes and microseconds > > I do.  I was against adding th

Re: [Python-Dev] datetime.timedelta total_microseconds

I don't think it's totally unreasonable to have other total_X() methods, where X would be days, hours, minutes and microseconds, but it also doesn't seem like a pressing need to me. I think the biggest argument against it is that they are all trivial to implement as necessary, because they're

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

3.8 alpha 2. > > On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle <mailto:p...@ganssle.io>> wrote: > > Hey all, > > This thread about the return type of datetime operations seems to > have stopped without any explicit decision - I think I responded > t

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

s purpose. > > On Sun, Jan 6, 2019 at 11:02 AM Paul Ganssle <mailto:p...@ganssle.io>> wrote: > > I did address this in the original post - the assumption that the > subclass constructor will have the same arguments as the base > constructor is baked into man

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

Cannon wrote: > > > On Sun, 6 Jan 2019 at 11:00, Paul Ganssle <mailto:p...@ganssle.io>> wrote: > > I did address this in the original post - the assumption that the > subclass constructor will have the same arguments as the base > constructor is baked in

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

cls): return cls.now() > ... > >>> D() > D(2019, 1, 6, 10, 33, 37, 161606) > >>> D.fromordinal(100) > Traceback (most recent call last): >   File "", line 1, in > TypeError: __new__() takes 1 positional argument but 4 were given > >&g

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

On 1/6/19 1:29 PM, Andrew Svetlov wrote: > From my perspective datetime classes are even more complex than int/float. > Let's assume we have > > class DT(datetime.datetime): ... > class TD(datetime.timedelta): ... > > What is the result type for the following expressions? > DT - datetime > DT -

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

o have arithmetic operations always create the base class was chosen, please let me know. Best, Paul On 1/5/19 3:55 AM, Alexander Belopolsky wrote: > > > On Wed, Jan 2, 2019 at 10:18 PM Paul Ganssle <mailto:p...@ganssle.io>> wrote: > > .. the original objection was that

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

On 1/6/19 9:14 AM, Steven D'Aprano wrote: > [...] > But a better question is, why would you (generic, not you personally) > imagine that, alone out of all flow control statements, ONLY "except" > clauses introduce a new scope? Every other flow control statement (for, > while, if, elif, else,

[Python-Dev] Return type of datetime subclasses added to timedelta

Happy New Year everyone! I would like to start a thread here for wider feedback on my proposal to change the return type of the addition operation between a datetime subclass and a timedelta. Currently, adding a timedelta to a subclass of datetime /always/ returns a datetime rather than an

Re: [Python-Dev] Get a running instance of the doc for a PR.

On 11/4/18 5:38 PM, Steven D'Aprano wrote: > On Sun, Nov 04, 2018 at 12:16:14PM -0500, Ned Deily wrote: > >> On Nov 4, 2018, at 12:04, Paul Ganssle wrote: >> >>> Some of the concerns about increasing the surface area I think are a >>> bit overbl

Re: [Python-Dev] Get a running instance of the doc for a PR.

On 11/4/18 12:16 PM, Ned Deily wrote: > On Nov 4, 2018, at 12:04, Paul Ganssle wrote: >> Some of the concerns about increasing the surface area I think are a bit >> overblown. I haven't seen any problems yet in the projects that do this, and >> I don't think it lends itself

Re: [Python-Dev] Get a running instance of the doc for a PR.

There is an open request for this on GH, but it's not currently done: https://github.com/rtfd/readthedocs.org/issues/1340 At the PyCon US sprints this year, we added documentation previews via netlify, and they have been super useful: https://github.com/pypa/setuptools/pull/1367 My understanding

Re: [Python-Dev] Official citation for Python

I think the "why" in this case should be a bit deeper than that, because until recently, it's been somewhat unusual to cite the /tools you use/ to create a paper. I see three major reasons why people cite software packages, and the form of the citation would have different requirements for each

Re: [Python-Dev] iso8601 parsing

Here is the PR I've submitted: https://github.com/python/cpython/pull/4699 The contract that I'm supporting (and, I think it can be argued, the only reasonable contract in the intial implementation) is the following: dtstr = dt.isoformat(*args, **kwargs) dt_rt =

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

> If it turns out that there's a dict implementation that's faster by not > preserving order, collections.UnorderedDict could be added. > There could also be specialized implementations that pre-size the dict (cf: > C++ unordered_map::reserve), etc., etc. > But these are all future things, which

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

I think the question of whether any specific implementation of dict could be made faster for a given architecture or even that the trade-offs made by CPython are generally the right ones is kinda beside the point. It's certainly feasible that an implementation that does not preserve ordering