[Python-Dev] Re: Some pattern annoyance

On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Partly because that's where the other discussants are (the network > externality is undeniably powerful), and partly (I believe) because > effective use of email is a skill that requires effort to

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Sat, 3 Dec 2022 at 14:46, Yoni Lavi wrote: > > I think this is over-complicating things. I think the key merit of your > > original proposal was its simplicity. Proposing more complicated ways of > > getting the result you want is (IMO) unlikely to succeed, and is only > > likely to cause

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Sat, 3 Dec 2022 at 10:57, Yoni Lavi wrote: > There's a number of Core devs that have taken strong positions against > this change, citing various reasons ranging from "the addition of a > function that returns a constant will cause bloat in the interpreter / > needs to be tested / etc" to

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On Mon, 17 Oct 2022 at 11:20, Denis Kotov wrote: > Stephen J. Turnbull wrote: > > Denis Kotov writes: > > > See: > > > https://youtube.com/clip/UgkxyNe_dsZKinT_RT3UGb-BaP0SnvKteo2o > > > No thanks, if it's not text I'm not going to look at it. I don't have > > time to watch videos with no

[Python-Dev] Re: Summary of Python tracker Issues

On Fri, 13 May 2022 at 19:54, Brett Cannon wrote: > > Can we shut this down or unsubscribe the weekly email? My understanding was that it would be updated to get its information from Github once the transition was complete. Is that not going to happen now? I'm not particularly bothered, as I

[Python-Dev] Re: Starting a new thread

On Tue, 10 May 2022 at 16:31, Barney Stratford wrote: > > Hello all. > > It occurs to me that creating threads in Python is more awkward than it needs > to be. Every time I want to start a new thread, I end up writing the same > thing over and over again: > > def target(*args, **kwds): >

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

On Wed, 27 Apr 2022 at 16:50, Victor Stinner wrote: > > Since I didn't get any serious review on my pull request since > February, I created this thread on python-dev to get more people > looking into this issue. Pull requests don't get much visibility from the wider community - I know I can't

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

On Wed, 27 Apr 2022 at 15:32, Victor Stinner wrote: > > On Tue, Apr 26, 2022 at 11:46 AM Victor Stinner wrote: > > I propose adding a -P option to Python command line interface to "not > > add sys.path[0]": > > https://github.com/python/cpython/pull/31542 > > My plan is to merge this change at

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On Sat, 23 Apr 2022 at 22:42, Rob Cliffe via Python-Dev wrote: > > UGH! > > I thought there was a general understanding that when typing was added > to Python, there would be no impact, or at least minimal impact, on > people who didn't use it. (Raises hand.) > Now we see an(other) instance of

[Python-Dev] Re: Declarative imports

On Fri, 8 Apr 2022 at 12:57, Daniel Pope wrote: > > On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote: > > > > I've read the rest of the thread so far, and agree strongly that we > > can't do this at the language/runtime level. > > You mean the hoisting, right? > > I don't see any reason why an

[Python-Dev] Re: Declarative imports

On Fri, 8 Apr 2022 at 10:27, Malthe wrote: > > On Fri, 8 Apr 2022 at 08:51, Paul Moore wrote: > > Are you exaggerating for effect here or would this *actually* just expand to > > > > from datetime import datetime > > default_args = { > > "

[Python-Dev] Re: Declarative imports

On Fri, 8 Apr 2022 at 09:29, Malthe wrote: > A workflow definition which could be a 5-liner quickly > becomes a 20-liner – consider for example: > > default_args = { > "start_date": @datetime.datetime(...) > } Are you exaggerating for effect here or would this *actually* just

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer) wrote: > > I would welcome a multiline comment format that didn't involve docstrings. > > Err, sorry, I meant multiline string format. I'm confused, what's wrong with """..."""? Triple quoted strings are not exclusively for docstrings...

[Python-Dev] Re: Make HAMT available to python script

On Sat, 2 Apr 2022 at 02:30, Christopher Barker wrote: > > On Fri, Apr 1, 2022 at 4:06 AM Steve Dower wrote: >> >> The main difference is that 'immutables' offers you a stable/versioned >> interface to use it, while the one that's in CPython is an internal >> implementation detail. If one day we

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Wed, 30 Mar 2022 at 12:28, Steve Dower wrote: > > On 30Mar2022 1132, Baptiste Carvello wrote: > > Le 28/03/2022 à 18:44, Steve Dower a écrit : > >> I think to most people "batteries included" doesn't necessarily mean > >> "standard library," with all that implies. It just means "it came with >

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Tue, 29 Mar 2022 at 00:37, Toshio Kuratomi wrote: > One thing about talking about "make urllib more like requests" that is > different than any of the other libs, though, is that requests aims to be > easier to use than anything else (which I note Chris Barker called out as why > he wanted

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, 28 Mar 2022 at 20:37, Steve Dower wrote: > Please let us know > *publicly* if you want to become the maintainer for a stdlib module and > then we can support them, but if nobody is willing/able/ready to care > for them it's irresponsible for us to keep shipping them to users. I'm sorry

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, 28 Mar 2022 at 17:45, Steve Dower wrote: > > I think to most people "batteries included" doesn't necessarily mean > "standard library," with all that implies. It just means "it came with > the first thing that I installed" (or alternatively, "at no additional > charge"). I think that for

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Sun, 27 Mar 2022 at 17:11, Christopher Barker wrote: > > With the json package included, all they need to do is `import json`. If that > wasn't there, they's look in PyPi for a JSON implementation, and find an > absolutely astonishing number of options. I just did a search for "JSON" > on

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Sun, 27 Mar 2022 at 00:52, Ethan Furman wrote: > > [apologies for the late post, just found this in my drafts folder] > > On 2/7/22 12:49 AM, Stéfane Fermigier wrote: > > > 3. Overall, I think the days where "battery included" was a positive > > argument are over > > I strongly disagree.

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On Sun, 6 Feb 2022 at 16:51, Christian Heimes wrote: > The urllib package -- and to some degree also the http package -- are > constant source of security bugs. The code is old and the parsers for > HTTP and URLs don't handle edge cases well. Python core lacks a true > maintainer of the code. To

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On Sun, 6 Feb 2022 at 14:15, Victor Stinner wrote: > I propose to deprecate the urllib module in Python 3.11. It would emit > a DeprecationWarning which warn users, so users should consider better > alternatives like urllib3 or httpx: well known modules, better > maintained, more secure, support

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

Strong -1 from me. urllib.request may not be "best practice", but it's still extremely useful for simple situations, and urllib.parse is useful for basic handling of URLs.Yes, the more complex aspects of urllib are better handled by external packages, but that's not sufficient argument for

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On Mon, 17 Jan 2022 at 06:52, Denis Kotov wrote: > > And that's why you need to do more work than arguing that in principle > > C++ is just a better language than C. We've been hearing that for 4 > > decades now (at least we greybeards have), and we've discovered that > > for many existing

[Python-Dev] Re: Changing PySequence and PyMapping checks

Personally, I dislike the presumption that you state in the bpo, that typing and linters have changed things so that being a sequence is more closely tied to implementing the Sequence abc these days. I consider it a flaw in typing and linters if that’s the case, not something to embrace. Paul.

[Python-Dev] Re: PEP 677 (Callable Type Syntax): Final Call for Comments

On Thu, 13 Jan 2022 at 08:48, Nick Coghlan wrote: > > The existing section on runtime behaviour in the PEP doesn't look ready for > SC consideration, since it essentially says "this hasn't been defined yet". +1. The runtime behaviour needs to be specified. Otherwise this PEP is a spec for how

[Python-Dev] Re: Suggestion: a little language for type definitions

On Mon, 10 Jan 2022 at 23:04, Greg Ewing wrote: > > Most of the effort of learning to read type expressions, in any > language, is learning their semantics, which is very different > from value expressions. Whether they happen to superficially > resemble other parts of the language is pretty much

[Python-Dev] Re: PEP 679 – Allow parentheses in assert statements

On Mon, 10 Jan 2022 at 11:43, Batuhan Taskaya wrote: > > > Does someone know if linters like pylint or pylakes current warn on > > "assert(test, msg)" statements? > > I believe so, both the python itself (through SyntaxWarnings) and > other linters warn about this. ❯ py Python 3.10.1

[Python-Dev] Re: RFC on Callable Syntax PEP

To me, these are mostly convincing examples that people need to name parts of a complex type like this :-) I don't actually find any of the syntaxes better than any other. They are all a bit bad, but I view that as the fault of the complex nested types, not the syntax (hence my preference for

[Python-Dev] Re: RFC on Callable Syntax PEP

On Tue, 21 Dec 2021 at 18:35, Steven Troxler wrote: > > I've been thinking about readability hard because I share many of your > concerns about readability. Before I comment on syntax, I'd like to question the example: > An example > = > > The function > > > To get at

[Python-Dev] Re: RFC on Callable Syntax PEP

I agree. The same concerns and reservations apply for me. On Sat, 18 Dec 2021 at 21:13, Terry Reedy wrote: > > Batuhan expresses my concerns better than I could, so I just add my > agreement. > > On 12/18/2021 3:13 PM, Batuhan Taskaya wrote: > > > tl;dr: I find it very troubling that we are

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On Wed, 8 Dec 2021 at 12:42, Petr Viktorin wrote: > > I assume it would be insensitive to ask whether we could just get rid of > > the stable ABI altogether and focus on the limited API? Just tell > > everyone they have to rebuild binary wheels for every Python feature > > release. Presumably the

[Python-Dev] Re: The current state of typing PEPs

On Fri, 3 Dec 2021 at 00:10, Shantanu Jain wrote: > > @Paul > > > ... missing resource is a central set of typing documentation that includes > > examples, FAQs and best practices as well as reference materials > > Like Sebastian, I agree, and this is something we're making progress on. That's

[Python-Dev] Re: The current state of typing PEPs

On Wed, 1 Dec 2021 at 12:08, Sebastian Rittau wrote: > Please note that users of you library usually won't care that the library > uses type hints. It's more important that there are type hints for the API, > which can also be supplied using a stub file. I tried that route, but I was informed

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

On Tue, 30 Nov 2021 at 19:07, Brett Cannon wrote: > > On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano wrote: >> >> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote: >> >> > And to be clear, it's often very non-obvious how to annotate something >

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 12:39, Oscar Benjamin wrote: > There are other open "issues" like this for SymPy where the > presumption is that not having type hints is now to be considered a > deficiency of the library regardless of whether the hints have any > benefit for internal use. I don't object

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 09:37, Chris Angelico wrote: > > On Tue, Nov 30, 2021 at 8:19 PM Paul Moore wrote: > > Also, related to the question Terry raised, IMO it would be useful to > > have a clear statement on code that *does* use type annotations, but > >

[Python-Dev] Re: The current state of typing PEPs

On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote: > > THAT'S the kind of thing that also has been happening with typing, and > why some of us feel the need to publicly re-state things that are all > agreed upon within this group, but are struggling to be heard over the > public discourse on the

[Python-Dev] Re: The current state of typing PEPs

On Fri, 26 Nov 2021 at 17:13, Guido van Rossum wrote: >> Although the more I think about it, given that I believe dataclasses >> use eval "under the hood", the less I understand *how* it manages to >> do that without special-case knowledge of the dataclass decorator...) > > Static checkers

[Python-Dev] Re: The current state of typing PEPs

On Thu, 25 Nov 2021 at 21:45, Christopher Barker wrote: > The issue is that, intended or not, typing is making it's way into Python > culture. As an instructor of beginning python users, I am unsure at this > point when to introduce type annotations. > > What is their role? Up to today, I have

[Python-Dev] Re: The current state of typing PEPs

On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote: > > My memory is also hazy, but I'm quite sure that *in my mind* annotations were > intended as a compromise between conflicting proposals for *typing*. We > didn't have agreement on the syntax or semantics, but we did know we wanted > to

[Python-Dev] Re: The current state of typing PEPs

On Sun, 21 Nov 2021 at 07:50, Christopher Barker wrote: > > TL;DR: > > Annotations can be, and are, used for other things than "typing". I just > noticed that PEP 563 apparently deprecated those other uses (well, sort of: > "uses for annotations incompatible with the aforementioned PEPs should

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

On Thu, 11 Nov 2021 at 11:51, Antoine Pitrou wrote: > > On Wed, 10 Nov 2021 21:12:17 -0600 > Tim Peters wrote: > > [Bob Fang ] > > > This is a modest proposal to consider having sorted containers > > > (http://www.grantjenks.com/docs/sortedcontainers/) in standard library. > > > > +1 from me,

[Python-Dev] Re: Proposal: Allow non-default after default arguments

On Tue, 9 Nov 2021 at 10:39, Sebastian Rittau wrote: > This might be better API design (although I don't think Python should be > opinionated about this outside the standard library), but this still > leaves the API change example and the very real problem of @overloads > unsolved. You can

[Python-Dev] Re: containment and the empty container

On Tue, 9 Nov 2021 at 06:31, Ethan Furman wrote: (IMO, Steven D'Aprano's comment above, which I don't think you have responded to yet, is the clearest summary of the options here. I agree with what he says, but just wanted to clarify one point below). > I've had a couple people tell me that

[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again

I've had about 5 or 6 of them. Paul On Thu, 4 Nov 2021 at 19:22, Brett Cannon wrote: > > What notification? (I fully admit I may not have gotten one due to some team > I'm in, but I have no such notification if it happened recently.) > > On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote: >>

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

On Wed, 3 Nov 2021 at 10:11, Marc-Andre Lemburg wrote: > I don't think limiting the source code encoding is the right approach > to making code more secure. Instead, tooling has to be used to detect > potentially malicious code points in code. +1 Discussing "making code more secure" without

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

On Tue, 19 Oct 2021 at 00:55, Guido van Rossum wrote: > > I should have added that I also don't feel I want to go at bat to fight for > this PEP. I do observe that it looks like the folks used to building large > systems (in Python or other languages) don't seem to like it, while it seems > to

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

On Mon, 18 Oct 2021 at 19:29, Guido van Rossum wrote: > where the convention is that keys at any level may be omitted altogether and > config itself may be NOne, then to safely access the value of > config["handler"]["parameters"]["y"] we would have to write > > y = None # Default > if config

[Python-Dev] Re: RFC on Callable Type Syntax

On Fri, 8 Oct 2021 at 16:29, Jelle Zijlstra wrote: > That's one of the differences between the proposals discussed here. The basic > proposal Pradeep pointed out would not support named arguments, the more > complete syntax favored by Guido (and also by me; 2(a) in Pradeep's email) > would

[Python-Dev] Re: RFC on Callable Type Syntax

On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar wrote: > Typing-sig has been discussing user-friendly syntax for the type used to > represent callables. [1] Since this affects the Python language syntax, we > wanted to get some high-level feedback from you before putting up a detailed > PEP.

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Mon, 4 Oct 2021 at 08:21, Antoine Pitrou wrote: > > On Sat, 2 Oct 2021 13:27:03 +0100 > Paul Moore wrote: > > On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > > > > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 >

[Python-Dev] Re: PEP 654 except* formatting

On Mon, 4 Oct 2021 at 07:16, Greg Ewing wrote: > > On 4/10/21 6:23 pm, Guido van Rossum wrote: > > On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > > wrote: > > > > Therefore my vote is for requiring `except* E` and keeping `except > > *E` as a SyntaxError. > >

[Python-Dev] Re: PEP 654 except* formatting

On Sun, 3 Oct 2021 at 16:55, Irit Katriel via Python-Dev wrote: > > We wonder if people have a view on which of the following is clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: > 2. except* E as e: // except* (E1, E2) as e: > > (The difference is in the whitespace around the

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 I agree with the comment made on that issue - this isn't the right way to handle the problem. We need to encourage projects to opt into the new approach and remove the

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Sat, 2 Oct 2021 at 03:27, Illia Volochii wrote: > > Hi everyone, > > ensurepip includes private copies of pip and setuptools. But PEP 453 states > that "once pip is able to run pip install --upgrade pip without needing > setuptools installed first, then the private copy of setuptools will be

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 28 Sept 2021 at 15:33, Eric Snow wrote: > > It means that the site module module can no longer be "customized" by > > modifying directly the site.py file (inject a path in PYTHONPATH env > > var where the customized site.py lives). But there is already a > > supported way to customize

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

On Thu, 16 Sept 2021 at 01:30, Chris Barker via Python-Dev wrote: > """ > "[i]terators are required to have an __iter__() method" which neither `for` > nor `iter()` actually enforce. > """ > > I'm confused -- as far as I can tell `for` does enforce this -- well, it > doesn't enforce it, but it

[Python-Dev] Re: A better way to freeze modules

On Fri, 3 Sept 2021 at 10:29, Simon Cross wrote: > > Hi Gregory, > > I think adding a meta path importer that reads from a standard > optimized format could be a great addition. I think the biggest open question would be "what benefits does this have over the existing zipimport?" Maybe it could

[Python-Dev] Re: A better way to freeze modules

My quick reaction was somewhat different - it would be a great idea, but it’s entirely possible to implement this outside the stdlib as a 3rd party module. So the fact that no-one has yet done so means there’s less general interest than the OP is suggesting. And from my experience, the reason for

[Python-Dev] Re: Problems with dict subclassing performance

Has anyone raised this on bugs.python.org? That's the best way to get something like this looked at, not via a post on Stack Overflow. The SO posting didn't include a bpo link. Paul On Thu, 12 Aug 2021 at 07:33, Marco Sulla wrote: > > No ideas? Excuse me for the up. > > On Fri, 6 Aug 2021 at

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On Wed, 11 Aug 2021 at 07:37, Larry Hastings wrote: > [...] > I think PEP 649 should be considered in the same way. In my opinion, the > important thing is to figure out what semantics we want for the language. I think this is a very important point. As originally implemented, annotations

[Python-Dev] Re: Roundup to GitHub Issues migration

On Wed, 23 Jun 2021 at 01:21, Brett Cannon wrote: > Regardless, there are no plans to halt what was decided when we accepted PEP > 581. Most of the concerns which have been brought up in this thread were > already expressed back then (the account merge one I didn't remember, hence > why I

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On Fri, 18 Jun 2021 at 01:57, Guido van Rossum wrote: > > I don’t see how the stable ABI works as a substitute for vendoring Python. A > lot of other things can still vary even when the C API remains the same! > (E.g. syntax, and stdlib behavior.) IMO it doesn't. However for certain

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On Wed, 9 Jun 2021 at 11:36, Inada Naoki wrote: > If I am wrong, can we stop keeping stable ABI at Python 3.12? > Python 4.0 won't come in foreseeable future. Stable ABI blocks Python > evolution. Conversely, the stable ABI allows projects to build cross-version binary wheels. Not many projects

[Python-Dev] Re: The repr of a sentinel

On Thu, 20 May 2021 at 20:06, Ethan Furman wrote: > > On 5/20/21 11:00 AM, Paul Moore wrote: > > > But it nevertheless feels like a bit of an abuse - the original point > > of ellipsis was for indexing, and in particular complex slices like > > a[1:20:2, ...,

[Python-Dev] Re: The repr of a sentinel

On Thu, 20 May 2021 at 18:13, Luciano Ramalho wrote: > > I'd like to learn about use cases where `...` (a.k.a. `Ellipsis`) is > not a good sentinel. It's a pickable singleton testable with `is`, > readily available, and extremely unlikely to appear in a data stream. > Its repr is "Ellipsis".

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Thu, 13 May 2021 at 09:23, Mark Shannon wrote: > > Hi Terry, > > On 13/05/2021 5:32 am, Terry Reedy wrote: > > On 5/12/2021 1:40 PM, Mark Shannon wrote: > > > >> This is an informational PEP about a key part of our plan to improve > >> CPython performance for 3.11 and beyond. > > > >> As

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Tue, 27 Apr 2021 at 18:01, Brett Cannon wrote: > Unfortunately I thought importlib.metadata would have used the module name > instead of the metadata details, but in hindsight am guessing that the > .dist-info is what it's using to do the lookup and that's based on the > package name

[Python-Dev] Re: OTish: Define Protocols near consumers [was: Keeping Python a Duck Typed Language.]

On Fri, 23 Apr 2021 at 10:31, Stephen J. Turnbull wrote: > SJIS = 'shift_jisx0213' > > *Now* that is a personal protocol, serving the same function of > telling me "this code deals with a legacy Japanese encoding" and > implementing it behind the scenes. But I don't see how that can be >

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 at 21:40, Adrian Freund wrote: > If I understand correctly your concerns with inferring return types for > inferred protocols are that it might be to restrictive and prevent > gradual typing. Here are some examples to show how gradual typing would > still work. OK, I have no

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 at 15:22, Adrian Freund wrote: > > On April 22, 2021 3:15:27 PM GMT+02:00, Paul Moore > wrote: > >but that's *absolutely* as far as I'd want to go. Note in particular > >that I don't want to constrain the return value > The problem is that this isn

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 at 13:23, Adrian Freund wrote: > > According to PEP 484 all missing annotations in checked functions should be > handled as Any. Any is compatible with all types. Yep, that's what I understood to be the case. > I think from a technical standpoint it should be possible to

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 at 11:21, Paul Moore wrote: > > On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote: > > > > Someone will likely correct me if this is inaccurate, but my > > understanding is that that's exactly what you get if you just don't > > give a type

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 at 11:06, Chris Angelico wrote: > > On Thu, Apr 22, 2021 at 7:53 PM Paul Moore wrote: > > I wonder whether type checkers could handle a "magic" type (let's call > > it DuckTyped for now :-)) which basically means "infer a protocol > > ba

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On Thu, 22 Apr 2021 at 09:46, Chris Angelico wrote: > Maybe in some cases, the "smaller protocols" option is practical, but > it would need to have a useful name. For instance, if it needs to be > readable, iterable, closeable, and autocloseable via > __enter__/__exit__, that's ... uhh a

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Thu, 15 Apr 2021 at 21:03, Christopher Barker wrote: > I am leaning toward at least SOME PEP about this -- having __version__ > around as a semi-convention with no official recommendation as to if or how > it should be used is kind of a mess. On the other hand, having a PEP that says you

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, 14 Apr 2021 at 21:59, David Mertz wrote: > > On Wed, Apr 14, 2021 at 9:12 PM Paul Moore wrote: >> >> If it's not basically equivalent to packaging.version.Version (and >> based on PEP 440) then we'll be creating a nightmare of confusion, >> because PE

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, 14 Apr 2021 at 18:04, Eric V. Smith wrote: >> Anyway, the question now for me is whether this is worth any more of my time. >> >> So: >> - Is there someone willing to sponsor? >> - Do folks generally think there's a chance of it being accepted without a >> huge debate and expansion of

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, 14 Apr 2021 at 18:01, David Mertz wrote: > > On Wed, Apr 14, 2021 at 5:44 PM Christopher Barker > wrote: >> >> Another possible issue: using Version would require an extra import in many >> module initializations -- is that a performance issue that would matter? > > > I like having a

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

On Wed, 14 Apr 2021 at 13:28, Victor Stinner wrote: > There are two main use cases for versions: > > * Display them to the user > * Compare versions to check if one is newer, older or the same > > I dislike using strings for comparison. You need to use > packaging.version for that: >

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Wed, 7 Apr 2021 at 06:15, Stephen J. Turnbull wrote: > > Greg Ewing writes: > > On 7/04/21 5:22 am, Brandt Bucher wrote: > > > we might consider updating those templates if the term "Reference > > > Implementation" implies a higher standard than "we've put in the > > > work to make this

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Tue, 6 Apr 2021 at 06:15, Stephen J. Turnbull wrote: > > Paul Moore writes: > > > It *is* merged and publicly released - it's in the latest 3.10 > > alpha. > > Merged, yes, but in my terminology alphas, betas, and rcs aren't > "public releases",

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Sun, 4 Apr 2021 at 13:49, Stephen J. Turnbull wrote: > Final note: once this is merged and publicly released, it will lose > its status as reference implementation in the above, strong sense. It *is* merged and publicly released - it's in the latest 3.10 alpha. That's really the point I was

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

On Sun, 4 Apr 2021 at 01:37, Brandt Bucher wrote: > > Mark Shannon said: > > I was relying on the "reference" implementation, which is also in the PEP. > > Can you please stop putting scare quotes around "reference implementation"? Agreed - apart from the implication Brandt noted, it's also

[Python-Dev] Re: PEP-376 and PEP-427 interpretation

On Mon, 29 Mar 2021 at 17:40, Theallredman via Python-Dev wrote: > So going back to my actual question SHA224 is disallowed in record files > because it's bit length is less then 256? It doesn't look like it's ever been excluded. The only explicit exclusions are MD5 and SHA1 as you point out.

[Python-Dev] Re: On the migration from master to main

On Fri, 26 Mar 2021 at 19:54, Mariatta wrote: > > > The branch has not been renamed. It will be renamed after the release of beta > 1. > > There is a pending PR on DevGuide on how to change your existing local > CPython repository to the new branch: >

[Python-Dev] Re: Merge Request Review Reminder

On Fri, 19 Mar 2021 at 17:26, Hasan Diwan wrote: > > For the side question, you can always use rebase instead of merge. Let me > know if you need further particulars? -- H There should be no need though, as the Python project has a policy of squash-merging all PRs. Paul

[Python-Dev] Re: pth file encoding

On Wed, 17 Mar 2021 at 09:26, Paul Moore wrote: > The problem is with the transition - we need to find a way to deal > with existing `.pth` files, and with people using older version of > tools (like setuptools and pipx) that write `.pth` files (so we can't > assume, for example, that

[Python-Dev] Re: pth file encoding

On Wed, 17 Mar 2021 at 08:52, Inada Naoki wrote: > On Windows, it must be UTF-8. For example, we use `chcp 65001` in > `activate.bat` to support unicode path. > On Unix, raw path is bytestring. So paths can be written as-is. Python > decode it with fsencoding. Remember that .pth files contain

[Python-Dev] Re: pth file encoding

On Wed, 17 Mar 2021 at 08:13, Michał Górny wrote: > > On Wed, 2021-03-17 at 13:55 +0900, Inada Naoki wrote: > > OK. setuptools doesn't specify encoding at all. So locale-specific > > encoding is used. > > We can not fix it in short term. > > How about writing paths as bytestrings in the long

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Sorry, I keep thinking I've finished and you keep making interesting points :-) On Wed, 3 Mar 2021 at 17:01, Irit Katriel wrote: > Raising an ExceptionGroup is an API change. If you call APIs that say they > will raise ExceptionGroups you need to update your code accordingly. If a > library

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, 3 Mar 2021 at 14:59, Irit Katriel wrote: >> 2. Given the above, why even have a means of grouping BaseExceptions >> at all? Why not just have ExceptionGroup that can only catch instances >> of Exception? > > Because the IGotInterrupted alternative involves wrapping a BaseException by >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, 3 Mar 2021 at 12:37, Irit Katriel wrote: > This is covered the PEP, but TL;DR: > If we could make "except KeyboardInterrupt" catch > BaseExceptionGroup([KeyboardInterrupt]) in a reasonably backwards compatible > way then we wouldn't need except*. [...] > As you noted, no library is

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Tue, 2 Mar 2021 at 21:46, Irit Katriel via Python-Dev wrote: > As an aside - I found it interesting that the option to wrap BaseException > instances by an Exception, which came up a couple of times in this thread, > didn't generate any anxiety. Probably because it wasn't clear that was

[Python-Dev] Re: Which thing is "Development Mode"

Coyot Linden (Glenn Glazer) wrote: > > On 3/1/21 08:49, Paul Moore wrote: > > On Mon, 1 Mar 2021 at 16:25, Coyot Linden (Glenn Glazer) > wrote: > > This is one of those cases, where those of us who have been around > Python for awhile can perhaps infer from context which

[Python-Dev] Re: Which thing is "Development Mode"

On Mon, 1 Mar 2021 at 16:25, Coyot Linden (Glenn Glazer) wrote: > This is one of those cases, where those of us who have been around > Python for awhile can perhaps infer from context which his meant, but > the phrase "put your Python project into development mode" is ambiguous > in a way that is

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Sat, 27 Feb 2021 at 13:03, Oscar Benjamin wrote: > More recently I've been exploring Julia. You could compare these pages: > > https://docs.python.org/3/tutorial/interpreter.html#invoking-the-interpreter > https://docs.julialang.org/en/v1/manual/getting-started/ > > When installing julia you

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Sat, 27 Feb 2021 at 01:08, Oscar Benjamin wrote: > > On Fri, 26 Feb 2021 at 23:06, Jim J. Jewett wrote: > > > > I think his point is that most of his students (economics or business, > > rather than comp sci) will never need to use Perl or C or Java. Python is > > friendly enough to be

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: > > Whenever I've used except Exception or stronger, it was a sanitary barrier > around code that might well do unpredictable or even stupid things. Adding a > new kind of exception that I hadn't predicted -- including ExceptionGroup -- >

  1   2   3   4   5   6   7   8   9   10   >