t class
> creation time, and checking for duplicates in the pattern can be done at
> compile time.
>
> I assume the compile-time check only works for named keyword attributes.
> The current implementation already does this.
>
> -1 on checking `__match_args__` anywhere other t
imag=0):
> ...print ("Experimentally, int supports keyword matching.")
> ...
> Experimentally, int supports keyword matching.
>
In this case I propose adjusting the PEP text. See
https://github.com/python/peps/pull/1908
> I take this as +1 for having more precisely
On Sat, Apr 3, 2021 at 4:20 AM Mark Shannon wrote:
> Hi Guido,
>
> On 02/04/2021 10:05 pm, Guido van Rossum wrote:
> > On Fri, Apr 2, 2021 at 12:43 PM Brandt Bucher > [...]
> > -1 on checking `__match_args__` anywhere other than the match block
> > i
7;s intended for conveying
information to tools *other* than the type checker, for example schema
checkers etc.).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-th
ntax.
>
>
>
> I am not sure whether you considered and rejected this option, but if so,
> perhaps you could add some language to the Rejected Ideas about
> it. Ultimately we couldn’t come up with anything better, so we decided
> that the PEP as it stands solves the problem in
to Python itself,
and their development speed is much faster than that of Python. So whenever
new syntax is required the strain becomes obvious. Thanks for making that
observation!
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/20
otated -- it's an escape hook of last resort, not the
way to add new syntax in the future. New syntax should enhance usability
and readability, and Annotated does neither.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feminist
thon.org/archives/list/python-dev@python.org/message/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-
; results in repeated evaluation). As a workaround, I have code to "affix"
> the evaluated expression in __annotations__ value. PEP 649 would resolve
> this and eliminate the need for such a hack.
>
Why not submit a PR that adds caching to get_type_hints(), rather than
promote a p
On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:
> Le 13/04/2021 à 04:24, Guido van Rossum a écrit :
> > I've been thinking about this a bit, and I think that the way forward is
> > for Python to ignore the text of annota
On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings wrote:
>
> On 4/12/21 7:24 PM, Guido van Rossum wrote:
>
> I've been thinking about this a bit, and I think that the way forward is
> for Python to ignore the text of annotations ("relaxed annotation syntax"),
> no
quirement that there
> > should be a whitespace or delimiter between a numeric literal and the
> > following keyword.
> >
>
> New example was found recently (see https://bugs.python.org/issue43833).
>
> >>> [0x1for x in (1,2)]
> [31]
>
> It is parsed as [0x
e.
>
>
> On Wed, 14 Apr 2021 10:58:07 +0900
> Inada Naoki wrote:
> > On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings
> wrote:
> > >
> > >
> > > On 4/13/21 1:52 PM, Guido van Rossum wrote:
> > >
> > >
> > > Because typing is,
On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings wrote:
>
> On 4/13/21 1:52 PM, Guido van Rossum wrote:
>
> On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings
> wrote:
>
>>
>> On 4/12/21 7:24 PM, Guido van Rossum wrote:
>>
>> I've been thinking about
into account.
>
> Le 13/04/2021 à 19:30, Guido van Rossum a écrit :
> > On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello
> > > <mailto:devel2...@baptiste-carvello.net>> wrote:
> >
> > Then, what's wrong with quoting? It's just 2 characters
structure?
>
In `__annotations__` it would be a string, as currently implemented in the
3.10 alpha code. The string just might not be parsable as an expression.
In the AST, it will have to be a new node that just collects tokens and
bracketed things; that could be an array of low-level tokens.
-
ve to return some other representation. Presumably the (purely
hypothetical) new syntax would be syntactic sugar for something that can be
expressed as an object, just like (as of PEP 604) X | Y is syntactic sugar
for Union[X, Y].
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why i
Let's just wait for the SC to join the discussion. I'm sure they will,
eventually.
On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings wrote:
> On 4/14/21 10:44 AM, Guido van Rossum wrote:
>
> besides the cost of closing the door to relaxed annotation syntax, there's
&
On Thu, Apr 15, 2021 at 16:48 Christopher Barker
wrote:
> And as I noted in my last post — many folks have not been paying attention
> to the typing discussions because they didn’t realize it concerned them.
>
It seems a little disingenuous to claim discussions about annotations don’t
concern yo
On Thu, Apr 15, 2021 at 18:20 Barry Warsaw wrote:
> On Apr 15, 2021, at 17:47, Oscar Benjamin
> wrote:
> >
> > Would it be problematic to postpone making __future__.annotations the
> default?
>
> This is a good question, and I think the SC would really like to know if
> anybody has objections to
list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RWLOLMWLPZ3O5VO7OQZSHTQGR4ICXDJV/
>
Ditto run with Larry's branch (PEP 649, assuming it's on by default
there -- otherwise, modify the source by inserting the needed future import
at the top)
The repo is github.com/python/mypy, the subdirectory to look is mypy, WITH
THE EXCLUSION OF THE typeshed SUBDIRECTORY THEREOF.
--
nt) => str' instead of 'Callable[[int], str]' -- but it would be
unpleasant if that syntax had a meaning like you propose outside
annotations.
On Sat, Apr 17, 2021 at 7:12 PM Nick Coghlan wrote:
>
>
> On Mon, 12 Apr 2021, 1:48 pm Guido van Rossum, wrote:
>
>>
&g
asses like this?
@
class C:
def method(self) -> C: ...
(My apologies for not doing more research, but I figured this would be
quicker for you to answer than for me to research, given that I've never
used pydantic.)
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why
3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/XRLAOOIJZRPDT2AW6LW4UVBEJD5NKLV5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he
On Mon, Apr 19, 2021 at 8:16 PM Glenn Linderman
wrote:
> On 4/19/2021 12:44 PM, Guido van Rossum wrote:
> > We had a similar thing at Dropbox, where `# coding: pyxl` would enable
> > a preprocessor that allowed HTML embedded in the Python code. It
> > translated this to func
g
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/24OF6XMFYK4PO2VPY6UFT2S3CBZFNOKB/
> Code of Conduct: http
On Tue, Apr 20, 2021 at 11:12 AM Ethan Furman wrote:
> On 4/20/21 8:46 AM, Guido van Rossum wrote:
>
> > I'd guess it is totally up to the object, since str() calls `__str__`
> and format() calls `__format__`. Of course this
> > now begs the question whether those e
on.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committ...@python.org/message/CLVXXPQ2T2LQ5MP2Y53VVQFCXYWQJHKZ/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~g
tra metadata would specifically be at "join" points in the
> >> traceback, which are a thing that this PEP is creating :-). And it's
> >> useful for every user of EGs, since by definition, an EG is
> >> multiplexing exceptions from multiple sources, so i
______
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/li
TEOQYL/
>
>
> Here's kind of where we left it:
>
> On 1/12/21 7:48 PM, Guido van Rossum wrote:
>
> On Tue, Jan 12, 2021 at 6: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 ab
ttribute. (Though in the fullness of times, type objects
presumably won't be shared between multiple interpreters, which solves the
problem in a different way.)
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-usi
b1f53 2012-06-22 Modules/_ssl.c
> - sslerror_type_spec
>
> bc07cb883e 2012-06-14 Modules/_curses_panel.c
> - PyCursesPanel_Type_spec
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to
on.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CGVRT4A7XUOEVWHZY3ZX32CABD7OKR2A/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him
There’s something in the dev guide, but not about tense. Worth adding. (My
pet peeve is not to write “The foo module resets the bar state when spam
happens,” because that isn’t clear about whether that’s the before or after
behavior.)
On Thu, Apr 29, 2021 at 17:37 Ethan Furman wrote:
> On 4/29/2
Hm, I actually like the imperative. In a commit or news message it feels
very natural to me. And in that context there is no confusion about whether
we’re commanding anyone (maybe we’re commanding git? :-).
But I am the ultimate intuitive writer — I never took a class in English
grammar or writing
I propose “exception tuple”, since syntactically and semantically it must
be a tuple. (Same as for isinstance() and issubclass().)
On Sat, May 8, 2021 at 05:52 Thomas Grainger wrote:
> That's this bit:
>
> ```
> except (A, B):
>^^
> ```
>
> bpo-43149 currently calls it an "ex
That’s a discussion for another day.
On Sat, May 8, 2021 at 09:17 Thomas Grainger wrote:
> Would it be possible to drop the requirement that multiple exception types
> are parenthesized? Is it only ambiguous with the old Python2 syntax?
>
> On Sat, 8 May 2021, 20:15 Guido van Ro
il to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/SN5RMHWBWKRRP5ZKONKERJY3VQODRZMT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
ey'll adopt column information and render it
> as such.
>
> There's a difference between tracebacks dumped as plain text (utf-8) by
> traceback.print_exc() appearing on stderr or directed into log files and
> what can be displayed within a terminal. It is highly unusual to
racker where we're discussing
various plans and ideas
Contributions are welcome!
I've also published the slides of my language summit presentation:
https://github.com/faster-cpython/ideas/blob/main/FasterCPythonDark.pdf
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(w
helmed by OpenSource tasks. If it were some obscure
> project
> I understand but not one of the most popular OpenSource product of today.
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about <https://compileralchemy.github.io/> | blog
> <https://www.python
There are a few mentions of Debian, but no explanation of what the issue is
about. Can you elaborate on that?
On Tue, May 18, 2021 at 06:15 Thomas Wouters wrote:
>
> The SC has just published the community update for March:
>
>
> https://github.com/python/steering-council/blob/main/updates/2021-
Thanks, that's the context I was missing!
Package management is hard. No wonder some folks try to bypass the whole
thing and use Docker images instead. :-(
On Tue, May 18, 2021 at 8:56 AM Christian Heimes
wrote:
> On 18/05/2021 16.19, Guido van Rossum wrote:
> > There are a f
gt;
> Skip
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail
> On Fri, May 21, 2021 at 2:48 PM Guido van Rossum wrote:
>
>> I suspect that you're running into the issue where compiler optimizations
>> are *forced* on for ceval.c.
>>
>> There's a comment near the top about this. Just comment out this line:
>>
>
ssage/UCSCYMMJA4UBBUZLUHSEOE2POEBNTKLF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
__
atch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message arc
hat).
>
> Victor
>
> On Mon, May 24, 2021 at 5:54 PM Guido van Rossum wrote:
> >
> > I'm confused. I've always assumed that --with-pydebug was intended for
> the situation where you're modifying the C code, so obviously you might
> have to debug C co
Sorry, that was me. :-)
On Tue, May 25, 2021 at 12:24 PM Brett Cannon wrote:
>
>
> On Fri, May 21, 2021 at 9:25 AM Julien Palard via Python-Dev <
> python-dev@python.org> wrote:
>
>> Le 5/11/21 à 8:39 PM, Guido van Rossum a écrit :
>> > I doubt that anyone h
re going to implement a specializing adaptive
interpreter, with the level of detail that's currently in the PEP? I don't
recall other standards track PEPs that don't also spell out the
specification of the proposal in detail.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him *
On Tue, May 25, 2021 at 1:50 PM Łukasz Langa wrote:
>
> On 25 May 2021, at 21:57, Guido van Rossum wrote:
>
> On Tue, May 25, 2021 at 12:34 PM Brett Cannon wrote:
>
>>
>> I personally think it should be a Standards Track PEP. This PEP isn't
>> docum
On Tue, May 25, 2021 at 7:56 PM Brett Cannon wrote:
>
> On Tue., May 25, 2021, 12:58 Guido van Rossum, wrote:
>
>> [...]
>> Or do you think the "Standards Track" PEP should just codify general
>> agreement that we're going to implement a specializing
On Tue, May 25, 2021 at 7:42 PM Inada Naoki wrote:
> On Tue, May 25, 2021 at 5:38 AM Guido van Rossum wrote:
> >
> > To the contrary, I think if you want the CI jobs to be faster you should
> add the CFLAGS to the configure call used to run the CI jobs.
> >
>
> -
__
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@pytho
d change the topic
> (as happened with #python-fr).
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-Dev
mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZF64Y53M3KEKAGROORJA6SD6GPX2HDJO/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pro
What are you trying to get from the archives? It is *possible* that I have
a personal archive saved somewhere.
On Sun, May 30, 2021 at 02:39 Julien Palard wrote:
> Le 5/29/21 à 11:14 PM, Guido van Rossum a écrit :
> > It looks like what's left of the archives is largely
ak
for line in lines:
Maybe there was an intermediate step (I vaguely recall a special dunder?),
but eventually we realized that the best way to write this was just
for line in f:
(the iterator can buffer internally) and we accepted that you can only
iterate once over a file --
d an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CW2SAOGIO5EIXU7GJZIN26MLF6AC2HD5/
> Code of Conduct: http://python.org/psf/codeofconduct/
&g
.
So maybe the docs should grow a standard way of saying "this is an unstable
API"?
Would we need a PEP to create an initial list of APIs (modules, classes,
etc.) that are considered unstable?
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronou
n Thu, Jun 3, 2021 at 10:32 AM Senthil Kumaran wrote:
> On Thu, Jun 03, 2021 at 10:10:53AM -0700, Guido van Rossum wrote:
> > This is not a complete thought yet, but it occurred to me that while we
> have
> > deprecated APIs (which will eventually go away), and provisional APIs
On Thu, Jun 3, 2021 at 11:11 Gregory P. Smith wrote:
> One obvious now in hindsight question: Why are any of these APIs even
> public? They all deserve underscore prefixed names to highlight their
> private-ness and potential instability.
>
Because they are still useful when manipulating or intr
quot;. For example, sub-modules of a package are
> called "_something.py" and they exposed in package/__init__.py (or
> another public module).
>
I was primarily thinking of the docs.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him *
ould be "dead API", what is a dead
API exactly? And doesn't it follow that all APIs are living? If we stick
with unstable, we're adopting a term that's in use by at least one other
language community (Rust), and the slightly negative connotation is welcome
-- people should thin
ll continue to exist for many versions, but their output can
> change? In one sense, dis.dis() always does the exact same thing: it
> shows you the disassembly of a piece of code. In another sense, its
> output changes drastically when things change.
>
That's debatable. I sure
On Fri, Jun 4, 2021 at 6:15 AM Victor Stinner wrote:
> On Fri, Jun 4, 2021 at 12:29 AM Guido van Rossum wrote:
> >> In the C API, there is the internal C API which fits with your
> >> description. To access it, you have to declare the
> >> Py_BUILD_CORE_MODULE macr
building mindshare for limiting API use to the stable
API. Thanks Petr for pushing this!
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
I don’t see how the stable ABI works as a substitute for vendoring Python.
A lot of other things can still vary even when the C API remains the same!
(E.g. syntax, and stdlib behavior.)
On Thu, Jun 17, 2021 at 11:49 Steve Dower wrote:
> On 6/9/2021 2:20 PM, Petr Viktorin wrote:
> > On 09. 06. 21
Can you elaborate on that use case? Which two applications are you thinking
of, and what was your goal in driving them? This sounds interesting but I
haven’t encountered this myself.
On Fri, Jun 18, 2021 at 09:44 Baptiste Carvello <
devel2...@baptiste-carvello.net> wrote:
> Le 18/06/2021 à 08:50,
ste-carvello.net> wrote:
> Hi,
>
> Le 18/06/2021 à 21:00, Guido van Rossum a écrit :
> > Can you elaborate on that use case? Which two applications are you
> > thinking of, and what was your goal in driving them? This sounds
> > interesting but I haven’t encountered this m
; To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
>> Code of Conduct: http
is feature to format()? It seems
doable (at least for keyword args -- for positional args I don't think it
makes sense).
Honestly, the rest of the discussion belongs on python-ideas.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministin
in cmd.pyi
class Cmd:
prompt: str
identchars: str
ruler: str
...
those are all instance attribute declarations.
I think that you're running into a different mypy bug, which is that you
can't override a plain attribute with a property in a subclass.
I think there&#
Okay, then Chris Barker’s explanation applies.
On Sat, Jun 26, 2021 at 16:35 Daniel Walker wrote:
> I wasn't looking at the type stub but cmd.py itself. It has
>
> PROMPT = '(Cmd) '
> ...
>
> class Cmd:
> prompt = PROMPT
> ...
>
> On Sat, Ju
responses you are getting help you
see why this is not so simple.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
Can we call this discussion closed? There’s not much more to be said. I’m
not picking on you, Chris, I just think that not much will be gained by
continuing the thread.
I appreciate Esmeralda’s messages and all the responses. Now let’s go fix
some bugs! :-)
(Obligatory XKCD comic:
https://xkcd.co
__
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.pytho
Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/QQOYHF77AFRZZ3ZPYZDNIPBGC2
Local_VarKind`, `_PyLocal_GetVarKind()`, `_PyLocal_SetVarKind()`. (The
API for this is very much in flux -- we'll settle by 3.11 beta 1 though. I
expect we'll also have some Python-level public (but unstable) API to
access these flags, so people can play around with this stuff.)
--
--Gu
dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/QLPJWPVNDZ3ODMS275VDW4M2UW6PUW5N/
> Code of Conduct: http://python.org/psf/codeofconduct
on-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3O6STJNH6NCNWEBOGV3OB3DC6M2K47RN/
> Code of Conduct: http://python.org/psf/codeofcond
Maybe you should also mention that in 3.11 we’re introducing a new concept,
dict *keys* version, which is more useful (for the specializing interpreter
anyway).
On Thu, Jul 29, 2021 at 12:47 Mark Shannon wrote:
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
>
> I implemented a version of this in
> https://github.com/larryhastings/co_annotations/pull/3 but Larry didn't
> like it.
>
However, I do like it, despite all Larry's arguing against it.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun he
As it happens, I have a working prototype of lazy in marshaling that would
work well for this.
On Wed, Aug 11, 2021 at 06:07 Larry Hastings wrote:
> On 8/11/21 5:21 AM, Inada Naoki wrote:
>
> But memory footprint and GC time is still an issue.
> Annotations in PEP 649 semantics can be much heavi
Oh, I agree it shouldn’t reference the typing module. But it should not
raise NameError. This whole thing already is a special case. We can debate
what else it should, e.g. skip the name, return a fixed error token, return
an error token that includes the name that failed (this is part if the
NameE
nction objects for annotation too.
>
> Function objects are heavier than code objects. And they are GC-tracked
> objects.
>
> I want to know how we can reduce the function objects created for
> annotation in PEP 649, before deprecating PEP 563.
>
> --
> Inada Naoki
>
I will try to find time to review the code.
On Thu, Aug 12, 2021 at 08:56 Larry Hastings wrote:
>
> On 8/12/21 8:25 AM, Guido van Rossum wrote:
>
> Maybe we could specialize the heck out of this and not bother with a
> function object? In the end we want to execute the cod
nt containing all the necessary
fields.
Thoughts? I'm especially interested in Petr's opinion given that this is a
case where we'd like to deprecate something in the stable ABI.
See also discussion in https://bugs.python.org/issue40222 (esp. near the
end).
--
--Guido van
On Fri, Aug 13, 2021 at 11:17 AM Terry Reedy wrote:
> On 8/13/2021 1:24 PM, Guido van Rossum wrote:
> [...]
> > Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the
> > PEP 387 stable ABI. What should we do?
>
> PEP 387 is Backwards Comp
On Sat, Aug 14, 2021 at 4:56 AM Serhiy Storchaka
wrote:
> 13.08.21 20:24, Guido van Rossum пише:
> > If these weren't part of the stable ABI, I'd choose (E). But because
> > they are, I think only (A) or (B) are our options. The problem with (C)
> > is that if ther
On Mon, Aug 16, 2021 at 9:30 AM Steve Dower wrote:
> On 8/16/2021 12:47 AM, Guido van Rossum wrote:
> > My current proposal is to issue a DeprecationWarning in PyCode_New() and
> > PyCode_NewWithPosArgs(), which can be turned into an error using a
> > command-line flag. If i
emented it). You gave me an idea now: the C
equivalent to .replace() could use the same input structure; one can leave
fields NULL that should be copied from the original unmodified.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is
hat isn't
>> _our_ problem to solve. The more often we change internal APIs that things
>> depend on, the more people will move their projects towards doing the right
>> thing with regards to either not using said APIs or rerunning an up to date
>> code generator as part of
ling list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4RH5YCXIHIP6
Hm, I don’t think the major use for bchr() will be with a constant.
On Sun, Aug 22, 2021 at 14:48 Gregory P. Smith wrote:
>
> On Tue, Aug 10, 2021 at 3:48 PM Christopher Barker
> wrote:
>
>> On Tue, Aug 10, 2021 at 3:00 PM wrote:
>>
>>> The history of bytes/bytearray is a dual-purpose view. I
On Sat, Aug 21, 2021 at 8:52 PM Nick Coghlan wrote:
>
> On Sun, 22 Aug 2021, 10:47 am Guido van Rossum, wrote:
>
>>
>> Everything here is about locals() and f_locals in *function scope*. (I
>> use f_locals to refer to the f_locals field of frame objects as seen f
cals() just
returns dict(sys._getframe().f_locals).
> None of this is clear (at least not to me) from PEP 558.
>
One problem with PEP 558 is that it's got too many words, and it's lacking
a section that crisply describes the semantics of the proposed
implementation. I've suggest
On Mon, Aug 23, 2021 at 8:46 AM Mark Shannon wrote:
> Hi Guido,
>
> On 23/08/2021 3:53 pm, Guido van Rossum wrote:
> > On Mon, Aug 23, 2021 at 4:38 AM Mark Shannon > <mailto:m...@hotpy.org>> wrote:
> >
> > Hi Nick,
> >
> > On 22/08/
1501 - 1600 of 6462 matches
Mail list logo
