On Fri, 8 Mar 2019 at 10:39, Steven D'Aprano wrote:
>
> On Fri, Mar 08, 2019 at 07:25:37AM +, Paul Moore wrote:
>
> > PS I would also prefer not to have to re-sign, but just have my
> > existing confirmation carried over. I don't *know* if there are any
>
On Tue, 19 Mar 2019 at 16:47, Sebastian Rittau wrote:
> But I had another thought: If I understand correctly, the exploitability
> of mktemp() relies on the fact that between determining whether the
> file exists and creation an attacker can create the file themselves.
> Couldn't this problem be s
On Thu, 21 Mar 2019 at 17:05, Steve Holden wrote:
>
> On Thu, Mar 21, 2019 at 11:33 AM Antoine Pitrou wrote:
>>
>> [...]
>>
>> Most users and applications should /never/ care about the order of XML
>> attributes.
>>
>> Regards
>>
>> Antoine
>
>
> Especially as the standards specifically say that
On Wed, 27 Mar 2019 at 15:29, Steve Dower wrote:
> If someone can show that either no third-parties are using it, or all
> those that do will probably never explicitly support Python 3.8 or
> later, or all those that do would prefer to stop using it, then I'll
> happily change my mind here. But ri
On Mon, 15 Apr 2019 at 22:35, Stefano Borini wrote:
>
> Hello,
>
> I am on a PEP scouting effort to check the current status of python
> packaging and its historical context, mostly for learning purposes. I
> noted that the PEP defines some functions for pkgutil (e.g.
> get_distributions), but I c
I agree - removing this just to make the coverage figures look pretty
seems like the wrong motivation.
Configuring coverage to understand that you want to exclude these
lines from the checking would be fine, as would accepting that a
coverage of slightly less than 100% is OK. Removing functionalit
On Wed, 1 May 2019 at 13:53, Chris Withers wrote:
>
> On 01/05/2019 13:37, Paul Moore wrote:
> > I agree - removing this just to make the coverage figures look pretty
> > seems like the wrong motivation.
> >
> > Configuring coverage to understand that you want to ex
On Tue, 7 May 2019 at 01:43, Eric V. Smith wrote:
> After that lightning talk, Larry and I talked about it some more, and
> for a number of reasons decided that it would make more sense if the
> syntax used an = sign. So we came up with f"{foo=}", which would also
> produce "foo='Hello'".
Works f
On Fri, 10 May 2019 at 18:54, Ned Deily wrote:
>
> Eek! I was just doing a bit of branch cleanup in the cpython repo and
> managed to trigger a bunch (30-ish) of duplicate checkin messages to
> bugs.python.org for old commits. I will remove them from b.p.o. Please
> ignore any 3.4 spam email
On Wed, 15 May 2019 at 09:51, Antoine Pitrou wrote:
>
> On Tue, 14 May 2019 18:11:14 -0700
> Barry Warsaw wrote:
>
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the
> > rest of the Steering Council, I hereby Accept this PEP.
>
> For future reference, is it possible to p
On Wed, 15 May 2019 at 11:49, Bastian Venthur wrote:
>
> On 15.05.19 11:33, Antoine Pitrou wrote:
> > How stable is the TOML format? Is it bound to change significantly in
> > the coming years?
> >
> > If the format is stable enough, then I think it's a good idea.
>
>
> The last update to the spe
On Wed, 15 May 2019 at 15:56, Victor Stinner wrote:
>
> Hi Paul,
> Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :
> > Also, is there an archive of the discussions anywhere? The PEP says
> > discussions happened on Zulip, but I don't follow that and I don'
On Wed, 15 May 2019 at 21:34, Chris Barker - NOAA Federal via
Python-Dev wrote:
>
> Frankly, multiple long meandering threads in s single mailing list are
> not s very good archive either.
They aren't, I agree. But in my view, they constitute the *source
material* that the summaries in the PEP sh
On Thu, 16 May 2019 at 13:05, Victor Stinner wrote:
> > PyPreConfig_INIT and PyConfig_INIT as macros that return a struct feel
> > weird to me. Specifically, the `PyPreConfig preconfig =
> > PyPreConfig_INIT;` pattern doesn't feel right. I'm sort of OK with these
> > being implemented as macros. B
On Tue, 21 May 2019 at 13:50, Steve Holden wrote:
>
> That seems entirely reasonable. I wonder if the larger community could
> somehow form an organization (the Dead Parrot SIG?) that would at least
> curate and monitor efforts to ensure their continued utility?
I have no idea whether there is
On Tue, 21 May 2019 at 14:03, Steven D'Aprano wrote:
> I know that saying anything against pip and virtual environments is
> heresy, but honestly, "just install it from PyPI" is not friendly to
> beginners or those who just want something that works without a load of
> extra complexity.
Speaking
On Wed, 22 May 2019 at 13:28, Christian Heimes wrote:
>
> Please use
> https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704
> for feedback and discussion.
>
> Thank you,
> Christian
Out of curiosity, why? There's been a lot of useful discussion here -
why
On Thu, 23 May 2019 at 14:25, Anders Munch wrote:
> A major version change serves as a heads up that something is going on and
> you need to check the consequences before upgrading.
Python's backward compatibility policy allows breaking changes between
versions X.Y and X.Y+1 (with a suitable dep
On Sun, 26 May 2019 at 12:23, Chris Angelico wrote:
>
> On Sun, May 26, 2019 at 8:07 PM Steven D'Aprano wrote:
> > On Sun, May 26, 2019 at 08:44:33AM +1000, Chris Angelico wrote:
> >
> > > From my reading of the description, you could also "assert a is b" -
> > > is that correct?
> >
> > Yes, tha
On Mon, 27 May 2019 at 16:11, Guido van Rossum wrote:
>
> No, there's only one locals() dict *per stack frame*. So no worries about
> concurrency.
Again, if the PEP is about formalising the behaviour as language
mandated, this is worth documenting explicitly.
Paul
___
On Tue, 28 May 2019 at 06:00, Nathaniel Smith wrote:
> - There's the "justified" action-at-a-distance that currently happens
> at module scope, where locals().__setitem__ affects variable lookup,
> and variable mutation affects locals().__getitem__. This can produce
> surprising results if you pa
On Tue, 23 Jul 2019 at 04:58, Kyle Stanley wrote:
>
> My primary motivation was to provide more explicit declaration of public vs
> private, not only for the purpose of shifting the responsibility to the
> authors, but also to shift the liability of using private members to the user.
My view is
On Tue, 30 Jul 2019 at 09:33, Christian Tismer wrote:
> >>> typing.NamedTuple("__f", x=int, y=int)
>
> >>> typing.NamedTuple("__f", x=int, y=int) is typing.NamedTuple("__f",
> x=int, y=int)
> False
This appears to go right back to collections.namedtuple:
>>> from collections import namedtuple
>
On Mon, 5 Aug 2019 at 15:44, Facundo Batista wrote:
>
> El lun., 5 de ago. de 2019 a la(s) 01:25,
> escribió:
> >
> > We should revisit what we want to do (if anything) about invalid escape
> > sequences.
> >
> > For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning
> > which
On Tue, 6 Aug 2019 at 17:39, Matt Billenstein wrote:
>
> On Mon, Aug 05, 2019 at 04:22:50AM -, raymond.hettin...@gmail.com wrote:
> > This once seemed like a reasonable and innocuous idea to me; however, I've
> > been using the 3.8 beta heavily for a month and no longer think it is a good
> >
On Wed, 7 Aug 2019 at 10:32, Steven D'Aprano wrote:
> No, I'm saying we don't have to rush this into 3.8. Let's keep the
> warning silent and push everything back a release.
>
> Now is better than never.
> Although never is often better than *right* now.
>
> Right now, we're looking at a
On Tue, 20 Oct 2020 at 13:13, Thomas Wouters wrote:
> The reason for this PEP is that pattern matching will make '_' (but not any
> other names) have the behaviour suggested in this PEP, but *only* in pattern
> matching.
That's something that should be addressed or debated in the pattern
matchi
On Tue, 20 Oct 2020 at 13:25, Thomas Wouters wrote:
>
> On Tue, Oct 20, 2020 at 2:22 PM Paul Moore wrote:
>>
>> On Tue, 20 Oct 2020 at 13:13, Thomas Wouters wrote:
>> > The reason for this PEP is that pattern matching will make '_' (but not
>> > an
On Tue, 20 Oct 2020 at 14:26, Thomas Wouters wrote:
> I'm not sure how to put it differently than I have in the PEP or the email: I
> proposed they use ? instead of _ and also apply that to regular unpacking
> (because it is very easy to see pattern matching as an extension of unpacking
> assig
On Tue, 20 Oct 2020 at 14:01, Mark Shannon wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> I am aware that there ha
On Wed, 21 Oct 2020 at 08:14, Christian Heimes wrote:
>
> On 21/10/2020 00.14, Steven D'Aprano wrote:
> > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> >
> >> What I don't see is where the money's coming from. It's fine to ask,
On Thu, 22 Oct 2020 at 12:52, Mark Shannon wrote:
> Getting a PGO/LTO comparison against 3.10 is tricky.
> Mainly because I'm relying on merging a bunch of patches and expecting
> it to work :)
>
> However, on a few simple benchmarks I'm seeing about a 70% speedup vs
> master for both default and
On Fri, 30 Oct 2020 at 18:30, Mark Shannon wrote:
>
> Hi Brandt,
>
> On 30/10/2020 4:09 pm, Brandt Bucher wrote:
> >> Can we discuss whether we want pattern matching in Python and the broader
> >> semantics first, before dealing with low level details?
> >
> > This is a huge step backward. These
On Fri, 30 Oct 2020 at 20:13, Raymond Hettinger
wrote:
>
> I vote against removal.
>
> We have no compelling need to disrupt an entire community and ecosystem even
> though it it is small.
[...]
> Given this kind of user response, I think it would irresponsible to drop
> support.
I vote for lea
On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano wrote:
>
> Thank you for the well-written PEP, although I don't agree with it. My
> response below is quite long. Here is my opinionated TL;DR:
For what it's worth, I find your rebuttal of PEP 642 convincing, and
in line with my thoughts on the matter
On Wed, 4 Nov 2020 at 13:14, Antoine Pitrou wrote:
>
> On Wed, 4 Nov 2020 13:27:50 +0100
> Thomas Wouters wrote:
> >
> > And it may not be immediately obvious from Mark's plans, but as far as we
> > can tell, the proposal is for speeding up pure-Python code. It will do
> > little for code that is
IMO, the tutorial should remain as a document aimed at new users, and
therefore it definitely should *not* include too much detail.
I've helped a couple of friends learn Python and I have always
directed them to the tutorial as the "official" guide for new users.
If the tutorial is no longer aimed
On Tue, 8 Dec 2020 at 15:19, David Mertz wrote:
>
> As a candidate for the new SC, if elected I would certainly find it more
> useful to have more specific thoughts from the outgoing SC than simply "we
> recommend." How divided was the vote? Who took the sides? What were the major
> points of d
Personally, I just have Visual Studio and VS Code as my text editor. I
rarely use Visual Studio directly, though, I mostly use the
`build.bat` and similar scripts in the `PCBuild` directory.
Having said that, I'm not doing anything like debugging problems with
DLLs, for which I imagine a decent C
On Sun, 3 Jan 2021 at 16:26, Barry Scott wrote:
> I read the above and believe I know what it meant without needing to read the
> PEP in detail.
> I like that a lot.
Personally, I read it and was horribly confused. I worked out most of
it, but I would *not* count it as intuitive or natural.
Spe
On Sun, 3 Jan 2021 at 23:38, Nick Coghlan wrote:
>
> The instance attribute syntax arose from trying to deal with two problems
> from class patterns in PEP 634:
>
> * "ATTR=TARGET" using "=" to bind to the right instead of to the left
> * no subsequent path to ever offering a syntax for *retrievi
On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky wrote:
> > case {"host" as host, "port" as port}:
>
> There're 2 obvious problems with it:
>
> a) In Python, {} with things inside it, but no ":" inside it, is a set,
> set.
> b) Everywhere else in Python, thing on the left of "as" gets into
> thing on
On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote:
> So, opposing Nick's proposal on the basis that it "looks like a set" is
> just like opposing set literals on the basis they they "look like a
> dict".
That's not what I was doing (I can't comment on what Paul S intended,
though). My position i
On Sat, 9 Jan 2021 at 14:54, Nick Coghlan wrote:
[...]
> And I've already said I'd be fine with making the colon mandatory if the SC
> share that view.
So the response to my comment that omitting the colon makes it hard to
see that it's a dictionary unpacking is either "don't use that form if
y
On Mon, 1 Feb 2021 at 17:19, Christian Heimes wrote:
> How much software actually uses wchar_t these days and interfaces with
> Python? Do you have examples for software that uses wchar_t and would
> benefit from wchar_t support in Python?
This is very much a drive-by comment (I haven't been foll
On Thu, 4 Feb 2021 at 10:34, Stefano Borini wrote:
> I'd focus only on the use of the feature "from the outside", that is,
> using the indexing operation as a common user.
> For implementing the dunders, it's an advanced feature and it's
> unlikely to be discussed during basic teaching sessions.
On Tue, 9 Feb 2021 at 11:55, Inada Naoki wrote:
> I think only we can do is documenting the option like this:
>
> """
> EncodingWarning is warning to find missing encoding="utf-8" option. It
> is common pitfall that many Windows user
> Don't try to fix them if you need to use locale specific enco
9, 2021 at 1:31 PM Paul Moore wrote:
> > If we can't provide a good recommendation
> > to the user on what to do, we shouldn't be warning them that what they
> > are currently doing is wrong.
>
> The warning can explicitly suggest to use encoding="
On Tue, 9 Feb 2021 at 16:28, Inada Naoki wrote:
>
> On Wed, Feb 10, 2021 at 1:19 AM Paul Moore wrote:
> >
> > But people who currently don't specify the encoding, and *don't* have
> > any issue (because the system locale is correct) will be getting told
> >
On Tue, 9 Feb 2021 at 16:52, Anders Munch wrote:
> How about swapping around "locale" and None? That is, make "locale" the new
> default that emits a warning, and encoding=None emits no warning. That has
> the advantage that old code can be updated to say encoding=None, and then it
> will wor
On Tue, 9 Feb 2021 at 16:54, Inada Naoki wrote:
>
> On Tue, Feb 9, 2021 at 9:31 PM Paul Moore wrote:
> >
> > Personally, I'm not at all keen on the idea of making users always
> > specify encoding in the first place, even if it's "just for the
> >
On Wed, 10 Feb 2021 at 01:29, Inada Naoki wrote:
> Note that many Python users don't use consoles.
I never suggested that they did. There's a GUI for setting user-level
and system-level environment variables. And whoever is introducing the
user to Python can show them how to set the necessary en
ning.
> >> That has the advantage that old code can be updated to say encoding=None,
> >> and then it will work on both old and new Pythons without warning.
> Paul Moore [mailto:p.f.mo...@gmail.com]
> > I don't understand why working code should have to change *
On Wed, 10 Feb 2021 at 16:06, Anders Munch wrote:
>
> Paul Moore [mailto:p.f.mo...@gmail.com]: wrote:
> > On Wed, 10 Feb 2021 at 14:33, Anders Munch wrote:
> >> The idea is to make is so that working code only needs to change once,
> >> even when supporting multi
On Thu, 11 Feb 2021 at 21:05, Jim J. Jewett wrote:
>
> Who will benefit from this new warning?
>
> Is this basically just changing builtins.open by adding:
>
> if encoding is None and sys.flags.encoding_warning: # and not Android and
> not -X utf8 ?
> warnings.warn(EncodingWarning("Ar
On Sat, 13 Feb 2021 at 07:11, Steven D'Aprano wrote:
>
> On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote:
>
> > It impairs readability, because it muddles the return type.
> > The function in the example returns a bool.
> > The annotation is also misleading as the annotation is on the
On Sat, 13 Feb 2021 at 17:33, Guido van Rossum wrote:
> On Sat, Feb 13, 2021 at 2:38 AM Paul Moore wrote:
>>
>> I have to agree here. I'm not a frequent user of type hints yet, but I
>> am starting to have to maintain code that has type hints, and from a
>> mainte
On Wed, 24 Feb 2021 at 10:55, Stéfane Fermigier wrote:
> There is probably a clever way to reuse common packages (probably via clever
> symlinking) and reduce the footprint of these installations.
Ultimately the problem is that a general tool can't deal with
conflicts (except by raising an error
On Wed, 24 Feb 2021 at 13:12, Antoine Pitrou wrote:
>
> On Wed, 24 Feb 2021 13:47:40 +0100
> Stéfane Fermigier wrote:
> > The 3rd solution is probably the best of the 3, but the sharing mechanism
> > still needs to be specified (and, if needed, implemented) properly.
>
> I wouldn't want to repeat
On Wed, 24 Feb 2021 at 18:25, Steve Dower wrote:
> I mean, this is _precisely_ what PEP 370 defines (including the "-s"
> option and PYTHONNOUSERSITE env variable to provide that one-way isolation).
>
> Is the problem that pip doesn't use it by default?
Note that these days, pip *does* use usersi
On Fri, 26 Feb 2021 at 13:31, Oscar Benjamin wrote:
> Where Python is awkward is at the point where you actually *want* to
> teach students to use the command line. The problem is that Python is
> not set up for command line use out of the box in a consistent way
> across different platforms.
My
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 --
> woul
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 usef
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 se
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
Tue, 2 Mar 2021 at 16:12, 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
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 ever
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 under
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
> an
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 d
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 term?
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 exe
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,
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
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:
> https://github.com/python/devguide/pull/662/
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. Do
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
misle
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 t
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 releas
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 hap
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:
> https://packa
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 `V
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 sco
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,
>> bec
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 "
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 reada
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
> &g
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
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 inf
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 i
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 i
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
> "define
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 instea
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 always
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".
Pers
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, ..., 3:
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
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 application
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 repli
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 allow
601 - 700 of 1862 matches
Mail list logo
