On Tue, Mar 3, 2020 at 8:06 AM Luca Wolf wrote:
>
> Dear Python Team,
>
> I have a good idea for a new comand in Python.
>
> It’s „intput()“ for numbers. So you don’t have to write „int(Input())“.
>
> It’s much easier to write and it’s faster too.
>
> You can use the same for „floatput()“, so
On Thu, Feb 27, 2020 at 8:15 PM Serhiy Storchaka wrote:
>
> 27.02.20 10:46, Chris Angelico пише:
> > On Thu, Feb 27, 2020 at 7:41 PM Serhiy Storchaka
> > wrote:
> >> sympy/utilities/runtests.py
> >>
> >> Sorry, but the current code
> >>
&g
On Tue, Feb 25, 2020 at 2:25 AM Antoine Pitrou wrote:
>
> On Mon, 24 Feb 2020 00:30:41 -0500
> Kyle Stanley wrote:
> > > In that case I'm not sure the author ought to get credit for the PR. They
> > can file a bug pointing out the typo and someone else can submit a fix.
> >
> > That sounds like
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 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
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 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 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 to me
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
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
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 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 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
On Wed, Apr 15, 2020 at 2:09 PM Raymond Hettinger
wrote:
>
> [GvR]
> > We should not try to import JavaScript's object model into Python.
>
> Yes, I get that. Just want to point-out that working with heavily nested
> dictionaries (typical for JSON) is no fun with square brackets and quotation
On Tue, Apr 7, 2020 at 5:03 AM Guido van Rossum wrote:
>
> On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano wrote:
>> Personally, I would not like to have to explain to newcomers why `match`
>> is a keyword but you can still use it as a function or variable, but not
>> other keywords like
On Sun, Apr 19, 2020 at 3:39 AM Paul Ganssle wrote:
>
> A few weeks ago, I submitted PEP 615 to the steering council for a decision.
> There's been a decent amount of discussion there with some very good
> questions. I think they are mostly resolved (though I'm happy to have other
> people
On Mon, Apr 6, 2020 at 1:53 PM Jonathan Goble wrote:
>
> I'm getting ready to get back into an old personal project with some new
> ideas. Before I do, I need to ask a question regarding the stability of
> CPython bytecode. Before you say it, I am well aware and fully understand
> that the
On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
wrote:
>
> I'm skeptical about anything that hides an object's "true nature": this is a
> major landmine in diagnostics because it lies to you about what
> you are looking at and where to look for its implementation.
>
> E. g. in this
On Thu, Mar 26, 2020 at 12:08 PM Ivan Pozdeev via Python-Dev
wrote:
>
>
> On 26.03.2020 2:41, Chris Angelico wrote:
> > On Thu, Mar 26, 2020 at 10:38 AM Ivan Pozdeev via Python-Dev
> > wrote:
> >> I'm skeptical about anything that hides an object's "true natu
On Sat, Mar 28, 2020 at 11:28 AM Ivan Pozdeev via Python-Dev
wrote:
>
> On 26.03.2020 19:24, Ethan Furman wrote:
> > Before Enum, the repr for socket.AF_UNIX was:
> >
> > 1
> >
> > Not very useful for debugging.
>
> On the contrary, it's perfect. I know everything I need: it's an integer
>
On Tue, May 12, 2020 at 5:20 PM Paul Moore wrote:
>
> On Tue, 12 May 2020 at 07:53, Brandt Bucher wrote:
> > > > Another proposed idiom, per-module shadowing of the built-in zip with
> > > > some subtly different variant from itertools, is an anti-pattern that
> > > > shouldn't be encouraged.
On Sat, May 16, 2020 at 1:54 AM Antoine Pitrou wrote:
>
> On Fri, 15 May 2020 10:46:25 -0400
> David Mertz wrote:
> >
> > > 1. +1 itertools.zip_strict function
> > > 2. +1 zip.strict(*args)
> > > 3. +1 zip(*args, mode='strict') # mode='shortest' by default
> > > 4. +0 zip(*args, strict=True)
>
On Wed, May 13, 2020 at 4:38 AM Ethan Furman wrote:
>
> > -
> > https://github.com/python/cpython/blob/27c0d9b54abaa4112d5a317b8aa78b39ad60a808/Lib/os.py#L510
>
> Wow -- I don't even know how to parse that!
>
Wow, that's quite an example. Of something, I'm not sure what, but
definitely an
On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon wrote:
> The accessibility of a thread-local variable is a strict superset of
> that of a function-local variable.
>
> Therefore storing the thread state in a thread-local variable is at
> least as capable as passing thread-state as a parameter.
>
And
On Sun, Mar 22, 2020 at 5:41 AM Steven D'Aprano wrote:
>
> On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > wrote:
> > > This is a proposal to add two new methods, ``cutprefix`` and
> > > ``cutsuffix``, to the APIs of
On Sun, Mar 22, 2020 at 1:02 PM Nathaniel Smith wrote:
>
> On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote:
> >
> > On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > > wrote:
> > > > This is a proposal to add two
On Wed, Sep 16, 2020 at 5:23 AM Mark Shannon wrote:
> In general, I would except macros to be used within libraries, so that
> those libraries gain the power of their custom macros without making
> Python ever larger and more complex.
>
> However, there is no reason why they cannot be made more
On Wed, Sep 16, 2020 at 5:31 AM Chris Angelico wrote:
> Users would be encouraged to try it but
> NOT to publish code using it.
Clarification: by "publish" I mean in production, or as libraries that
people will be depending on. It'd be on par with playing around in a
fork of Pyt
On Thu, Oct 15, 2020 at 11:38 AM Tim Peters wrote:
> I think this is premature. There is almost never an optimization
> that's a pure win in all cases. For example, on some platforms
> `timsort` will never be as fast as the old samplesort in cases with a
> very large number of equal elements, and
On Sat, Oct 17, 2020 at 12:30 PM Tim Peters wrote:
>
> I don't plan on making a series of these posts, just this one, to give
> people _some_ insight into why the new algorithm gets systematic
> benefits the current algorithm can't. It splits the needle into two
> pieces, u and v, very carefully
On Tue, Jun 2, 2020 at 8:55 PM Nick Coghlan wrote:
>
>
>
> On Tue., 2 Jun. 2020, 11:23 am Steven D'Aprano, wrote:
>>
>>
>>
>> > The conceptual idea here is that the "truncate" flag name would technically
>> > be a shorter mnemonic for "truncate_silently", so clearing it gives you an
>> >
On Sat, Sep 19, 2020 at 11:44 AM Guido van Rossum wrote:
> Another brainstorm (or brainfart): maybe repr() should show the module/class
> and the name, and str() should only show the name. We'd then get
> ```
> >>> # Mock-up!
> >>> print(str(re.i))
> IGNORE
> >>> print(repr(re.i))
> re.IGNORE
>
On Wed, Oct 21, 2020 at 3:38 AM Steven D'Aprano wrote:
>
> On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote:
>
> > Do you have any details to back this up? You're not just asking for a
> > proposal to be accepted, you're actually asking for (quit
On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
>
> Hi everyone,
>
> CPython is slow. We all know that, yet little is done to fix it.
>
> I'd like to change that.
> I have a plan to speed up CPython by a factor of five over the next few
> years. But it needs funding.
>
> The overall aim is
On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano wrote:
> A minor point, and I realise that the costs are all in very round
> figures, but they don't quite match up: $2 million split over five
> stages is $400K per stage, not $500K.
The proposal is for four stages.
ChrisA
On Tue, Oct 27, 2020 at 10:00 AM Greg Ewing wrote:
>
> On 27/10/20 8:24 am, Victor Stinner wrote:
> > I would
> > rather want to kill the whole concept of "access" time in operating
> > systems (or just configure the OS to not update it anymore). I guess
> > that it's really hard to make it
On Tue, Oct 27, 2020 at 2:42 AM Matti Picus wrote:
>
>
> On 10/21/20 2:38 PM, Matti Picus wrote:
> > On 10/21/20 20:42:02 +1100 Chris Angelico wrote:
> >
> >> When I go looking for PyPy performance stats, everything seems to be
> >> Python 2.7. Is there anyw
On Fri, Jul 3, 2020 at 4:09 AM David Mertz wrote:
>> An issue is that commit messages are uneditable after merge, so something
>> written somewhere suggesting consideration of this would be a good idea,
>> with authors/mergers bearing this in mind, however unusual a change on this
>> basis
On Fri, Jul 3, 2020 at 5:17 AM Ivan Pozdeev via Python-Dev
wrote:
>
>
> On 02.07.2020 21:20, Chris Angelico wrote:
> > On Fri, Jul 3, 2020 at 4:09 AM David Mertz wrote:
> >>> An issue is that commit messages are uneditable after merge, so something
> &g
On Wed, Jul 8, 2020 at 10:45 AM Greg Ewing wrote:
>
> On 8/07/20 12:24 pm, Daniel Moisset wrote:
> > Many people in this thread have argued that the double meaning in the
> > PEP might be confusing, but Python already has a double meaning in other
> > places.
>
> But assignment targets have
On Wed, Jul 8, 2020 at 6:17 PM Inada Naoki wrote:
>
> Since this is very new system, can we have some restriction
> to allow aggressive optimization than regular Python code?
>
> # Class Pattern
>
> Example:
>
> match val:
> case Point(0, y): ...
> case Point(x, 0): ...
>
On Wed, Jul 8, 2020 at 8:56 PM Inada Naoki wrote:
>
> On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote:
> >
> >
> > These two I would be less averse to, but the trouble is that they make
> > the semantics a bit harder to explain. "Dotted names are loo
On Fri, Jul 3, 2020 at 10:10 AM Łukasz Langa wrote:
> Commit messages aren't usually scrutinized to this extent. If you looked at
> the last 1000 commits in cpython, you'd find quite a few with messages that
> could be seriously improved. We don't though because commits are immutable.
> You
On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain wrote:
> - Finally, I did mention increasing the scope of constant value patterns to
> accommodate expressions (as opposed to just dotted names). If we were to do
> this, it’s a reason to prefer some syntaxes for constant value patterns over
>
On Sat, Jul 4, 2020 at 12:48 AM Rob Cliffe via Python-Dev
wrote:
>
> Whoa!
>
> I have an uneasy feeling about this PEP.
>
> AFAIK the usual procedure for adding a new feature to Python is:
> An idea is raised and attracts some support.
> Someone sufficiently motivated writes a PEP.
>
On Fri, Jul 3, 2020 at 11:03 PM Ivan Pozdeev via Python-Dev
wrote:
>
>
> On 03.07.2020 15:26, Henk-Jaap Wagenaar wrote:
>
> On Fri, 3 Jul 2020 at 13:10, Ivan Pozdeev wrote:
>>
>> So what?
>
> Unnecessary
>>
>> They'll have to synchronise their history to ours to be able to make a PR.
>> And if
On Sun, Jul 12, 2020 at 11:04 AM Guido van Rossum wrote:
>
> On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico wrote:
>>
>> On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing
>> wrote:
>> >
>> > Just had another thought about marking assignment targets.
>
On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing wrote:
>
> Just had another thought about marking assignment targets.
>
> The PEP currently forbids repeating bound names in a pattern
> to avoid raising expectations that
>
> case Point(x, x):
>
> would match only if the two arguments were equal.
On Thu, Jul 2, 2020 at 7:27 PM Antoine Pitrou wrote:
> Otherwise why stop at English? I could just as well write my comments
> in French if it's all about individual freedom. Requiring English is
> not inclusive, it forced people like me to painfully adapt to a
> language I wasn't used to. And
On Wed, Jun 24, 2020 at 3:49 PM Ethan Furman wrote:
>
> On 06/23/2020 10:31 PM, Chris Angelico wrote:
> > On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote:
> >> On 06/23/2020 09:01 AM, PEP 622 wrote:
> >>
> >>> from enum import Enum
> >
On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote:
>
> On 06/23/2020 09:01 AM, PEP 622 wrote:
>
> > from enum import Enum
> >
> > class Color(Enum):
> > BLACK = 1
> > RED = 2
> >
> > BLACK = 1
> > RED = 2
> >
> > match color:
> > case .BLACK | Color.BLACK:
> > print("Black
On Mon, Jun 29, 2020 at 12:53 AM wrote:
>
> In my humble opinion, this doesn't warrant the creation of a new structure,
> but rather a restructuring of PEPs.
>
> As mentioned by others, we have a "Rejected Ideas" section already, but that
> seems to somewhat miss the point. It captures only the
On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote:
>
> On Wed, 24 Jun 2020 12:38:52 -0700
> Guido van Rossum wrote:
> > Everyone,
> >
> > If you've commented and you're worried you haven't been heard, please add
> > your issue *concisely* to this new thread. Note that the following issues
> >
On Wed, Jun 24, 2020 at 5:30 AM Rob Cliffe via Python-Dev
wrote:
>
> The PEP is great, but this strikes me as horribly confusing, given that
> 401|403|404 is already legal syntax.
> IIUC any legal expression can come between `case` and `:`, but expressions
> that contain `|` at their outermost
On Wed, Jun 24, 2020 at 2:04 AM Guido van Rossum wrote:
> def http_error(status):
> match status:
> case 404:
> return "Not found"
> case 418:
> return "I'm a teapot"
> case _:
> return "Something else"
>
> Note the last block: the
On Wed, Jun 24, 2020 at 10:11 AM Guido van Rossum wrote:
>
> On Tue, Jun 23, 2020 at 4:41 PM MRAB wrote:
>>
>> On 2020-06-23 22:50, Barry Warsaw wrote:
>> > On Jun 23, 2020, at 14:31, Chris Angelico wrote:
>> >
>> >> I can't find it among
On Sat, Jun 13, 2020 at 3:50 AM Edwin Zimmerman wrote:
>
> My previous timings were slightly inaccurate, as they compared spawning
> processes on Windows to forking on Linux. Also, I changed my timing code to
> run all process synchronously, to avoid hitting resource limits.
>
> Updated
On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno wrote:
> Tools should adapt to the language, not the other way around. If things had
> to be done the way they had always been done, without any change, for fear of
> people not being used to it, we wouldn't even have Python at all. People
>
On Tue, Jul 28, 2020 at 5:24 AM Steven Barker wrote:
>
> A single-name unpacking assignment can do exactly what you want, albeit with
> slightly less helpful exception messages:
>
> jack, = (p for p in people if p.id == '1234') # note comma after the name
> jack
>
Agreed. As a minor
On Sat, Aug 15, 2020 at 12:32 AM Mark Shannon wrote:
>
> Hi all,
>
> I've written up a critique of PEP 622.
> Rather than dump a 2000 line email on you all, I've made a git repo.
>
> https://github.com/markshannon/pep622-critique
>
I started reading it. You're saying the same things that
On Tue, Jan 12, 2021 at 4:22 AM Larry Hastings wrote:
>
>
> I've written a new PEP. Please find it below. Happy reading!
>
Can this get added to the PEPs repo and assigned a number and such?
BTW, the currently preferred wording for the copyright blurb is
slightly different. If you're the sole
On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann wrote:
>
>
> On 1/8/21 4:31 PM, Mats Wichmann wrote:
> >
> >
> > Someone reported a testsuite break on stuff I work on (scons) with
> > 3.10a4, and it looks similar to this which appears in the changelog at
> >
> >
On Tue, Jan 12, 2021 at 5:10 AM Larry Hastings wrote:
>
>
> Certainly. I'm just another victim in the copy-and-paste wars.
>
Ah yes, the Battle of the Clipboard. Iconic, epic, such a glorious
engagement! But the casualties were steep. Fortunately we can rebuild.
> I actually have write access
On Tue, Jan 12, 2021 at 12:56 PM Larry Hastings wrote:
>
> It was a balancing act. Using an 64-byte empty dict per object with no
> defined annotations seems so wasteful. And anything short of an empty dict,
> you'd have to guard against. Current code already has to guard against
>
On Tue, Nov 24, 2020 at 7:00 AM Ethan Furman wrote:
>
> On 11/23/20 11:06 AM, Larry Hastings wrote:
> > On 11/23/20 8:15 AM, Brian Coleman wrote:
> >> def process(root_node: Node):
> >> def process_node(node: Node):
> >> if isinstance(node, StringNode):
> >> return
On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote:
>
> FWIW, I'd like to add my +1 to usage of "as" for spelling class capture
> patterns. This is by far the clearest and easiest to read form I've seen thus
> far, and I suspect that it would be the easiest to explain to users already
>
On Tue, Nov 17, 2020 at 9:44 PM Steven D'Aprano wrote:
> `try...except` is no different.
> ...
> The only wrinkle in the case of `try...except` is that the error
> variable is deleted, even if it wasn't actually used. If you look at the
> byte-code generated, each compound try...except with an
On Wed, Nov 18, 2020 at 4:08 AM Richard Damon wrote:
>
> One comment about having the exception handler 'save state' and restore
> it is that frequently the purpose of the exception handler is TO make
> changes to outer variable to fix things up based on the exception.
>
> I could see the desire
On Wed, Nov 18, 2020 at 8:38 AM Steven D'Aprano wrote:
> To start with, what else are they using "e" for? Surely it would be more
> important to use a better name *there* rather than change the exception
> variable.
2.718281828?
ChrisA
___
Python-Dev
On Tue, Nov 10, 2020 at 3:19 AM Simon Cross
wrote:
>
> I really enjoyed learning from this "user manual with a strong
> narrative component" so I would personally like to see it stay even if
> a new tutorial is created for a different kind of audience.
If that were to happen, what I'd prefer is
On Tue, Nov 10, 2020 at 3:38 AM Guido van Rossum wrote:
>
> Do you want to join the docs WG? IIUC it’s open to new members. (Carol?)
>
Me personally, or members of this conversation in general?
My life is a bit too chaotic at the moment to take on more
responsibilities, although I might
On Tue, Nov 3, 2020 at 8:53 AM Glenn Linderman wrote:
>
> On 11/2/2020 1:42 PM, Guido van Rossum wrote:
> > But we feel that `case x, x` can easily be misunderstood as "a tuple
> > of two equal values"
>
> So what _is_ the syntax for "a tuple of two equal values" ?
>
> case x, ?x: # comes to
On Sat, Oct 31, 2020 at 5:31 AM Mark Shannon wrote:
> > It's right here that you lose me. Anyone who reduces pattern matching to "a
> > fancy switch statement" probably isn't the right person to be discussing
> > its semantics and usefulness with. It seems that some people just can't
> >
On Wed, Oct 21, 2020 at 3:31 AM Mark Shannon wrote:
>
> Hi Chris,
>
> On 20/10/2020 4:37 pm, Chris Angelico wrote:
> > On Wed, Oct 21, 2020 at 12:03 AM Mark Shannon wrote:
> >>
> >> Hi everyone,
> >>
> >> CPython is slow. We all know
On Wed, Oct 21, 2020 at 8:23 PM Matti Picus wrote:
> Just to set the record straight, PyPy has been available on conda-forge
> [0] since March, and has seen close to 70,000 downloads [1] from that
> channel alone, in addition to the downloads from
> https://downloads.python.org/pypy and the other
On Wed, Oct 21, 2020 at 10:38 PM Matti Picus wrote:
>
> On 10/21/20 20:42:02 +1100 Chris Angelico wrote:
>
> > When I go looking for PyPy performance stats, everything seems to be
> > Python 2.7. Is there anywhere that compares PyPy3 to CPython 3.6 (or
> > whichever
On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
>
> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
>
> > That'd leave open
> > the option for "foo() if x else foo()" to be optimized down to just
> > "foo()", altho
On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> On 1/12/21 10:37 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
> >>
> >> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
> >>
> >>>
On Fri, Jan 15, 2021 at 10:13 PM Rob Cliffe via Python-Dev
wrote:
>
>
>
> On 12/01/2021 15:53, Mark Shannon wrote:
> > Hi everyone,
> >
> >
> >
> > In master we convert `if x: pass` to `pass` which is equivalent,
> > unless bool(x) has side effects the first time it is called. This is a
> >
On Wed, Jan 13, 2021 at 9:08 PM Emily Bowman wrote:
>
> Even if you define __bool__() as returning a bool, and error/undefined
> behavior otherwise, that doesn't eliminate side effects. Is it even possible
> to nail down a definition to the point that you can say, "Thou shalt not
> mutate or
On Wed, Jan 13, 2021 at 8:02 PM Ethan Furman wrote:
>
> On 1/12/21 11:27 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> >> Optimizations are an implementation detail, and implementation details
> >> should not change the la
On Wed, Jan 13, 2021 at 4:24 AM Richard Damon wrote:
>
> On 1/12/21 10:53 AM, Mark Shannon wrote:
> > Hi everyone,
> >
> > Should the optimizer eliminate tests that it can prove have no effect
> > on the control flow of the program, even if that may eliminate some
> > side effects in __bool__()?
On Fri, May 14, 2021 at 7:31 PM Petr Viktorin wrote:
> Perhaps it would be beneficial to provide a common base class or
> factory, so we get a good repr. But I don't think another common value
> like None and Ellipsis would do much good.
>
Agreed - I think Sentinel would make a great class, from
On Tue, May 18, 2021 at 8:51 PM Stephen J. Turnbull
wrote:
>
> 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)
On Thu, May 13, 2021 at 5:37 PM Abdur-Rahmaan Janhangeer
wrote:
>
> Greetings,
>
> One crucial missing piece in the Python world is the focus
> on internals of projects. You have many talks on usage and
> scaling but not enough on internals. Even less workshops.
> For OpenSource to thrive, you
On Sat, May 15, 2021 at 2:04 AM Barry Warsaw wrote:
>
> On May 14, 2021, at 02:38, Chris Angelico wrote:
> >
> > Do we ever really need the ability to pass a specific sentinel to a
> > function, or are we actually looking for a way to say "and don't pass
>
On Fri, May 21, 2021 at 3:51 AM David Mertz wrote:
>
> On Thu, May 20, 2021 at 6:21 AM Tal Einat wrote:
>>
>> On Sat, May 15, 2021 at 2:09 AM David Mertz wrote:
>> > Just add a ._uuid attribute and have object equality follow equality of
>> > that attribute. There's no reason to expose that in
On Mon, May 24, 2021 at 6:40 PM Łukasz Langa wrote:
>
>
> On 20 May 2021, at 07:03, pjfarl...@earthlink.net wrote:
>
> The Python Developers Guide specifically states to get VS2017 for developing
> or enhancing python on a Windows system.
>
> Is it still correct to specifically use VS2017 , or
On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
>
> I think it makes sense, and I do see a difference between Provisional and
> Unstable. Is this anything more than a documentation label?
>
Would it be a pipe dream to hope that static checkers could be taught
to recognize them? Not a huge
On Fri, Jun 4, 2021 at 8:31 AM Guido van Rossum wrote:
>
> On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote:
>>
>> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote:
>> >
>> > I think it makes sense, and I do see a difference between Provisional and
&
On Wed, Jun 30, 2021 at 2:36 AM wrote:
>
> I just stumbled upon the following issue and subsequent pull request. It is a
> very small bugfix. There is currently a bug in Python and this pull request
> fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it
> doesn't get
On Fri, Jul 2, 2021 at 10:06 AM Eric V. Smith wrote:
>
> On 7/1/2021 7:39 PM, esmeraldagar...@byom.de wrote:
> > "Merging something is also a responsibility to whoever does it" - And it's
> > also a responsibility to fix bugs, no? I don't get why you're so afraid of
> > (maybe!) introducing a
On Mon, Apr 26, 2021 at 2:27 PM Nathaniel Smith wrote:
> Yeah, you've understood correctly, and you see why I wrote "both the
> current proposal and the alternative have very complex implications
> and downsides" :-)
>
> [chomp lots of very helpful summarizing]
Gotcha, thanks!
ChrisA
On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble wrote:
>
> On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote:
>>
>> On 4/29/21 10:35 AM, Jonathan Goble wrote:
>> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote:
>>
>>
>> >> Which raises the question: Do we want to have a standard name for
On Thu, Apr 22, 2021 at 7:53 PM Paul Moore wrote:
> I wonder whether type checkers could handle a "magic" type (let's call
> it DuckTyped for now :-)) which basically means "infer a protocol
> based on usage in this function". So if I do:
>
> def my_fn(f: DuckTyped):
> with f:
> data
On Thu, Apr 22, 2021 at 5:03 PM Ryan Gonzalez wrote:
>
> On Apr 21, 2021, 5:29 PM -0500, Paul Bryan , wrote:
>
> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes
On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan wrote:
>
>
>
> On Sat, 24 Apr 2021, 10:02 am Skip Montanaro,
> wrote:
>>
>>
>>> Practically speaking, one issue I have is how easy it is to write
>>> isinstance or issubclass checks. It has historically been much more
>>> difficult to write and
On Sat, Mar 27, 2021 at 3:33 AM Baptiste Carvello
wrote:
>
> Le 25/03/2021 à 15:59, Stefano Borini a écrit :
> > On Tue, 23 Mar 2021 at 21:39, Python Steering Council
> > wrote:
> >> This isn’t just about ‘master’ being rooted in slavery.
> >
> > No it's not and I am shocked that such ignorance
On Sun, Apr 4, 2021 at 6:20 PM Paul Moore wrote:
>
> On Sun, 4 Apr 2021 at 01:37, Brandt Bucher wrote:
> >
> > Mark Shannon said:
> > > I was relying on the "reference" implementation, which is also in the PEP.
> >
> > Can you please stop putting scare quotes around "reference implementation"?
>
801 - 900 of 992 matches
Mail list logo
