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" wrote:> On 3 J
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 here, since it s
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' being None) could not be
Re: [Python-Dev] f-strings
On Tue, Dec 19, 2017 at 8:47 AM, Stephen J. Turnbull < [email protected]> 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] Guarantee ordered dict literals in v3.7?
On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull < [email protected]> 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 usual
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 even> existed (and
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 augmented-assignment-expressio
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 nonetheless bizarre 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 the>> interpreter?>>>> Would thi
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 3-wise
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 < [email protected]> 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] 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] 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 isn'
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] 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. Som
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 bytes
Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
t 2:23 PM, Victor Stinner wrote: > 2016年04月13日 23:02 GMT+02:00 Eric Fahlgren : > > Percentage of 1-byte args= 96.80% > > Yeah, I expected such high ratio. Good news that you confirm it. > > > > Non-argument ops =53,719 > > On
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 [mailto:gunkm...@gmail.
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 list
Re: [Python-Dev] PEP 487: Simpler customization of class creation
On Wed 2016年06月22日 Eric Snow [mailto:[email protected]] 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 cls.__dict__
[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: 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)> wou
[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 A
[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
[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 retu
[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 goi
[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 a
[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 622: Structural Pattern Matching [was: PEP 622 railroaded through?]
On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < [email protected]> 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