[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
Hello, On Sat, 27 Mar 2021 20:01:27 + Irit Katriel wrote: [] > > you gentlemen come up with the "ultimate" way to deal with multiple > > errors, > > I've been mistaken for a man before, but no-one has ever confused me > for gentle. I'll take that as a compliment. Sorry, was just a figure of speech ;-). [] > Pluggable is not without its problems. I'm all in favor of you > developing this idea and proposing an alternative. > As I said before, you just need to answer two questions: > 1. show a limitation of our approach (the contrived flat-set is not > one - see below) > 2. describe how a pluggable approach works for that case As I mentioned, I wanted to share concern about adding complex, arguably special-purpose semantics to the core language, and back that by an example on how to address some (not all) points of PEP 645 in a more lightweight (on the language more manner). It's hard to show a technical limitation of your approach - because again, it's already complex and special-purpose, and I can't say I've faced cases where regular application of it would be guaranteed and omissions would be visible. I vice versa can point to a limitation in "generic exception filters" approach - it handles "how to match exceptions more flexibly" issue, but doesn't cover "how to handle automagic reraising of multiple (unhandled) exceptions" part. In my list, that's good - in normal exception handling, exception are (re)raised explicitly. It's pretty big conceptual jump to make handling of that implicit (and exception handling in general is condemned as too-implicit control flow construct by some parties). Overall, my idea wasn't to come up with an alternative proposal so late in PEP654 lifecycle, nor even delay its submission to SC. I just decided to sounds these concern in the end (had them in my notes since initial posting), and ask for clarifications like if there's a cross-language prior art regarding it. [] > > > > def chained(e, excs): > > > > while e: > > > > if isinstance(e, excs): > > > > return e > > > > e = e.__cause__ # Simplified, should consider __context__ > It's different because your "match" function returns a single > exception (the first one that is of OSError type). Any further > OSErrors will be reraised. The PEP's except* knows how to match > multiple exceptions of the relevant type. For this case, it was "chained" function (exception filter), which was concerned only with catching OSError anywhere in the exception chain. As mentioned in the other comment, if there's a need to reraise (parts) of original exception, in must be stored as an attribute of an exception returned from filter. All that's pretty clear and explicit, though I agree if it (reraising) needs to be done often, it may be cumbersome. If it needs to be done. We here touch the question of how exactly such (multiple) exceptions would be handled. And PEP654 is pretty bare on that too - it offers machinery to make that possible, but barely talks of actual usecases (where it starts talk about that is in "Rejected ideas" section, not in the main narrative). > > My understanding is that ExceptionGroup is carefully designed to > > allow subclassing it and override behavior, and the above should be > > possible by subclassing. > > Indeed: > > class PaulsExceptionGroup(ExceptionGroup): Thanks for confirming. [] > So your concern with our design is that ExceptionGroup implements a > generic split() that handles tracebacks and nested structure > correctly, and you might not need that because maybe you don't nest > or you don't care about tracebacks? My concern is still that it adds quite a big chunk of complexity to the core semantics of language. PEP654's ExceptionGroup is clearly carefully designed to (try) to be general, there's no questions about that. > If that is the case then I think you are confusing "generic" with > "special-purpose". ExceptionGroup is generic, it works for general > nested groups with arbitrary tracebacks and cause/context. That's > the opposite of special-purpose. Sadly, to me it still looks that all its generic complexity is rooted in Trio and friends, and for other usecases simpler approach would suffice. Again, that's just personal opinion. I'm just worried to see "except*" in code where it's really needed (and be able to easily grasp what it does), and dread seeing it where it's not really needed (in that regard, PEP654 tries to delineate it clearly from the rest of Python, thanks). > Irit -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/IMLSCMN74RJBFYGATQS7PK3GKBR6MLWG/ Code of Conduct: http://python.org
[Python-Dev] PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer
Hi Christian, Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating the situation and discussing the PEP, the Steering Council is happy with the PEP, and hereby accepts it. The SC is of the opinion that this change will make it considerable easier to maintain the extension modules that depend on OpenSSL while allowing us to leverage the new APIs and improvements in the future. As indicated in the PEP, OpenSSL 1.1.1 is the default variant and version of OpenSSL on almost all supported platforms and distributions almost all known Major CI providers provide images with OpenSSL 1.1.1, so we believe this has the right balance to improve the situation without causing major impact or breakage. Nevertheless, the Steering Council would like to see this change reflected properly in the documentation, What's New (linking against the new instructions here: https://docs.python.org/3.10/using/unix.html#custom-openssl) and release manager notices so this is properly communicated to our users. The Steering Council also thanks Christian for his patience explaining different aspects of the PEP, including in the PEP some extra requested information and for considering the concerts raised. Congratulations, Christian! With thanks from the whole Python Steering Council, Pablo Galindo Salgado ___ 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/INLCO2EZVQW7R7J2OL6HWVLVU3TQRAZV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
Overall, I am still uncomfortable with PEP 653, and would probably not support its acceptance. Although it has thankfully become a much less radical proposal than it was a few weeks ago (thanks, Mark, for your attention to our feedback), I feel that the rules it binds implementations to are *very* premature, and that the new mechanisms it introduces to do so only modestly improve potential performance at great expense to the ease of learning, using, and maintaining code using structural pattern matching. A few notes follow: > For example, using `sympy`, we might want to write: > > ``` > # a*a == a**2 > case Mul(args=[a, b]) if a == b: > return Pow(a, 2) > ``` > > Which requires the sympy class `Symbol` to "self" match. For `sympy` to > support this pattern with PEP 634 is possible, but a bit tricky. With this > PEP it can be implemented very easily. Maybe I'm missing something, but I don't understand at all how the provided code snippet relies on the self-matching behavior. Have the maintainers of SymPy (or any large library supposedly benefitting here) come out in support of the PEP? Are they at least aware of it? Have they indicated that the proposed idiom for implementing self-matching behavior using a property is truly too "tricky" for them? Have you identified any stdlib classes that would benefit greatly from this? For me, `__match_class__` feels like a feature without demonstrated need. Even if there is a great demand for this, I certainly think that there are far better options than the proposed flagging system: - A `@match_self` class decorator (someone's bound to put one on PyPI, at any rate). - Allowing `__match_args__ = None` to signal this case (an option we previously considered, and my personal preference). ...both of which can be added later, if needed. Further, PEP 634 makes it very easy for libraries to support Python versions with *and* without pattern matching (something I consider to be an important requirement). The following class works with both 3.9 and 3.10: ``` class C(collections.abc.Sequence): ... ``` While something like this is required for PEP 653: ``` class C: if sys.version_info >= (3, 10): from somewhere import MATCH_SEQUENCE __match_container__ = MATCH_SEQUENCE ... ``` > PEP 634 relies on the `collections.abc` module when determining which > patterns a value can match, implicitly importing it if necessary. This PEP > will eliminate surprising import errors and misleading audit events from > those imports. I think that a broken `_collections_abc` module *should* be surprising. Is there any reasonable scenario where it's expected to not exist, or be not be fit for this purpose? And I'm not sure how an audit event for an import that is happening could be considered "misleading"... I certainly wouldn't want it suppressed. > Looking up a special attribute is much faster than performing a subclass test > on an abstract base class. How much faster? A quick benchmark on my machine suggests less than half a microsecond. PEP 634 (like PEP 653) already allows us to cache this information for the subject of a match statement, so I doubt that this is actually a real issue in practice. An indeed, with the current implementation, this test isn't even performed on the most common types, such as lists, tuples, and dictionaries. At the very least, PEP 653's confusing new flag system seems to be a *very* premature optimization, seriously hurting usability for a modest performance increase. (Using them wrongly also seems to introduce a fair amount of undefined behavior, which seems to go against the PEP's own motivation.) > If the value of `__match_args__` is not as specified, then the implementation > may raise any exception, or match the wrong pattern. I think there's a name for this sort of behavior... ;) A couple of other, more technical notes: - PEP 653 requires mappings to have a `keys()` method that returns an object supporting set inequality operations. It is not really that common to find this sort of support in user code (in my experience, it is more likely that user-defined `keys()` methods will return iterables). It's not even clear to me if this is an interface requirement for mappings in general. For example, `weakref.WeakKeyDictionary` and `weakref.WeakValueDictionary` presently do not work with PEP 653's requirements for mapping patterns, since their `keys()` methods return iterators. - Treating `__getitem__` as pure is problematic for some common classes (such as `defaultdict`). That's why we use two-argument `get()` instead. As well-fleshed out as the pseudocode for the matching operations in this PEP may be, examples like this suggest that perhaps we should wait until 3.11 or later to figure out what actually works in practice and what doesn't. PEP 634 took a full year of work, and the ideas it proposed changed substantially during that time (in no small part because we h
[Python-Dev] SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup
Hello Mario, Thank you for your submission of PEP 648 (Extensible customizations of the interpreter at startup). The Python Steering Council has reviewed the PEP and before we can pronounce on it, we have some additional questions and comments we’d like you to address. Once these questions are settled, we are requesting that you post the PEP to python-dev for another round of comments. In general, the SC is in favor of deprecating the executable hack capabilities of pth files, and this PEP is currently the most concrete proposal to get there. We would like to eventually go farther, including deprecation of pth files entirely, but that is outside the scope of this PEP. General PEP feedback The introduction of the section titled “Benefits of __sitecustomize__” seems out of place. It forward references the solution without explanation. It also says “The use of a __sitecustomize__ will allow…”; the question is, a __sitecustomize__ what? Directory? File? Perhaps it should be moved to later in the PEP after the semantics of __sitecustomize__ is defined? Some of the terminology used in the PEP could be clarified. For example, I suggest using the term “directory” instead of “folder” throughout the PEP, and use the term “module” or “file” instead of “script” to describe the things inside __sitecustomize__ directories that Python imports, since “scripts” typically describe standalone files that implement applications. For example, must the files be named with .py extension (or presumably .pyc, .pyo) under the normal Python module import rules? (Later in the PEP you do allude to the requirement that the file name must end in .py, but it would be much better to explain this right up front, in a formal specification.) Another ambiguity is what the PEP means by “executing” said “scripts”. Does that mean importing them? Reading them then exec()’ing them? Something else? This section should be clear that Python will import the modules it found, if that’s indeed what the PEP is proposing. The “Backward compatibility” section has this incomplete sentence: “Ignoring those lines in pth files.” There’s this odd grammar in the “Do nothing” section: “After analysing the impact of this change, we believe it is worth given the enhanced experience it brings.” Perhaps it should read “...it is worth it, given the…”? Definition of “site path” The PEP should precisely define what it means when it says “...a folder named __sitecustomize__ located in any site path”. What exactly is a “site path”? Is this any directory on sys.path? Is it a directory named site-packages? This phrase is also ambiguous: “As the folder will be within sys.path, given that it is located in site paths...”. “sys.path” isn’t a thing that can hold a folder, since it’s just a list of strings, and it also can get extended by any number of means, e.g. by setting the PYTHONPATH environment variable at interpreter startup time. So for example, how does PYTHONPATH affect the algorithm? What is the rationale for adding multiple __sitecustomize__ directories, rather than a single directory (or possibly two, one in Python’s system location and one in the user location)? This would simplify the discovery process, and tools like pip can warn the user if a name collision were to occur. I think the PEP needs to be much more crisp and precise in defining the when and how __sitecustomize__ directories are discovered at start up time. Order of Execution I think this section should outline the entire startup execution order. Exactly when do pth files still get evaluated in relationship to __sitecustomize__ discovery? How do pth file sys.path extensions affect the search for __sitecustomize__ directories? This section also says files in __sitecustomize__ will be executed in “file name sorted order”, but the PEP is unclear whether all such files found in every __sitecustomize__ directory will be sorted together, or only within a single __sitecustomize__ directory. Presumably file system encodings are used to determine file name sort order, but I think the PEP should be explicit about this. I’d like to see the execution order for the entire proposed new Python startup sequence as a recipe, or perhaps even some Python pseudo-code. Impact on startup time We still think that startup performance can be a concern. This section needs more data. For example, while the executable part of pth files is being deprecated, both pth and __sitecustomize__ modules will exist. How does this affect startup time in a world where both have to be discovered and processed? The PEP says: “If the user has custom scripts, we think that the impact on the performance of walking each of the folders is acceptable, as the user wants to use this feature.” Does the user really want to use this feature? Won’t it more likely be the system administrator or Python distribution and packaging ecosystem that chooses to use th
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
Hi Brandt, On 30/03/2021 5:25 pm, Brandt Bucher wrote: Overall, I am still uncomfortable with PEP 653, and would probably not support its acceptance. Although it has thankfully become a much less radical proposal than it was a few weeks ago (thanks, Mark, for your attention to our feedback), I feel that the rules it binds implementations to are *very* premature, and that the new mechanisms it introduces to do so only modestly improve potential performance at great expense to the ease of learning, using, and maintaining code using structural pattern matching. A few notes follow: For example, using `sympy`, we might want to write: ``` # a*a == a**2 case Mul(args=[a, b]) if a == b: return Pow(a, 2) ``` Which requires the sympy class `Symbol` to "self" match. For `sympy` to support this pattern with PEP 634 is possible, but a bit tricky. With this PEP it can be implemented very easily. Maybe I'm missing something, but I don't understand at all how the provided code snippet relies on the self-matching behavior. No I'm missing something. That should read case Mul(args=[Symbol(a), Symbol(b)) if a == b: ... I'll fix that in the PEP thanks. Have the maintainers of SymPy (or any large library supposedly benefitting here) come out in support of the PEP? Are they at least aware of it? Have they indicated that the proposed idiom for implementing self-matching behavior using a property is truly too "tricky" for them? Have you identified any stdlib classes that would benefit greatly from this? For me, `__match_class__` feels like a feature without demonstrated need. Even if there is a great demand for this, I certainly think that there are far better options than the proposed flagging system: The distinction between those classes that have the default behavior and those that match "self" is from PEP 634. I didn't introduce it. I'm just proposing a more principled way to make that distinction. - A `@match_self` class decorator (someone's bound to put one on PyPI, at any rate). - Allowing `__match_args__ = None` to signal this case (an option we previously considered, and my personal preference). ...both of which can be added later, if needed. Further, PEP 634 makes it very easy for libraries to support Python versions with *and* without pattern matching (something I consider to be an important requirement). The following class works with both 3.9 and 3.10: ``` class C(collections.abc.Sequence): ... ``` While something like this is required for PEP 653: ``` class C: if sys.version_info >= (3, 10): from somewhere import MATCH_SEQUENCE __match_container__ = MATCH_SEQUENCE ... ``` Or class C: __match_container__ = 1 # MATCH_SEQUENCE Which is one reason the PEP states that the values of MATCH_SEQUENCE, etc. will never change. PEP 634 relies on the `collections.abc` module when determining which patterns a value can match, implicitly importing it if necessary. This PEP will eliminate surprising import errors and misleading audit events from those imports. I think that a broken `_collections_abc` module *should* be surprising. Is there any reasonable scenario where it's expected to not exist, or be not be fit for this purpose? No reasonable scenario, but unreasonable scenarios happen all too often. And I'm not sure how an audit event for an import that is happening could be considered "misleading"... I certainly wouldn't want it suppressed. It's misleading because a match statement doesn't include any explicit imports. Looking up a special attribute is much faster than performing a subclass test on an abstract base class. How much faster? A quick benchmark on my machine suggests less than half a microsecond. PEP 634 (like PEP 653) already allows us to cache this information for the subject of a match statement, so I doubt that this is actually a real issue in practice. An indeed, with the current implementation, this test isn't even performed on the most common types, such as lists, tuples, and dictionaries. Half a microsecond is thousands of instructions on a modern CPU. That is a long time for a single VM operation. At the very least, PEP 653's confusing new flag system seems to be a *very* premature optimization, seriously hurting usability for a modest performance increase. (Using them wrongly also seems to introduce a fair amount of undefined behavior, which seems to go against the PEP's own motivation.) Why do you say it is a premature optimization? It's primary purpose is reliability and precise semantics. It is more optimizable, I agree, but that is hardly premature. You also say it is confusing, but I think it is simpler than the workarounds to match "self" that you propose. This is very subjective though. Evidently we think differently. If the value of `__match_args__` is not as specified, then the implementation may raise any exception, or match the wrong pattern.
[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup
On 30/03/2021 19.01, Barry Warsaw wrote: > Hello Mario, > > Thank you for your submission of PEP 648 (Extensible customizations of the > interpreter at startup). The Python Steering Council has reviewed the PEP > and before we can pronounce on it, we have some additional questions and > comments we’d like you to address. Once these questions are settled, we are > requesting that you post the PEP to python-dev for another round of comments. Hi Mario, could you please include a security analysis of the feature, too? I would like to avoid new ways to exploit Python. In particular I don't think that -S (no site module) is the right way to disable __sitecustomize__. It disables too much useful features. It might be a good idea to disable __sitecustomize__ with -I (isolated mode). There should be a new audit event, too. Christian ___ 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/UFADYZGCTF6ZJUX66VAK4XYMJBL6TMMW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup
Great points Christian, thanks. -Barry > On Mar 30, 2021, at 10:59, Christian Heimes wrote: > > On 30/03/2021 19.01, Barry Warsaw wrote: >> Hello Mario, >> >> Thank you for your submission of PEP 648 (Extensible customizations of the >> interpreter at startup). The Python Steering Council has reviewed the PEP >> and before we can pronounce on it, we have some additional questions and >> comments we’d like you to address. Once these questions are settled, we are >> requesting that you post the PEP to python-dev for another round of comments. > > Hi Mario, > > could you please include a security analysis of the feature, too? I > would like to avoid new ways to exploit Python. > > In particular I don't think that -S (no site module) is the right way to > disable __sitecustomize__. It disables too much useful features. It > might be a good idea to disable __sitecustomize__ with -I (isolated mode). > > There should be a new audit event, too. > > Christian signature.asc Description: Message signed with OpenPGP ___ 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/Q7G26FI7TX42RDJH7BVKBQEOLHMZNTU4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
Hi Mark.
I've spoken with Guido, and we are willing to propose the following amendments
to PEP 634:
- Require `__match_args__` to be a tuple.
- Add new `__match_seq__` and `__match_map__` special attributes, corresponding
to new public `Py_TPFLAGS_MATCH_SEQ` and `Py_TPFLAGS_MATCH_MAP` flags for use
in `tp_flags`. When Python classes are defined with one or both of these
attributes set to a boolean value, `type.__new__` will update the flags on the
type to reflect the change (using a similar mechanism as `__slots__`
definitions). They will be inherited otherwise. For convenience,
`collections.abc.Sequence` will define `__match_seq__ = True`, and
`collections.abc.Mapping` will define `__match_map__ = True`.
Using this in Python would look like:
```
class MySeq:
__match_seq__ = True
...
class MyMap:
__match_map__ = True
...
```
Using this in C would look like:
```
PyTypeObject PyMySeq_Type = {
...
.tp_flags = Py_TPFLAGS_MATCH_SEQ | ...,
...
}
PyTypeObject PyMyMap_Type = {
...
.tp_flags = Py_TPFLAGS_MATCH_MAP | ...,
...
}
```
We believe that these changes will result in the best possible outcome:
- The new mechanism should faster than either PEP.
- The new mechanism should provide a better user experience than either PEP
when defining types in either Python *or C*.
If these amendments were made, would you be comfortable withdrawing PEP 653? We
think that if we're in agreement here, a compromise incorporating these
promising changes into the current design would be preferable to submitting yet
another large pattern matching PEP for a very busy SC to review and pronounce
before the feature freeze. I am also willing, able, and eager to implement
these changes promptly (perhaps even before the next alpha) if so.
Thanks for pushing us to make this better.
Brandt
___
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/QJR5TT5BW55PZFXJJFEYUCNZ5XQF256O/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)
On Tue, 30 Mar 2021 at 17:32, Brandt Bucher wrote: Hi Brandt, > > Which requires the sympy class `Symbol` to "self" match. For `sympy` to > > support this pattern with PEP 634 is possible, but a bit tricky. With this > > PEP it can be implemented very easily. > > Maybe I'm missing something, but I don't understand at all how the provided > code snippet relies on the self-matching behavior. > > Have the maintainers of SymPy (or any large library supposedly benefitting > here) come out in support of the PEP? Are they at least aware of it? Have > they indicated that the proposed idiom for implementing self-matching > behavior using a property is truly too "tricky" for them? Speaking as a maintainer of SymPy I do support the PEP but not for SymPy specifically. I just used SymPy as an example of something that seems like it should be a good fit for pattern matching but also shows examples that don't seem to work with PEP 634 in the way intended. I'm sure SymPy will use case/match when support for Python 3.9 is dropped but I don't see it as something that would be a major feature for SymPy users or for internal code. I expect that case/match would make some code tidier and potentially it could make some things a little faster (although that depends on it being well optimised - half a microsecond might seem small until you add up millions of them). There is a recently opened SymPy issue discussing the possible use of this: https://github.com/sympy/sympy/issues/21193 Pattern matching and destructuring more generally are significant features for symbolic libraries such as SymPy which has much code for doing this and can also be used with other dedicated libraries such as matchpy. Much more is needed than case/match for that though: rewriting, substitution, associative/commutative matching etc. It's not clear to me that core Python could ever provide anything new that would lead to a groundbreaking improvement for SymPy in this respect. The surrounding discussion of the various pattern matching PEPs has led me to think of the idea of destructuring as more of a general language feature that might not in future be limited to case/match though. I'm not sure where that could go for Python but I'm interested to see if anything more comes of it. I like a lot of the features in PEP 634 and the way I see it this PEP (653) underpins those. The reason I support PEP 653 is because it seems like a more principled approach to the mechanism for how pattern-matching should work that places both user-defined types and builtin types on an even footing. The precise mechanisms (match_class, match_self etc) and their meanings do seem strange but that's because they are trying to codify the different cases that PEP 634 has introduced. It's possible that the design of that mechanism can be improved and there have been suggestions for that in this thread. I do think though that it is important to have a general extensible mechanism rather than a specification based on special cases. I also think that the use of the Sequence and Mapping ABCs is a bad idea on practical grounds (performance, circularity in the implementation) and is not in keeping with the rest of the language. ABCs have always been optional in the past: Python uses protocols rather than ABCs (ducktyping etc). Finally, speaking as someone who also teaches introductory programming with Python then with *that* hat on I would have preferred it if none of the pattern-matching PEPs had been accepted. The advantage of Python in having a simple and easily understood core erodes with each new addition to core syntax. For novice users case/match only really offers increased complexity compared to if/elif but it will still be something else that needs to be learned before being able to read existing code. Oscar Oscar ___ 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/GLIIJUWBY2RT734FCLVUYM3XB3RJWNYY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup
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 just as bad as the status quo. Cheers, Nick. > ___ 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/MSOV7NKDCO7L3X46SDDLVTUEN7ER2EDB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup
Hi Nick, Please don't, since that would force everyone to start using PEP 648 just > to extend sys.path, which would be just as bad as the status quo. I think Barry is referring to deprecate the execution capabilities of pth files (https://bugs.python.org/issue33944), not the files themselves. Cheers, Pablo Galindo Salgado On Wed, 31 Mar 2021 at 00:34, Nick Coghlan wrote: > > > 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 just as bad as the status quo. > > Cheers, > Nick. > > > >> ___ > 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/MSOV7NKDCO7L3X46SDDLVTUEN7ER2EDB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/TZW2UT4B7OUVVZ3YCRHRZNU4HZS7W66R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup
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 auditable and discoverable. To me that means deprecating pth files and finding something better, but maybe not. In any case, this is outside the scope of PEP 648 so just pretend that part wasn’t in my response. -Barry > On Mar 30, 2021, at 17:00, Pablo Galindo Salgado wrote: > > Hi Nick, > > Please don't, since that would force everyone to start using PEP 648 just to > extend sys.path, which would be just as bad as the status quo. > > I think Barry is referring to deprecate the execution capabilities of pth > files (https://bugs.python.org/issue33944), not the files themselves. > > Cheers, > Pablo Galindo Salgado > > On Wed, 31 Mar 2021 at 00:34, Nick Coghlan wrote: > > > 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 just as bad as the status quo. > > Cheers, > Nick. > > > > ___ > 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/MSOV7NKDCO7L3X46SDDLVTUEN7ER2EDB/ > Code of Conduct: http://python.org/psf/codeofconduct/ signature.asc Description: Message signed with OpenPGP ___ 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/UMVGVXXXBWDIBBKZLSXNSJ6WTNTKC2XF/ Code of Conduct: http://python.org/psf/codeofconduct/
