À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 :-) !
On 2022-10-30 20:43:23 +0100, Peter Otten wrote:
> On 30/10/2022 14:37, Peter J. Holzer wrote:
> > On 2022-10-30 09:23:27 -0400, Thomas Passin wrote:
> > > On 10/30/2022 6:26 AM, Peter J. Holzer wrote:
> > > > On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote:
> > > > > The funny thing is that if
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, Opti
On 01/11/2022 01.56, Stefan Ram wrote:
dn writes:
On 31/10/2022 11.44, Chris Angelico wrote:
...
I'm curious to what extent sloppy English correlates with sloppy code.
...
When it comes to CVs/resumés (see what I did there?), I must admit that
the most egregious of errors in spelling or gra
On 31/10/2022 11.44, Chris Angelico wrote:
On Mon, 31 Oct 2022 at 09:39, dn wrote:
On 31/10/2022 06.06, Stefan Ram wrote:
Paulo da Silva writes:
Is there anything to do without loosing my script structure and usual
practice?
to lose (losing): to stop having something
to loose (loo
On Mon, 31 Oct 2022 at 09:39, dn wrote:
>
> On 31/10/2022 06.06, Stefan Ram wrote:
> > Paulo da Silva writes:
> >> Is there anything to do without loosing my script structure and usual
> >> practice?
> >
> >to lose (losing): to stop having something
> >to loose (loosing): to let or make l
On 31/10/2022 06.06, Stefan Ram wrote:
Paulo da Silva writes:
Is there anything to do without loosing my script structure and usual
practice?
to lose (losing): to stop having something
to loose (loosing): to let or make loose (see next line)
loose (adj.): not firmly attached/tied/fas
On 30/10/2022 17.48, Paulo da Silva wrote:
Às 02:32 de 30/10/22, dn escreveu:
On 30/10/2022 11.59, Paulo da Silva wrote:
Solution (below) will not work if the mention of Foos in GLOBALS is
a forward-reference. Either move GLOBALS to suit, or surround "Foos"
with quotes.
This is the problem for
Às 17:06 de 30/10/22, Stefan Ram escreveu:
Paulo da Silva writes:
Is there anything to do without loosing my script structure and usual
practice?
to lose (losing): to stop having something
to loose (loosing): to let or make loose (see next line)
loose (adj.): not firmly attached/tied
Às 22:34 de 29/10/22, dn escreveu:
Out of interest, tested snippet in PyCharm, cf native-mypy. It flags the
original:
GLOBALS.foos: Optional[Foos]=Foos()
but not the fall-back:
GLOBALS.foos=Foos()
Must admit, the first query coming to mind was: why is the typing taking
place at i
Às 10:26 de 30/10/22, Peter J. Holzer escreveu:
On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote:
Às 22:34 de 29/10/22, dn escreveu:
Solution (below) will not work if the mention of Foos in GLOBALS is a
forward-reference.
Either move GLOBALS to suit, or surround "Foos" with quotes.
Às 01:14 de 30/10/22, Thomas Passin escreveu:
On 10/29/2022 1:45 PM, Paulo da Silva wrote:
Hi!
Consider this simple script ...
___
from typing import List, Optional
class GLOBALS:
foos=None
class Foo:
def __init__(self):
pass
class Foos:
Foos: List[F
Às 02:32 de 30/10/22, dn escreveu:
On 30/10/2022 11.59, Paulo da Silva wrote:
Solution (below) will not work if the mention of Foos in GLOBALS is a
forward-reference. Either move GLOBALS to suit, or surround "Foos"
with quotes.
This is the problem for me. So far, without typing, I used to have
On 30/10/2022 14:37, Peter J. Holzer wrote:
On 2022-10-30 09:23:27 -0400, Thomas Passin wrote:
On 10/30/2022 6:26 AM, 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 initi
On 2022-10-30 09:23:27 -0400, Thomas Passin wrote:
> On 10/30/2022 6:26 AM, 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 :-) !
> > >
> > > __
On 10/30/2022 6:26 AM, Peter J. Holzer wrote:
On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote:
Às 22:34 de 29/10/22, dn escreveu:
Solution (below) will not work if the mention of Foos in GLOBALS is a
forward-reference.
Either move GLOBALS to suit, or surround "Foos" with quotes.
On 2022-10-29 23:59:44 +0100, Paulo da Silva wrote:
> Às 22:34 de 29/10/22, dn escreveu:
> > Solution (below) will not work if the mention of Foos in GLOBALS is a
> > forward-reference.
> > Either move GLOBALS to suit, or surround "Foos" with quotes.
^^^
On 2022-10-29 20:14:12 -0400, Thomas Passin wrote:
> I don't understand
>
> class Foos:
> Foos: List[Foo]=[]
>
> If "Foos" is supposed to be a class attribute, then it cannot have the same
> name as the class.
Why not? They are in different namespaces.
#v+
#!/usr/bin/python3
class Foos:
On 30/10/2022 11.59, Paulo da Silva wrote:
Solution (below) will not work if the mention of Foos in GLOBALS is a
forward-reference. Either move GLOBALS to suit, or surround "Foos"
with quotes.
This is the problem for me. So far, without typing, I used to have some
config and globals classes, mo
On 10/29/2022 1:45 PM, Paulo da Silva wrote:
Hi!
Consider this simple script ...
___
from typing import List, Optional
class GLOBALS:
foos=None
class Foo:
def __init__(self):
pass
class Foos:
Foos: List[Foo]=[]
# SOME GLOBALS ARE USED HERE in a r
Às 22:34 de 29/10/22, dn escreveu:
Out of interest, tested snippet in PyCharm, cf native-mypy. It flags the
original:
GLOBALS.foos: Optional[Foos]=Foos()
but not the fall-back:
GLOBALS.foos=Foos()
Must admit, the first query coming to mind was: why is the typing taking
place at i
Out of interest, tested snippet in PyCharm, cf native-mypy. It flags the
original:
GLOBALS.foos: Optional[Foos]=Foos()
but not the fall-back:
GLOBALS.foos=Foos()
Must admit, the first query coming to mind was: why is the typing taking
place at initialisation-time, rather than within
Do you want the following?
```
from typing import List, Optional
class GLOBALS:
foos: Optional[Foos] = None
class Foo:
def __init__(self):
pass
class Foos:
Foos: List[Foo] = []
def __init__(self):
pass
GLOBALS.foos = Foos()
```
Kind regards,
Sam Ezeh
On S
Hi!
Consider this simple script ...
___
from typing import List, Optional
class GLOBALS:
foos=None
class Foo:
def __init__(self):
pass
class Foos:
Foos: List[Foo]=[]
# SOME GLOBALS ARE USED HERE in a real script
def __init__(self):
pass
G
On 8/27/2011 9:42 AM, Jason Swails wrote:
P.S. I'll note that my "preferred" behavior is how python3.2 actually
operates
Python core developers agree. This is one of the reasons for breaking a
bit from 2.x to make Python 3.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/py
On Sat, Aug 27, 2011 at 6:42 AM, Jason Swails wrote:
> Hello everyone,
>
> This is probably a basic question with an obvious answer, but I don't quite
> get why the type(foo).__name__ works differently for some class instances
> and not for others. If I have an "underived" class, any instance of
On Sat, Aug 27, 2011 at 11:42 PM, Jason Swails wrote:
> I can't explain this behavior (since doesn't every class inherit from object
> by default? And if so, there should be no difference between any of my class
> definitions).
That is true in Python 3, but not in Python 2. That's why your exampl
Hello everyone,
This is probably a basic question with an obvious answer, but I don't quite
get why the type(foo).__name__ works differently for some class instances
and not for others. If I have an "underived" class, any instance of that
class is simply of type "instance". If I include an expli
28 matches
Mail list logo
