By the time a KeyboardInterrupt or SystemExit is being grouped into an
ExceptionGroup, it already isn't being treated as an immediate interruption ...
it has (presumably) already killed its own execution path, but it should not
kill the program as a whole. Whether ExceptionGroup inherits from E
Are you saying that
except *ValueError as e:
will catch
ValueError
and
ExceptionGroup(ValueError)
but miss
ExceptionGroup(ExceptionGroup(ValueError))
?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email t
If it (compatible __new__ and __init__) needs to be checked at definition time,
just try create an instance passing the same arguments you would pass to the
base class. If the creation it doesn't raise an exception, that is good enough.
This isn't about theoretical type safety against malice; i
Ideally, (at least) trivial subclasses could be declared, and the class itself
would serve as the marker. I would prefer regular subclasses, so that they
could offer methods as well. Alternatively, at least copy the instance
__dict__ to the new ExceptionGroup instance.
By compatible __init__
I think his point is that most of his students (economics or business, rather
than comp sci) will never need to use Perl or C or Java. Python is friendly
enough to be useful, but this is still a major pain point.
The problem is made worse because it often hits at the beginning instead of 7
l
> We keep the ability to wrap any exception, while we lose the "fail-fast if
> you forget to handle an ExceptionGroup" feature, which was intended as a
> kindness towards those who abuse "except Exception".
How is this a kindness?
Whenever I've used except Exception or stronger, it was a sanitary
FWIW, the only situation I can think of where you would care that the enclosed
exception instances are BaseException but not regular Exception is interactive
debugging, and even then there are enough other ways to kill the whole process
that I think most people would use one of them instead of w
You still need except* for the (unusual?) case where the ExceptionGroup
contains multiple individual Exceptions, and you want them all to be processed.
(This possibility is the justification for the PEP, but the difficulty of
associating an exception with the specific task that raised it sugges
> Thank you for turning to what happens with 'except ValueError' when an
> ExceptionGroup[ValueError] is raised, this is important.
> I'm not sure it's safe to assume that it is necessarily a > programming
>error, and that the interpreter can essentially break the program in this
> case.
I'm bett
ValueError("Partner: 3 File: 127 record: 93 is missing field: currency") tells
the production support people who to contact and what to say.
I'm not sure what additional context would be helpful, let alone how it might
have been available "at the time", but lost now that the ValueAttribute is
> Why would you want a different flavor of ExceptionGroup?
The easiest example you took care of by saving the exceptions in a list instead
of a set. Next would be the ExceptionGroup vs BaseExceptionGroup that I
*don't* like, but someone might. There are also libraries that promise to
raise on
[They are not CS students]
> Why is that relevant?
Because for many users, python is NOT a programming language; it is an
application like any other. It happens to be very powerful and flexible, but
the point isn't to program; it is to produce better reports.
If the hurdle to get started (eit
> In fact, if you're happy with RuntimeError here, making
> ExceptionGroup inherit from Exception (instead of
> BaseException) would do just as well -- after all RuntimeError
> is pretty arbitrary
Agreed, and I think it should inherit from Exception.
> (in fact, it's wrong, because the problem is
> And unlike a venv, "python -m" doesn't let you ensure
> that the code executed is the version installed in user site-packages
I have had enough problems with this that when I do modify/replace something, I
put in a marker that I can check for explicitly. Expecting this marker to run
automatic
Looking at the following PEP example, I'm still not sure what he should do to
handle some but not all OSError instances:
...raise ExceptionGroup(
... "eg",
... [
... ValueError(1),
... TypeError(2),
... OSError(3),
...
Paul Moore wrote:
> What's wrong with Version(module.__version__)? And if the __version__
> attribute isn't a valid version, raise an exception?
I don't have a deep answer, but I do think __version__ should be specified (or
at least mentioned) at https://docs.python.org/3/reference/datamodel.html
Baptiste Carvello wrote:
> Le 14/04/2021 à 19:44, Guido van Rossum a écrit :
> > No, what I heard is that, since in *most* cases the string quotes are
> > not needed, people are surprised and annoyed when they encounter cases
> > where they are needed.
> Well, I had assumed quotes would be used i
Larry Hastings wrote:
> On 4/14/21 1:42 PM, Baptiste Carvello wrote:
> > Are there specific annoyances associated with quoting always, apart
> > from the 2 more characters?
> Yes. Since the quoted strings aren't parsed by Python, syntax errors in
> these strings go undetected until somebody doe
Christopher Barker wrote:
> ... folks don't want annotations to hurt run-time performance,
> particularly when they are being used primarily for
> pre-run-time static type checking.
So are we looking for three separate optimization levels at compile time?
Base level: evaluate everything, keep
Nathaniel Smith (in a conversation with Irit) wrote:
> ... suggested having each
> 'except Blah as exc' clause be executed once, receiving an
> ExceptionGroup containing all the Blah exceptions. Guido pointed out
> that this broke typing -- 'exc' would not longer have type 'Blah' --
> and I was li
Antoine Pitrou wrote:
> On Sat, 8 May 2021 02:58:40 +
> Neil Schemenauer nas-pyt...@arctrix.com wrote:
> > It would be cool if we could mmap the pyc files and have the VM run
> > code without an unmarshal step.
> > What happens if another process mutates or truncates the file while the
> CPyth
esmeraldagarcia＠byom.de wrote:
>> "If you would like more value out of it or to speed
>> up the process, you can provide your own reviews." -
> Seriously? I can't help but feel like that comment
> sounds kinda arrogant.
I've done it and it sometimes helps. That said, there is still a problem -
How badly would the code objects be crippled?
>(no exception table, no endline/column tables,
> qualname defaults to name)
That sounds like it would be a pain for debugging, but might still work for
source/code that hadn't actually changed and was just being re-compiled and run
(possibly with t
Guido van Rossum wrote:
> On Fri, Aug 13, 2021 at 11:17 AM Terry Reedy tjre...@udel.edu wrote:
> > On 8/13/2021 1:24 PM, Guido van Rossum wrote:
> I'm actually not sure what use case you're talking about.
"source/code that hadn't actually changed and was just being re-compiled and
run". I've do
except* looks like the exception statement has a footnote, which isn't wrong.
*(E1, E2) looks like they are being unpacked, which is wrong.
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.
Yury Selivanov wrote:
> IMO it would make more sense to write `except all E`,
> but `all()` is a built-in and so this would be at
> odds with (1). [`try: .. except group:` already being valid
> syntax today ]
If anything, that makes "except all E" less of a problem; the built-in all is
not an
(On June 19, 2013) Barry Warsaw wrote about porting mailman from
flufl.enum to the stdlib.enum:
> Switching from call syntax to getitem syntax for looking up an
> enum member by name, e.g.
>-delivery_mode = DeliveryMode(data['delivery_mode'])
>+delivery_mode = Delivery
On Mon, Oct 10, 2016, at 14:04, MRAB wrote:
> Instead of locking the object, could we keep the GIL, but have it
> normally released?
> A thread could then still call a function such as PyWeakref_GetObject()
> that returns a borrowed reference, but only if it's holding the GIL. It
> would be able
I agree that startup time is a problem, but I wonder if some of the pain
could be mitigated by using a persistent process.
For example, in
https://mail.python.org/pipermail/python-dev/2017-July/148664.html Ben Hoyt
mentions that the Google Cloud SDK (CLI) team has found it "especially
problematic
Building on Brett's suggestion:
FrameContext: used in/writable by one frame
ContextStack: a FrameContext and its various fallbacks
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
In https://mail.python.org/pipermail/python-dev/2017-August/148869.html
Nick Coghlan wrote:
> * what we want to capture at generator creation time is
> the context where writes will happen, and we also
> want that to be the innermost context used for lookups
So when creating a generator, we w
On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
at 12:32 AM, Jim J. Jewett wrote:
> The key requirement for using immutable datastructures is to make
> "get_execution_context" operation fast.
Do you really need the whole execution context, or do you ju
Should PEP 550 discuss other implementations? E.g., the object space used
in pypy?
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev
On Aug 24, 2017 11:02 AM, "Yury Selivanov" wrote:
On Thu, Aug 24, 2017 at 10:05 AM, Jim J. Jewett
wrote:
> On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017
> at 12:32 AM, Jim J. Jewett wrote:
If you look at this small example:
foo = new_context_k
I think there is general consensus that this should go in a module other
than sys. (At least a submodule.)
The specific names are still To Be Determined, but I suspect seeing the
functions and objects as part of a named module will affect what works.
So I am requesting that the next iteration jus
Does setting an ImplicitScopeVar to None set the value to None, or just
remove it?
If it removes it, does that effectively unmask a previously masked value?
If it really sets to None, then is there a way to explicitly unmask
previously masked values?
Perhaps the initial constructor should requir
It isn't clear to me that reusing the inspect.Signature object was even
considered. If it was rejected as too complicated for most signatures, please
put that in the PEP. My own opinion, admittedly not as a typing fan, is that
if you need enough details to want more than Callable, then you pro
Steve Dower wrote:
> Okay, I'll let myself get sucked into responding ONE TIME, but only
> because you gave me such a nice API to work with :)
This actually pushed me hard towards adding the null-aware operators. I agree
that the named-function approach Paul suggests is better. I admit that th
Larry Hastings wrote:
> In Python, if you evaluate an undefined name, Python raises a
> NameError. This is so consistent I'm willing to call it a "rule".
Would it help the think of the function creation as catching that exception,
and then finishing construction with its own version of NaN?
"The East Asian symbol for *ten* looks like a plus sign, so ``十= 10`` is a
complete Python statement."
Normally, an identifier must begin with a letter, and numbers can only be used
in the second and subsequent positions. (XID_CONTINUE instead of XID_START)
The fact that some characters with
Serhiy Storchaka wrote:
> 02.11.21 16:16, Petr Viktorin пише:
> > As for \0, can we ban all ASCII & C1 control characters except
> > whitespace? I see no place for them in source code.
> All control characters except CR, LF, TAB and FF are banned outside
> comments and string literals. I think it
Chris Angelico wrote:
> I'm not sure how a linter would stop
> someone from publishing code on PyPI that causes confusion by its
> character encoding, for instance.
If it becomes important, the cheeseshop backend can run various validations
(including a linter) on submissions, and include those r
Stephen J. Turnbull wrote:
> Jim J. Jewett writes:
> > At the time, we considered it, and we also considered a narrower
> > restriction on using multiple scripts in the same identifier, or at
> > least the same identifier portion (so it was OK if separated by
> > _)
ptmcg＠austin.rr.com wrote:
> ... add a cautionary section on homoglyphs, specifically citing
> “A” (LATIN CAPITAL LETTER A) and “Α” (GREEK CAPITAL LETTER ALPHA)
> as an example problem pair.
There is a unicode tech report about confusables, but it is never clear where
to stop. Are I (upper cas
Compatibility variants can look different, but they can also look identical.
Allowing any non-ASCII characters was worrisome because of the security
implications of confusables. Squashing compatibility characters seemed the
more conservative choice at the time. Stestagg's example:
е = lam
Stephen J. Turnbull wrote:
> Christopher Barker writes:
> > For example, in writing math we often use different scripts to mean
> > different things (e.g. TeX's Blackboard Bold). So if I were to use
> > some of the Unicode Mathematical Alphanumeric Symbols, I wouldn't
> > want them to get normali
Steven D'Aprano wrote:
> I think
> that many editors in common use don't support bidirectional text, or at
> least the ones I use don't seem to support it fully or correctly. ...
> But, if there is a concrete threat beyond "it looks weird", that it
> another issue.
Based on the original post (a
Paul Moore wrote:
> More hazy memories here, but I think the original proposal left open
> the possibility of annotations not being types at all - for example,
> being docstrings for the arguments, or option names for a "function
> call to CLI" tool, etc.
Absolutely.
While it was clear that Guid
Steven D'Aprano wrote:
> On Sat, Nov 20, 2021 at 11:46:56PM -0800, Christopher Barker wrote:
> Maybe PEP 563 could include a decorator in the typing module to
> destringify all the annotations in a class or function?
If it were in an annotations module, that would probably be sufficient.
If it
Christian Heimes wrote:
> On 09/12/2021 19.26, Petr Viktorin wrote:
> > If the code is the authoritative source of truth, we need a proper
> > parser to extract the information. ... unfortunately I don't trust it
> > enough to let it define the API. Bugs in the parser could result in
> > the API
> In Python 3.11, Python still implements around 100 types as "static
> types" which are not compatible with subinterpreters, like
> &PyLong_Type and &PyUnicode_Type. I opened
> https://bugs.python.org/issue40601 about these static types, but it
> seems like changing it may break the C API *and* th
Immortal objects shouldn't be reclaimed by garbage collection, but they still
count as potential external roots for non-cyclic liveness.
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
How common is it to reload a module in production code?
It seems like "object created at the module level" (excluding __main__) is at
least as good of an heuristic for immortality as "string that meets the
syntactic requirements for an identifier". Perhaps also anything created as
part of clas
Guido van Rossum wrote:
> On Wed, Dec 15, 2021 at 6:57 PM Jim J. Jewett jimjjew...@gmail.com wrote:
> > Immortal objects shouldn't be reclaimed by garbage collection, but they
> > still count as potential external roots for non-cyclic liveness.
> So everything reference
Petr Viktorin wrote:
>>> In Python 3.11, Python still implements around 100 types as "static
>>> types" which are not compatible with subinterpreters,
...
>>> seems like changing it may break the C API *and* the stable ABI
> > If sub-interpreters each need their own copy of even immutable built-in
Why are Immutability and transitive Immortality needed to share an object
across interpreters?
Are you assuming that a change in one interpreter should not be seen by others?
(Typical case, but not always true.)
Or are you saying that there is a technical problem such that a change -- even
Steven D'Aprano wrote:
> In comparison, Mark's version:
> @Callable
> def IntToIntFunc(a:int)->int:
> pass
> # in the type declaration
> func: IntToIntFunc
> uses 54 characters, plus spaces and newlines (including 7 punctuation
> characters); it takes up three extra lines, plus a b
Steven D'Aprano wrote:uble the size of Callable.
> > I think it takes only the characters needed to write the name IntToIntFunc.
> ... you may only use it once.
Could you provide an example where it is only used once?
The only way I can imagine is that you use it here when when defining your
com
I'm seeing enough different interpretations to think things aren't quite
specified -- but I'm not sure if it matters.
(1) Is any of this something that should affect computation, or is it really
just a question of how to interpret possibly ambiguous documentation?
(2) Are any of these troubl
Steven D'Aprano wrote:
> On Sat, Jan 08, 2022 at 12:59:38AM +0100, jack.jan...@cwi.nl wrote:
> For example, the arrow syntax for Callable `(int) -> str` (if accepted)
> could be a plain old Python expression, usable anywhere the plain old
> Python expression `Callable[[int], str]` would be.
In
Guido van Rossum wrote:
> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
> blah".format(x=1) as a docstring either, not "
- Should we require the presence of NaNs in order for CPython to build?
- Should we require IEEE 754 floating-point for CPython-the-implementation?
- Should we require IEEE 754 floating-point for Python-the-language?
I don't have strong opinions on the first two, but for the language definition,
There are problems with urllib. With hindsight, it would have been nice to do
a few things differently. But that doesn't make migrating away from it any
easier.
This thread has mentioned several "better" alternatives -- but with the
exception of 3rd party Requests, the docs don't even mention
> Why do you think the stdlib *must *provide an example implementation
> for this specific scenario? Is there something unique to HTTP request
> handling that you feel is important to demonstrate?
*must* is too strong, but I would use a very strong *should*.
I think the stdlib should provide sim
I think you skimmed over "A floating point expert can probably look at this ...
"
I remember a time when I just assumed more bits was better, and a later time
when I figured smaller was better, and a still later time when I wanted to
match the published requirements for bitsize. So that was se
I suggest being a little more explicit (even blatant) that the particular
details of:
(1) which subset of functionally immortal objects are marked as immortal
(2) how to mark something as immortal
(3) how to recognize something as immortal
(4) which memory-management activities are skipped or
> "periodically reset the refcount for immortal objects (only enable this
> if a stable ABI extension is imported?)" -- that sounds quite expensive,
> both at runtime and maintenance-wise.
As I understand it, the plan is to represent an immortal object by setting two
high-order bits to 1. The h
> Is ``allow_all_extensions`` the best name for the context manager?
Nope. I'm pretty sure that "parallel processing via multiple simultaneous
interpreters" won't be the only reason people ever want to exclude certain
extensions.
It might be easier to express that through package or module nam
> That sounds like a horrible idea. The GIL should never be held during an
> I/O operation.
For a greenfield design, I agree that it would be perverse. But I thought we
were talking about affordances for transitions from code that was written
without consideration of multiple interpreters. In
There is an important difference between monkeypatching in general, vs
monkey-patching an object that was explicitly marked and documented as
expecting a monkeypatch.
(That said, my personal opinion is that this is pretty heavyweight for very
little gain; why not just create a placeholder class
FWIW, the web archive
https://mail.python.org/archives/list/python-dev@python.org/thread/ZX2JLOZDOXWVBQLKE4UCVTU5JABPQSLB/
does not seem to display the problems ... apparently the individual messages
are not included in view source, and are cleaned up for chrome's inspect. I'm
not sure whether
Is it possible for the installer to check whether or not there is a
pre-existing system-wide launcher, and only do the complicated stuff
if it is actually there?
-jJ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
On Wed, Sep 11, 2019 at 5:36 AM Steve Dower wrote:
> But you mention "only do ... stuff if ... there" - what stuff are you
> referring to? The installer should do *less* if it's partially installed
> already, not more.
My understanding was that
(1) You believe the py.exe launcher should be instal
I wouldn't worry too much about the the Singletons in this issue; they could be
solved in any of several ways, all of which would be improvements conceptually
-- if performance and backwards compatibility were resolved.
In theory, the incr/decr pair should be delegated to the memory store, with
There is value in saying "These are things that might be limited by the
implementation."
There is great value in documenting the limits that CPython in particular
currently chooses to enforce. Users may want to see the numbers, and other
implementations may wish to match or exceed these minimu
David Mertz wrote:
> On Wed, Dec 11, 2019, 6:40 AM Mark Shannon m...@hotpy.org
> wrote:
> > I NEVER care about memory at all... except inasmuch as it effects speed.
In my admittedly idiosyncratic experience, memory is usually by far my most
constrained resource. I do care about it, even if pyth
Victor Stinner wrote:
> I started to modify Python internals to pass explicitly the Python
> thread state ("tstate") to internal C a functions:
Is work this summarized somewhere like a PEP?
> https://vstinner.github.io/cpython-pass-tstate.html
describes the motivation, but not the details on why
Why do sub-interpreters require (separate and) heap-allocated types?
It seems types that are statically allocated are a pretty good use for immortal
objects, where you never change the refcount ... and then I don't see why you
need more than one copy.
__
Ronald Oussoren wrote:
> > On 28 Apr 2020, at 20:38, Jim J. Jewett jimjjew...@gmail.com wrote:
> > Why do sub-interpreters require (separate and) heap-allocated types?
> > It seems types that are statically allocated are a pretty good use for
> > immortal
> > objec
Even then, disconnect seems like the primary use case, with a
channel.kill_for_all being a specialized subclass. One argument for leaving it
to a subclass is that it isn't clear what other interpreters should do when
that happens. Shut down? Start getting exceptions if they happen to use it
David Mertz wrote:
> Fwiw, I don't think it changes my order, but 'strict' is a better word than
> 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> they used "equal".
I would say that 'equal' is worse than 'strict'. but 'strict' is also wrong.
Zipping to a potentiall
I don't think that sharing data only by copying is the final plan. Proxied
objects seem like a fairly obvious extension.
I am also a bit suspicious of that great timing; perhaps latency is also
important for startup?
___
Python-Dev mailing list -- pyt
In fairness, if the process is really exiting, the OS should clear that out.
Even if it is embedded, the embedding process could just release (or zero out)
the entire memory allocation. I personally like plugging those leaks, but it
does feel like putting purity over practicality.
Even without platform differences, limits on the value of parameters really
ought to be in the docstring, which is available to inspect. If you're asking
for a more specific convention that could actually be used, that still probably
still needs to be written.
__
There are the usual concurrency problems of "read a value, change it, store it
back without checking whether it already changed". The only thing special
about lifecycle happens at refcount 0, which should not happen when more than
one interpreter has a reference.
Similarly, C code can mess thi
I actually like that it looks like instantiation; it seems to be saying "Do we
have the sort of object we would get from this instantiation?"
Unfortunately, this does aggravate the confusion over whether a variable is
being used as a filter, vs binding to something from the matched object.
___
Guido van Rossum wrote:
> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote:
> > The key thing I'm hoping for in PEP 622 itself is
> > that "Syntactic compatibility with a possible future
> > enhancement to assignment statements" be considered
> > as a constraint on the syntax fo
Nick Coghlan wrote:
> On Thu, 2 Jul 2020 at 00:50, Guido van Rossum gu...@python.org wrote:
> > As to allowing object destructuring syntax like
> > Point(x, y) = p
> > that definitely has merit, but it is a complex subject that should be a
> > separate
> > PEP.
> This is the main point I'm
If the writing is less formal (and I think most comments and even most
documentation is somewhat informal), you can sometimes just address the reader
directly, as "you".
For the most formal writing most people will ever encounter, one can use "one"
as the singular pronoun of indeterminate gende
The biggest problem with this is figuring out when to switch. If you switch
within a single example, you will confuse many readers. If you have a series
of related examples, people will disagree about when it is reasonable to
substitute a new person.
Using specific personal names (Alice and
Specifying British English (as opposed to just British spelling) would probably
tempt people to use more Brit-only idioms, in the same way that Monty Python
tempts people to make Flying Circus references.
I don't love the idea of talking more about how many zeroes in a billion, or
whether "tabl
Unless I'm missing something, part of M.-A. Lemburg's objection is:
1. The wchar_t type is itself an important interoperability story in C. (I'm
not sure if this includes the ability, at compile time, to define wchar_t as
either of two widths.)
2. The ability to work directly with wchar_t wi
To me, "else:" has a slightly different meaning than "case _:"
case _: essentially a default, ensuring that the match logic is
complete.
else: OK, the subject of this match failed, here is our fallback logic.
Whether this distinction is important enough to express in code is anoth
Glenn Linderman wrote:
> On 7/10/2020 3:15 AM, Gustavo Carneiro wrote:
...
> > Therefore, I posit that the style of try...except indentation only
> > works where the number of cases is small.
> > But for the case of pattern matching, I expect the number of cases to
> > be matched to be a lot high
I don't think anyone has asked for more indentation in that sense; it has only
even come up in a suggestion of less. (2-space indents for case instead of 4)
People do disagree about whether or not case statements (and possibly an else
statement) should be indented more than 0 spaces compared t
Federico Salerno wrote:
> On 11/07/2020 19:29, Jim J. Jewett wrote:
> > To me, "else:" has a slightly different meaning than "case _:" ...
> Could you construct two examples to prove behaviour would be different
> between the two?
The behavior would be identi
Larry Hastings wrote:
> As for leveraging the convention of using '_' for values you don't care
> about in Python--that's actually why I /don't/ like it as the wildcard
> pattern. To date, everyone who uses '_' understands it's just an
> identifier, no different from any other identifier.
Not
Mark Shannon wrote:
> In future, could you avoid editing emails when replying to them?
> A lot of context can get lost.
I'll add another voice to Ethan's saying that I appreciate having as much as
possible trimmed.
As long as people are arguing in good faith (and I assume that they are here),
In theory, this table could be stored somewhere other than the code object, so
that it doesn't actually get paged in or occupy cache unless tracing is on.
Whether that saves enough to be worth the extra indirections when tracing is
on, I have no intention of volunteering to measure. I will not
I think this example should be in the PEP.
___
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.pyt
101 - 200 of 227 matches
Mail list logo
