Re: [Python-Dev] Return type of alternative constructors

[Guido van Rossum]

On Tue, May 10, 2016 at 6:21 AM, Nick Coghlan  wrote:

> On 10 May 2016 at 02:30, Guido van Rossum  wrote:
> > On Sun, May 8, 2016 at 7:52 PM, Nick Coghlan  wrote:
> >> P.S. It occurs to me that a sufficiently sophisticated typechecker
> >> might be able to look at all of the calls to "cls(*args, **kwds)" in
> >> class methods and "type(self)(*args, **kwds)" in instance methods, and
> >> use those to define a set of type constraints for the expected
> >> constructor signatures in subclassses, even if the current code base
> >> never actually invokes those code paths.
> >
> > Could you restate that as a concrete code example? (Examples of the
> problems
> > with "construction features" would also be helpful, probably -- abstract
> > descriptions of problems often lead me astray.)
>
> Rectangle/Square is a classic example of the constructor signature
> changing, so I'll try to use that to illustrate the point with a
> "displaced_copy" alternate constructor:
>
> class Rectangle:
> def __init__(self, top_left_point, width, height):
> self.top_left_point = top_left_point
> self.width = width
> self.height = height
>
> @classmethod
> def displaced_copy(cls, other_rectangle, offset):
> """Create a new instance from an existing one"""
> return cls(other.top_left_point + offset, other.width,
> other.height)
>

(But why is it a class method? I guess the example could also use an
instance method and it would still have the same properties relevant for
this discussion.)


> class Square:
> def __init__(self, top_left_point, side_length):
> super().__init__(top_left_point, side_length, side_length)
>
> At this point, a typechecker *could* have enough info to know that
> "Square.displaced_copy(some_rectangle, offset)" is necessarily going
> to fail, even if nothing in the application actually *calls*
> Square.displaced_copy.
>

The question remains of course whether the type checker should flag Square
to be an invalid subclass or merely as not implementing displaced_copy().

Anyway, at this point I believe we're just violently agreeing, so no need
for another response. Though Serhiy may be unhappy with the lack of
guidance he's received...

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ctypes compatibility with 2.3

[Brett Cannon]

On Tue, 10 May 2016 at 01:18 Martin Panter  wrote:

> I am working on , to fix shell
> injection problems with ctypes.util.find_library(). The proposal for
> Python 3 is to change os.popen(shell-script) calls to use
> subprocess.Popen().
>
> However the Python 2.7 version of the module has a comment which says
> “This file should be kept compatible with Python 2.3, see PEP 291.”
> Looking at , it is not
> clear why we have to maintain this compatibility. My best guess is
> that there may be an external ctypes package that people want(ed) to
> keep compatible with 2.3, and also keep synchronized with 2.7.
>

That's correct and the maintainer is/was Thomas Heller who I have cc'ed to
see if he's okay with lifting the restriction.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Return type of alternative constructors

[Nick Coghlan]

On 10 May 2016 at 02:30, Guido van Rossum  wrote:
> On Sun, May 8, 2016 at 7:52 PM, Nick Coghlan  wrote:
>> P.S. It occurs to me that a sufficiently sophisticated typechecker
>> might be able to look at all of the calls to "cls(*args, **kwds)" in
>> class methods and "type(self)(*args, **kwds)" in instance methods, and
>> use those to define a set of type constraints for the expected
>> constructor signatures in subclassses, even if the current code base
>> never actually invokes those code paths.
>
> Could you restate that as a concrete code example? (Examples of the problems
> with "construction features" would also be helpful, probably -- abstract
> descriptions of problems often lead me astray.)

Rectangle/Square is a classic example of the constructor signature
changing, so I'll try to use that to illustrate the point with a
"displaced_copy" alternate constructor:

class Rectangle:
def __init__(self, top_left_point, width, height):
self.top_left_point = top_left_point
self.width = width
self.height = height

@classmethod
def displaced_copy(cls, other_rectangle, offset):
"""Create a new instance from an existing one"""
return cls(other.top_left_point + offset, other.width, other.height)

class Square:
def __init__(self, top_left_point, side_length):
super().__init__(top_left_point, side_length, side_length)

At this point, a typechecker *could* have enough info to know that
"Square.displaced_copy(some_rectangle, offset)" is necessarily going
to fail, even if nothing in the application actually *calls*
Square.displaced_copy.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] ctypes compatibility with 2.3

[Martin Panter]

I am working on , to fix shell
injection problems with ctypes.util.find_library(). The proposal for
Python 3 is to change os.popen(shell-script) calls to use
subprocess.Popen().

However the Python 2.7 version of the module has a comment which says
“This file should be kept compatible with Python 2.3, see PEP 291.”
Looking at , it is not
clear why we have to maintain this compatibility. My best guess is
that there may be an external ctypes package that people want(ed) to
keep compatible with 2.3, and also keep synchronized with 2.7.

I would like to lift this restriction to at least 2.4, because that is
when the “subprocess” module was added. I notice that there is already
code that relies on the list.sort(key=...) feature, which was added in
2.4. Ideally I would prefer to drop the restriction and only require
2.7 compatibility. Would either of these options be a problem?

If it is a problem, I think it is still possible to avoid the shell by
passing a sequence of program arguments to os.popen(). But I prefer
not to do this, because the function is marked as deprecated, and the
code would be substantially different to Python 3.

-Martin
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com