On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou wrote:
>> There're also various tools for dealing specifically with git branch
>> layout as used by Github, and every real man writes their own (because
>> it's easier to shoot a 5-liner than to review whether somebody else's
>> tool do what you need
On Mon, Jun 26, 2017 at 1:52 AM, Antoine Pitrou wrote:
> On Mon, 26 Jun 2017 01:27:20 +1000
> Chris Angelico wrote:
>> On Sun, Jun 25, 2017 at 7:25 PM, Antoine Pitrou wrote:
>> >> There're also various tools for dealing specifically with git branch
>> >>
On Thu, Jul 6, 2017 at 5:33 AM, Mark Lawrence via Python-Dev
wrote:
> On 05/07/2017 20:05, Mark Dickinson wrote:
>
>> Oh, and you'd have to rewrite the power algorithm, which currently
>> depends on the size of a limb in bytes being a multiple of 5. :-)
>>
>
> What is a limb, as my search foo has
On Fri, Jul 21, 2017 at 1:49 PM, Nick Coghlan wrote:
> The are some genuine downsides in increasing the complexity of
> bootstrapping CPython when all you're starting with is a VCS clone and
> a C compiler, but those complications are ultimately no worse than
> those we already have with Argument
On Fri, Jul 21, 2017 at 2:09 PM, Nick Coghlan wrote:
> On 21 July 2017 at 13:55, Chris Angelico wrote:
>> On Fri, Jul 21, 2017 at 1:49 PM, Nick Coghlan wrote:
>>> The are some genuine downsides in increasing the complexity of
>>> bootstrapping CPython when all yo
On Tue, Aug 29, 2017 at 12:23 PM, Steve Dower wrote:
>> Check your line lengths, I think they may be too long? (Or maybe my mail
>> client is set too short?)
>
>
> Yeah, not sure what's happened here. Are PEPs supposed to be 80? Or 72?
According to the emacs stanza at the end, 70. I don't know of
On Fri, Sep 1, 2017 at 9:35 AM, Manciu, Catalin Gabriel
wrote:
> A huge Python program with lots of PyLong inplace operations (not just
> adds, this can be applied to all PyLong inplace operations), regardless of
> them
> being in a loop or not, might benefit from such an optimization.
If you're
On Sat, Sep 2, 2017 at 6:35 AM, Joe Jevnik via Python-Dev
wrote:
> Is it true that checking for refcount == 1 is enough? What if a user wrote:
>
> args = (compute_integer(), 5)
> # give away args to someone
> int.__iadd__(*args)
>
> here `args[0]` still has refcount=1 because only `args` owns this
On Wed, Sep 6, 2017 at 2:30 PM, INADA Naoki wrote:
>>> This patch moves a few imports inside functions. I wonder whether that kind
>>> of change actually helps with real applications—doesn't any real application
>>> end up importing the socket module anyway at some point?
>>
>> I don't know if thi
On Wed, Sep 6, 2017 at 10:11 AM, R. David Murray wrote:
> I've written a PEP proposing a small enhancement to the Python loop
> control statements. Short version: here's what feels to me like a
> Pythonic way to spell "repeat until":
>
> while:
>
> break if
>
> The PEP goes
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,
>
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
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
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
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
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 (??) ?
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
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
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
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:
> > >
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
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
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
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
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
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
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
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):
>
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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 "
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
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
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
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
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
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
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
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
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.
>
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
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
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
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
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
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
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-
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
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
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
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
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
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
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
On Fri, Aug 9, 2019 at 4:00 AM Barry Warsaw wrote:
>
> On Aug 8, 2019, at 10:41, Tim Peters wrote:
>
> > Whereas SyntaxError would give no clue whatsoever, and nothing useful
> > to search for. In contrast, a search for TargetScopeError would
> > presumably find a precisely relevant explanation
On Fri, Aug 9, 2019 at 11:22 PM Steven D'Aprano wrote:
>
> And this change won't fix that, because *good* paths that currently work
> today will fail in the future, but *bad* paths that silently do the
> wrong thing will continue to silently do the wrong thing.
Except that many paths can be both
On Sat, Aug 10, 2019 at 12:56 PM Guido van Rossum wrote:
>
> On Fri, Aug 9, 2019 at 11:06 AM Barry Warsaw wrote:
>>
>> Nick and I are now on the same page, so I don’t think we *have* to have a
>> formal SC vote.
>
>
> OK, I agree. Let's remove TargetScopeError from the PEP and from the
> implem
On Sat, Aug 10, 2019 at 6:39 PM Paul Moore wrote:
> There are *many* valid ways to write Windows pathnames in your code:
>
> 1. Raw strings
> 2. Doubling the backslashes
> 3. Using pathlib (possibly with slash as a directory separator, where
> it's explicitly noted as a portable option)
> 4. Using
On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth wrote:
>
> On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka wrote:
>>
>> 22.06.19 01:08, Daniel Holth пише:
>> > Thanks. I think I might like an option to disable str(bytes) without
>> > disabling str != bytes. Unless the second operation would also c
On Wed, Sep 11, 2019 at 5:05 AM Ned Batchelder wrote:
>
> On 9/10/19 11:06 AM, Benjamin Peterson wrote:
> > On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
> >> Maybe I'm not involved enough in the release process, but this seems
> >> confusing to me. On the same day that the PSF put up a p
On Wed, Sep 11, 2019 at 5:49 AM Ivan Pozdeev via Python-Dev
wrote:
>
> On 10.09.2019 21:12, Chris Angelico wrote:
> > On Wed, Sep 11, 2019 at 12:47 AM Daniel Holth wrote:
> >> On Sat, Jun 22, 2019 at 2:48 AM Serhiy Storchaka
> >> wrote:
> >>> 22.06.19
On Fri, Sep 27, 2019 at 5:04 AM Ethan Furman wrote:
>
> On 09/26/2019 09:28 AM, Brett Cannon wrote:
> > Steve Dower wrote:
>
> >> The biggest thing that will change is that all our CI systems will stop
> >> testing 2.7, and there's a good chance we'll lock (or delete?) the 2.7
> >> branch from our
On Wed, Oct 9, 2019 at 11:44 AM Rob Cliffe via Python-Dev
wrote:
>
> The documentation at
> https://docs.python.org/3.2/library/profile.html
> contains the sentence
> For example, if your_integer_time_func() returns times measured in
> thousands of seconds, you would construct the Profile
On Wed, Oct 16, 2019 at 10:51 AM wrote:
>
> I cannot get Python 3.8.0 installed on Linux ( RHEL 8 / CentOS 8).
>
> It's not available in any package repo. When I try to build from source,
> there are dependencies missing (3), that I cannot find anywhere.
>
> More info here: (I did not want to wr
On Wed, Dec 4, 2019 at 3:20 AM Mark Shannon wrote:
>
> Hi Everyone,
>
> I am proposing a new PEP, still in draft form, to impose a limit of one
> million on various aspects of Python programs, such as the lines of code
> per module.
>
> Any thoughts or feedback?
>
The main justification for these
On Wed, Dec 4, 2019 at 1:31 PM Gregory P. Smith wrote:
> Overall I like the idea of limits... But... in my experience, limits like
> this tend to impact generated source code or generated bytecode, and thus any
> program that transitively uses those.
>
Overall, I *dislike* the idea of limits, b
On Wed, Dec 4, 2019 at 3:16 PM Steven D'Aprano wrote:
>
> On Wed, Dec 04, 2019 at 01:47:53PM +1100, Chris Angelico wrote:
>
> > Integer sizes are a classic example of this. Is it acceptable to limit
> > your integers to 2^16? 2^32? 2^64? Python made the choice to NOT lim
On Wed, Dec 4, 2019 at 5:22 PM Kyle Stanley wrote:
>
> > BTW, I think 2to3 can help to move from 2&3 code to 3-only code.
>
> > Instead, we can do:
>
> > * Don't recommend u-prefix except in Python 2&3 code.
> > * Provide a tool to remove the u-prefix.
>
> +1, this seems like the smoothest way of
On Sat, Dec 7, 2019 at 2:01 AM Guido van Rossum wrote:
>
> Let's try to avoid having PEP discussions in the peps tracker, period. That
> repo's tracker is only meant to handle markup and grammar.
>
> But if you want to prevent a PR from being merged, in general you should put
> [WIP] in the subj
On Sat, Dec 7, 2019 at 9:58 AM Greg Ewing wrote:
>
> On 7/12/19 2:54 am, Rhodri James wrote:
>
> > You've talked some about not making the 640k mistake
>
> I think it's a bit unfair to call it a "mistake". They had a 1MB
> address space limit to work with, and that was a reasonable place
> to put
On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon wrote:
> Bear in mind that the costs of higher limits are paid by everyone, but
> the benefits are gained by few.
Can we get some stats on what the costs of higher limits (or having no
limit at all) is? Or, putting it the other way: Since CPython
curre
On Tue, Dec 10, 2019 at 4:56 AM Mark Shannon wrote:
>
>
> On 09/12/2019 2:15 pm, Chris Angelico wrote:
> > On Tue, Dec 10, 2019 at 1:09 AM Mark Shannon wrote:
> >> Bear in mind that the costs of higher limits are paid by everyone, but
> >> the benefits are gaine
On Tue, Dec 10, 2019 at 10:51 AM Steven D'Aprano wrote:
>
> On Mon, Dec 09, 2019 at 02:12:37PM -0800, Nathaniel Smith wrote:
> > > > On 09/12/2019 2:15 pm, Chris Angelico wrote:
> > > You: "We should limit things. Stuff will be faster."
> > > Oth
On Thu, Dec 12, 2019 at 8:46 AM Antoine Pitrou wrote:
> > 1) Handling a large number of concurrent clients on a continuously running
> > web server that receives a significant amount of traffic.
>
> Not sure how that works? Each client has an accepted socket, which is
> bound to a local port numb
On Mon, Dec 16, 2019 at 12:00 PM Kyle Stanley wrote:
> On a related note though, I'm not a fan of this behavior:
> >>> str(b'\xc3\xa1')
> "b'\\xc3\\xa1'"
>
> Passing a bytes object to str() without specifying an encoding seems like a
> mistake, I honestly don't see how this ("b'\\xc3\\xa1'") woul
On Tue, Dec 24, 2019 at 1:57 PM Kyle Stanley wrote:
> Add (much faster for dicts):
> >>> timeit.timeit("s = set(); s.add(0)", number=100_000_000)
> 13.330938750001224
> >>> timeit.timeit("d = {}; d[0] = None", number=100_000_000)
> 5.788865385999088
I think this is an artifact of Python not havin
On Wed, Jan 22, 2020 at 4:03 AM Eric V. Smith wrote:
> The reason repr adds the '.0' that 'g' does not is to avoid this problem:
>
> >>> type(eval(repr(17.0))) == type(17.0)
> True
> >>> type(eval(format(17.0, '.17g'))) == type(17.0)
> False
>
The OP wasn't asking about eval, though, but about
On Fri, Jan 24, 2020 at 7:05 PM Victor Stinner wrote:
> We kept a compatibility layer with Python 2 on purpose, PEP 4 says:
>
> "In order to facilitate writing code that works in both Python 2 & 3
> simultaneously, any module that exists in both Python 3.5 and Python
> 2.7 will not be removed from
On Fri, Jan 24, 2020 at 7:40 PM Victor Stinner wrote:
>
> The change is that Python 2.7 is no longer supported (since 2020-01-01).
>
Which means that it's now okay to remove things, correct? Starting
with 3.9, it's no longer necessary to maintain compatibility with 2.7?
ChrisA
__
On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote:
>
> The only thing I'm unsure of here is whether direct use of the `==` and
> `!=` operators are included as "implicit calls" to the dunders. I
> *think* I understand Guido's intention, but I'm not sure:
>
> * x == y MUST call `__eq__`
>
> *
On Sat, Jan 25, 2020 at 9:40 AM Tim Peters wrote:
> I think it needs more words, though, to flesh out what about this is
> allowed by the language (as opposed to what CPython happens to do),
> and to get closer to what Guido is trying to get at with his
> "*implicit* calls". For example, it's at
On Tue, Feb 4, 2020 at 10:12 AM Sebastian Berg
wrote:
>
> Now, probably this has been rejected a hundred times before, and there
> are some very good reason why it is a horrible thought...
>
> But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> operation (and in a sense it seems
On Tue, Feb 4, 2020 at 1:08 PM Steven D'Aprano wrote:
>
> On Tue, Feb 04, 2020 at 12:33:44PM +1100, Chris Angelico wrote:
>
> [Sebastian Berg]
> > > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> > > operation (and in a sense it seems
On Thu, Feb 6, 2020 at 3:47 AM Brandt Bucher wrote:
>
> > I have one suggestion: Wouldn't it be useful for these operators to also
> > accept sets (functionally acting like a dict with None for all values)?
>
> > Why None? Why not 0, or False, or 42? This sort of thing belongs more in
> > a f
On Thu, Feb 6, 2020 at 7:42 PM Musbur wrote:
>
> Depends on what d is.
>
> >>> type({})
>
>
> So the result is {(1, 2): None}, but the ambiguity comes from the
> definition of {}, not from my proposal.
>
Actually, what Serhiy hinted at was a consequence (and, I would say, a
rather weird corner
On Fri, Feb 7, 2020 at 9:30 AM Brandt Bucher wrote:
>
> Sorry Paul, I sent my reply too soon.
>
> I see what you're saying, and I'm pretty firmly -1 on reinventing (or
> importing) copy.copy. We already have an API for copying a dict (dict.copy).
>
> I still fail to see problem with using a metho
801 - 900 of 1000 matches
Mail list logo
