[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

On Fri, 27 Jan 2023 at 06:42, Thomas Ratzke wrote: > > Hi all, > > i would like to suggest the following Python feature. It naturally > happens that one want's to repeat the current iteration of a for loop > for example after an error happened. For this purpose, I usually set a > flag and put a wh

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

On Mon, 5 Dec 2022 at 05:11, Rob Cliffe via Python-Dev wrote: > > Wild suggestion: > Make None.__hash__ writable. > E.g. > None.__hash__ = lambda : 0 # Currently raises AttributeError: > 'NoneType' object attribute '__hash__' is read-only Hashes have to be stable. If you change the hash

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

On Thu, 1 Dec 2022 at 17:26, Yoni Lavi wrote: > > > the language makes no guarantee about hash consistency between > executions > > because it's futile in the general case, even if objects were to get a serial > `id` and hash by it for example, any change in the number of objects created > acros

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

On Wed, 30 Nov 2022 at 10:48, Steven D'Aprano wrote: > Let's consider a thought-experiment: suppose we agree to your proposal > to make hash(None) return a constant, but at the same time modify the > set iteration algorithm so that it starts from a different position each > time you iterate, makin

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

On Tue, 29 Nov 2022 at 13:12, Oscar Benjamin wrote: > As for point 2. the fact that sets are currently non-deterministic is > actually a relatively new thing in Python. Before hash-randomisation > set and dict order *was* deterministic but with an arbitrary order. > That was only changed because o

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

On Tue, 29 Nov 2022 at 09:51, Brett Cannon wrote: > ... we worked hard to stop people from relying on consistent > hashing/iteration from random-access data structures like dict and set. > Say what? Who's been working hard to stop people from relying on consistent iteration order for a dict? Ch

[Python-Dev] Re: Switching to Discourse

On Fri, 22 Jul 2022 at 03:17, Skip Montanaro wrote: > > > No, Discord is a different thing; it does text and voice communication > > channels in real-time. If you're familiar with Slack, it's broadly > > similar in purpose. > > Thanks (and to the others who replied). It seems like they've tried to

[Python-Dev] Re: Switching to Discourse

On Fri, 22 Jul 2022 at 03:07, Skip Montanaro wrote: > > I have a perhaps stupid question. Is Discord the same as > discuss.python.org, just by another name? I find the similarity in > names a bit confusing. > No, Discord is a different thing; it does text and voice communication channels in real-

[Python-Dev] Re: [OT] Re: Raw strings ending with a backslash

On Sun, 29 May 2022 at 05:05, MRAB wrote: > > On 2022-05-28 16:03, MRAB wrote: > > On 2022-05-28 13:17, Serhiy Storchaka wrote: > >> 28.05.22 14:57, Damian Shaw пише: > >>> That PR seems to make \' and \" not special in general right? > >>> > >>> I think this is a more limited proposal, to only ch

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

On Wed, 27 Apr 2022 at 16:04, Greg Ewing wrote: > > On 27/04/22 1:26 pm, Chris Angelico wrote: > > On Wed, 27 Apr 2022 at 11:18, Greg Ewing > > wrote: > >> > >> The proposed feature is analogous to forward declaring a > >> struct in C. Would you

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

On Wed, 27 Apr 2022 at 11:18, Greg Ewing wrote: > > On 27/04/22 2:01 am, Chris Angelico wrote: > > That would be the case if monkeypatching were illegal. Since it's not, > > wherein lies the difference? > > The proposed feature is analogous to forward declaring a

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

On Wed, 27 Apr 2022 at 08:06, Greg Ewing wrote: > > On 27/04/22 1:04 am, Joao S. O. Bueno wrote: > > MonkeyPatching in Python is not illegal in this sense. > > I'm not suggesting it is. You're seizing on the wrong part > of the analogy. The point is that what you call something > doesn't change it

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

On Wed, 27 Apr 2022 at 05:05, Larry Hastings wrote: > > > On 4/26/22 09:31, MRAB wrote: >> Perhaps: >> >>class C: ... > > Also, your suggestion is already legal Python syntax; it creates a class with > no attributes. So changing this existing statement to mean something else > would potenti

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

On Tue, 26 Apr 2022 at 22:56, Greg Ewing wrote: > > On 26/04/22 12:33 pm, Chris Angelico wrote: > > That's exactly what I mean though: if the only difference between > > "monkeypatching" and "not monkeypatching" is whether it was intended, > > the

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

On Tue, 26 Apr 2022 at 10:05, Greg Ewing wrote: > > On 23/04/22 5:44 pm, Chris Angelico wrote: > > On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote: > >> > >> Still, it's not the intent of my PEP to condone or facilitate > >> monkeypatching. >

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

On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote: > > > On 4/22/22 22:03, Chris Angelico wrote: > > Anyhow, [a forward-defined class object is] a class, with some special > features (notably that you can't instantiate it). > > Yes. Specifically, here's my in

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

On Sat, 23 Apr 2022 at 12:50, Larry Hastings wrote: > > > On 4/22/22 19:17, Chris Angelico wrote: > > I'm unsure about the forward class. How is it different from subclassing an > ABC? > > They're just different objects. A subclass of an ABC is either its

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

On Sat, 23 Apr 2022 at 11:16, Larry Hastings wrote: > This PEP proposes an additional syntax for declaring a class which splits > this work across two statements: > * The first statement is `forward class`, which declares the class and binds >the class object. > * The second statement is `cont

[Python-Dev] Re: Declarative imports

On Fri, 8 Apr 2022 at 18:29, Malthe wrote: > > This is an idea which has been brought up before, sometimes introduced > as "heresy". But an interesting twist has surfaced now which is > typing. > > But firstly, let me present the idea. It is very simple, that Python > should have declarative impor

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On Fri, 1 Apr 2022 at 19:51, Victor Stinner wrote: > In Python, sadly the types.CodeType type also has a public constructor > and many projects break at each Python release because the API > changes. Hopefully, it seems like the new CodeType.replace() method > added to Python 3.8 mitigated the iss

[Python-Dev] Re: walrus operator and expression

On Tue, 29 Mar 2022 at 09:53, Ethan Furman wrote: > > In the following bit of code: > > > while s := input.read(MAXBINSIZE): > while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)): > s += ns > line = binascii.b2a_base64(s) > output.write(li

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On Tue, 22 Feb 2022 at 03:00, Larry Hastings wrote: > > > On 2/21/22 22:06, Chris Angelico wrote: > > On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote: > > While I don't think it's fine to play devil's advocate, given the choice > between "this

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"

On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote: > > > While I don't think it's fine to play devil's advocate, given the choice > between "this will help a common production use-case" (pre-fork servers) and > "this could hurt a hypothetical production use case" (long-running > applications t

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

On Wed, 9 Feb 2022 at 04:50, Christopher Barker wrote: > So my thoughts: > > Rather than deprecate urllib, we refactor it a bit (and maybe deprecate parts > of it), so that it: > > 1) contains the core building blocks: e.g. urllib.parse with which to build > "better" libraries, > > 2) make the "

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

On Fri, Jan 14, 2022 at 2:12 AM Steven Troxler wrote: > > Using an operator is an interesting idea, and we should probably call it out > as an alternative in the PEP. > It's not a substitute for the current PEP from the standpoint of typing-sig > for a few reasons: > > (A) We care that the synta

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

On Mon, Jan 10, 2022 at 12:05 PM Steven D'Aprano wrote: > > On Mon, Jan 10, 2022 at 05:39:42AM +1100, Chris Angelico wrote: > > > From my understanding, "x->y" would create a Callable if given two > > *types*, but its meaning if given two other objects is st

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

On Mon, Jan 10, 2022 at 3:49 AM Christopher Barker wrote: > > If "x->y" is syntactically valid anywhere in Python code, it's not a > problem that there are no core data types for which it's meaningful.) > > Here's where I'm not so sure -- this looks a lot like a binary operator, but > it behaves

[Python-Dev] Re: About vulnerabilities in Cpython native code

On Sun, Jan 9, 2022 at 7:35 PM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > > Not completely, just very minorly. I'm distinguishing between attacks > > that can be triggered remotely, and those which require the attacker > > to run specific Python

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

On Sun, Jan 9, 2022 at 3:47 PM Steven D'Aprano wrote: > The point I am making here is not that I was a dimwit who couldn't even > read Python, but that "easy to read" and "readable" is more a matter of > familiarity than an inherent property of the language itself. With > enough familiarity, even

[Python-Dev] Re: About vulnerabilities in Cpython native code

On Fri, Jan 7, 2022 at 6:09 PM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > > Python source code is not user input though. So there has to be a way > > for someone to attack a Python-based service, like attacking a web app > > by sending HTTP requests to

[Python-Dev] Re: About vulnerabilities in Cpython native code

On Fri, Jan 7, 2022 at 2:57 PM Stephen J. Turnbull wrote: > > Patrick Reader writes: > > > And Python is not like JavaScript (in the browser), where code is > > supposed to be run in a total sandbox. Python is not supposed to be a > > completely memory-safe language. You can always access memor

[Python-Dev] Re: About vulnerabilities in Cpython native code

On Fri, Jan 7, 2022 at 1:59 AM lxr1210--- via Python-Dev wrote: > > Hi all, > > I am currently doing some research on the security of CPython. I used the > open source vulnerability analysis engine, Infer(https://fbinfer.com/), to > scan the native code of CPython 3.10.0. > > The scan results sh

[Python-Dev] Re: Function Prototypes

On Fri, Dec 24, 2021 at 1:36 PM Steven D'Aprano wrote: > > My question is, why does it need `@Callable`? Lukasz proposed just using > > any (undecorated) function, with the convention being that the body is > > `...` (to which I would add the convention that the function *name* be > > capitalized,

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On Thu, Dec 16, 2021 at 7:03 AM Eric Snow wrote: > > On Wed, Dec 15, 2021 at 12:18 PM Chris Angelico wrote: > > Sorry if this is a dumb question, but would it be possible to solve > > that last point with an immortal arena [1] from which immortal objects > > could be al

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On Thu, Dec 16, 2021 at 6:03 AM Eric Snow wrote: > * using the ref count isn't the only viable approach; another would be > checking the pointer itself >+ put the object in a specific section of static data and compare > the pointer against the bounds >+ this avoids loading the actual obje

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

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 > violates them at runtime. To be specific, is the following considered > as an error? > > >>> def muladd

[Python-Dev] Re: Optimizing literal comparisons and contains

On Mon, Nov 29, 2021 at 10:11 AM Rob Cliffe via Python-Dev wrote: > > I am slightly surprised that it seems to be *easier* to fold selected > constant expressions than to have more generic code to fold them all. > Or at least, all those that don't contain containers, such as > 1 in [0,1,2] T

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Tue, Nov 16, 2021 at 12:13 PM Steven D'Aprano wrote: > > On Mon, Nov 15, 2021 at 10:43:12PM +1100, Chris Angelico wrote: > > > The problems here are not Python's, they are code reviewers', and that > > means they're really attacks against the code revi

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 10:22 PM Abdur-Rahmaan Janhangeer wrote: > > Greetings, > > > > Now what happens? where do you go from there to a vunerability or > backdoor? I think it might be a bit obvious that there is something > funny going on if I see: > > if (user.admin == "root" and check_pass

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

On Sat, Nov 13, 2021 at 3:20 AM Steven D'Aprano wrote: > > On Fri, Nov 12, 2021 at 10:07:13AM -0500, Paul Ganssle wrote: > > > I knew about sortedcontainers and I also don't remember ever seeing a > > situation where I needed one or recommended its use. > > We have a very odd situation where appar

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

On Wed, Nov 10, 2021 at 5:45 PM Steven D'Aprano wrote: > > On Wed, Nov 10, 2021 at 05:11:33PM +1100, Chris Angelico wrote: > > > Nothing's technically new. You could make an inefficient sorted dict like > > this: > > > > class SortedDict(dict): >

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

On Wed, Nov 10, 2021 at 5:03 PM Christopher Barker wrote: > > Maybe a stupid question: > > What are use cases for sorted dicts? > > I don’t think I’ve ever needed one. Me neither, tbh. > Also, I can’t quite tell from the discussion If a “sorted dict” implements > something new, or is an interna

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

On Wed, Nov 10, 2021 at 11:44 AM Ethan Furman wrote: > I don't know if there's a formal name, but in my mind, if you have something > you don't have nothing. If you have a > barrel with nothing in it (not even air, just a hard vacuum) then saying you > have nothing in that barrel is a true > st

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

On Tue, Nov 9, 2021 at 8:38 PM Sebastian Rittau wrote: > > Currently, Python doesn't allow non-default arguments after default > arguments: > > >>> def foo(x=None, y): pass >File "", line 1 > def foo(x=None, y): pass > ^ > SyntaxError: non-default argument follows d

[Python-Dev] Re: PEP 467: Minor bytes and bytearray improvements

On Fri, Nov 5, 2021 at 2:59 AM Jonathan Goble wrote: > > On Thu, Nov 4, 2021 at 10:37 AM Eric Fahlgren wrote: >> >> On Thu, Nov 4, 2021 at 12:01 AM Ethan Furman wrote: >>> >>> >>> bytearray.fromsize(5, fill=b'\x0a') >>> bytearray(b'\x0a\x0a\x0a\x0a\x0a') >> >> >> What happens if you su

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

lowing that would prevent Petr’s examples in which active code is displayed after the comment mark, which to me seems to be one of the more egregious examples. Or maybe this case is no worse than others and isn’t worth singling out. —Chris > > As for \0, can we ban all ASCII & C1 co

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

On Wed, Nov 3, 2021 at 10:22 PM Steven D'Aprano wrote: > > On Wed, Nov 03, 2021 at 11:21:53AM +1100, Chris Angelico wrote: > > > TBH, I'm not entirely sure how valid it is to talk about *security* > > considerations when we're dealing with Python source c

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

On Wed, Nov 3, 2021 at 8:01 PM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > > But I was surprised to find that Python would let you use > > unicode_escape for source code. > > I'm not surprised. Today it's probably not necessary, but I

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

On Wed, Nov 3, 2021 at 5:12 PM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > > Huh. Is that level of generality actually still needed? Can Python > > deprecate all but a small handful of encodings? > > I think that's pointless. With few exceptions

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

On Wed, Nov 3, 2021 at 11:09 AM Steven D'Aprano wrote: > > On Wed, Nov 03, 2021 at 03:03:54AM +1100, Chris Angelico wrote: > > On Wed, Nov 3, 2021 at 1:06 AM Petr Viktorin wrote: > > > Let me know if it's clear in the newest version, with this note: > > >

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

On Wed, Nov 3, 2021 at 5:07 AM David Mertz, Ph.D. wrote: > > This is an amazing document, Petr. Really great work! > > I think I agree with Marc-André that putting it in the actual Python > documentation would give it more visibility than in a PEP. > There are quite a few other PEPs that have si

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

On Wed, Nov 3, 2021 at 1:06 AM Petr Viktorin wrote: > Let me know if it's clear in the newest version, with this note: > > > Here, ``encoding: unicode_escape`` in the initial comment is an encoding > > declaration. The ``unicode_escape`` encoding instructs Python to treat > > ``\u0027`` as a singl

[Python-Dev] Naming convention for AST types

As part of messing with the parser for PEP 671, I've come across what looks like a convention, but I'm not sure of the details. Most AST nodes start with a capital letter: Expr, Name, BoolOp, etc. Some don't: keyword, arg, withitem. Is it true that the ones that don't start with a capital are the

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

On Sun, Oct 24, 2021 at 12:35 AM Marc Mueller wrote: > > > Bear in mind that these last ones are exactly equivalent to the "or" > > operator, as they'll use the default if you have any falsy value. > > variable = some_function(...) or [] > > Isn't that in itself a good argument in favor of (??) ?

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

On Sat, Oct 23, 2021 at 6:20 AM Marc Mueller wrote: > > Most of the discussion so far has been focused on (?.). Tbh though, I'm more > interested in (??) and (??=). Just reading through code, I constantly notice > boilerplate like this which could easily be substituted. > > variable = some_funct

[Python-Dev] Re: Semi-proposal: Tagged None

On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D. wrote: > > On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano wrote: >> >> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote: >> > None and its ilk often conflate too many qualities. For example, is it >> > missing because it doesn't exi

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

On Wed, Oct 20, 2021 at 3:25 AM Baptiste Carvello wrote: > > Le 18/10/2021 à 20:26, Guido van Rossum a écrit : > > > > y = None # Default > > if config is not None: > > handler = config.get("handler") > > if handler is not None: > > parameters = handler.get("parameters") > > if parame

[Python-Dev] Re: What is __int__ still useful for?

On Thu, Oct 14, 2021 at 10:51 AM Victor Stinner wrote: > > Honestly, I don't understand well the difference between __int__() and > __index__(). > > * https://docs.python.org/dev/reference/datamodel.html#object.__int__ > * https://docs.python.org/dev/reference/datamodel.html#object.__index__ __in

[Python-Dev] Re: Python multithreading without the GIL

On Sun, Oct 10, 2021 at 2:31 PM Dan Stromberg wrote: > > > On Thu, Oct 7, 2021 at 9:10 PM Chris Angelico wrote: >> >> Concurrency is *hard*. There's no getting around it, there's no >> sugar-coating it. There are concepts that simply have to be learned, >

[Python-Dev] Re: Python multithreading without the GIL

ng in GIL-enabled mode, that might be an easier intermediate target while still adding value. —Chris But to sweeten the pot he has also applied a bunch of unrelated speedups > that make it faster in general, so that overall it’s always a win. But > presumably we could upstream the latter eas

[Python-Dev] Re: Python multithreading without the GIL

On Fri, Oct 8, 2021 at 1:51 PM Sam Gross wrote: > > Hi, > > I've been working on changes to CPython to allow it to run without the global > interpreter lock. I'd like to share a working proof-of-concept that can run > without the GIL. The proof-of-concept involves substantial changes to CPython

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

On Fri, Oct 8, 2021 at 1:45 PM S Pradeep Kumar wrote: > The Callable type is also usable as an expression, like in type aliases > `IntOperator = (int, int) -> int` and `cast((int) -> int, f)` calls. > > **Question 1**: Are there concerns we should keep in mind about such a syntax > proposal? >

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

On Tue, Sep 28, 2021 at 3:21 AM Eric Snow wrote: > > On Mon, Sep 27, 2021 at 11:09 AM Chris Angelico wrote: > > When exactly does the freezing happen? > > When you build the executable (e.g. "make -j8", > ".\PCbuild\build.bat"). So your changes to thos

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

On Tue, Sep 28, 2021 at 2:58 AM Eric Snow wrote: > > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to default

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

Note: I am all for not enforcing anything here -- let's keep duck typing alive! If static type checkers want to be more pedantic, they can be -- that's kinda what they are for :-) But the OP wrote: """ "[i]terators are required to have an __iter__()

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Wed, Sep 8, 2021 at 10:42 PM Victor Stinner wrote: > > On Wed, Sep 8, 2021 at 7:46 AM Steven D'Aprano wrote: > > >>> bytes.from_int(121404708502361365413651784, 'little') > > # should return b'Hello world' > > Really? I don't know anyone serializing strings as a "bigint" number. > Did

[Python-Dev] Re: Notes on PEP 8

On Fri, Aug 27, 2021 at 3:02 AM Skip Montanaro wrote: >> >> However, it has become a de facto standard for all Python code, and in the >> document itself, there is frequent wording akin to "Identifiers used in the >> standard library must be ASCII compatible ...", and even advice for third >> p

[Python-Dev] Re: Dropping out of this list

On Thu, Aug 19, 2021 at 12:42 PM Jonathan Goble wrote: > > On Wed, Aug 18, 2021 at 10:22 PM Terry Reedy wrote: >> >> On 8/18/2021 9:37 PM, Edwin Zimmerman wrote: >> > On 8/18/21 9:18 PM, Jonathan Goble wrote: >> >> I am mostly a lurker, but I am also considering unsubscribing if someone >> >> do

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

On Mon, Aug 16, 2021 at 5:44 PM Federico Salerno wrote: > > "Pretendere" in Italian means "to demand", it's a false friend with the > English "pretend". I don't know whether Marco is Italian (the false > friend might also be there between Spanish or whatever other romance > language he speaks and

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

On Mon, Aug 16, 2021 at 7:56 AM Marco Sulla wrote: > > On Sun, 15 Aug 2021 at 23:33, Tim Peters > wrote:ople have said now, including me, they had no idea what > > you meant.by "I pretend your immediate excuses". It's not a complaint > > that it's expressed inelegantly, but that they can't make _

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

On Mon, Aug 16, 2021 at 6:36 AM Marco Sulla wrote: > > As Chris implied, the second 'sentence' is not grammatical English > > Oh, this is enough. The sense of the phrase was very clear and you all > have understood it. Remarking grammatical errors is a gross violation &

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

On Mon, Aug 16, 2021 at 12:24 AM Marco Sulla wrote: > > On Thu, 12 Aug 2021 at 12:54, Steven D'Aprano wrote: > > Are you looking for upvotes on StackOverflow > > This is unacceptable. I pretend your immediate excuses. > ? I don't understand this, what do you mean? ChrisA ___

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

On Thu, Aug 12, 2021 at 3:01 AM Larry Hastings wrote: > > On 8/11/21 5:15 AM, Chris Angelico wrote: > > On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: > > This approach shouldn't break reasonable existing code. That said, this > change would be observable fro

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

On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: > Specifically: currently, decorators are called just after the function or > class object is created, before it's bound to a variable. But we could > change it so that we first bind the variable to the initial value, then call > the decor

[Python-Dev] Re: Python3 OSF/1 support?

tems where there is at least a maintainer and build bot, but I'm not sure what, it anything, came from that. Cheers Chris On 14/07/2021 15:44, Senthil Kumaran wrote: On Wed, Jul 14, 2021 at 04:30:33AM +, Jay K wrote: Hi. I have an Alpha/OSF machine up and running. It is little slow, bu

[Python-Dev] Re: Is the Python review process flawed?

On Fri, Jul 2, 2021 at 10:06 AM Eric V. Smith wrote: > > On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote: > > "Merging something is also a responsibility to whoever does it" - And it's > > also a responsibility to fix bugs, no? I don't get why you're so afraid of > > (maybe!) introducing a ne

[Python-Dev] Re: Is the Python review process flawed?

On Wed, Jun 30, 2021 at 2:36 AM wrote: > > I just stumbled upon the following issue and subsequent pull request. It is a > very small bugfix. There is currently a bug in Python and this pull request > fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it > doesn't get revi

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, Jun 4, 2021 at 8:31 AM Guido van Rossum wrote: > > On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote: >> >> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: >> > >> > I think it makes sense, and I do see a difference between Provisional and &

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: > > I think it makes sense, and I do see a difference between Provisional and > Unstable. Is this anything more than a documentation label? > Would it be a pipe dream to hope that static checkers could be taught to recognize them? Not a huge de

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

Might be out of context here, but IMHO "." shouldn't be assumed to be the current directory anyway. As someone who has ported python to a system where it isn't, these assumptions tend to cause problems. Cheers Chris Sent from my iPhone > On 3 Jun 2021, at 09:

[Python-Dev] Re: name for new Enum decorator

the first N bits" as opposed to using the highest occurring bit as the N. That way you can be sure you didn't leave off any flags at the end. --Chris > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email t

[Python-Dev] Re: name for new Enum decorator

check. That would change the kind of name you want, though. Otherwise, some things that occur to me: factorable, factorizable, factorized, decomposable. The thinking here is that each named member should be capable of being decomposed / factored into individual v

[Python-Dev] Re: Question for potential python development contributions on Windows

On Mon, May 24, 2021 at 6:40 PM Łukasz Langa wrote: > > > On 20 May 2021, at 07:03, pjfarl...@earthlink.net wrote: > > The Python Developers Guide specifically states to get VS2017 for developing > or enhancing python on a Windows system. > > Is it still correct to specifically use VS2017 , or is

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

On Fri, May 21, 2021 at 3:51 AM David Mertz wrote: > > On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote: >> >> On Sat, May 15, 2021 at 2:09 AM David Mertz wrote: >> > Just add a ._uuid attribute and have object equality follow equality of >> > that attribute. There's no reason to expose that in

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

On Tue, May 18, 2021 at 8:51 PM Stephen J. Turnbull wrote: > > Steve Holden writes: > > On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano > > wrote: > > > > > Steve > > > (one of the other ones) > > > > > > > We are all other Steves! > > +1 > > There were five Steves (and one Stephanie) in

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

On Sat, May 15, 2021 at 2:04 AM Barry Warsaw wrote: > > On May 14, 2021, at 02:38, Chris Angelico wrote: > > > > Do we ever really need the ability to pass a specific sentinel to a > > function, or are we actually looking for a way to say "and don't pass

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

On Fri, May 14, 2021 at 7:31 PM Petr Viktorin wrote: > Perhaps it would be beneficial to provide a common base class or > factory, so we get a good repr. But I don't think another common value > like None and Ellipsis would do much good. > Agreed - I think Sentinel would make a great class, from

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

ve, open-source > development model. > I was curious what you meant by "is more suitable to a collaborative, open-source development model," but I didn't see it elaborated on in the PEP. If this is indeed a selling point, it might be worth mentioning that and saying why. --Chris &

[Python-Dev] Re: Speeding up CPython

On Thu, May 13, 2021 at 5:37 PM Abdur-Rahmaan Janhangeer wrote: > > Greetings, > > One crucial missing piece in the Python world is the focus > on internals of projects. You have many talks on usage and > scaling but not enough on internals. Even less workshops. > For OpenSource to thrive, you nee

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Fri, May 7, 2021 at 6:39 PM Steven D'Aprano wrote: > On Fri, May 07, 2021 at 06:02:51PM -0700, Chris Jerdonek wrote: > > > To know what compression methods might be effective, I’m wondering if it > > could be useful to see separate histograms of, say, the start column

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

th no compression > whatsoever. > To know what compression methods might be effective, I’m wondering if it could be useful to see separate histograms of, say, the start column number and width over the code base. Or for people that really want to dig in, maybe access to the set of all pairs co

[Python-Dev] Re: stdlib Flag Enums and the "no value" member

On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble wrote: > > On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote: >> >> On 4/29/21 10:35 AM, Jonathan Goble wrote: >> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: >> >> >> >> Which raises the question: Do we want to have a standard name for

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

On Mon, Apr 26, 2021 at 2:27 PM Nathaniel Smith wrote: > Yeah, you've understood correctly, and you see why I wrote "both the > current proposal and the alternative have very complex implications > and downsides" :-) > > [chomp lots of very helpful summarizing] Gotcha, thanks! ChrisA ___

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

On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote: > > > > On Sat, 24 Apr 2021, 10:02 am Skip Montanaro, > wrote: >> >> >>> Practically speaking, one issue I have is how easy it is to write >>> isinstance or issubclass checks. It has historically been much more >>> difficult to write and mai

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote: > > On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote: > > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote: > >> Sure. This was in my list of reasons why the backwards compatibility > >> tradeoffs are forcing us into awkward compr

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

On Fri, Apr 23, 2021 at 11:22 AM Larry Hastings wrote: > > > On 4/20/21 10:03 AM, Mark Shannon wrote: > > If you guarded your code with `isinstance(foo, Sequence)` then I could not > use it with my `Foo` even if my `Foo` quacked like a sequence. I was forced > to use nominal typing; inheriting f

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

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 > based on usage in this function". So if I do: > > def my_fn(f: DuckTyped): > with f: > data =

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

On Thu, Apr 22, 2021 at 5:03 PM Ryan Gonzalez wrote: > > On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote: > > As demonstrated, protocols don't get us there because duck typing isn't a > matter of having an object exhibit all of the attributes of a duck, but > rather some subset of attributes

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

On Wed, Apr 21, 2021 at 3:04 AM Mark Shannon wrote: > Then came type hints. PEP 484 explicitly said that type hints were > optional and would *always* be optional. > > Then came along many typing PEPs that assumed that type hints would only > used for static typing, making static typing a bit less

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

On Wed, Apr 21, 2021 at 1:05 AM Skip Montanaro wrote: >> >> Perhaps there's some history in the python-dev archives that would inform >> you of previous discussions and help you repeating already-considered >> arguments. > > > This topic has come up a few times over the years. Maybe it would be

  1   2   3   4   5   6   7   8   9   10   >