).
However, I don't think the decision is quite as clearcut as it is for
`__index__` implying `__int__`.
Lossy conversions to int shouldn't imply anything about conversions to
real numbers or floating point values.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane,
Hi folks,
Brett recently posted about the update to PEP 1 that added the PEP Sponsor
role, but folks may not have noticed that we've also made the amendments
needed to allow the PEP decision making process to restart:
https://github.com/python/peps/pull/896/files
This is the smallest change to PE
On Fri, 15 Mar 2019 at 03:01, Victor Stinner wrote:
>
> Hi,
>
> Le lun. 11 mars 2019 à 13:26, Nick Coghlan a écrit :
> > This is the smallest change to PEP 1 that we consider potentially viable:
> > handling all PEPs through the BDFL-Delegate model, with the Steerin
utor Licensing
Agreement process was tightly coupled to some custom fields in b.p.o
[1], and that is now very close to being resolved thanks to Mariatta's
efforts (and provides a nice workflow improvement in its own right).
Cheers,
Nick.
[1] https://www.python.org/dev/peps/pep-0581/#update-t
atch:
* https://docs.python.org/3/library/warnings.html#warning-categories
* https://docs.python.org/3/library/exceptions.html#warnings
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Pyt
ation by third
party low level code:
* PEP 576: Exposing the internal FastCallKeywords convention to 3rd
party modules
* PEP 580: Revising the callable struct hierarchy internally and in
the public C API
* PEP 579: Background information for the problems the other two PEPs
are attempting to add
ou'd like to avoid full deprecation
Hence the last one only showing up to those folks that are running
automated tests or otherwise enabling all warnings.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-
7;t want to use it, they don't have to use it.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
e
DeprecationWarning".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/
ick.
P.S. I've also posted a draft update to PEP 432 that modifies it to
reflect Victor's extraction of the part we already have as a private
API to PEP 587:https://github.com/python/peps/pull/965
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ode execution (e.g. the shelve module loading pickle files
from disk).
If this part of the API were lower down the stack (e.g.
"_io.open_for_code_execution") then I think it would make more sense -
APIs like tokenize.open(), runpy.run_path(), PyRun_SimpleFile(),
shelve, etc, could use that
upport.cpython_only,
so they get skipped automatically when the test suite is run against
another implementation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
s - it needs the package structure
information from the "-m" switch to learn otherwise.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mai
attempt the coercion, and then complain about it on
stderr (regardless of whether the coercion succeeded or not)
The original PEP 580 implementation tried to keep the config API
simpler by always complaining, but that turned out to break the world
(plenty of contexts where things get u
On Sun, 7 Apr 2019 at 12:45, Nick Coghlan wrote:
> The original PEP 580 implementation tried to keep the config API
> simpler by always complaining, but that turned out to break the world
> (plenty of contexts where things get upset by unexpected output on
> stderr).
Err, PEP 538. No
Thanks Antoine.
As BDFL-Delegate I'm happy with this version of the PEP, so it's my
pleasure to accept it for inclusion in Python 3.8.
Regards,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
the reverse order can be made to work, that would be good, but if
that proves intractable, Ethan's suggestion of reversing the
documented deprecation makes sense.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ad now so that there's more time for discussion prior to the 3.8b1
deadline.
==
PEP: 558
Title: Defined semantics for locals()
Author: Nick Coghlan
BDFL-Delegate: Nathaniel J. Smith
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017-09-08
Python-Version: 3.8
Post-Hi
On Wed, 22 May 2019 at 00:51, Nick Coghlan wrote:
> P.S. I'm away this weekend, so I expect the reference implementation
> to be done late next week, and I'd be submitting the PEP to Nathaniel
> for formal pronouncement at that point. However, I'm posting this
> thre
ract mathematical concept describing anything
> that maps keys to values).
That makes sense - I'll update the text.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@pyt
(I'll likely write a more detailed reply once I'm back on an actual
computer, but wanted to send an initial response while folks in the US are
still awake, as the detailed reply may not be needed)
Thanks for this write-up Nathaniel - I think you've done a good job of
capturing the available design
On Wed., 29 May 2019, 2:29 pm Guido van Rossum, wrote:
> So why is it “hellish” for JITs if locals() returns a proxy, while
> frame.f_locals being a proxy is okay?
>
As I understand it, they already drop out of compiled mode if they detect
that the code is tinkering with frame objects.
Having a
On Wed, 29 May 2019 at 16:08, Greg Ewing wrote:
>
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no ne
On Thu, 30 May 2019 at 09:12, Greg Ewing wrote:
>
> Nick Coghlan wrote:
> > If there was a compelling use case for letting "a = 1; exec(src);
> > print(a)" print something other than "1" at function scope, then I'd
> > be more amenable to t
On Fri., 31 May 2019, 5:20 am Xavier de Gaye, wrote:
> Currently f_locals is documented as readonly [1].
>
Read-only in the sense that you can't rebind it to point to a different
object - the dict it points to is mutable.
> The PEP says:
> > * "Don't change what isn't broken": the current trac
Hi folks,
The reference implementation for PEP 558 (my attempt to fix the interaction
between tracing functions and closure variables) is currently segfaulting
somewhere deep in the garbage collector, and I've found that there's an
issue with the PyEval_GetLocals() API returning a borrowed referen
On Fri., 31 May 2019, 6:34 pm Nathaniel Smith, wrote:
> I wouldn't mind having a little more breathing room. It's frustrating
> to miss the train, but these bugs are several decades old so I guess
> nothing terrible will happen if their fixes get delayed to 3.9.
>
And I could put that extra time
On Wed., 26 Jun. 2019, 4:14 pm Elias Zamaria, wrote:
> Nick Coghlan, I'm thinking about what you said, over a year ago, about
> finding a new champion for PEP 467. I think it would be a privilege to work
> on something like that, which may be used by millions of people over a
>
On Fri., 14 Jun. 2019, 2:05 am Steve Dower, wrote:
> On 13Jun2019 0816, Jeroen Demeyer wrote:
> > On 2019-06-13 17:11, Steve Dower wrote:
> >> The cost of that convenience is that
> >> we can never optimise internals because they are now public API.
> >
> > I think that the opposite is true actua
On Sat., 24 Oct. 2020, 4:21 am Guido van Rossum, wrote:
> On Fri, Oct 23, 2020 at 6:19 AM Tin Tvrtković
> wrote:
>
>> Hi,
>>
>> first of all, I'm a big fan of the changes being proposed here since in
>> my code I prefer the 'union' style of logic over the OO style.
>>
>> I was curious, though, i
hat
the new write-through proxy can reuse them without taking a separate
copy of them)
Cheers,
Nick.
P.S. If that sounds like a request for help, that's because it is ;)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Pytho
On Fri, 30 Oct 2020 at 20:52, Fabio Zadrozny wrote:
> On Fri, Oct 30, 2020 at 7:02 AM Nick Coghlan wrote:
> As a note, the current implementation does allow debuggers to mutate frame
> locals -- as long as they understand that they need to call `
> PyFrame_LocalsToFast ` when
On Fri, 30 Oct 2020 at 23:34, Victor Stinner wrote:
>
> Le ven. 30 oct. 2020 à 11:02, Nick Coghlan a écrit :
> > > Ok, I've created https://bugs.python.org/issue42197 to track it.
> >
> > Please also have a look at PEP 558 and its draft reference
> > imple
clarity of intent that PEP 642 might offer to not be worth that cost
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
ressions for subclauses that can be evaluated
early and potentially skip the full structural match if the guard
clause becomes necessarily false (while abiding by the requirement
that the guard expressions still follow normal left-to-right
evaluation rules - the subexpression evaluations are j
g, src is c
case (?is s, msg):
... # Any msg, src is s
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le..
...
Most ad hoc examples seem to lean towards sequence matching (I guess
because they're shorter), but it's accounting for the readability of
class and mapping patterns that places the most constraints on the
choice of prefix sigil.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gma
On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano, wrote:
>
>
>
> (3) Overriding the default comparison with an explicit sigil is
> allowed:
>
>
> case ==True:
> print("True, or 1, or 1.0, or 1+0j, etc")
>
> case ==None:
> print("None, or something weird that equals None")
>
On Sun., 1 Nov. 2020, 3:01 pm Guido van Rossum, wrote:
> On Sat, Oct 31, 2020 at 21:48 Dan Stromberg wrote:
>
>>
>> On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum
>> wrote:
>>
>>>
>>> I think this over-stresses the notion that users might want to override
>>> the comparison operator to be use
On Sun, 1 Nov 2020 at 11:29, Nick Coghlan wrote:
> On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano, wrote:
>> (4) Patterns which could conceivably be interpreted as assignment
>> targets default to capture patterns, because that's what is normally
>> wanted in patt
On Tue., 3 Nov. 2020, 8:07 am Ethan Furman, wrote:
> On 11/2/20 1:52 PM, 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 eq
r (like introducing a
SkippedBinding node into the AST so most of the compiler doesn't need
to care how the wildcard is spelled in the surface syntax), but I
doubt those are going to matter to most folks in deciding which of the
proposals on offer they prefer (or if they'd prefer continue wi
On Sat., 7 Nov. 2020, 9:56 am Greg Ewing,
wrote:
> On 7/11/20 4:03 am, Thomas Wouters wrote:
>
> > It's also why I'm not in favour of PEP 642 and other proposals for
> > solving some of the problems in the Structural Pattern Matching proposal
> > (sigils, etc): it widens the gap instead of closin
On Wed., 11 Nov. 2020, 8:10 am Brett Cannon, wrote:
>
>
> On Mon, Nov 9, 2020 at 10:40 PM Tobias Kohn wrote:
>
>> One of the simplest patterns is without doubt the literal pattern that
>> essential only matches itself (e.g., ``case 123:`` or ``case
>> 'abc':``). Any future unification of patter
n Thu, Nov 12, 2020 at 7:38 AM Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
>
>> Hi,
>>
>> Le 08/11/2020 à 07:47, Nick Coghlan a écrit :
>> > Hi folks,
>> >
>> > I have updated PEP 642 significantly based on the feedback receive
uality constraints), changes in spelling
(double-underscore vs single-underscore for wildcards), or slight
changes in how constructs are defined (the inferred constraints for
literals and attribute lookups get redefined as syntactic sugar for
their explicit counterparts, rather than being first cl
ainst a
non-wildcard irrefutable pattern)
case {"x" as a, "y" as b):
... # A mapping with "x" & "y" keys, capturing those to "a" and "b"
case {"x":__, "y":__}:
... # A
amenable to a similar solution (i.e. spell the capture
patterns for those cases with `as`, not `:` or `=`).
Cheers,
Nick.
P.S. I've started my TODO list for v3 at
https://github.com/ncoghlan/peps/issues/6
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
print("Other HTTP code")
It starts to look a bit more strange when matching sequences, though:
match seq:
case as first, *middle, as last:
... # Or should that be "*as middle"?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisba
le already works in the current master branch!
Nice!
I remember the work you put in getting runtime reconfiguration working
again for 3.7.1, so it's cool to see that capability maturing even
further.
> Nick Coghlan recently withdrew his PEP 432 since PEP 587 was rejected.
s/rejected/accepted/
On Sun., 15 Nov. 2020, 5:25 pm Guido van Rossum, wrote:
> But Point(x as a) already has a meaning in PEP 634; it’s a positional
> argument captured in x *and* in a. (Previously spelled as Point(a := x).
> The phrase ‘as a’ can be added after any pattern to *also* capture it in
> ‘a’. More typical
On Sun., 29 Nov. 2020, 6:31 am Paul Ganssle, wrote:
> Considering the people involved and the nature of the list, I suspect that
> adding a new @python.org mailing list would be better than discourse. In
> my experience, it's very difficult to just follow a single topic on the
> discourse, and mo
ot;x=y" looks up "x" as an instance attribute and binds
"y" as a local variable).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list -- python-dev@python.org
To un
port = optional_port
case __ as m:
raise TypeError(f"Unknown address format: {m!r:.200}")
port = int(port)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list -
On Mon, 4 Jan 2021, 2:19 am Barry Scott, wrote:
>
> I quickly read 642 v3 and missed an explanation about why the syntax to
> match a string object is
> str{} and not str. Are you saying that I MUST use {} so that when case is
> parsed its clear that its a class
> with no constraints?
>
Yes. "s
On Mon, 4 Jan 2021, 2:50 am Paul Moore, wrote:
> On Sun, 3 Jan 2021 at 16:26, Barry Scott wrote:
> > I read the above and believe I know what it meant without needing to
> read the PEP in detail.
> > I like that a lot.
>
> Personally, I read it and was horribly confused. I worked out most of
> i
On Mon, 4 Jan 2021, 4:34 am Ethan Furman, wrote:
> On 1/3/21 8:50 AM, Paul Moore wrote:
>
> > Personally, I read it and was horribly confused.
>
> >> case object{.host as host, .port as port}:
> >> pass
>
> Leading periods is a big no-go for me, for all the reasons listed in
On Mon, 4 Jan 2021 at 18:38, Paul Moore wrote:
>
> On Sun, 3 Jan 2021 at 23:38, Nick Coghlan wrote:
> >
> > The instance attribute syntax arose from trying to deal with two problems
> > from class patterns in PEP 634:
> >
> > * "ATTR=TARGET" using &
age feature rather than a CPython
implementation detail, then metaclasses could write:
cls_cell = namespace["__classcell__"]
@property
def defining_class(obj):
return cls_cell.get()
namespace[defining_class.fget.__name__] = defining_class
Cheers,
Nick.
--
Nick Coghlan
Both EnumMeta and ABCMeta should probably be relying on __set_name__ for
their per-member set up work these days, rather than deferring that work
until after __new__ returns.
Cheers,
Nick.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscri
On Sat, 9 Jan 2021, 7:07 am Joseph Martinot-Lagarde,
wrote:
> Paul Sokolovsky wrote:
> > Hello,
> > On Tue, 5 Jan 2021 20:37:27 +1000
> > Nick Coghlan ncogh...@gmail.com wrote:
> > > object(host=as host, port=as port}:", but that
> > > couldn't
On Sun, 10 Jan 2021, 12:22 am Paul Moore, wrote:
> On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote:
>
> > So, opposing Nick's proposal on the basis that it "looks like a set" is
> > just like opposing set literals on the basis they they "look like a
> > dict".
>
> That's not what I was doing (
On Sun, 10 Jan 2021, 12:54 am Nick Coghlan, wrote:
>
>
> On Sun, 10 Jan 2021, 12:22 am Paul Moore, wrote:
>
>> On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote:
>>
>>
>> The dictionary destructuring can act as an example. We know Nick's
>> positi
On Sat, 9 Jan 2021, 8:50 pm Paul Sokolovsky, wrote:
> >
> > The key difference relative to PEP 634 is that even when the code
> > author uses the shorthand form, *readers* will still get at least the
> > "as" keyword as a prompt,
>
> Ok, so let's summarize the alternatives:
>
> 1. PEP634, which s
On Sun, 10 Jan 2021, 2:55 am Paul Moore, wrote:
> On Sat, 9 Jan 2021 at 14:54, Nick Coghlan wrote:
>
> [...]
> > And I've already said I'd be fine with making the colon mandatory if the
> SC share that view.
>
> So the response to my comment that omitting the
On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky, wrote:
> And I patiently continue this thread, hoping that people whose argument
> would be along the lines of "I teach Python, and I don't want to teach
> my students 2 ways of doing the same thing, and which way use when. Why,
> if PEP634 offers jus
On Tue, 12 Jan 2021, 11:55 am Ethan Furman, wrote:
> On 1/7/21 4:56 AM, Nick Coghlan wrote:
>
> > Both EnumMeta and ABCMeta should probably be relying on `__set_name__`
> > for their per-member set up work these days, rather than deferring
> > that work until after
On Wed, 13 Jan 2021, 12:35 pm Larry Hastings, wrote:
>
> On 1/12/21 5:28 PM, Brett Cannon wrote:
>
> The other thing to keep in mind is we are talking about every module,
> class, and function getting 64 bytes ... which I bet isn't that much.
>
> Actually it's only every module and class. Functi
As far as I'm aware, the design is in a potentially acceptable state, I
just stalled out completely on the boring bits of finishing the
implementation of the write-through proxy:
* implement & test the rest of the mutable mapping methods
* refactor to properly share code with the odict implementat
Note that PEP 558 already doesn't change behaviour in tracing mode any more
though - that idea didn't survive the first round of review.
Cheers,
Nick.
On Wed, 27 Jan 2021, 9:58 pm Nick Coghlan, wrote:
> As far as I'm aware, the design is in a potentially acceptable state, I
Hmm, I need to review the state of my PEP PRs, as what's in the main repo
definitely isn't up to date. The tracing mode distinction should be long
gone, but is still mentioned in the text on python.org.
Cheers,
Nick.
On Wed, 27 Jan 2021, 10:03 pm Nick Coghlan, wrote:
> Note
PEP to try to clear that up:
https://github.com/python/peps/pull/1783/files
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-l
On Thu, 28 Jan 2021, 11:18 pm Mark Shannon, wrote:
>
> Hi Nick,
>
> Regarding `f_locals` PEP 558 states:
>
> """
> Instead of being a direct reference to the internal dynamic snapshot
> used to populate the independent snapshots returned by locals(),
> frame.f_locals will be updated to instead re
On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote:
> Hi
>
> It is a lot more complex, because you need to worry about coherency.
> With a direct proxy coherency is not an issue.
>
For things in the frame, it *is* a direct proxy - reads pull from the frame
object, and writes go to both the frame
On Wed, 20 Jan 2021 at 19:22, Victor Stinner wrote:
>
> Reply to an old thread.
>
> On Sat, Oct 31, 2020 at 8:02 AM Nick Coghlan wrote:
> > > Debuggers and profilers usually only care of specific frames or
> > > function calls (ex: 10% of function calls or even a s
On Sat, 30 Jan 2021 at 10:30, Nick Coghlan wrote:
> On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote:
>> With a direct proxy coherency is not an issue.
>
> For things in the frame, it *is* a direct proxy - reads pull from the frame
> object, and writes go to both the fr
On Sat, 30 Jan 2021, 10:22 pm Mark Shannon, wrote:
> Hi Nick,
>
> A couple more issues with PEP 558, as I see it.
>
>
> Lack of specification
> -
>
> There is no specification section in PEP 558.
>
> Much of PEP 558 describes the differences between the current behavior
> and
On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote:
> Hi Nick,
>
> On 30/01/2021 4:44 am, Nick Coghlan wrote:
> > On Sat, 30 Jan 2021 at 10:30, Nick Coghlan wrote:
> >> On Sat, 30 Jan 2021, 12:13 am Mark Shannon, wrote:
> >>> With a direct proxy coherency i
On Sat, 30 Jan 2021, 10:55 pm Nick Coghlan, wrote:
>
>
> On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote:
>
>>
>>
>
>> The break in compatibility with locals() seems much more intrusive, yet
>> you are OK with that (as am I).
>>
>
> PyEval_
On Sun, 31 Jan 2021 at 14:09, Nick Coghlan wrote:
> On Sat, 30 Jan 2021, 10:55 pm Nick Coghlan, wrote:
>> On Sat, 30 Jan 2021, 10:18 pm Mark Shannon, wrote:
>>> The break in compatibility with locals() seems much more intrusive, yet
>>> you are OK with that (as am I
On Wed, 3 Feb 2021, 10:16 pm Sven R. Kunze, wrote:
> Hi Mark,
>
> I've been working on a project heavily relying on frame.f_locals.
>
> Are you planning to remove it?
>
No, PEP 558 doesn't remove it, it enhances it to be a live view of the
frame state instead of an inconsistently updated snapsho
On Tue, 9 Feb 2021, 6:21 am Python Steering Council, <
steering-coun...@python.org> wrote:
> After much deliberation, the Python Steering Council is happy to announce
> that we have chosen to accept PEP 634, and its companion PEPs 635 and 636,
> collectively known as the Pattern Matching PEPs. We
bian didn't put the user's local bin directory on the
system path by default, so commands provided by user level package
installs didn't work without the user adjusting their PATH. The
CPython Windows installer also doesn't adjust PATH by default (for
good reasons). And unlike a
On Fri, 5 Mar 2021, 9:10 pm Steven D'Aprano, wrote:
> I was curious how and why return annotations use the arrow `->` symbol,
> so I went spelunking into the depths of the Python-Ideas and Python-Dev
> mailing lists.
>
> Much to my surprise, I couldn't find any discussion or debate about it.
>
I
On Sat, 27 Mar 2021, 9:24 am Guido van Rossum, wrote:
> Everyone,
>
> Given the resounding silence I'm inclined to submit this to the Steering
> Council. While I'm technically a co-author, Irit has done almost all the
> work, and she's done a great job. If there are no further issues I'll send
>
On Sun, 28 Mar 2021, 12:34 am Irit Katriel via Python-Dev, <
python-dev@python.org> wrote:
>
> Hi Paul,
>
> IIUC, you are saying that exception group should not be a builtin type
> because it is (1) complex (2) special-purposed. Instead, you propose that
> we make exception handling pluggable.
>
On Mon, 29 Mar 2021, 7:47 pm Mark Shannon, wrote:
[Guido wrote]
> >
> > Also, I think that we should probably separate this out in two separate
> > flag sets, one for subjects and one for class patterns -- it is pretty
> > confusing to merge the flag sets into a single value when their
> > appli
On Wed, 31 Mar 2021, 3:15 am Barry Warsaw, wrote:
> . We would like to eventually go farther, including deprecation of pth
> files entirely, but that is outside the scope of this PEP.
>
Please don't, since that would force everyone to start using PEP 648 just
to extend sys.path, which would be
On Wed, 31 Mar 2021 at 11:01, Barry Warsaw wrote:
>
> Kind of :)
>
> PEP 648 would definitely allow us to deprecate the executable part of pth
> files. I let my own biases leak in to my response because I would like to
> find a way to replace the sys.path feature of pth with something much more
Thanks for picking this back up!
The deferral section can go away now that you're actively working on it
again, and +1 from me on the resolution of the previously open questions
(although I wouldn't be particularly upset if the SC considered bchr
redundant, given that "bchr = bytes.fromord" is a t
On Fri, 16 Apr 2021, 3:14 pm Larry Hastings, wrote:
>
> Anyway I assume it wasn't "fixable". The compiler would presumably
> already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL
> would be cheaper every time for a global or builtin. The fact that it
> already doesn't do so i
On Sat, 17 Apr 2021, 3:51 am , wrote:
> Guys, the issue is that I most of the time see that somebody used C++ for
> one or two times, did not understand it and left with bad taste ...
>
I've got more than a decade and a half of experience with both C++ (dating
back to the relatively low quality
On Sun, 18 Apr 2021, 1:59 am Jelle Zijlstra,
wrote:
> El sáb, 17 abr 2021 a las 8:30, Nick Coghlan ()
> escribió:.
>
>>
>> Metaclass __prepare__ methods can inject names into the class namespace
>> that the compiler doesn't know about, so yeah, it unfortunately h
On Sun, 18 Apr 2021, 2:47 am Antoine Pitrou, wrote:
> On Sun, 18 Apr 2021 02:13:57 +1000
> Nick Coghlan wrote:
> >
> > If
> > they want automatic resource management, then we want them working out
> how
> > to lift the affected code out of C and into Python (for
On Mon, 12 Apr 2021, 1:48 pm Guido van Rossum, wrote:
>
> At the very least I recommend that the SC take this into account when they
> consider PEP 649. Accepting it has some nice benefits when it comes to the
> scoping rules for annotations -- but it would forever close the door for
> the "relax
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 maintain a check that something looks like a duck.
>>
>> `if hasattr(foo, 'c
On Fri, 23 Apr 2021, 12:34 pm Inada Naoki, wrote:
>
> I think using ABC to distinguish sequence or mapping is a bad idea.
>
> There are three policies:
>
> a) Use duck-typing; just us it as sequence. No type check at all.
> b) Use strict type checking; isinstance(x, list) / isinstance(x, (list,
>
On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, wrote:
>
> So I now suspect that my knee-jerk answer is wrong. Am I going too far
> down the rabbit hole? Should I *just* make the change for user classes
> and leave builtin classes untouched? What do you think?
>
I'd suggest kicking the can down
On Tue, 4 May 2021, 10:50 am Łukasz Langa, wrote:
>
> On 4 May 2021, at 02:04, Łukasz Langa wrote:
>
> Having renamed the branch in my fork first, the exact sequence I used on
> my own clone was:
>
> ❯ git checkout master
> ❯ git branch -m master main
> ❯ git fetch origin
> ❯ git branch -u origi
On Sat, 8 May 2021, 8:53 am Pablo Galindo Salgado,
wrote:
> > One thought: could the stored column position not include the
> indentation? Would that help?
>
> The compiler doesn't have access easy access to the source unfortunately
> so we don't know how much is the indentation. This can make li
1601 - 1700 of 6587 matches
Mail list logo
