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
> 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
> 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
> "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
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
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
> 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
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
- 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,
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
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
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
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
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
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 --
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
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 referenced by
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
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
> In Python 3.11, Python still implements around 100 types as "static
> types" which are not compatible with subinterpreters, like
> _Type and _Type. I opened
> https://bugs.python.org/issue40601 about these static types, but it
> seems like changing it may break the C API *and* the stable ABI
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
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
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
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
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
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:
е =
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
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
> > _)
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
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
"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
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?
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
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
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
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
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
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
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
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
>
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
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,
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
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
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
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),
...
> 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
> 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
[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
> 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
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
> 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
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
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
> 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
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
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__
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;
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
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
Please include an example for:
except *ExceptionGroup: pass
I *think* it swallows all exceptions, instead of re-raising.
I *think* it also catches (and then swallows) bare exception that were not
initially part of an ExceptionGroup.
I *think* it catches anything that gets raised, not just
The "no subclasses" seems pretty severe, particularly if you can't even use
marker attributes because it isn't clear when a different instance of container
ExceptionGroup will be substituted.
The justification for this restriction was that .split() had to be be able to
instantiate ... wouldn't
Petr: What about except *(TypeError, ExceptionGroup):?
Irit: Good question. We should block that as well.
But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility
seems to explicitly recommend the very similar:
except (Exception, ExceptionGroup):
Looking at the other replies, I'm wondering if you fully understand python's
variant of version numbering.
I suggest we change the announcement template from:
"Python 3.9.2 is the newest major release of the Python programming language,
and it contains many new features and optimizations."
Eric Traut wrote:
"""It must be possible to express the type guard within the function signature.
In other words, the implementation should not need to be present. This is
important for compatibility with type stubs and to guarantee consistent
behaviors between type checkers."""
Can type
Another advantage of annotating the variable is that it moves some stuff out
the signature line.
def is_str_list(val: List[object]) -> TypeGuard[List[str]]:
is probably OK on length, but if there were even a second typed and defaulted
parameter, it would start to get unwieldy. And if the
following lines to end of Lib\site.py:
_origopen=open
def open(...):
if ...
warnings.warn(...)
_origopen(...)
"
-jJ
On Fri, Feb 12, 2021 at 6:28 PM Inada Naoki wrote:
>
> On Sat, Feb 13, 2021 at 4:53 AM Jim J. Jewett wrote:
> >
> > Offering encoding=&qu
Current PEP 647 draft says:
"Some built-in type guards provide narrowing for both positive and negative
tests (in both the if and else clauses)"
Should there be a separate (sub-?) type for those TypeGuards that *do* allow
narrowing even on a False? Leaving it as an implementation detail
Offering encoding="locale" (or open.locale or ... ) instead of a long function
call using False (locale.getpreferredencoding(False)) seems like a win for
Explicit is Better Than Implicit. It would then be possible to say "yeah,
locale really is what I meant".
Err... unless the charset
On Thu, Feb 11, 2021 at 7:35 PM Inada Naoki wrote:
> The PEP helps developers living on UTF-8 locale to find missing
> `encoding="utf-8"` bug.
> This type of bug is very common, and many Windows users are suffered
> by the bug when reading JSON, YAML, TOML, Markdown, or any other UTF-8
> files.
(I apologize if my summaries distort what Inada Naoki
explained.)
He said that some people use the default None when they really want
either UTF-8 or ASCII.
My concern is that the warning will be a false alarm if they really do
need whatever locale returns, and that case may still be common.
Who will benefit from this new warning?
Is this basically just changing builtins.open by adding:
if encoding is None and sys.flags.encoding_warning: # and not Android and
not -X utf8 ?
warnings.warn(EncodingWarning("Are you sure you want locale instead of
utf-8?"))
Even for the
Inada Naoki wrote:
> Default encoding is used for:
> a. Really need to use locale specific encoding
> b. UTF-8 (bug. not work on Windows)
> c. ASCII (not a bug, but slow on Windows)
> I assume most usages are (b) and (c). This PEP can reduce them soon.
Is this just an assumption, based on
If a TypeGuard returns false, does that mean "it doesn't match", or just "I
can't prove it matches, but it still might"? That seems relevant to the else
clause ... and seems to have changed since the last version I looked at.
-jJ
___
Python-Dev
(1) Is it really a TypeGuard, or more of a TypeAssertion?
(2) Does this push too hard on "annotations only have one meaning"? If it has
to imported from typing, then probably not, but I think that is worth adding to
the PEP.
(3) Why can't the falsey case of an Optional String narrow to a set
I just reread PEP 597, then re-reread the Rationale.
The PEP helps when the locale is ASCII or C, but that isn't enforced in actual
files. I am confident that this is a frequent problem for packages downloaded
from mostly-English sites, including many software repositories.
It does not seem
The last time I noticed this question (probably around python 2.4?), it was
considered a deliberate decision.
There are languages with more open classes, such as (IIRC) Ruby and Smalltalk,
but Python chose to remain somewhat closed, because monkey-patching is
undesirable, and can be a problem
I see a bunch of similar -- but not quite the same -- use cases.
I feel like instead of a set, it should be a dict pointing to an object with
attributes that describe the module in various ways (top-level vs subpackage,
installed on this machine or not, test module or not, etc). I'll
I probably wouldn't think of that on my own, but the need is rare enough that
having the recipe in the documentation (preferably including the docstring)
might be enough. (Or it might not.)
___
Python-Dev mailing list -- python-dev@python.org
To
Paul Sokolovsky wrote:
> Ok, let's take "module attribute" as an example. Why do you think
> there's anything wrong with this code:
> ==
> import config
> from .types import *
> if config.SUPPORT_BIGINT:
> var: bigint = 1
> else:
> var: int64 = 1
"Wrong" is too strong, but it would be
Larry Hastings wrote:
> The control-flow exclusion is for /module//attribute/ or /class
> attribute/ annotations:
> class C:
> if random.random() > 0.5:
> my_attr:int=3
> else:
> my_attr2:float=3.5
That very example would be helpful in the FAQ, though I understand if you're
Could you be more explicit about what is banned by the control-flow exclusion?
I'm assuming that:
class A:
bar=float
if FOO:
bar=int
def a(x:int, y:int)->int # function defined with annotations
inside control flow
return x+y
[Steven D'Aprano st...@pearwood.info responding to Paul Sokolovsky] wrote:
> > Let us be clear: failed matches do not affect
> > surrounding
> > namespaces unless you declare capture variables as global or
> > nonglobal. They might affect the current namespace, but not
> > surrounding namespaces.
I think your changed constructor:
class Car:
def __init__(self, manufacturer, variant):
self.brand = manufacturer
self.model = variant
is a particularly good example, and the PEP should specify whether:
Car("Chrysler", "PT Cruiser")
is matched by:
I suppose that does follow from treating _ specially by not binding to it at
all; I just hadn't thought through it. (I think my mental model had it wiping
out the previous binding even if the "new" one wasn't available.) So I would
prefer that this be stated explicitly in the PEP. (And maybe
I don't love the way it moves the variable name away from the capture location,
but it does offer a decent solution for anonymous placeholder variables (other
than _ or __), and makes it clear which variables are being bound (only those
in front of an = sign) vs limiting potential matches
Not being able to use a particular variable name (such as match or case) in the
limited context of matching is only a minor wart. Unfortunately, _ for
internationalization is already a well-established convention for something
that you might well want to do within each separate case. It isn't
Nick Coghlan doesn't want to ever be having conversations about why "case
True:" doesn't behave the same way as "case some.attr.referring.to.true:".
Guido thinks that it strange enough that you won't see it. I agree that it is
odd to define a complicated alias for True, but it isn't so odd to
case mylib.STATUS_OK, >result:
case mylib.STATUS_OK, >>result:
case mylib.STATUS_OK, ->result:
The second problem with those is that ">" has a very strong tie to "greater
than".
I think -> or even >> *might* be enough to overcome that, but I'm not
comfortable.
(The first problem, of
Matching *should* look like instantiation ...
case Point(2, 4)
*should* mean "Does it match the object that Point(2, 4) would create?".
case Point(2, y=4)
is less crucial, because they *could* rewrite the call -- but why should they
have to? Changing from constants, and
case
I *hope* this was a typo! If
case Point(x=a, y=b):
assigns to a and b (instead of x and y, as in a normal call), then that is ...
going to be very easy for me to forget, and to miss even when I'm aware of it.
-jJ
___
Python-Dev mailing list --
Emily Bowman wrote:
> If you can update to a breaking Python version, but aren't allowed one
> single point version of an external module, you have a process problem.
Agreed. Does it surprise you to know that many large organizations have a
process problem?
Raihan Rasheed Apurbo wrote:
> In CPython we have reference counting. My question is can we optimize current
> RC using
> strategies like Deferred RC and Coalescing?
You might also look at some of the older attempts to remove reference counting
entirely in favor of (usually) the Boehm tracing
Oscar Benjamin's study of sympy is part of what prompted this, and does provide
a concrete example of why constructors should be echoed.
I think in general, the matching has fallen into two categories:
(1) Simple literal-like matching, that mostly works OK. There is still some
concern over
ah... we may have been talking past each other.
Steve Dower wrote:
> On 25Jul2020 2014, Jim J. Jewett wrote:
> > But it sounds as though you are saying the benefit
[of storing the line numbers in an external table, I thought,
but perhaps Pablo Galindo Salgado and yourself were
tal
I certainly understand saying "this change isn't important enough to justify a
change."
But it sounds as though you are saying the benefit is irrelevant; it is just
inherently too expensive to ask programs that are already dealing with
internals and trying to optimize performance to make a
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
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
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
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.
1 - 100 of 226 matches
Mail list logo
