> >>> Example.__bases__
> (First, Second)
Sorry, that should have been
>>> Example.__bases__
(, )
That's what I get for writing an example from memory rather than copying it from
a REPL session. It doesn't change the point I wanted to make, though.
Thanks,
Chris Bouchard
--
https://mail.python
(Apologies if this has already been discussed. I tried to search and didn't find
anything relevant.)
I was playing around with 3.12.0b4 this evening and noticed an odd (to me, at
least) behavior with types.get_original_bases(). I hesitate to call it a bug
because I think I understand *why* it's be
On 4/21/22 15:00, Greg Ewing wrote:
On 20/04/22 10:57 pm, Sam Ezeh wrote:
Has anyone here used or attempted to use a nested class inside an enum?
If so, how did you find it? (what did you expect to happen and did
your expectations align with resulting behaviour etc.)
That's a pretty open-ende
On 20/04/22 10:57 pm, Sam Ezeh wrote:
Has anyone here used or attempted to use a nested class inside an enum?
If so, how did you find it? (what did you expect to happen and did
your expectations align with resulting behaviour etc.)
That's a pretty open-ended question. Is there something about
Hello everyone,
Has anyone here used or attempted to use a nested class inside an enum?
If so, how did you find it? (what did you expect to happen and did
your expectations align with resulting behaviour etc.)
Here are two examples describing the situation I'm talking about
```
class Outer(Enum
On 10/02/2022 09:20, Igor Basko wrote:
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example
Hi everyone,
This is my first question here. Hope to get some clarification.
Basically this question is about multiple inheritance and the usage of
super().__init__ in parent
classes.
So I have two classes that inherit from the same base class.
For example class B and class C inherit from A
half Of Karsten Hilbert
Sent: Friday, December 31, 2021 7:09 AM
To: python-list@python.org
Subject: Re: builtins.TypeError: catching classes that do not inherit from
BaseException is not allowed
Am Thu, Dec 30, 2021 at 03:57:25PM -0800 schrieb hongy...@gmail.com:
> > > Then what cases/scena
On Friday, December 31, 2021 at 4:18:28 PM UTC+8, Marco Sulla wrote:
> It was already done: https://pypi.org/project/tail-recursive/
A few days ago, I also noticed another similar project:
https://github.com/baruchel/tco
It seems that they are very similar, even identical. But I'm not sure, so I
On Friday, December 31, 2021 at 7:17:18 PM UTC+8, hongy...@gmail.com wrote:
> On Friday, December 31, 2021 at 4:18:28 PM UTC+8, Marco Sulla wrote:
> > It was already done: https://pypi.org/project/tail-recursive/
> A few days ago, I also noticed another similar project:
> https://github.com/baruc
Am Thu, Dec 30, 2021 at 03:57:25PM -0800 schrieb hongy...@gmail.com:
> > > Then what cases/scenarios can demonstrate the beauty of recursion?
> > >
> > Walking a tree.
>
> There are many type of trees. Do you mean all of them?
Palm trees don't lend themselves to recursion all that much.
Karsten
ctorial
> return factorial(n-1, n*acc)
> File "/home/werner/this-script.py", line 28, in func
> raise TailRecurseException(args, kwargs)
> TypeError: exceptions must derive from BaseException
>
> During handling of the above exception, another exception occurred:
>
integers
though, ...
-Original Message-
From: Python-list On
Behalf Of hongy...@gmail.com
Sent: Thursday, December 30, 2021 6:27 PM
To: python-list@python.org
Subject: Re: builtins.TypeError: catching classes that do not inherit from
BaseException is not allowed
On Friday, December 31
On Friday, December 31, 2021 at 7:50:48 AM UTC+8, MRAB wrote:
> On 2021-12-30 23:27, hongy...@gmail.com wrote:
> > On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote:
> >> Neither of these wants to be recursive, and writing them recursively
> >> pollutes the function signatur
On 2021-12-30 23:27, hongy...@gmail.com wrote:
On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote:
Neither of these wants to be recursive, and writing them recursively
pollutes the function signature with parameters that really exist just
to be local variables. Passing an ac
On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote:
> Neither of these wants to be recursive, and writing them recursively
> pollutes the function signature with parameters that really exist just
> to be local variables. Passing an accumulator down is a terrible way
> to demo
On Fri, Dec 31, 2021 at 9:42 AM hongy...@gmail.com
wrote:
> > (Also, is this REALLY an optimization? Exception handling isn't the
> > fastest. Yes, it avoids some measure of recursion depth, but it looks
> > like a pretty inefficient way to do things. Python is not Lisp, and
> > there are very ver
gt; > >
> > > [1]
> > > https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800
> > Why did you post in two places at once? Did you need more people to
> > tell you the same thing as the error message?
>
>
On Thursday, December 30, 2021 at 11:23:35 PM UTC+8, Chris Angelico wrote:
> If it's an exception, it needs to subclass Exception or BaseException.
I see. That is, the following:
class TailRecurseException(Exception):
def __init__(self, args, kwargs):
self.args = args
self.kwargs = kwa
On Thursday, December 30, 2021 at 11:24:20 PM UTC+8, Chris Angelico wrote:
> On Fri, Dec 31, 2021 at 2:03 AM hongy...@gmail.com
> wrote:
> > See here [1] for the related discussion.
> >
> > [1]
> > https://discuss.python.org/t/typeerror-catching-classes-that-do-
On Fri, Dec 31, 2021 at 2:03 AM hongy...@gmail.com
wrote:
> See here [1] for the related discussion.
>
> [1]
> https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800
Why did you post in two places at once? Did you need mo
On Fri, Dec 31, 2021 at 2:00 AM hongy...@gmail.com
wrote:
>
> I try to compute the factorial of a large number with tail-recursion
> optimization decorator in Python3. The following code snippet is converted
> from the code snippet given here [1] by the following steps:
>
> $ pyenv shell datasci
aise TailRecurseException(args, kwargs)
> TypeError: exceptions must derive from BaseException
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/home/werner/this-script.py", line 46, in
> p
ng handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/werner/this-script.py", line 46, in
print(factorial(1))
File "/home/werner/this-script.py", line 33, in func
except TailRecurseException as e:
TypeError: ca
Usually an abstract class cannot be instantiated:
>>> from abc import ABCMeta, abstractmethod
>>> from fractions import Fraction
>>> class A(Fraction, metaclass=ABCMeta):
@abstractmethod
def frobnicate(self): pass
>>> A()
Traceback (most recent call last):
File "", lin
13.04.21 15:47, Peter Otten пише:
> As to the | operator, maybe it could be added to Mapping?
The | operator returns a new instance, but constructor is not a part of
the Mapping interface. You cannot make a general implementation, and
making __or__ an abstract method will break all existing Mappin
12.04.21 19:01, Andreas R Maier пише:
> Hi,
> I have written some classes that represent immutable views on collections
> (see "immutable-views" package on Pypi).
>
> Currently, these view classes inherit from the abstract collection classes
> such as Mapping,
On 12/04/2021 18:01, Andreas R Maier wrote:
Hi,
I have written some classes that represent immutable views on collections (see
"immutable-views" package on Pypi).
Currently, these view classes inherit from the abstract collection classes such as Mapping,
Sequence, Set. However, they
Hi,
I have written some classes that represent immutable views on collections (see
"immutable-views" package on Pypi).
Currently, these view classes inherit from the abstract collection classes such
as Mapping, Sequence, Set. However, they implement the read-only methods of
dict, li
Do you make frequent use of Abstract Base Classes (ABCs), prefer to use
an ordinary super-class for the same purpose, or steer-clear? Are they
more-usually employed when the project includes an extensive design
stage, and the meta-class integral to some hierarchy of entities?
Previous Friday
On Fri, Oct 30, 2020 at 5:16 PM Julio Di Egidio wrote:
> Not to mention, from the point of view of formal verification,
> this is the corresponding annotated version, and it is in fact
> worse than useless:
>
> def abs(x: Any) -> Any:
> ...some code here...
>
Useless because, in the absence of
On Friday, 30 October 2020 05:09:34 UTC+1, Chris Angelico wrote:
> On Fri, Oct 30, 2020 at 1:06 PM Julio Di Egidio wrote:
> > On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer wrote:
> > > I think you are trying to use Python in a way contrary to its nature.
> > > Python is a dynamicall
On Fri, Oct 30, 2020 at 1:06 PM Julio Di Egidio wrote:
>
> On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer wrote:
> > I think you are trying to use Python in a way contrary to its nature.
> > Python is a dynamically typed language. Its variables don't have types,
> > only its objects.
On Sunday, 25 October 2020 20:55:26 UTC+1, Peter J. Holzer wrote:
> On 2020-10-22 23:35:21 -0700, Julio Di Egidio wrote:
> > On Friday, 23 October 2020 07:36:39 UTC+2, Greg Ewing wrote:
> > > On 23/10/20 2:13 pm, Julio Di Egidio wrote:
> > > > I am now thinking whether I could achieve the "standa
Peter J. Holzer wrote at 2020-10-25 20:48 +0100:
>On 2020-10-22 23:35:21 -0700, Julio Di Egidio wrote:
> ...
>> and the whole lot, indeed why even subclass ABC?
You often have the case that a base class can implement
a lot of functionality based on a few methods defined
by derived
On 2020-10-22 23:35:21 -0700, Julio Di Egidio wrote:
> On Friday, 23 October 2020 07:36:39 UTC+2, Greg Ewing wrote:
> > On 23/10/20 2:13 pm, Julio Di Egidio wrote:
> > > I am now thinking whether I could achieve the "standard"
> > > behaviour via another approach, say with decorators, somehow
> >
I'm a C++ programmer and Python programmer as well. Python classes are not
exactly like C++ classes.
If you define a class where every method has an implementation, then it really
isn't abstract. It can be instantiated. You can force it to be abstract by
doing from abc import A
On Friday, 23 October 2020 07:36:39 UTC+2, Greg Ewing wrote:
> On 23/10/20 2:13 pm, Julio Di Egidio wrote:
> > I am now thinking whether I could achieve the "standard"
> > behaviour via another approach, say with decorators, somehow
> > intercepting calls to __new__... maybe.
>
> I'm inclined to
On 23/10/20 2:13 pm, Julio Di Egidio wrote:
I am now thinking whether I could achieve the "standard"
behaviour via another approach, say with decorators, somehow
intercepting calls to __new__... maybe.
I'm inclined to step back and ask -- why do you care about this?
Would it actually do any ha
):
>pass
>
> Then subclass from that:
>
>class MoreConcrete(Concrete):
>pass
>
> If you do a
>
>issubclass(, ABC)
>
> you'll get
>
>True
Ah, right, that's the point I was missing: how to tell the
compiler when a mor
#x27;s say you subclass from ABC:
class Abstract(ABC):
pass
Then you subclass from that:
class Concrete(Abstract):
pass
Then subclass from that:
class MoreConcrete(Concrete):
pass
If you do a
issubclass(, ABC)
you'll get
True
The idea behind abstract
On Thu, 22 Oct 2020 at 22:09, Marco Sulla
wrote:
> Not sure because I never tried or needed, but if no @abstractsomething in
> A is defined and your B class is a subclass of A, B should be an abstract
> class, not a concrete class.
>
Now I'm sure:
>>> from abc import ABC, abstractmethod
>>> cla
On Thu, 22 Oct 2020 at 18:31, Julio Di Egidio wrote:
> why
> only if there are abstract methods defined in an ABC
> class is instantiation disallowed?
>
Not sure because I never tried or needed, but if no @abstractsomething in A
is defined and your B class is a subclass of A, B should be an abst
OO language the class would be not
instantiable, period, since it's "abstract". But
this is not so in Python, to the point that, also
for uniformity, I am feeling compelled to define an
@abstractmethod __init__ in my ABC classes, whether
they need one or not, and whether there are
On 8/6/20 10:53 PM, ZHAOWANCHENG wrote:
> So instances of user-defined classes are immutable by default?
> Or the description of "if a tuple contains any mutable object either
> directly or indirectly, it cannot be used as a key." in the document
> is not completely corr
On 8/6/20 8:53 PM, ZHAOWANCHENG wrote:
> So instances of user-defined classes are immutable by default?
No, they're clealry mutable.
> Or the description of "if a tuple contains any mutable object either directly
> or indirectly, it cannot be used as a key."
me = mycls()
>>> >>> me.a = 2 # mutable?
>>> >>> {(1, me): 'mycls'}
>>> {(1, <__main__.mycls object at 0x022824DAD668>): 'mycls'}
>>> >>>
>>>
>>>
>>> So are
aced into a tuple that as a key of a dict:
> >>> class mycls(object):
> ... a = 1
> ...
> >>> me = mycls()
> >>> me.a = 2 # mutable?
> >>> {(1, me): 'mycls'}
> {(1, <__main__.mycls object at 0x000
): 'mycls'}
>> {(1, <__main__.mycls object at 0x022824DAD668>): 'mycls'}
>> >>>
>>
>>
>> So are instances of user-defined classes mutable or immutable?
>>
> user class instances are clearly mutable, and in my python
On 8/6/20 7:40 AM, Robin Becker wrote:
On 06/08/2020 05:17, ZHAOWANCHENG wrote:
So are instances of user-defined classes mutable or immutable?
user class instances are clearly mutable, and in my python 3.8 you can
do horrid things like this
>
> [snip buggy/incorrect uses of __hash__
hat as a key of a dict:
> >>> class mycls(object):
> ... a = 1
> ...
> >>> me = mycls()
> >>> me.a = 2 # mutable?
> >>> {(1, me): 'mycls'}
> {(1, <__main__.mycls object at 0x022824DAD668>):
of a dict:
>>> class mycls(object):
... a = 1
...
>>> me = mycls()
>>> me.a = 2 # mutable?
>>> {(1, me): 'mycls'}
{(1, <__main__.mycls object at 0x022824DAD668>): 'mycls'}
>>>
So are i
:
... a = 1
...
>>> me = mycls()
>>> me.a = 2 # mutable?
>>> {(1, me): 'mycls'}
{(1, <__main__.mycls object at 0x022824DAD668>): 'mycls'}
>>>
So are instances of user-defined classes mutable or immutable?
--
https://mail.python.org/mailman/listinfo/python-list
joseph pareti wrote:
> one more question. In the code below, there are 2 init() methods, one for
> the class 'Fahrzeug' and
> one for the class 'PKW'.
> The program works when I instantiate the class as:
>
> fiat = PKW("Fiat Marea",50,0)
>
> but it fails if I say:
>
> fiat = PKW("Fia
On 2020-03-13 09:46:29 +0100, joseph pareti wrote:
> The program works when I instantiate the class as:
>
> fiat = PKW("Fiat Marea",50,0)
>
> but it fails if I say:
>
> *fiat = PKW("Fiat Marea",50,0,1)*
The __init__ method of PKW has this signature:
> def __init__(self, bez, ge, ins):
You
one more question. In the code below, there are 2 init() methods, one for
the class 'Fahrzeug' and one for the class 'PKW'.
The program works when I instantiate the class as:
fiat = PKW("Fiat Marea",50,0)
but it fails if I say:
*fiat = PKW("Fiat Marea",50,0,1)*
*Traceback (most recent call l
joseph pareti writes:
> thank you, that fixes it. I also noticed that both statements work:
>
> super(PKW, self).__init__(bez,ge)
>
> or
>
>super().__init__(bez,ge)
The first is the required Python 2 calling (at least the first argument is
required). The second way can be used
> On 12 Mar 2020, at 14:28, joseph pareti wrote:
>
> thank you, that fixes it. I also noticed that both statements work:
>
> super(PKW, self).__init__(bez,ge)
This form is for python 2 compatibility.
>
> or
>
> super().__init__(bez,ge)
This is the python 3 way. If you do not
thank you, that fixes it. I also noticed that both statements work:
super(PKW, self).__init__(bez,ge)
or
super().__init__(bez,ge)
Am Do., 12. März 2020 um 12:58 Uhr schrieb MRAB :
> On 2020-03-12 10:54, joseph pareti wrote:
> > The following code that uses a class 'Fahrzeug' an
On 2020-03-12 10:54, joseph pareti wrote:
The following code that uses a class 'Fahrzeug' and an inherited class
'PKW' runs correctly. However, if I use the 'super ' statement in in the
PKW class, it ends with the following error message:
*Traceback (most recent call last): File "erben_a.py",
The following code that uses a class 'Fahrzeug' and an inherited class
'PKW' runs correctly. However, if I use the 'super ' statement in in the
PKW class, it ends with the following error message:
*Traceback (most recent call last): File "erben_a.py", line 19, in
fiat = PKW("Fiat Marea",
y horse for that
matter) I'm pleased at the (lack of negative) response to my allied
question about nested classes, which would solve the original problem)
There's nothing "wrong" with it. It is uncommon. But like a lot of
things, the value (or cost/pitfalls) com
r) I'm pleased at the (lack of negative) response to my allied
question about nested classes, which would solve the original problem)
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
The whole point of object
oriented programme is to present things with the same external API but
different internal implementations, or managing a different thing with
common characteristics.
I have use nested classes when the nested class is strongly associated
with the enclosing class,
On 23/07/19 11:55 PM, Cameron Simpson wrote:
On 23Jul2019 14:54, DL Neil wrote:
Do you use nested classes?
Python manages nested classes.
I've NEVER seen such 'in the wild'.
(but perhaps I lead a sheltered life?)
So sheltered :-)
Well, over here there aren't the ve
On 7/22/19 7:54 PM, DL Neil wrote:
Do you use nested classes?
[following-on from the earlier, "Namespaces: memory vs 'pollution'" discussion
thread, wherein a certain 'someone' remembered to from ... import ... as ... an
'action' class but forgot to al
On 23Jul2019 14:54, DL Neil wrote:
Do you use nested classes?
Python manages nested classes.
I've NEVER seen such 'in the wild'.
(but perhaps I lead a sheltered life?)
So sheltered :-)
In my experience it's uncommon. I've done it a few times.
"Nested" c
Do you use nested classes?
[following-on from the earlier, "Namespaces: memory vs 'pollution'"
discussion thread, wherein a certain 'someone' remembered to from ...
import ... as ... an 'action' class but forgot to also import the
related custom error
On 16/07/19 10:57 PM, Cameron Simpson wrote:
On 16Jul2019 10:20, Chris Angelico wrote:
On Tue, Jul 16, 2019 at 10:17 AM DL Neil
wrote:
When used, do you embed a class's name within its own code, as a
literal?
[...]
So, what about other situations where one might need to access the
class's o
On 16Jul2019 10:20, Chris Angelico wrote:
On Tue, Jul 16, 2019 at 10:17 AM DL Neil wrote:
When used, do you embed a class's name within its own code, as a
literal?
[...]
So, what about other situations where one might need to access the
class's own name or that of its/a super-class? eg
clas
> >>>
>
> One of the answers recommended super() [agreed!] in order to avoid
> embedding "C1" into the code. The explanation: in case the name of the
> parent class is ever changed.
>
> Which is eminently reasonable (remember, the parent class may be in a
&
embedding "C1" into the code. The explanation: in case the name of the
parent class is ever changed.
Which is eminently reasonable (remember, the parent class may be in a
separate file, and thus few "cues" to remember to inspect and amend
sub-classes' code!)
So, what
Dave,
On 30/04/19 7:36 AM, Dave wrote:
On 4/29/19 3:26 PM, Terry Reedy wrote:
On 4/29/2019 1:38 PM, Dave wrote:
As apps get more complex we add modules, or Python files, to organize
things. One problem I have is a couple of data classes (list of
dictionary objects) in a few modules that
On 4/29/19 3:26 PM, Terry Reedy wrote:
On 4/29/2019 1:38 PM, Dave wrote:
As apps get more complex we add modules, or Python files, to organize
things. One problem I have is a couple of data classes (list of
dictionary objects) in a few modules that are used in a number of the
other modules
On 4/29/2019 1:38 PM, Dave wrote:
As apps get more complex we add modules, or Python files, to organize
things. One problem I have is a couple of data classes (list of
dictionary objects) in a few modules that are used in a number of the
other modules. For example a list of meter reading
As apps get more complex we add modules, or Python files, to organize
things. One problem I have is a couple of data classes (list of
dictionary objects) in a few modules that are used in a number of the
other modules. For example a list of meter reading dictionaries in one
module is used by
On 2019-02-27 12:34:37 -0500, Dennis Lee Bieber wrote:
> On Tue, 26 Feb 2019 19:15:16 -0800 (PST), jf...@ms4.hinet.net declaimed the
> following:
>
> >So, may I say that the Python compiler is a multi-pass one?
>
> No... that is implementation dependent...
True, but
> The common Pyt
jf...@ms4.hinet.net於 2019年2月26日星期二 UTC+8下午4時46分04秒寫道：
> ast於 2019年2月26日星期二 UTC+8上午12時25分40秒寫道：
> > Hello
> >
> > I noticed a quirk difference between classes and functions
> >
> > >>> x=0
> > >>>
> > >>> cla
Chris Angelico於 2019年2月27日星期三 UTC+8上午11時29分04秒寫道：
> On Wed, Feb 27, 2019 at 2:21 PM wrote:
> >
> > Chris Angelico於 2019年2月27日星期三 UTC+8上午9時25分11秒寫道：
> > > On Wed, Feb 27, 2019 at 12:21 PM wrote:
> > > >
> > > > Gregory Ewing at 2019/2/27 AM 5:26:49 wrote:
> > > > > Thomas Jollans wrote:
> > > > >
On Wed, Feb 27, 2019 at 2:21 PM wrote:
>
> Chris Angelico於 2019年2月27日星期三 UTC+8上午9時25分11秒寫道：
> > On Wed, Feb 27, 2019 at 12:21 PM wrote:
> > >
> > > Gregory Ewing at 2019/2/27 AM 5:26:49 wrote:
> > > > Thomas Jollans wrote:
> > > > > I imagine there's a justification for the difference in behaviou
Chris Angelico於 2019年2月27日星期三 UTC+8上午9時25分11秒寫道：
> On Wed, Feb 27, 2019 at 12:21 PM wrote:
> >
> > Gregory Ewing at 2019/2/27 AM 5:26:49 wrote:
> > > Thomas Jollans wrote:
> > > > I imagine there's a justification for the difference in behaviour to do
> > > > with the fact that the body of a class
On Wed, Feb 27, 2019 at 12:21 PM wrote:
>
> Gregory Ewing at 2019/2/27 AM 5:26:49 wrote:
> > Thomas Jollans wrote:
> > > I imagine there's a justification for the difference in behaviour to do
> > > with the fact that the body of a class is only ever executed once, while
> > > the body of a functi
On 2/26/19, Gregory Ewing wrote:
> Thomas Jollans wrote:
>> I imagine there's a justification for the difference in behaviour to do
>> with the fact that the body of a class is only ever executed once, while
>> the body of a function is executed multiple times.
>
> I suspect there isn't any deep r
Gregory Ewing at 2019/2/27 AM 5:26:49 wrote:
> Thomas Jollans wrote:
> > I imagine there's a justification for the difference in behaviour to do
> > with the fact that the body of a class is only ever executed once, while
> > the body of a function is executed multiple times.
>
> I suspect there i
#x27;s 117 bugs in the code.
-Original Message-
From: Python-list On
Behalf Of Gregory Ewing
Sent: Tuesday, February 26, 2019 4:27 PM
To: python-list@python.org
Subject: Re: Quirk difference between classes and functions
Thomas Jollans wrote:
> I imagine there's a justification for
Thomas Jollans wrote:
I imagine there's a justification for the difference in behaviour to do
with the fact that the body of a class is only ever executed once, while
the body of a function is executed multiple times.
I suspect there isn't any deep reason for it, rather it's just
something that
On 25/02/2019 21.15, Chris Angelico wrote:
> On Tue, Feb 26, 2019 at 6:58 AM DL Neil
> wrote:
>>
>> On 26/02/19 5:25 AM, ast wrote:
>>> I noticed a quirk difference between classes and functions
>>> >>> x=0
>>> >>> class Test:
ast於 2019年2月26日星期二 UTC+8上午12時25分40秒寫道：
> Hello
>
> I noticed a quirk difference between classes and functions
>
> >>> x=0
> >>>
> >>> class Test:
> x = x+1
> print(x)
> x = x+1
> print(x)
>
On Tue, Feb 26, 2019 at 5:06 PM Gregory Ewing
wrote:
>
> Chris Angelico wrote:
> > Classes and functions behave differently. Inside a function, a name is
> > local if it's ever assigned to; but in a class, this is not the case.
>
> Actually, it is. Assigning to a
Chris Angelico wrote:
Classes and functions behave differently. Inside a function, a name is
local if it's ever assigned to; but in a class, this is not the case.
Actually, it is. Assigning to a name in a class body makes it part
of the class namespace, which is the local namespace at the
On Tue, Feb 26, 2019 at 6:58 AM DL Neil wrote:
>
> On 26/02/19 5:25 AM, ast wrote:
> > I noticed a quirk difference between classes and functions
> > >>> x=0
> > >>> class Test:
> > x = x+1
> > print(x)
> >
On 26/02/19 5:25 AM, ast wrote:
I noticed a quirk difference between classes and functions
>>> x=0
>>> class Test:
x = x+1
print(x)
x = x+1
print(x)
...
Previous code doesn't generate any errors.
x at the right of = in first "
Hello
I noticed a quirk difference between classes and functions
>>> x=0
>>>
>>> class Test:
x = x+1
print(x)
x = x+1
print(x)
1
2
>>> print(x)
0
Previous code doesn't generate any errors.
x at the right of = in fi
jf...@ms4.hinet.net於 2018年12月28日星期五 UTC+8下午4時04分07秒寫道：
> eryk sun at 2018/12/27 UTC+8 PM 6:58:33 wrote:
> > On 12/27/18, jf...@ms4.hinet.net wrote:
> > >
> > > I still don't get it. When I change it to using list comprehension, the
> > > problem is still there. (it now has no late-binding variable
eryk sun at 2018/12/27 UTC+8 PM 6:58:33 wrote:
> On 12/27/18, jf...@ms4.hinet.net wrote:
> >
> > I still don't get it. When I change it to using list comprehension, the
> > problem is still there. (it now has no late-binding variable, right? :-)
> >
> class Too:
> > ... XS = [15, 15, 15,
On Fri, Dec 28, 2018 at 8:47 AM eryk sun wrote:
>
> On 12/27/18, Chris Angelico wrote:
> >
> > Class scope is special, and a generator expression within that class
> > scope is special too. There have been proposals to make these kinds of
> > things less special, but the most important thing to r
On 12/27/18, Chris Angelico wrote:
>
> Class scope is special, and a generator expression within that class
> scope is special too. There have been proposals to make these kinds of
> things less special, but the most important thing to remember is that
> when you create a generator expression, it
On Fri, Dec 28, 2018 at 3:31 AM Ian Kelly wrote:
>
> On Wed, Dec 26, 2018 at 11:21 PM Chris Angelico wrote:
> >
> > On Thu, Dec 27, 2018 at 1:56 PM wrote:
> > >
> > > I saw the code below at stackoverflow. I have a little idea about the
> > > scope of a class, and list comprehension and generat
On Wed, Dec 26, 2018 at 11:21 PM Chris Angelico wrote:
>
> On Thu, Dec 27, 2018 at 1:56 PM wrote:
> >
> > I saw the code below at stackoverflow. I have a little idea about the scope
> > of a class, and list comprehension and generator expressions, but still
> > can't figure out why Z4 works and
On 12/27/18, jf...@ms4.hinet.net wrote:
>
> I still don't get it. When I change it to using list comprehension, the
> problem is still there. (it now has no late-binding variable, right? :-)
>
class Too:
> ... XS = [15, 15, 15, 15]
> ... Z4 = [val for val in XS]
> ... Z5 = [XS[0]
1 - 100 of 2489 matches
Mail list logo
