[Python-ideas] Re: Extension methods in Python

[Steven D'Aprano]

On Thu, Jun 24, 2021 at 11:53:55PM -0400, Ricky Teachey wrote:

> Would this feature allow me to declare str objects as not iterable in some
> contexts?
> 
> If so, +1.

While I'm glad to see some more positivity in this thread, alas, no, 
extension methods are not a mechanism for making strings non-iterable.

Nor do they help with floating point inaccuracies, resolve problems with 
circular imports, or make the coffee *wink*

Extension methods are a technology for extending classes with extra 
methods, not removing them.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WQTGBCC3XJU32NMDSXG4TOSKBPCKVU5U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

I was debugging some code that was using TLSv1.2 when I expected it to only 
support TLSv1.3, I tracked it down to a call to:

context.miunimum_version = ssl.TLSVersion.TLSv1_3

it should have been:

context.minimum_version = ssl.TLSVersion.TLSv1_3

I'd like invalid attribute assignment to be prevented at runtime
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Jonathan Fine]

Thank you Thomas for concisely and fairly reporting your experience, and
based on that suggesting a way to improve Python. Thank you for taking the
time to do this.

Here's a typo that caused a bug (which inconvenienced the original poster):

context.miunimum_version = ssl.TLSVersion.TLSv1_3
> context.minimum_version = ssl.TLSVersion.TLSv1_3
>

Here's the fix the original poster suggested:

I'd like invalid attribute assignment to be prevented at runtime
>

This can already be done, if type(context) is defined using __slots__.
However, a search in the docs for slots is not so helpful.
 https://docs.python.org/3/search.html?q=slots

Some of the better search results (for the question asked) seem to be:

https://docs.python.org/3/reference/datamodel.html?highlight=slots#object.__slots__
https://docs.python.org/3/reference/datamodel.html?highlight=slots
https://docs.python.org/3/howto/descriptor.html?highlight=slots

I see two ideas here. One idea is to improve the documentation for
__slots__, and perhaps provide tools that make it easier to create a class
that uses slots.

Here's a challenge. Find a page in docs.python.org that describes clearly,
with helpful examples, when and how to use __slots__.

The second idea, which the OP asks for, is a change to type(context) in the
standard library ssl module. Here note:

https://docs.python.org/3/library/ssl.html
Warning Don’t use this module without reading the Security considerations.
Doing so may lead to a false sense of security, as the default settings of
the ssl module are not necessarily appropriate for your application.

Given that context is important for security, perhaps it's worthwhile
closing the door to spelling errors creating security holes.

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4GJKWUMWJNEW2CEWUXCTXCQM7VDTK3YW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extension methods in Python

[Stephen J. Turnbull]

Chris Angelico writes:

 > if it's a fallback after default behaviour fails (like __getattr__)
 > [...] it's likely to impact performance a lot less.

I guess the effect on performance is that it takes one more check to
get to AttributeError?

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BETDFWCN2J27MGWI6WL3SMF5CDDV2MFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extension methods in Python

[Stephen J. Turnbull]

David Mertz writes:

 > That said, one crucial difference is once an extension method is
 > "used" we are stuck with it for the entire module.

While you get it for all objects of type(foo) in the whole module,
presumably whatever syntax you used to "use" it, you can use to get
rid of it, or at least replace it with an extension that raises or
logs or somehow signals that the extension is deactivated.  Or maybe
del works on it.

 > In contrast, functions can be both namespaced and redefined. [...]
 > We get scoping and namespaces that extension method lack.

But isn't the point of an extension to a class that we want it to be
class-wide in that module?  I don't see why we should turn extensions
into something we can already do with functions.  (Assuming we want
them at all, and so far only Steven's backporting application makes
any sense to me).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WQ53AYI73FPQJ5NGUBS6JMGHG7OLTNUJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extension methods in Python

[Chris Angelico]

On Fri, Jun 25, 2021 at 7:43 PM Stephen J. Turnbull
 wrote:
>
> Chris Angelico writes:
>
>  > if it's a fallback after default behaviour fails (like __getattr__)
>  > [...] it's likely to impact performance a lot less.
>
> I guess the effect on performance is that it takes one more check to
> get to AttributeError?
>

It also means that this code applies only when other things have
failed, so high performance lookups will still be high performance.
But there've been many variants of this proposal in this thread, all
subtly different.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2ES5H7LDK3AN6KJ5UY3EDZ2Y2EEHVSOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Guido van Rossum]

Would a static type checker have found this?

On Fri, Jun 25, 2021 at 02:07 Thomas Grainger  wrote:

> I was debugging some code that was using TLSv1.2 when I expected it to
> only support TLSv1.3, I tracked it down to a call to:
>
> context.miunimum_version = ssl.TLSVersion.TLSv1_3
>
> it should have been:
>
> context.minimum_version = ssl.TLSVersion.TLSv1_3
>
> I'd like invalid attribute assignment to be prevented at runtime
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BHZNLW2647Z6KYRP672J63RJ7CDGUUVV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Bluenix]

I am not fully aware of how ssl.SSLContext is used, but adding __slots__ would 
prevent this. You would see an error similar to: AttributeError: 'MyClass' 
object has no attribute 'my_attribute'
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CTC2BBSOKIWZ7QLXRKCFH2FP6OMBQXJX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Guido van Rossum]

On Fri, Jun 25, 2021 at 8:22 AM Bluenix  wrote:

> I am not fully aware of how ssl.SSLContext is used, but adding __slots__
> would prevent this. You would see an error similar to: AttributeError:
> 'MyClass' object has no attribute 'my_attribute'
>

That's a reasonable solution, except that it's not backwards compatible.
It's possible that there is code out there that for some reason adds
private attributes to an SSLContext instance, and using __slots__ would
break such usage. (They could perhaps fix their code by using a dummy
subclass, but that could well become a non-trivial change to their code,
depending on where they get their SSLContext instances.)

So unless there's evidence that nobody does that, we're stuck with the
status quo. I'm adding Christian Heimes to the thread in case he has a
hunch either way.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U7N5K542MGEAC3VXDPJEVUV4OPB6QJ2P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Chris Angelico]

On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum  wrote:
>
> On Fri, Jun 25, 2021 at 8:22 AM Bluenix  wrote:
>>
>> I am not fully aware of how ssl.SSLContext is used, but adding __slots__ 
>> would prevent this. You would see an error similar to: AttributeError: 
>> 'MyClass' object has no attribute 'my_attribute'
>
>
> That's a reasonable solution, except that it's not backwards compatible. It's 
> possible that there is code out there that for some reason adds private 
> attributes to an SSLContext instance, and using __slots__ would break such 
> usage. (They could perhaps fix their code by using a dummy subclass, but that 
> could well become a non-trivial change to their code, depending on where they 
> get their SSLContext instances.)
>
> So unless there's evidence that nobody does that, we're stuck with the status 
> quo. I'm adding Christian Heimes to the thread in case he has a hunch either 
> way.
>

Another possible solution - although I'm not sure how practical this
would be - would be to have __init__ accept only specific keyword
arguments. You could do something like:

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT,
minimum_version=ssl.PROTOCOL_TLSv1_1)

and it would work, but if you misspell "minimum_version", it would
error out. That's actually what I expected it to do, based on the
signature; but it doesn't, it simply ignores the argument. Not
actually sure what it does with kwargs.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HBXVMJ5S665XGTEAKUHJTF452OJXVNBP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Guido van Rossum]

On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico  wrote:

> On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum  wrote:
> >
> > On Fri, Jun 25, 2021 at 8:22 AM Bluenix  wrote:
> >>
> >> I am not fully aware of how ssl.SSLContext is used, but adding
> __slots__ would prevent this. You would see an error similar to:
> AttributeError: 'MyClass' object has no attribute 'my_attribute'
> >
> >
> > That's a reasonable solution, except that it's not backwards compatible.
> It's possible that there is code out there that for some reason adds
> private attributes to an SSLContext instance, and using __slots__ would
> break such usage. (They could perhaps fix their code by using a dummy
> subclass, but that could well become a non-trivial change to their code,
> depending on where they get their SSLContext instances.)
> >
> > So unless there's evidence that nobody does that, we're stuck with the
> status quo. I'm adding Christian Heimes to the thread in case he has a
> hunch either way.
> >
>
> Another possible solution - although I'm not sure how practical this
> would be - would be to have __init__ accept only specific keyword
> arguments. You could do something like:
>
> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT,
> minimum_version=ssl.PROTOCOL_TLSv1_1)
>
> and it would work, but if you misspell "minimum_version", it would
> error out. That's actually what I expected it to do, based on the
> signature; but it doesn't, it simply ignores the argument. Not
> actually sure what it does with kwargs.
>

But that's not what the OP wrote -- his code used an attribute assignment.
It looks like SSLContext just throws the *args and **kwds away. You *must*
set the attribute. I don't know why it has *args and **kwds at all -- maybe
so that you can subclass it and define an __init__ that takes those?

It all seems a mystery to me. I've never used this directly -- I've always
just used urllib's default for https URLs.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HVOEIESRKDOZMZ7RVQEQFK23HJ6TTTC7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Chris Angelico]

On Sat, Jun 26, 2021 at 5:09 AM Guido van Rossum  wrote:
>
> On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico  wrote:
>>
>> On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum  wrote:
>> >
>> > On Fri, Jun 25, 2021 at 8:22 AM Bluenix  wrote:
>> >>
>> >> I am not fully aware of how ssl.SSLContext is used, but adding __slots__ 
>> >> would prevent this. You would see an error similar to: AttributeError: 
>> >> 'MyClass' object has no attribute 'my_attribute'
>> >
>> >
>> > That's a reasonable solution, except that it's not backwards compatible. 
>> > It's possible that there is code out there that for some reason adds 
>> > private attributes to an SSLContext instance, and using __slots__ would 
>> > break such usage. (They could perhaps fix their code by using a dummy 
>> > subclass, but that could well become a non-trivial change to their code, 
>> > depending on where they get their SSLContext instances.)
>> >
>> > So unless there's evidence that nobody does that, we're stuck with the 
>> > status quo. I'm adding Christian Heimes to the thread in case he has a 
>> > hunch either way.
>> >
>>
>> Another possible solution - although I'm not sure how practical this
>> would be - would be to have __init__ accept only specific keyword
>> arguments. You could do something like:
>>
>> ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT,
>> minimum_version=ssl.PROTOCOL_TLSv1_1)
>>
>> and it would work, but if you misspell "minimum_version", it would
>> error out. That's actually what I expected it to do, based on the
>> signature; but it doesn't, it simply ignores the argument. Not
>> actually sure what it does with kwargs.
>
>
> But that's not what the OP wrote -- his code used an attribute assignment. It 
> looks like SSLContext just throws the *args and **kwds away. You *must* set 
> the attribute. I don't know why it has *args and **kwds at all -- maybe so 
> that you can subclass it and define an __init__ that takes those?
>
> It all seems a mystery to me. I've never used this directly -- I've always 
> just used urllib's default for https URLs.
>

Yeah - my first thought on reading the OP's issue was "hmm, can't you
just use kwargs and get them validated?", but it doesn't validate. So
this would require both changing the SSLContext class *and* the
calling code. Unideal, but less backward incompatible than __slots__
would be.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/44NNXNALG2F25TTIXYDEFYIJGHGLGBJR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Christian Heimes]

On 25/06/2021 20.17, Guido van Rossum wrote:
> On Fri, Jun 25, 2021 at 8:22 AM Bluenix  > wrote:
> 
> I am not fully aware of how ssl.SSLContext is used, but adding
> __slots__ would prevent this. You would see an error similar to:
> AttributeError: 'MyClass' object has no attribute 'my_attribute'
> 
> 
> That's a reasonable solution, except that it's not backwards compatible.
> It's possible that there is code out there that for some reason adds
> private attributes to an SSLContext instance, and using __slots__ would
> break such usage. (They could perhaps fix their code by using a dummy
> subclass, but that could well become a non-trivial change to their code,
> depending on where they get their SSLContext instances.)
> 
> So unless there's evidence that nobody does that, we're stuck with the
> status quo. I'm adding Christian Heimes to the thread in case he has a
> hunch either way.

I agree, it is a backwards incompatible change. Also __slots__ won't
work. The class has class attributes that can be modified in instances.
You cannot have attributes that are both class and instance attributes
with __slots__. We'd have to overwrite __setattr__() and block unknown
attributes of exact instances of ssl.SSLContext.

Christian


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CCIK7ASYNPYD4QTO462LZHTSKTD6FJKN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Guido van Rossum]

On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes 
wrote:

> On 25/06/2021 20.17, Guido van Rossum wrote:
> > On Fri, Jun 25, 2021 at 8:22 AM Bluenix  > > wrote:
> >
> > I am not fully aware of how ssl.SSLContext is used, but adding
> > __slots__ would prevent this. You would see an error similar to:
> > AttributeError: 'MyClass' object has no attribute 'my_attribute'
> >
> >
> > That's a reasonable solution, except that it's not backwards compatible.
> > It's possible that there is code out there that for some reason adds
> > private attributes to an SSLContext instance, and using __slots__ would
> > break such usage. (They could perhaps fix their code by using a dummy
> > subclass, but that could well become a non-trivial change to their code,
> > depending on where they get their SSLContext instances.)
> >
> > So unless there's evidence that nobody does that, we're stuck with the
> > status quo. I'm adding Christian Heimes to the thread in case he has a
> > hunch either way.
>
> I agree, it is a backwards incompatible change. Also __slots__ won't
> work. The class has class attributes that can be modified in instances.
>

Oh, I see. There are two class attributes, sslsocket_class and
sslobject_class, and their docs say they can be overridden per instance.
Could we perhaps create a custom descriptor that allows both per-instance
and per-class assignment and lookup?


> You cannot have attributes that are both class and instance attributes
> with __slots__. We'd have to overwrite __setattr__() and block unknown
> attributes of exact instances of ssl.SSLContext.
>

Well, if we don't think it's supported behavior to subclass SSLContext,
perhaps we could do that. The bug in the OP's code (misspelling
minimum_version in assignment) is pretty hard to find.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VGSFW6UXY7NRHZ6OUWJMXABFVVFMHIQN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Thomas Grainger]

How about an alternative frozen dataclass with a explicit replace,
configure and create methods?

@dataclasses.dataclass(frozen=True)
class SSLContextFactory:
minimum_version: TLSVersion = TLSVersion.TLSv1_2
options: ...

replace = dataclasses.replace

def configure(self, ctx: SSLContext):
ctx.mimumum_version = self.minimum_version
ctx.options = self.options
...

def create(self):
ctx = SSLContext()
self.configure(ctx)
return ctx

On Fri, 25 Jun 2021, 20:52 Guido van Rossum,  wrote:

> On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes 
> wrote:
>
>> On 25/06/2021 20.17, Guido van Rossum wrote:
>> > On Fri, Jun 25, 2021 at 8:22 AM Bluenix > > > wrote:
>> >
>> > I am not fully aware of how ssl.SSLContext is used, but adding
>> > __slots__ would prevent this. You would see an error similar to:
>> > AttributeError: 'MyClass' object has no attribute 'my_attribute'
>> >
>> >
>> > That's a reasonable solution, except that it's not backwards compatible.
>> > It's possible that there is code out there that for some reason adds
>> > private attributes to an SSLContext instance, and using __slots__ would
>> > break such usage. (They could perhaps fix their code by using a dummy
>> > subclass, but that could well become a non-trivial change to their code,
>> > depending on where they get their SSLContext instances.)
>> >
>> > So unless there's evidence that nobody does that, we're stuck with the
>> > status quo. I'm adding Christian Heimes to the thread in case he has a
>> > hunch either way.
>>
>> I agree, it is a backwards incompatible change. Also __slots__ won't
>> work. The class has class attributes that can be modified in instances.
>>
>
> Oh, I see. There are two class attributes, sslsocket_class and
> sslobject_class, and their docs say they can be overridden per instance.
> Could we perhaps create a custom descriptor that allows both per-instance
> and per-class assignment and lookup?
>
>
>> You cannot have attributes that are both class and instance attributes
>> with __slots__. We'd have to overwrite __setattr__() and block unknown
>> attributes of exact instances of ssl.SSLContext.
>>
>
> Well, if we don't think it's supported behavior to subclass SSLContext,
> perhaps we could do that. The bug in the OP's code (misspelling
> minimum_version in assignment) is pretty hard to find.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VGSFW6UXY7NRHZ6OUWJMXABFVVFMHIQN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OFABWJUMIUFXQAYFULBNDMIAYGVWOWLH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Jonathan Fine]

It may help to think separately about existing code using ssl, and about
new code. However, I'm not a user of ssl, so please doubt my opinions below.

EXISTING CODE
Those maintaining existing code might welcome an easy way of checking that
the code doesn't have a misleading assignment. They might also appreciate a
quick fix, such as using a subclass of type(context) that does have
__slots__. (Such devices might not work well with all existing code.)

NEW CODE
Those creating new code might appreciate a new API that has been redesigned
to simplify the interface and better support security audits. For example:

>>> context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
>>> context


Perhaps better is that type(context).__repr__ show the attributes of the
context object (and anything inherited from the parent class).

BITWISE OPERATIONS
Also, the sample code (in docs ssl.html)

ctx = ssl.create_default_context(Purpose.CLIENT_AUTH)
ctx.options &= ~ssl.OP_NO_SSLv3

contains bitwise operations whose meaning requires some thought.
-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/E5JEVSXRNDZF3AUH7XZZ5XXXJE4JNIDU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Steven D'Aprano]

Hi Thomas,

On Fri, Jun 25, 2021 at 09:06:58AM -, Thomas Grainger wrote:

> I'd like invalid attribute assignment to be prevented at runtime

Are you making a specific request for ssl context objects, or a general 
language-wide request that applies to all objects?


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AP2IXDVONOEUZJKFBT7GO2UMAN3A3UOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Eric V. Smith]

On 6/25/2021 8:09 PM, Steven D'Aprano wrote:

Hi Thomas,

On Fri, Jun 25, 2021 at 09:06:58AM -, Thomas Grainger wrote:


I'd like invalid attribute assignment to be prevented at runtime

Are you making a specific request for ssl context objects, or a general
language-wide request that applies to all objects?


It seems like many of the suggestions are SSLContext specific. I don't 
think we should be adding __slots__ or otherwise redefining the 
interface to that object. Isn't this a general "problem" in python, 
that's always been present? Why are we trying to address the problem 
with this specific object? I suggest doing nothing, or else thinking big 
and solve the general problem, if in fact it needs solving.


Eric

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VOXGE4M6D25VROYCCOEJP75X4MVYDJXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Steven D'Aprano]

On Fri, Jun 25, 2021 at 11:17:09AM -0700, Guido van Rossum wrote:
> On Fri, Jun 25, 2021 at 8:22 AM Bluenix  wrote:
> 
> > I am not fully aware of how ssl.SSLContext is used, but adding __slots__
> > would prevent this. You would see an error similar to: AttributeError:
> > 'MyClass' object has no attribute 'my_attribute'
> >
> 
> That's a reasonable solution, except that it's not backwards compatible.
> It's possible that there is code out there that for some reason adds
> private attributes to an SSLContext instance, and using __slots__ would
> break such usage. (They could perhaps fix their code by using a dummy
> subclass, but that could well become a non-trivial change to their code,
> depending on where they get their SSLContext instances.)

Given that this is a mildly troubling security flaw/bug/vulnerability, I 
think that breaking backwards-compatibility is justified.

If that requires a few users to subclass SSLContext, that's a relatively 
small cost for fixing the bug.

I don't think it is serious enough to justify it in minor releases, but 
we can surely fix it in 3.11 or maybe even 3.10 if we move fast? (3.10.0 
candidate 1 is scheduled for August.)

I have no opinion whether it should be considered serious enough to 
backport to older versions, but I think it justifies a small backwards- 
incompatible change going forward.



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PKEZL2GSXO34NYFO7AFO2SQ46ST7DPR4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Steven D'Aprano]

On Fri, Jun 25, 2021 at 12:48:51PM -0700, Guido van Rossum wrote:

> > I agree, it is a backwards incompatible change. Also __slots__ won't
> > work. The class has class attributes that can be modified in instances.
> >
> 
> Oh, I see. There are two class attributes, sslsocket_class and
> sslobject_class, and their docs say they can be overridden per instance.
> Could we perhaps create a custom descriptor that allows both per-instance
> and per-class assignment and lookup?

Something like this, perhaps?

https://code.activestate.com/recipes/577030-dualmethod-descriptor/


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WVTCUFTEDCB6FMLABDH4KTJ443IUNTXT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Oscar Benjamin]

On Sat, 26 Jun 2021 at 01:23, Eric V. Smith  wrote:
>
> On 6/25/2021 8:09 PM, Steven D'Aprano wrote:
> > Hi Thomas,
> >
> > On Fri, Jun 25, 2021 at 09:06:58AM -, Thomas Grainger wrote:
> >
> >> I'd like invalid attribute assignment to be prevented at runtime
> > Are you making a specific request for ssl context objects, or a general
> > language-wide request that applies to all objects?
>
> It seems like many of the suggestions are SSLContext specific. I don't
> think we should be adding __slots__ or otherwise redefining the
> interface to that object. Isn't this a general "problem" in python,
> that's always been present? Why are we trying to address the problem
> with this specific object? I suggest doing nothing, or else thinking big
> and solve the general problem, if in fact it needs solving.

I would say that the general problem highlighted here is that
assigning attributes is a bad API. Given that this is already how the
SSL module works, a backwards compatible way to move forwards could be
defining a new class with a more typical interface and better
verification of inputs etc.


Oscar
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KKBYSXKEFRQ5QVWLGGZWUX475AWLRPFU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes

[Christopher Barker]

As has been  said, allowing arbitrary attribute assignments is standard
Python.

But given the security implications, it does make sense to have more
validation in this case.

If backward incompatibility is not an option how about raising a Warning?

-CHB


On Fri, Jun 25, 2021 at 6:30 PM Oscar Benjamin 
wrote:

> On Sat, 26 Jun 2021 at 01:23, Eric V. Smith  wrote:
> >
> > On 6/25/2021 8:09 PM, Steven D'Aprano wrote:
> > > Hi Thomas,
> > >
> > > On Fri, Jun 25, 2021 at 09:06:58AM -, Thomas Grainger wrote:
> > >
> > >> I'd like invalid attribute assignment to be prevented at runtime
> > > Are you making a specific request for ssl context objects, or a general
> > > language-wide request that applies to all objects?
> >
> > It seems like many of the suggestions are SSLContext specific. I don't
> > think we should be adding __slots__ or otherwise redefining the
> > interface to that object. Isn't this a general "problem" in python,
> > that's always been present? Why are we trying to address the problem
> > with this specific object? I suggest doing nothing, or else thinking big
> > and solve the general problem, if in fact it needs solving.
>
> I would say that the general problem highlighted here is that
> assigning attributes is a bad API. Given that this is already how the
> SSL module works, a backwards compatible way to move forwards could be
> defining a new class with a more typical interface and better
> verification of inputs etc.
>
>
> Oscar
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KKBYSXKEFRQ5QVWLGGZWUX475AWLRPFU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LRQKGYNE5YEDI4OEQAGZKKYARMENDGMF/
Code of Conduct: http://python.org/psf/codeofconduct/