[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: 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: 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: 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: > 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: 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: 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] 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: 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] 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?

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: 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: 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)

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: 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: 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: 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: 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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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: [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: 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: 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: 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

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

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: 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

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: 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

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

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

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

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] 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] [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] 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] 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

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: 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: What to do about invalid escape sequences

Steve Holden writes: > This whole thread would be an excellent justification for following 3.9 > with 4.0. It's as near as we ever want to get to a breaking change, and a > major version number would indicate the need to review. If increasing > strictness of escape code interpretation in strin

[Python-Dev] May God bless and keep Python 2 ... far away from us!

Paul Moore writes: > On Wed, 18 Sep 2019 at 18:52, Chris Barker via Python-Dev > wrote: > > it would be good to be clear what EXACTLY "support stops" means. It means patches and PRs submitted after that date will almost certainly be dropped on the floor (and definitely will be after Benjamin t

[Python-Dev] Re: May God bless and keep Python 2 ... far away from us!

Paul Moore writes: > What I was trying to say was more that I'm not quite sure where > people asking the question are coming from - they are clearly > worried about the impact there might be on them when support > stops. Sure. I don't really understand why people are putting so much effort i

[Python-Dev] Re: Deprecating the "u" string literal prefix

Steve Holden writes: > In which case, wouldn't "_" make a better literal prefix than "i"? There's no reason to suppose that "i" would be drop-in compatible for GNU gettext (for example, gettext purely deals with the message catalog lookup, while i-strings might be able to deal with currency form

[Python-Dev] Re: Should set objects maintain insertion order too?

David Mertz writes: > Even though I was the first person in this thread to suggest > collections.OrderedSet, I'm "meh" about it now. As I read more and played > with the sortedcollections package, it seemed to me that while I might want > a set that iterated in a determinate and meaningful ord

[Python-Dev] Question: how to extend standard Python library to add new functionalities?

Daniel, Your question seems to be a request for help in writing the extension. This list is for discussion and improvement of proposed implementations. For help in writing the code, the python-corementorship list is a better venue. If your question is for help in designing the extension, and de

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

Dima Tisnek writes: > I thought that collections compatibility was kept up to 3.8 > specifically because py2 was alive. > No that that requirement is gone, so should the shim, right? Python 2 is still very much alive (even in a Python 3 venv :-þ): (analysis.venv) 01 16:56$ /usr/bin/python

[Python-Dev] Review status policy [was: PEP 585: Type Hinting Generics ...]

Guido van Rossum writes: > This now happened. Maybe you can just submit it to the SC for > review? Or did that already happen? (I no longer have any insight > into the SC's queue.) Shouldn't the fact that it's been submitted be public? As a status value in the header material of the PEP itsel

[Python-Dev] Re: Proliferation of tstate arguments.

Victor Stinner writes: > Le jeu. 19 mars 2020 à 02:17, Kyle Stanley a écrit : > > Agreed; a PEP (even if it's just informational) would go a long way in > > helping to clear up some misunderstandings. > > I am still moving blindly in the darkness of CPython internals and so > I don't feel

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

Ivan Pozdeev via Python-Dev writes: > > On 22.03.2020 7:46, Steven D'Aprano wrote: > > On Sun, Mar 22, 2020 at 06:57:52AM +0300, Ivan Pozdeev via Python-Dev > > wrote: > > > >> Does it need to be separate methods? > > Yes. > > > > Overloading a single method to do two dissimilar things i

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

Cameron Simpson writes: > As a diversion, _are_ there use cases where an empty affix is useful or > reasonable or likely? In the "raise on failure" design, "aba".cutsuffix('.doc') raises, "aba".cutsuffix('.doc', '') returns "aba". BTW, since I'm here, thanks for your discussion of context

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

Walter Dörwald writes: > A `find()` that supports multiple search strings (and returns the > leftmost position where a search string can be found) is a great help in > implementing some kind of tokenizer: In other words, you want the equivalent of Emacs's "(search-forward (regexp-opt list-of

[Python-Dev] reversed enumerate

Ilya Kamenshchikov writes: > I needed reversed(enumerate(x: list)) in my code, def reversed_enumerated_list(l): return zip(reversed(range(len(l)), reversed(l)) > and have discovered that it wound't work. I wouldn't have expected it to, because enumerate's result is unbounded. But I'm def

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

Brandt Bucher writes: > Still agreed. But I think they would be *better* served by the > proposed keyword argument. > > This whole sub-thread of discussion has left me very confused. Was > anything unclear in the PEP's phrasing here? I thought it was quite clear. Those of us who disagree s

[Python-Dev] Voting conventions [was: PEP 618: Add Optional Length-Checking To zip]

These negative votes surprise me. Given that it's clear that a generic strict-mode zip is non-trivial to write, and that there is significant demand for it, are people saying "+0 Python would not be a better programming environment if itertools.zip_strict() were adopted," and "-1 Python would be a

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

Gregory P. Smith writes: > Agreed. The best way to reduce accidental incorrect use of the > builtin is to make the builtin capable of doing what a people want > directly without having to go discover something in a module > somewhere. Executive summary: My argument (and one of Steven d'Apra

[Python-Dev] [Spam] Re: Accepting PEP 618: zip(strict=True)

Serhiy Storchaka writes: > Of course the ship is already sailed, but I was surprised that the > keyword variant won, while it was not popular initially. It was very popular with the proponent, however. Steve ___ Python-Dev mailing list -- python-dev

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Ethan Furman writes: > _ does not bind to anything, but of what practical importance is that? *sigh* English speakers ... mutter ... mutter ... *long sigh* It's absolutely essential to the use of the identifier "_", otherwise the I18N community would riot in the streets of Pittsburgh. Not good

[Python-Dev] Re: The Anti-PEP

Brett Cannon writes: > I agree, and that's what the Rejected Ideas section is supposed to > capture. Perhaps there could be guidance, in documentation (and if appropriate from the PEP-Delegate or the Steering Council), that the PEP proponent collaborate with a leading opponent, critic, and/or u

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Richard Damon writes: > I thought _ was also commonly used as: > > first, -, last = (1, 2, 3) > > as a generic don't care about assignment. It is. But there are other options (eg, 'ignored') if '_' is used for translation in the same scope. > I guess since the above will create a local,

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Richard Damon writes: > I wasn't imply local to the match statement, but if the match is used > inside a function, where using the binding operatior = will create a > local name, even if there is a corresponding global name that matches > (unless you use the global statement), will a match sta

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Daniel. writes: > IMHO, the most obvious solution is that the bind should be available only > inside case block and if you need to change a global or a nonlocal you do > this explicitly inside the case block, Do you mean case x: x = x ? > if this is the case you can pickup a bi

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

To bring this thread back to encouraging diversity, I must point out that diverse English dialects are not all there is to diversity, folks. Nathaniel Smith writes: > In particular, it emphasizes that the new text is accomplishing > "the same goal", "maintaining the original intent", That disp

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Rhodri James writes: > That's the clearest explanation of why "_" needs to be treated > carefully, but I don't think it argues for the PEP's special treatment. That depends on whether you care about taking advantage of the convention that "_" is a dummy. In fact, _ = gettext partakes of that

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

@Inada-sama: For RFC conformance to S&W, see footnote [3] at the end. MRAB writes: > If you believe you have something important to say, then at least > say it clearly. Indeed -- that commit log is an example of the kind of writing the reference to Strunk & White was intended to reduce; repeti

[Python-Dev] [Suspected Spam]Re: Recent PEP-8 change

MRAB writes: > It's also like saying that you shouldn't split infinitives Amusingly, Strunk (1918) was perfectly happy with split infinitives, though he noted it centered whiteness. (Obviously he didn't put it that way, more along the lines of "some people will look down on you.") In general,

[Python-Dev] Re: Recent PEP-8 change

Greg Ewing writes: > On 4/07/20 4:33 am, Jim J. Jewett wrote: > > If Bob and Alice seem neutral to you, would you do a double-take > > on Kehinde or Oladotun? > > Maybe we should use randomly generated names for hypothetical > persons? Randomly generated according to what character repertoi

[Python-Dev] [Suspected Spam]Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

MRAB writes: > On 2020-07-04 16:23, Stephen J. Turnbull wrote: > > 3. Write in a comfortable dialect. (Exceptions: legalese and > > The Academic Register are strictly forbidden, even if you're > > native in one of those. :-) > I'd also add: Tr

[Python-Dev] Re: [Suspected Spam]Re: Recent PEP-8 change

Emily Bowman writes: > Whatever he meant, nothing about split infinitives is in my 1918 > original copy of Strunk's rules, I'm not sure what you mean by "copy of rules", but it's mentioned couple of times in the book. I'm referring to this passage, from http://www.gutenberg.org/files/37134/371

[Python-Dev] [OT] Speaking of the recent PEP-8 change

Greg Ewing writes: > On 5/07/20 3:24 am, Stephen J. Turnbull wrote: > > Amusingly, Strunk (1918) was perfectly happy with split > > infinitives, though he noted it centered whiteness. (Obviously > > he didn't put it that way, more along the lines of "some pe

[Python-Dev] Re: [OT] Speaking of the recent PEP-8 change

David Mertz writes: > On Sun, Jul 5, 2020 at 2:37 PM Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > > > Are you saying that people who split infinitives are usually > > > black, > > > > Of course not. Base rates sugg

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Guido van Rossum writes: > [several reasons why not binding _ is a no-op, and] > A note about i18n: [...]. So can we please lay this one to rest? Yes, please! I was just about to ask about that. I could not believe that in July 2020 people were ignoring I18N, especially the fact that I18N w

[Python-Dev] Re: Procedure for trivial PRs

Jeff Allen writes: > It will seem odd that I should know or care about this, not having > any relevant rights over CPython, but I'm trying to adopt it in the > projects where I do. But you do have a relevant right: to state your opinion about the governance of the project, both the values and

[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)

Steven D'Aprano writes: > Oh, I'm sorry, I based my comment on Chris' comment that Mark was > repeating everyone else's arguments. My bad :-( Mark can be tendentious. Some of his arguments in the main gist were also made by others, but mostly they do seem to be reiterations of his own pet pee

[Python-Dev] Installation issue on Python-3.5.9 ...

Saikat Das via Python-Dev writes: > Hello Team,  > While installing Python-3.5.9 in CentOS-5 I am getting the below > errors: Not our problem (details below). You should get help from someone with experience in building large programs. Best if they are local looking at your console. If you'v

[Python-Dev] Re: Enum and the Standard Library

Ethan Furman writes: > I counted roughly 25 Enums in the stdlib at this point, and only two of > them have modified reprs or strs; and one of those is an internal class. > It's worth noting that two others are buggy -- one is being fancy with > values and didn't get the custom __new__ cor

[Python-Dev] The Python documentation is now compatible with Sphinx 3.2 and newer

Victor Stinner writes: > I discussed with the Sphinx maintainers. They accepted to add two new > options to Sphinx 3.2 to add an opt-in Sphinx 2 compatibility mode: Wow, this is really going the extra mile! Great work, Victor! ___ Python-Dev mailing

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

Ivan Pozdeev via Python-Dev writes: > Possessive and obstructive behavior like Victor describes below is > incompatible with the bazaar model of development (=a model where > the dev team accepts contributions from a wide range of people). True, but Python *modules* have frequently followed a

Re: [Python-Dev] Tracker archeology

Brett Cannon writes: > Sounds like a "*verify issue* stage is needed. Although I guess I kind of > assumed as part of the triage issue verification would happen as well, but > that might be too much as a single step. Are you confusing "reproduce" with "verify"? Remember, one of the three clas

[Python-Dev] OS X Installer for 3.0.1 and supported versions

Ned Deily writes: > I see three plausible options: > > 1. Release an installer built for 10.5 and higher. >pros: delivers 32-support and 64-support; >cons: prematurely disenfranchises 10.4 users +0 This would bother me; I have a couple of older Macs that run 10.4. But it's acceptabl

Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions

Guido van Rossum writes: > Actually I expect that to be fairly common among people who are not so > much into technology, strapped for funds but appreciative of quality, > bought an expensive Mac once expecting it would last a long time, and > are hanging on to it until it dies (which could be

Re: [Python-Dev] Issues to be closed: objections?

Daniel (ajax) Diniz writes: > M.-A. Lemburg wrote: > >> http://bugs.python.org/issue1231081 platform.processor() could be smarter > > Thanks, Marc-Andre! > > If anyone else feels like closing some of these issues, go ahead (no > need to report back, I'll find it out later). My rather burea

[Python-Dev] A suggestion: Do proto-PEPs in Google Docs

[Aside to Guido: Oops, I think I accidentally sent you a contentless reply. Sorry!] As a suggestion, I think this is relevant to everybody who might be writing a PEP, so I'm cross-posting to Python-Dev. Probably no discussion is needed, but Reply-To is set to Python-Ideas. On Python-Ideas, Guid

Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs

Summary: Google Docs is easy to use, featureful, and here now. Since AIUI the PEPs eventually need to be hosted at python.org, I see Google Docs as an immediate replacement for email transmission of early drafts of PEPs, not as a permanent solution to PEP storage. William Dode writes: > Isn't

Re: [Python-Dev] Attention Bazaar mirror users

David Cournapeau writes: > On Sat, Feb 21, 2009 at 6:21 AM, Barry Warsaw wrote: > > In both those cases, you can use the PPA: > Please note that for many people in a corporate/university > environment, this is not an option. Granted, you can install it by > yourself at this point, Er, what

Re: [Python-Dev] Attention Bazaar mirror users

David Cournapeau writes: > > Er, what are people without access to PPAs doing building Python from > > a VCS checkout? > > I don't see the link between access to PPA and building Python from > sources. I didn't say "from source", I said "from a VCS checkout". If using a *specific* recent o

Re: [Python-Dev] Attention Bazaar mirror users

"Martin v. Löwis" writes: > sjt sez: > > I didn't say "from source", I said "from a VCS checkout". If using a > > *specific* recent official release of a core tool is bureaucratically > > infeasible, it would IMO be very unusual if you're allowed to checkout > > and build arbitrary versions

Re: [Python-Dev] Attention Bazaar mirror users

"Martin v. Löwis" writes: > so ignoring the primary target group of the setup when discussing > changes to is is, well, counter-productive. I'm *not* ignoring them; I'm stating a strong belief that the great majority of them will not be adversely affected by this change. Since almost by defini

Re: [Python-Dev] draft 3.1 release schedule

"Martin v. Löwis" writes: > >From time to time, people ask what they can do push a change into Python > that they really think is important. I once offered that people who > want a patch in Python really badly should review 10 other patches in > return, up to the point where they make a recomm

Re: [Python-Dev] draft 3.1 release schedule

Tennessee Leeuwenburg writes: > > I hope that somebody will pick up the slack here, because review is > > really important to the workflow, and getting more people involved in > > reviewing at some level is more important (because it's less > > glamorous in itself) than attracting coders. >

<    2   3   4   5   6   7   8   9   10   11   >