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 pt
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.
On Wed, 31 Mar 2021, 3:15 am Barry Warsaw, wrote:
> . We would like to eventually go farther, including deprecation of pth
> files entirely, but that is outside the scope of this PEP.
>
Please don't, since that would force everyone to start using PEP 648 just
to extend sys.path, which would be
On 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, b
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
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 ha
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
> commen
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
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 ar
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 *ve
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 mod
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
12 matches
Mail list logo
