Re: Fwd: A typing question
Às 21:08 de 31/10/22, Peter J. Holzer escreveu: On 2022-10-30 11:26:56 +0100, Peter J. Holzer wrote: On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote: The funny thing is that if I replace foos by Foos it works because it gets known by the initial initialization :-) ! from typing import List, Optional class GLOBALS: Foos: Optional[Foos]=None [...] class Foos: That seems like a bug to me. But is it even true? I just tried to reproduce it (should have done that before answering) with mypy 0.942 (included in Ubuntu 22.04 LTS): [p1]--- from typing import List, Optional class GLOBALS: foos: Optional[Foos]=None class Foo: def __init__(self): pass class Foos: Foos: List[Foo]=[] # SOME GLOBALS ARE USED HERE def __init__(self): pass GLOBALS.foos=Foos() --- [p2]--- from typing import List, Optional class GLOBALS: Foos: Optional[Foos]=None class Foo: def __init__(self): pass class Foos: Foos: List[Foo]=[] # SOME GLOBALS ARE USED HERE def __init__(self): pass GLOBALS.Foos=Foos() --- --- p1 2022-10-31 21:59:49.639869922 +0100 +++ p2 2022-10-31 21:58:19.815830677 +0100 @@ -1,7 +1,7 @@ from typing import List, Optional class GLOBALS: -foos: Optional[Foos]=None +Foos: Optional[Foos]=None class Foo: @@ -15,4 +15,4 @@ def __init__(self): pass -GLOBALS.foos=Foos() +GLOBALS.Foos=Foos() So the only difference is the capitalization of foos. And mypy accepts both (as it probably should): % mypy p1 Success: no issues found in 1 source file % mypy p2 Success: no issues found in 1 source file If you did something different, please explain what you did. Yes for mypy. Try to run them (python3 ). Paulo -- https://mail.python.org/mailman/listinfo/python-list
Information about slow execution notebook
I wish to know why sometimes my notebook won't execute my program And VS code won't connect to kernels. Thank you Nhlanhla Ndwandwe Sent from my Galaxy -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
Chris Angelico writes:
> On Mon, 31 Oct 2022 at 14:38, Julieta Shem wrote:
>>
>> Chris Angelico writes:
>>
>> > The most straight-forward way to represent this concept in an
>> > object-oriented way is subclassing.
>> >
>> > class Stack:
>> > ... # put whatever code is common here
>> >
>> > class Empty(Stack):
>> > ... # put Empty-specific code here, possibly overriding Stack methods
>> >
>> > class Pair(Stack):
>> >... # ditto, overriding or augmenting as needed
>> >
>> > This way, everything is an instance of Stack, but they are still
>> > distinct types for when you need to distinguish.
>>
>> Can you provide a small example? I can't see what you mean, but it
>> seems interesting.
>
> Sure. The easiest way would be to take your existing Empty and Pair
> classes, have them subclass Stack, and don't bother putting any code
> at all into Stack. Then construct an Empty and a few Pairs, and what
> you'll see is that all of them are also instances of Stack.
>
> After that, it's really a question of what you expect to be able to do
> with either an Empty or a Pair. Anything that should be possible with
> both types (that is, anything that should be possible with either
> variant of Stack) should get moved into the Stack type, while anything
> that is specific to one or the other stays in its own class. So here's
> a very very simple example:
>
> class Stack:
> def prepend(self, other):
> return Pair(other, self)
>
> class Empty(Stack):
> def is_last(self):
> return True
> def get_current(self):
> raise ValueError("Stack empty")
> def get_next(self):
> raise ValueError("Stack empty")
>
> class Pair(Stack):
> def __init__(self, item1, item2):
> self.item1 = item1
> self.item2 = item2
> def get_current(self):
> return self.item1
> def get_next(self):
> return self.item2
> def is_last(self):
> return isinstance(self.item2, Empty)
>
> With this setup, you can build a stack by prepending items onto an
> Empty endpoint, and can iterate over it with the get_current and
> get_next methods. (Making this actually iterable, so that it works
> with a Python 'for' loop, would be a good exercise.)
>
> In this example, there isn't much code in the Stack class. But you
> could easily add more, and it would apply to both Empty and Pair.
Thank you so much for the example. It's very interesting as it sort of
reverses my intuition. It seems non-obvious. I had in mind to build a
Stack out of Empty and Pair, but you seem to have done it the other way
around.
But I still don't see a way of using your classes up there in which I
have a single name to build empty and non-empty stacks. Let me
clarify. If I wish for an empty stack, I wish I could just say
>>> Stack()
Stack()
and if I wish for a nonempty stack, I'd write
>>> Stack(1, Stack(2, Stack(3, Stack(
Stack(1, Stack(2, Stack(3, Stack(
With your classes, I think I must write
>>> Empty() # That's an empty stack
...
>>> Pair(1, Pair(2, Empty())) # That's a non-empty stack
...
In other words, I need to memorize two different names for using stacks.
I'm trying to have a single name for both parts of the union (that is my
design of a stack).
Thanks so much!
--
https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
Alan Gauld writes: > On 30/10/2022 14:01, Julieta Shem wrote: > >> I wrote the classes >> >> class Empty: >> ... >> class Pair: >> ... >> >> (*) How to build a stack? >> >> These Lisp-like sequences are clearly a stack. > > That is a very important observation. A Pair IS-A Stack(sort of). > If you had a stack you could create a Pair from it certainly. Yes, they are the same thing --- in my mind ---, except possibly for the user interface, names and stuff. I do prefer to make the user think he has something else simply because it has a different name. It is not the user's business to know what things are on the inside. >> So far so good, but when it comes to building a better user interface >> for it I have no idea how to do it. I think one of the purposes of OOP >> is to organize code hierarchically so that we can reuse what we wrote. > > One of the purposes of classes certainly. I'm not so sure it's a purpose > of OOP. They are not the same thing. A class is a programming construct > OOP is a programming style. Classes facilitate OOP but can be used > outside of OOP too. That's an interesting observation. I like that. Classes are one thing and OOP is another. Of course, at the extreme I think I will get nowhere in trying to detect in high-precision what is OOP and what is not. The same for classes. I always liked to think of C structures as some class. Instead of saying ``new Whatever()'', I'd say ``malloc(sizeof ...)''. I'd then have many procedures whose first argument were a pointer to Whatever. They're the methods. So the structure Whatever si the class itself. Is this use of C outside of OOP? I say it is not because my notion of OOP is that --- a way to make objects and have methods operate on them, changing them or not. Should I allow the non-change of objects to be OOP as well? I think so. To me what distinguishes functional from imperative is, for example, imperative has side-effects. We can take an imperative set of tools and do not produce any side-effects (locally speaking, of course) and that would be indisguishable from functional programming. We can say that imperative languages are more general than functional ones. (That's my non-educated guess for the moment anyhow.) >> So I tried to make a Stack by inheriting Pair. > > But you said above that a Pair was a Stack. Inheritance implies an > IS-A relationship, so Stack inheriting Pair would mean that a Stack > was a Pair. That is not really true. That's another interesting observation. I do not have much understanding of how to really think of these things and that's most likely why I never tried to understand OOP or imperative programming. It seems very difficult. What I meant is that a Pair was a Stack and a Stack was a Pair. The reason I was creating a Stack at all was just to make the user think it's something different --- and with more obvious names for the case under analysis, which was the use of a stack-like data structure. > A Stack could use a Pair (or many of them) but it is not a Pair. Is this how I should design it? I tried that, actually. It seemed to complicate my life because I had to provide to my Stack class various other methods my Pair class already had. > Trying to use inheritance inappropriately is one of the > biggest (and commonest) mistakes in OOP. It invariably leads > to complications. If in doubt use delegation instead. What is delegation? I think that's why I never went into OOP and imperative languages. It just seems bloody difficult to get anything right. Call me stupid or what you will, but it seems very difficult. Any book recomendations on getting this thing mathematics-clear? Thank you! -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
I think:
class Stack:
def __init__( self, *args ):
self.data = args
def __str__( self ):
return f"Stack({','.join(str(x) for x in self.data)})"
gives equivalent output for the if len(args) is 0 or 2, if it’s okay for
self.data to be a tuple.
class Stack:
def __init__( self, *args ):
self.data = list(args)
def __str__( self ):
return f"Stack({','.join(str(x) for x in self.data)})"
If it’s desired self.data be a list.
From: Python-list on
behalf of Stefan Ram
Date: Tuesday, November 1, 2022 at 3:43 PM
To: [email protected]
Subject: Re: an oop question
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***
Julieta Shem writes:
>clarify. If I wish for an empty stack, I wish I could just say
Stack()
>Stack()
>and if I wish for a nonempty stack, I'd write
Stack(1, Stack(2, Stack(3, Stack(
>Stack(1, Stack(2, Stack(3, Stack(
If this is all,
main.py
class Stack:
def __init__( self, *args ):
self.data = [ args[ 0 ], args[ 1 ]]if len( args ) else []
def __str__( self ):
if len( self.data ):
return f"Stack({self.data[0]}, {self.data[1]})"
else:
return f"Stack()"
print( Stack() )
print( Stack(1, Stack(2, Stack(3, Stack( )
output
Stack()
Stack(1, Stack(2, Stack(3, Stack(
.
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!itEYnwU5jJ0z8_rkW_q_ogw3ZJUNdHdMNkMLpSAqBdozBNrr7NqPs_gNsbx8W9uXRLZpG38C9an17Yx2zUf-mSA$
--
https://mail.python.org/mailman/listinfo/python-list
Re: Information about slow execution notebook
> On 1 Nov 2022, at 16:08, nhlanhlah198506 wrote: > > I wish to know why sometimes my notebook won't execute my program And VS code > won't connect to kernels. Thank you Nhlanhla Ndwandwe Sent from my Galaxy You need to provide details on what you do and what happens. Reminder do not attach screen shots, they are striped in this mailing list. Cut-n-paste full error message information. Barry > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
[email protected] (Stefan Ram) writes: > Julieta Shem writes: >>clarify. If I wish for an empty stack, I wish I could just say > Stack() >>Stack() >>and if I wish for a nonempty stack, I'd write > Stack(1, Stack(2, Stack(3, Stack( >>Stack(1, Stack(2, Stack(3, Stack( > > If this is all, > > main.py > > class Stack: > def __init__( self, *args ): > self.data = [ args[ 0 ], args[ 1 ]]if len( args ) else [] > def __str__( self ): > if len( self.data ): > return f"Stack({self.data[0]}, {self.data[1]})" > else: > return f"Stack()" > > print( Stack() ) > > print( Stack(1, Stack(2, Stack(3, Stack( ) > > output > > Stack() > Stack(1, Stack(2, Stack(3, Stack( Thanks! But we've left behind a more basic requirement --- the Stack class wishes for all the methods already written in some class called Pair, which has a certain connection with a class Empty. This requirement has been implicit in the first message in this thread, though. I didn't make it explicit. (In other words, this part of the thread only makes sense by taking into account all the previous messages up in the thread.) -- https://mail.python.org/mailman/listinfo/python-list
Re: an oop question
[email protected] (Stefan Ram) writes: > [email protected] (Stefan Ram) writes: >>The crucial feature OOP adds to this is polymorphism ("late binding"). > > If polymorphism is so crucial, the idea of subclasses > has something to it! [...] I wonder what Rich Hickey would say here. Didn't he design Clojure with ``multimethods'' so that we can get some kind of polymorphism without subclassing? -- https://mail.python.org/mailman/listinfo/python-list
Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8
On 11/1/22, [email protected] wrote: > > **IDLE can’t Import TKINTER > > Python may not be configured for TK** > > Checkmark for TK is set in the Installation Progress. What went wrong and ho > can I fix it? Run the following command to check whether the ImportError has any further information. py -3.10-32 -c "from tkinter import *" It could be a missing extension module or DLL, or mismatched version. You could try modifying the installation to remove tkinter and IDLE, and then again to restore it. -- https://mail.python.org/mailman/listinfo/python-list
Re: Problems with IDLE in Windows 8.1 and installer x86 Version 3.10.8
On 11/1/22, Nithish Ramasamy wrote: > > pip install tkinter > Wait some minutes to install tkinter There is no tkinter package on PyPI. It's part of the standard library and included with the python.org installer as an optional component. -- https://mail.python.org/mailman/listinfo/python-list
