[Python-Dev] Re: Some pattern annoyance

Christian Tismer-Sperling writes: > I thought this list would always stay intact as an alternatice > to the web things. How sad! The list is alive. You got an immediate answer, did you not? It's just that almost all of the people who are engaged with discussion every day have found alternativ

[Python-Dev] Re: PEP 638: Syntactic macros

Stéfane Fermigier writes: > NB: on a very basic level, I remember trying, a few years ago, to use the > Unicode "empty set" symbol as a synonym for set(), and it didn't end well, > for several reasons, including the fact that Python didn't like it as a > variable name. I know about the issue

[Python-Dev] Re: PEP 638: Syntactic macros

cd...@cam.ac.uk writes: > I think that's exactly the problem with a lack of Python > macros. The full quote, of course, goes: "There should be one-- and > preferably only one --*obvious* way to do it." You understand that the Zen is humorous? Most of the Zen, if taken universally and seriousl

[Python-Dev] Re: PEP 638: Syntactic macros

Joshua Herman writes: > I think that this would be better as a library in my opinion. There's a third party package called MacroPy that provides macros, although I haven't heard anything about it in a couple of years. I seem to recall that it's a preprocessor that hooks into the import system.

[Python-Dev] [Suspected Spam]Requesting a review on a PR

Wheeler Law writes: > I opened an issue[1] related to respecting the > `http.client.HTTPConnection.debuglevel` value; I opened a > subsequent PR[2] that fixes the issue back in November and I was > wondering if I could get some feedback on it. I can't help you with that, but this list is now

[Python-Dev] C- Python on Windows

Guenther Sohler writes: Hi, Guenther! > I have successfully used C-Python (3) in a software project in unix and its > great stuff! > The environment was cmake using g++ in Linux Congratulations! > Now when i want to get my project compiled in windows, whats the easiest > development chain

[Python-Dev] Re: Switching to Discourse

Cameron Simpson writes: > I'm presuming we're talking about ways to bidirectionally mirror between > mailman and a Discourse forum. Yes. > None of that is easy to fix - mailing lists essentially just forward > messages, with some gatewaying of what messages they allow inbound > depending

[Python-Dev] Re: Switching to Discourse

Baptiste Carvello writes: > There is a small catch though: unless I'm mistaken, Discourse won't let > you subscribe to just a set of categories, so any filtering has to > happen on the Mailman side. There are two approaches that come to mind. The first is list-per-category, which would most e

[Python-Dev] Re: Switching to Discourse

Ethan Furman writes: > It seems to me the best possible outcome of Discourse vs email is > somebody / some company donating the time and/or funding to improve > Discourse's and Mailman's abilities to interoperate with each > other. There are fundamental differences between email's aysnchronou

[Python-Dev] Re: Switching to Discourse

Barry Warsaw writes: > I absolutely love not having to slog through hundreds of emails > before my first shots of caffeine, and I can now pull from > Discourse or GH when it’s convenient for me. It’s also much easier > to disengage for a few days and catch up later. I absolutely cannot imagin

[Python-Dev] Re: Switching to Discourse

Baptiste Carvello writes: > Le 05/12/2022 à 14:50, Stephen J. Turnbull a écrit : > > > > I'd be sad, but I get the feeling that the only people left > > reading it are "here for the community", not to develop code, … > I think this is indeed true, b

[Python-Dev] Re: Switching to Discourse

Barney Gale writes: > I did; I think it was a mistake to start discourse without a plan for > shutting down this mailing list. "Start"? When it was started it was an experiment. Nobody had a strong take on whether Discourse would really take off or not, or even whether there might be a dual-c

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

Denis Kotov writes: > For example, PyObject is much better to implement using C++ class, > it will bring RAII that will reduce number of issues not free > memory in CPython Well, yes, that's the C++ Kool-Aid we're all supposed to drink. But it has its costs, too. How does it affect performan

[Python-Dev] Re: Switching to Discourse

Terry Reedy writes: > On 7/21/2022 8:46 PM, Christopher Barker wrote: > > Does anyone else find it very odd to call a communication system “discord”? > For games, most of which involve combat, it seems appropriate. For > CPython development, 'harmony' might be better. Already taken by the

[Python-Dev] Re: Switching to Discourse

Cameron Simpson writes: > On 21Jul2022 17:46, Christopher Barker wrote: > >OT: > >Does anyone else find it very odd to call a communication system > >“discord”? > > I think it is a refreshing level of honesty about what live chat is > like. As in "discordant". I would refine "live chat"

[Python-Dev] Re: Switching to Discourse

Cameron Simpson writes: > Discourse does not do `In-Reply-To:` very well at all. Here's some > headers from the _second_ post in the "Core dev sprint this year" > thread: > > Message-ID: > > In-Reply-To: > References: I'm tempted to write something uncivil, but instead

[Python-Dev] Re: Switching to Discourse

Eric Snow writes: > I consider the ability to search message archives to be essential to > effective contribution[.] +1 > There are relevant three aspects to archival and search that are worth > asking about here: > > 1. search functionality on the [archive] web site > 2. ability to sear

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

Paul Ganssle writes: > If you didn't already know what the square brackets did, how would > you try and find out? First I'd look it up in Python Essential Reference (Hi, @dabeaz! it won't be there, though ;-). Then I'd go to the Language Reference for "def" and "class". And if that failed, th

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

Samuel Colvin writes: > Overall, I agree we should be using ISO8601 for exactly this reason (at > least for dates, for datetimes ISO8601 gets pretty wacky > ) I have never had a use for anything but -mm-ddThh:mm:ss (and very occasionally -mm-d

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

Alan G. Isaac writes: > 4. It implements ISO 8601 (which exists for a reason): > https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates Yes!!! "Standardization is my Valentine!" :-D -- RIP WotR Bombshell ___ Python-Dev mailing list -- python-dev@pyt

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

Sasha Kacanski writes: > Why you don't simplify with api A,B,C and forth and then follows > explanation ofr what is stable, unstable, semi... So forth This is exactly what they're hammering out. It's not easy for several reasons, chief of which is that in each case the boundary is a matte

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

Denis Kotov writes: > Yes, C++ ABI is specific to each compiler, but it is not a problem, > because you will anyway recompile CPython for each compiler !! Right, but the point is that we want few C++ compilers people really use to get upset by Python code. Since most changes are backward compa

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

Denis Kotov writes: > From huge codebase experience with C++, it does not cause > significantly better (1) Readabillity or (2) Maintainability on its > own compared to C But that's not what we're talking about. "Port CPython to C++" is a perennial suggestion that gets rejected fairly quickly,

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

MRAB writes: > On 2022-04-29 18:02, Guido van Rossum wrote: > > On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin > > wrote: > > > > On 29. 04. 22 16:32, Victor Stinner wrote: > > > Ok, let me start with the serious business: API name. > > > > > >

[Python-Dev] Re: Using the Python C API in C++

h.vetin...@gmx.com writes: > > > While I don't know who proposed C++11 or where, I'd therefore like > > > to propose to move to _at least_ C++14. > > > > What benefits does this have for Python development? > > Likewise I can ask what benefits choosing C++11 would have? Not for me to answ

[Python-Dev] Re: Using the Python C API in C++

h.vetin...@gmx.com writes: > While I don't know who proposed C++11 or where, I'd therefore like > to propose to move to _at least_ C++14. What benefits does this have for Python development? ___ Python-Dev mailing list -- python-dev@python.org To uns

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

Larry Hastings writes: > On 4/22/22 19:36, Terry Reedy wrote: > > How about a 'regular' class statement with a special marker of some > > sort.  Example: 'body=None'. > > It's plausible.  I take it "body=None" would mean the declaration would > not be permitted to have a colon and a class

[Python-Dev] Re: About PEPs being discussed on Discourse

Brett Cannon writes: > On Thu, Apr 7, 2022 at 7:33 PM Stephen J. Turnbull < > stephenjturnb...@gmail.com> wrote: > > The specific mention of "community moderation" and "thread management" > > makes me suspect that part of that effect is due to inc

[Python-Dev] Re: About PEPs being discussed on Discourse

Gregory P. Smith writes: > We feel it too. We've been finding Discourse more useful from a community > moderation and thread management point of view as well as offering markdown > text and code rendering. Ideal for PEP discussions. The specific mention of "community moderation" and "thread ma

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

Barry Warsaw writes: > While I don’t underestimate the work and complexity, we can do > both. I.e. separate the stdlib development cycle from the > interpreter (for all but a handful of required packages perhaps). > We could still distribute “sumo” releases which include all the > batteries,

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

Steven D'Aprano writes: > Or maybe, as a developer (not an end-user of an app), you could be more > proactive in reporting those warnings to the third party, and > encouraging them to fix them. Maybe even submitting a patch? As Chris B points out, it's quite possible that (generic) you have

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

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 code. For example, using ctypes OK. AFAICT that was a red herring introduced to the thread solely to s

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

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 it. Not sure what your point is. Of course there has to be a vector. But as a Mailman develope

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

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 memory manually > using `ctypes`, or, ultimately, `/proc/self/mem`. Tr

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

Steven D'Aprano writes: > I don't think that's what PEP 563 says. Annotations are not > *restricted* to only be strings, it is merely that when the > function or class object is built, the annotations are left as > strings. You're right, I was imprecise. I meant as PEP 563 is implemented now

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

Executive summary: The typing-suspicious crowd has a valid complaint about PEPs 563 and 649, but it's not that they weren't warned. Christopher Barker writes: > Annotations can be, and are, used for other things than "typing". I > just noticed that PEP 563 apparently deprecated those other use

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

Executive summary: I guess the bottom line is that I'm sympathetic to both the NFC and NFKC positions. I think that wetware is such that people will go to the trouble of picking out a letter-like symbol from a palette rarely, and in my environment that's not going to happen at all because I use J

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

Abdur-Rahmaan Janhangeer writes: > As a programmer, i don't want a language which bans unicode stuffs. But that's what Unicode says should be done (see below). > If there's something that should be fixed, it's the unicode standard, Unicode is not going to get "fixed". Most features are impor

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

Christopher Barker writes: > Would a proposal to switch the normalization to NFC only have any hope of > being accepted? Hope, yes. Counting you, it's been proposed twice. :-) I don't know whether it would get through. We know this won't affect the stdlib, since that's restricted to ASCII.

[Python-Dev] Re: Do we need to remove everything that's deprecated?

Christopher Barker writes: > On Sun, Nov 14, 2021 at 8:19 AM Stephen J. Turnbull < > stephenjturnb...@gmail.com> wrote: > > > > But do > > > we need to support running the same code on 3.5 to 3.10? > > > > Need? No. Want to not raise a big m

[Python-Dev] Re: Do we need to remove everything that's deprecated?

Christopher Barker writes: > On Sat, Nov 13, 2021 at 12:01 AM Stephen J. Turnbull > > > What I think would make a difference is a six-like tool for making > > "easy changes" like substituting aliases and maybe marking other stuff > > that requires huma

[Python-Dev] Re: Do we need to remove everything that's deprecated?

Victor Stinner writes: > In Python, usually, there is a better alternative. As in life. > Do you have to repeat "You should check for DeprecationWarning in > your code" in every "What's New in Python X.Y?" document? That probably doesn't hurt, but I doubt it does much good for anybody except

[Python-Dev] Ignore my previous post Re: containment and the empty container

Aargh. The whole point of Cameron's post was about implementing "in", and all of it makes sense now. Sorry. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailma

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

Cameron Simpson writes: > On 08Nov2021 23:32, MRAB wrote: > >A flag could be a member, but could a set of flags? > > Probably one flavour should raise a TypeError then with this comparison. > I wouldn't want "member flag present in SomeFlag.something" and > "set-of-members present in So

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

Tim Peters writes: > [Ethan Furman ] > > .. on the other hand, it seems that collections of related flags > > are often treated as in set theory, where the empty set is a > > member of any non-empty set. > > Not how any set theory I've ever seen works: a set S contains the > empty set if a

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

Chris Angelico writes: > Ah, okay, so much for that, then. What about the weaker sense: > Characters below 128 are always and only represented by those byte > values? So if you find byte value 39, it might not actually be an > apostrophe, but if you're looking for an apostrophe, you know for s

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

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've exchanged a lot of code (not Python, though) with folks whose editors were limited to 8 bit codes or even just ASC

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

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 (GB18030, Big5 has a couple of code point pairs that encode the same very rare characters, ISO 2022 extens

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

Jim J. Jewett writes: > At the time, we considered it, and we also considered a narrower > restriction on using multiple scripts in the same identifier, or at > least the same identifier portion (so it was OK if separated by > _). This would ban "παν語", aka "pango". That's arguably a good id

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

Serhiy Storchaka writes: > All control characters except CR, LF, TAB and FF are banned outside > comments and string literals. I think it is worth to ban them in > comments and string literals too. +1 > > For homoglyphs/confusables, should there be a SyntaxWarning when an > > identifier loo

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

Serhiy Storchaka writes: > This is excellent! > > 01.11.21 14:17, Petr Viktorin пише: > >> CPython treats the control character NUL (``\0``) as end of input, > >> but many editors simply skip it, possibly showing code that Python > >> will not > >> run as a regular part of a file. > > It

[Python-Dev] raising a io exception when fileno is requested on a tarfile FileInFile

makap...@gmail.com writes: > When you call extractfile() on a TarFile, the result is a buffered > version of a _FileInFile pseudo-file. When fileno() is called on > this resulting file, fileno() it not exist (understandably) and an > AttributeError is raised. I would like to suggest raising

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

Marc Mueller writes: > True, but from my experience 'None' is just by far the most common > default. Why not improve how we handle it? The question is whether this is an improvement in the long run. When some falsies are expected, in-range values, "if arg is None: ..." or "x = default if arg i

[Python-Dev] Worried about Python release schedule and lack of stable C-API

jack.jan...@cwi.nl writes: > I’m getting increasingly worried about the future of Python, You mean about the fact that Python has a plethora (rapidly growing!) of powerful, efficient extension packages and you want to use them all (perhaps recursively)? :-) I really don't think this bodes ill

[Python-Dev] Re: f-strings in the grammar

Guido van Rossum writes: > I don't know about the line breaks, but in recent weeks I've found myself > more than once having to remind myself that inside interpolations, you must > use the other type of quote. My earlier remarks were specifically directed to line breaks. I see the point, but

[Python-Dev] Re: f-strings in the grammar

Eric V. Smith writes: > >> But this does not: > >> > >> f'{1 + > >> 2}' > > > > The later is an error with or without the 'f' prefix and I think that > > this should continue to be the case. > > > The thought is that anything that's within braces {} and is a valid > expression should b

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

Ethan Furman writes: > `int.from_bytes` methods, and is an appropriate name for the target > domain (where bytes are treated as characters). The relevant domains treat bytes as bytes. It's frequently useful (and dare I say "Pythonic"?) for *programmers* to take advantage of the mnemonic of tre

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

Marc-Andre Lemburg writes: > On 26.08.2021 06:07, Christopher Barker wrote: > > But now a question -- the current text reads: > > > > "Code in the core Python distribution should always use UTF-8" > > "The following policy is prescribed for the standard library > > ... In addition, string

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

Christopher Barker writes: > PR here: Thanks for your prompt efforts! The notes toward a "near future" agenda are above and beyond. > Interesting some of the cruft in there e.g. still referring to "new style > classes" :-) I think that should also come out "now", but that's a +1 to the ide

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

Terry Reedy writes: > We could add (perhaps at the end of the first paragraph) something like > "(Since the 2.x stdlib is frozen, all 2.x-specific guidelines were > removed in Sept 2021.)" Anyone interested could then check git log for > the last commit before then. How about including th

[Python-Dev] Dropping out of this list

In re: Requests for Censorship :-( Luciano Ramalho writes: > Instead of going silently, I wanted to call on the adult supervision > to do something about the adult. I'm sympathetic, because I value your participation in this list. But I'm also sympathetic to the moderators, because usually th

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

Antoine Pitrou writes: > In what context is `bchr()` useful? As a builtin, not my problem, I'm not the proponent. As a facility with *some* spelling, it's convenient in contexts where chr() is, but much less so (eg, coding ROT13 ;-). I know I've used this translation in mail hacking, but I don

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

Christopher Barker writes: > A byte is not a character While I am -0.5 on bchr for many of the reasons already cited in the thread (and would be -1 if the methods names proposed for the feature were a bit more aesthetic), I don't think this argument is valid. Bytes that could otherwise be arbitr

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

Irit Katriel via Python-Dev writes: > Andrei is suggesting to look at each enum value as the set of "bits set to > 1" in this value, and then apply a set-thoery term to the problem. > [...] Anyway, I don't know whether this kind of terminology is > widely accessible. I think the everyday mea

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

Christopher Barker writes: > I find this whole conversation confusing -- does anyone really think a > substantial performance boost to cPython is not a "good thing"? > [PyPy, Numba, Cython] are why Python is very useful today -- but > none of them make the case that making cPython run faster

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

Oscar Benjamin writes: > The break even point where both implementations take equal time is > around about 5% density. What that means is that for a 1000 x 1000 > matrix with 10% of elements nonzero it is faster to ask flint to > construct an enormous dense matrix and perform a huge number of

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

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 my 6th grade class (of 27). "Steve, move that " became an idiom -- Other Ste

[Python-Dev] Re: Speeding up CPython

Abdur-Rahmaan Janhangeer writes: > That's why i guess what i am proposing might seem simple I'm saying that we already have the simple version, spelled git clone; git checkout main~5000 then git log -U0 main~5000..main | grep -v '^[-+ ]' which provides very nice hints for the diligen

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

Mark Shannon writes: > On 13/05/2021 5:32 am, Terry Reedy wrote: > > The claim that starts the Motivation section, "Python is widely > > acknowledged as slow.", has multiple problems. > How would you rephrase it, bearing in mind that needs to be short? We can make CPython run significan

[Python-Dev] Re: Speeding up CPython

Abdur-Rahmaan Janhangeer writes: > No i mean fake path in the sense of a fork > of CPython with issues for learning purposes *Creating* plausible issues is hard work, I assure you as a university professor. Coming up with "exercises" that are not makework requires expertise in both the domain

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

Paul Moore writes: > What you're missing, I think, is that we're talking about > typing.Protocol - see here: > https://docs.python.org/3/library/typing.html#typing.Protocol I understand that we're talking about typing. What I don't understand is how any general facility provided in a standard

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

Chris Angelico writes: > On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote: > > Duck typing usually falls squarely into the EAFP category. > > Isn't it orthogonal? Not really. If you ask 'thing' to 'thing[0]', you don't find out whether it is a list or a dict (or any number of other thin

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

Luciano Ramalho writes: > A HUGE insight I learned studying Go is that Protocols should be > defined near the code that CONSUMES it, and not near the code that > PROVIDES it. That's exactly the opposite of how we use ABCs, or > Java folks use interfaces (most of the time). I don't see how tha

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

Denis, There's a standard way of interesting the Python community in new syntax (and C++, while not Python, is new syntax in spades to this community ;-). You take a hunk of the standard library (in this case it would have to be an accelerator written in C since you want to compare C++ vs. C) or

[Python-Dev] Re: Typing syntax and ecosystem, take 2

Hugh Fisher writes: > There are a lot of programmers like me. Those languages I listed > are widely used, and therefore we assume that if a Python language > construct looks like something we've used before, it will work in > the same way. That's not very persuasive. When in London, England,

[Python-Dev] Typing syntax and ecosystem, take 2

Hugh Fisher writes: > In any Python 3.6 or later, type > > >>> x : float = 1 > >>> isinstance(x, float) > >>> type(x) [snip] > As someone who has programmed in FORTRAN, Pascal, C/C++, > Java, and Go this is not at all what I consider reasonable. >From the point of view of typi

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

Paul Moore writes: > I'm OK with these terms (although I don't actually think you *will* > get sufficient consensus on them to make them unambiguous) > once the implementation is merged into the CPython source, I think > it should simply be referred to as "the implementation" and > qualifi

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

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 happen, and you can try it out here" > > Maybe "prototype implementat

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

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", they're merely "accessible to the public". (I'm happy to adopt your terminology when you're in the conversation, I'm

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

Matthias Klose writes: > No, you can't see that with CPython's CI alone. The Debian and > Ubuntu build machines trigger CI tests per architecture for around > 3000 packages depending on python3.9, using the just built > python3.9, and without rebuilding these packages. That's where I > see

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

Matthias Klose writes: > Looking at the failing CI tests triggered by these builds, yes I > see that 32bit archs have the ABI change. I'm not sure precisely what you mean by that, but if you mean that CI has caught the bug, then > So maybe it's worth to re-introduce these RC builds, seems to

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

Mark Shannon writes: > Calling something a "reference" implementation suggests that it is > something that people can refer to, that is near perfectly correct and > fills in the gaps in the specification. Shoe fits, doesn't it? Both Guido and Brandt to my recall have specifically considered

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

Antoine Pitrou writes: > On Sun, 04 Apr 2021 00:34:18 - > "Brandt Bucher" wrote: > > Can you please stop putting scare quotes > I'm not a native English speaker, but I don't understand how > putting quotes around a reasonably polite expression devalues > anyone's work. "Scare quotes"

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

Paul Moore writes: > The one thing that *is* substantially worse for Python, is the > circumlocutions needed in the documentation to say how to run Python. > But that's 100% down to us not being willing to say "just type the > command python". And the reason for *that* is mostly historical, >

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

Jim J. Jewett writes: > > which file am I actually running? > > which interpreter am I actually running? > > how do I tell the computer to use a different interpreter? > > If you need to care about any of these, then the environment is > fighting you -- and the application probably stinks.

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

Executive summary: This thread is about a "seven blind men and an elephant" problem. Jim J. Jewett writes: > 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 useful, but t

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

Steven D'Aprano writes: > On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote: > > That's what I would mean by basic sys-admin skills. And *surprise!* > > my students don't have them, and don't need them ... until they start > > using

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

Mike Miller writes: > "sys-admin" is a bit of an overstatement in my phrasing. The core > is that you need to understand how a PATH works and be able to run > pip and cd into folders and perhaps run rm/del, etc. Basic > command-line skills? That's what I would mean by basic sys-admin skills

[Python-Dev] Re: Security releases of CPython

Mike Miller writes: > Sounds like automating until it is "just a push of a button," > should be a goal. According to Victor there has been progress, but > always room for more. When XEmacs was releasing betas regularly, everything from tagging the local authoritative repo to pushing to the pub

[Python-Dev] Re: Python standardization

Paul Sokolovsky writes: > Hello, > > On Sat, 13 Feb 2021 23:10:59 +0900 > "Stephen J. Turnbull" wrote: > > > Chris Angelico writes: > > > > > Can you explain what would be improved by having a formalized > > > standard? >

[Python-Dev] Re: Python standardization

Chris Angelico writes: > Can you explain what would be improved by having a formalized > standard? The Language Reference together with the Library Reference *already* constitute a formalized standard. They are at least as precise as most W3C or IETF standards. What you and Dan seem to be ref

[Python-Dev] Enum bug?

Paul Bryan via Python-Dev writes: > Should this be considered a bug in the Enum implementation? Probably not. The underlying implementation of Enums is integers, and False and True *are* the integers 0 and 1 for most purposes. And it propagates further. Same example: >>> class Foo(enum.Enum)

[Python-Dev] minor PR 22981 waiting review ~20 days: https://github.com/python/cpython/pull/22981

Alfred Perlstein writes: > PR 22981 is a minor update to doctest to allow it to safely consume > modules which contain objects that cause inspect.unwrap to throw. > > I believe the review comments in the PR have been addressed at this > point for ~20 days.  The patch is relatively small, r

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Paul Sokolovsky writes: > Sorry, but there may be a suggestion of tactics of sneaking somebody's > "pet feature" past the attention of core developers by employing > sycophant techniques. I've had enough of your random aspersions. They make it impossible for me to continue reading your posts.

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Paul Sokolovsky writes: > Also to clarify, [cowboy attitude] referred to difference in > approaches in response to particular issue(s) raised. One thing is > to say "it's hard to implement it better with the limited VM > infrastructure and resources we have" (that of course leads to > further

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Paul Sokolovsky writes: > Well, I'd call that "cowboy attitude in programming language > design" ;-). That was uncalled for, especially since you're selling an idea without an implementation yourself. > We'd certainly make it blend well with the rest of Python. But how long will that take?

[Python-Dev] Re: Ideas for improving the contribution experience

> My suggestion: create the developers by creating group(s) of > mentors Do you know about https://mail.python.org/mailman3/lists/core-mentorship.python.org/ and if you do, why isn't that what you suggest? ___ Python-Dev mailing list -- python-dev@

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Glenn Linderman writes: > Mathematics never came up with separate symbols for equality and > assignment. Mathematics doesn't need them, until we come to an age where we do mathematics on algorithms. It's perfectly possible to do algebra interpreting "let x = 3" as an equation of the form "f(x)

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Jim J. Jewett writes: > What advantage can there be in re-using syntax to mean something > opposite to what it normally does? In math, it allows us to write "solve c = f(x) for x". That doesn't mean "bind c to the value f(x)", it means exactly the opposite. No problem here, I suppose. So

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

Ned Batchelder writes: > I feel like we are missing a key element of Riccardo's point: > "without editorial guidance."   Changes are being made without > first having an agreement about what the tutorial should be. That's really unfortunate. But there also ought to be an editorial activity, s

  1   2   3   4   5   6   7   8   9   10   >