[Python-Dev] Re: Small lament...

Oh, man, it has been a while. The last one I remember is PEP 404 (if you can find it :) ), dated 2011 and it wasn't an April Fool's... On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro wrote: > Just wanted to throw this out there... I lament the loss of waking up on > April 1st to see a creative

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

On Wed, Dec 1, 2021 at 10:50 PM Christopher Barker wrote: > I know this isn't really the place for this conversation, but: > > >> which is what `os.PathLike` represents, hence why `str` isn't covered by >> it); >> > > wait, what? It seems so clear to me that "PathLike" (as a type specifier) >

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

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 supply more than one byte for the fill argument? Silent truncation, raise ValueError('too long') or ???

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I don't like the .name syntax (grit on Tim's monitor; does not >> suggest the meaning). [...] But I don't know what syntax (where >> necessary) to suggest. > > https://photos.app.goo.gl/xN68s3QMMBTPTLD47

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

On Thu, Jun 18, 2020 at 8:06 AM Serhiy Storchaka wrote: > It would be easier if add a new function instead of a new keyword > argument to the existing function. > We've implemented the new zip in our sitecustomize.py, and think the keyword makes it easier. I've instructed our development staff

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On Mon, Apr 13, 2020 at 9:00 AM Steve Dower wrote: > On 13Apr2020 1325, Paul Moore wrote: > > Personally, I'd say that "recommended 3rd party tools" reads as saying > > "if you want a 3rd party tool to build extensions, these are good (and > > are a lot easier than using the raw C API)". That's

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

On Tue, Mar 24, 2020 at 2:53 PM Ethan Furman wrote: > On 03/24/2020 01:37 PM, Eric V. Smith wrote: > > On 3/24/2020 3:30 PM, Steve Dower wrote: > >> On 24Mar2020 1849, Brett Cannon wrote: > >>> -1 on "cut*" because my brain keeps reading it as "cute". > >>> +1 on "trim*" as it is clear what's

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

On Fri, Mar 20, 2020 at 11:56 AM Dennis Sweeney wrote: > If ``s`` is one these objects, and ``s`` has ``pre`` as a prefix, then > ``s.cutprefix(pre)`` returns a copy of ``s`` in which that prefix has > been removed. If ``s`` does not have ``pre`` as a prefix, an > unchanged copy of ``s`` is

[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?

On Thu, Nov 28, 2019 at 10:02 AM Brett Cannon wrote: > But there is other things that might break your code between releases, > such as bug fixes, language changes that become the default, etc. Are > deprecations the biggest pain point in transitioning to a new Python > version for people, or is

Re: [Python-Dev] Finding Guido's replacement

On Sun, Jul 22, 2018 at 1:19 PM Chris Angelico wrote: > * Finally, "For Life" is far too long. We need to change our rulers > periodically. > ​With the proposed bi-weekly death matches, "for life" may actually be too short.​ ___ Python-Dev mailing

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 9:27 AM Paul Moore wrote: > From my reading, PEP 572 takes the position that "parent local > scoping" is what people expect from assignment expressions *in > comprehensions* and it's useful enough that there is no reason not to > make that the behaviour. The behaviour

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, Jun 25, 2018 at 2:16 PM Steve Holden wrote: > ​I'd like to ask: how many readers of ​ > > ​this email have ever deliberately taken advantage of the limited Python 3 > scope in comprehensions and generator expressions to use what would > otherwise be a conflicting local variable name?​ >

Re: [Python-Dev] Python3 compiled listcomp can't see local var - bug or feature?

On Mon, Jun 11, 2018 at 3:10 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > Skip, I think you have misunderstood the point I was making. It was > not whether the loop variable should leak out of a list comprehension. > Rather, it was whether a local variable should, so to speak,

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[esr] > All this code runs under either 2 nor 3 without requiring six or any other > shim library. We've got an application that's about 500k loc, runs under both 2 and 3. It has only one shim, a 'metaclass' decorator similar to what six provides, other than that it's all quite clean 2- and

Re: [Python-Dev] A fast startup patch (was: Python startup time)

On Sat, May 5, 2018 at 10:30 AM, Toshio Kuratomi wrote: > On Fri, May 4, 2018, 7:00 PM Nathaniel Smith wrote: > >> What are the obstacles to including "preloaded" objects in regular .pyc >> files, so that everyone can take advantage of this without rebuilding

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, Apr 17, 2018 at 6:20 PM, Steven D'Aprano wrote: > If there are tests which intentionally verify this behaviour, that > really hurts your position that the behaviour is an accident of > implementation. It sounds like the behaviour is intended and required. > ​It is

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, Apr 17, 2018 at 2:23 AM, Chris Angelico wrote: > Augmented assignment is currently all of these: > > augassign: ('+=' | '-=' | '*=' | '@=' | '/=' | '%=' | '&=' | '|=' | '^=' | > '<<=' | '>>=' | '**=' | '//=') > > I'm actually not sure whether the

Re: [Python-Dev] Sets, Dictionaries

On Thu, Mar 29, 2018 at 10:11 AM, David Mertz wrote: > I agree with everything Steven says. But it's true that even as a 20-year > Python user, this is an error I make moderately often when I want an empty > set... Notwithstanding that I typed it thousands of times before sets

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > I understand the motivation to guarantee order, but it's a programmer > convenience that has nothing to do with the idea of mapping, and the > particular (insertion) order is very special and

Re: [Python-Dev] f-strings

On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > If I were Bach, I'd compose a more-itertools-like module to be named > Variations_on_the_F_String. :-) > ​Would that be P.D.Q. Bach to whom you are referring?​

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Fri, Dec 1, 2017 at 5:24 AM, Random832 wrote: > You're completely missing the context of the discussion, which was the > supposed reason that a *new* function call operator, with the proposed > syntax function?(args), that would short-circuit (based on the > 'function'

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Thu, Nov 30, 2017 at 2:48 AM, Andrea Griffini wrote: > Not really related but the PEP says that arguments in Python are evaluated > before the function (as a reason to reject the idea of None-aware function > call) but this is not the case: > ​I think you're missing something

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Wed 2016-06-22 Eric Snow [mailto:ericsnowcurren...@gmail.com] wrote: > The problem I have with this is that it still doesn't give any strong > relationship with the class definition. > Certainly in most cases it will amount to the same thing. However, there is > no way to know if

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

Just on the off chance that it’s related, could it have something to do with the bug in findlabels? http://bugs.python.org/issue26448 (I have high confidence that my patch fixes the problem, just haven’t gotten around to completing the tests.) From: Demur Rumed

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

or Stinner <victor.stin...@gmail.com> wrote: > 2016-04-13 23:02 GMT+02:00 Eric Fahlgren <ericfahlg...@gmail.com>: > > Percentage of 1-byte args= 96.80% > > Yeah, I expected such high ratio. Good news that you confirm it. > > > > Non-argum

Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units

On Wednesday, April 13, 2016 09:25, Victor Stinner wrote: > The side effect of wordcode is that arguments in 0..255 now uses 2 bytes per > instruction instead of 3, so it also reduce the size of bytecode for the most > common case. > > Larger argument, 16-bit argument (0..65,535), now uses 4

Re: [Python-Dev] When should pathlib stop being provisional?

On Wednesday, April 06, 2016 07:39, Steven D'Aprano wrote: > > How well does that apply to path/__path__? > > I think it's potentially the same. Possibly there are fewer existing uses of > "obj.path" out there which conflict with this use, but there's at least one in the > std lib: sys.path.

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

David R. Murray wrote: > I think the intuitive notion of "literal" is "the value is literally what is > written > here". Which is a redundant statement; 'as written' is, after all, what > literally > means when used correctly :). That makes it a language-agnostic concept if > I'm > correct.

Re: [Python-Dev] New Windows installer for Python 3.5

I believe that the new default location addresses your first question: the 64-bit will install in c:/Program Files/Pythonxx and the 32-bit in c:/Program Files (x86)/Pythonxx (at least this has been my standard practice for several years). Eric On Jan 4, 2015 7:03 AM, Paul Moore