Chris Angelico於 2019年5月18日星期六 UTC+8下午3時09分37秒寫道：
> On Sat, May 18, 2019 at 1:51 PM wrote:
> >
> > Correct me if I am wrong, please.
> >
> > I always think that the LEGB rule (e.g. the namespace to look up for) was
> > applied at compile-time, only the binding was resolved "dynamically" at
> > ru
On Sat, May 18, 2019 at 1:51 PM wrote:
>
> Correct me if I am wrong, please.
>
> I always think that the LEGB rule (e.g. the namespace to look up for) was
> applied at compile-time, only the binding was resolved "dynamically" at
> run-time. For example:
>
> def foo():
> print(x)
>
> foo() wi
Irv Kalb writes:
> ...
> The only thing that threw me was that in a line like:
>
> self.x = self.x + 1
>
> in a method, these two uses of self.x can refer to different variables. I
> actually teach Python, and this would be a very difficult thing to explain to
> students.
>
> I have never run
Correct me if I am wrong, please.
I always think that the LEGB rule (e.g. the namespace to look up for) was
applied at compile-time, only the binding was resolved "dynamically" at
run-time. For example:
def foo():
print(x)
foo() will cause a NameError. But after
x = 5
foo() will run corr
On 05/17/2019 11:37 AM, Irv Kalb wrote:
self.x = self.x + 1
I have never run across this issue because I would never use the same name as
an instance attribute and a class attribute.
So you treat your class attributes as if they were static?
--
~Ethan~
--
https://mail.python.org/mailman/lis
On Sat, May 18, 2019 at 4:40 AM Irv Kalb wrote:
>
> Thanks for your comments. I am very aware of all the other issues that you
> explained.
>
> The only thing that threw me was that in a line like:
>
> self.x = self.x + 1
>
> in a method, these two uses of self.x can refer to different variables
> On May 15, 2019, at 5:41 PM, Ben Finney wrote:
>
> Irv Kalb writes:
>
>> I just saw some code that confused me. The confusion has to do with
>> class variables and instance variables.
>
> (Perhaps unrelated, but here's another confusion you may be suffering
> from: There's no such thing as
Irv Kalb writes:
> I just saw some code that confused me. The confusion has to do with
> class variables and instance variables.
(Perhaps unrelated, but here's another confusion you may be suffering
from: There's no such thing as a “class variable” or “instance
variable”. In Python, a “variable
> On May 15, 2019, at 11:02 AM, Rob Gaddi
> wrote:
>
> On 5/15/19 10:52 AM, Irv Kalb wrote:
>> I just saw some code that confused me. The confusion has to do with class
>> variables and instance variables. In order to understand it better, I built
>> this very small example:
>> class Test:
On 5/15/19 10:52 AM, Irv Kalb wrote:
I just saw some code that confused me. The confusion has to do with class
variables and instance variables. In order to understand it better, I built
this very small example:
class Test:
x = 0
def __init__(self, id):
self.id = id
On 2/1/19 7:15 AM, sinless...@gmail.com wrote:
Hello guys can you help me to solve problem when i compile proram got error like this
"Instance of 'dict' has no 'replace' member[no member](67;14)".
Python dicts don't have a replace method.
It looks like you're trying to replace strings inside
On Mon, 16 Apr 2018 09:03:47 -0700, Irv Kalb wrote:
> I have been writing OOP code for many years in other languages and for
> the past few years in Python. I am writing new curriculum for a course
> on OOP in Python.
If you're going to be teaching Python, please don't teach terminology
which
Chris Angelico wrote:
> On Tue, Apr 17, 2018 at 3:34 AM, Peter Otten <__pete...@web.de> wrote:
>> Irv Kalb wrote:
>>
>>> I have been writing OOP code for many years in other languages and for
>>> the
>>> past few years in Python. I am writing new curriculum for a course on
>>> OOP
>>> in Python.
On Tue, Apr 17, 2018 at 3:34 AM, Peter Otten <__pete...@web.de> wrote:
> Irv Kalb wrote:
>
>> I have been writing OOP code for many years in other languages and for the
>> past few years in Python. I am writing new curriculum for a course on OOP
>> in Python. In order to see how others are explai
> On Apr 16, 2018, at 9:48 AM, duncan smith wrote:
>
> On 16/04/18 17:03, Irv Kalb wrote:
>> I have been writing OOP code for many years in other languages and for the
>> past few years in Python. I am writing new curriculum for a course on OOP
>> in Python. In order to see how others are ex
Irv Kalb wrote:
> I have been writing OOP code for many years in other languages and for the
> past few years in Python. I am writing new curriculum for a course on OOP
> in Python. In order to see how others are explaining OOP concepts, I have
> been reading as many books and watching as many v
On 16/04/18 17:03, Irv Kalb wrote:
> I have been writing OOP code for many years in other languages and for the
> past few years in Python. I am writing new curriculum for a course on OOP in
> Python. In order to see how others are explaining OOP concepts, I have been
> reading as many books a
On 2018-04-16 18:03, Irv Kalb wrote:
> He gives a demonstration using the following example:
>
> class PartyAnimal():
> x = 0
>
> def party(self):
> self.x = self.x + 1
> print('So far', self.x)
>
> [snip]
>
> But there is something there that seems odd. My understandin
From: Python-list on
behalf of Irv Kalb
Sent: Monday, April 16, 2018 10:03 AM
To: python-list@python.org
Subject: Instance variables question
> class PartyAnimal():
> x = 0
>
> def party(self):
> self.x = self.x + 1
> print('So far', self.x)
Your not accessing the
On Sat, 3 Oct 2015 04:35 pm, neubyr wrote:
> I was wondering if there is any resource that explains why certain methods
> like str() and type() were implemented the way they are, rather than
> .to_string() or .type() instance/object methods.
There is a FAQ that might help with this question:
htt
On 10/3/2015 2:35 AM, neubyr wrote:
I was wondering if there is any resource that explains why certain
methods like str() and type()
These are classes. Calling a class calls the class construction and
initialization functions. These return an instance of the class.
While reading the tutoria
In a message of Fri, 02 Oct 2015 23:35:28 -0700, neubyr writes:
>I was wondering if there is any resource that explains why certain methods
>like str() and type() were implemented the way they are, rather than
>.to_string() or .type() instance/object methods.
>
>I find instance/object methods more
On 20/06/2015 08:24, Steven D'Aprano wrote:
On Fri, 19 Jun 2015 07:29 pm, Robin Becker wrote:
I'm trying to overcome a recursive import issue in reportlab.
..
I'm afraid I don't understand what you are trying to say here. Why can't the
user just set up "such a default" e.g. canvas_ba
On Fri, 19 Jun 2015 07:29 pm, Robin Becker wrote:
> I'm trying to overcome a recursive import issue in reportlab.
>
> Module reportlab.rl_config uses various sources (eg ~/.reportlab_settings)
> to initialize various defaults eg canvas_basefontname. If a user wants to
> utilize reportlab to set u
Robin Becker writes:
> I'm trying to overcome a recursive import issue in reportlab.
> ... sketched solution ...
In the "zope" project, the same problem was approached in a slightly different
way -- see the product "zope.deferredimport". It allows to defer
an actual import for an imported name u
Robin Becker writes:
> For the specific case of the canvas_basefontname I don't actually need
> to do anything specific since it is just a string
The configuration values should be nothing but immutable values:
strings, integers, booleans. Possibly collections of those.
You seem to be implying
On 19/06/2015 11:23, Peter Otten wrote:
Robin Becker wrote:
.
Do I understand this correctly? You got bitten by a complex setup and now
you are hoping to improve the situation by making it even more complex?
How about reordering initialisation in such a way that the user defaults are
Robin Becker wrote:
> I'm trying to overcome a recursive import issue in reportlab.
>
> Module reportlab.rl_config uses various sources (eg ~/.reportlab_settings)
> to initialize various defaults eg canvas_basefontname. If a user wants to
> utilize reportlab to set up such a default, it's not pos
In Rio
writes:
> Hi, When running below code, I get error saying:
> instance attribute "a" defined outside __init__
That's a warning, not an error. And it's a warning from pylint,
not from Python itself.
It's trying to suggest better style, that's all. It's unusual to
define instance vari
On 12/10/2010 5:20 AM, frank cui wrote:
> Hi all,
>
> I'm a novice learner of python and get caught in the following trouble
> and hope experienced users can help me solve it:)
>
> Code:
> ---
> $ cat Muffle_ZeroDivision.py
> #!/
On 01/-10/-28163 02:59 PM, frank cui wrote:
Hi all,
I'm a novice learner of python and get caught in the following trouble and
hope experienced users can help me solve it:)
Code:
---
$ cat Muffle_ZeroDivision.py
#!/usr/bin/env
On 06/23/2010 02:56 PM, John Reid wrote:
>
>
> Thomas Jollans wrote:
>>> The InstanceCounted.count is 1 at the end. If I omit the call to
>>> "self.method = print_exception_decorator(self.method)" then the instance
>>> count goes down to 0 as desired. I thought that the decorator might be
>>> hol
Thomas Jollans wrote:
The InstanceCounted.count is 1 at the end. If I omit the call to
"self.method = print_exception_decorator(self.method)" then the instance
count goes down to 0 as desired. I thought that the decorator might be
holding a reference to the instance through the bound method, so
> The InstanceCounted.count is 1 at the end. If I omit the call to
> "self.method = print_exception_decorator(self.method)" then the instance
> count goes down to 0 as desired. I thought that the decorator might be
> holding a reference to the instance through the bound method, so I added
> t
John Reid wrote:
> Hi,
>
> I've written a decorator that prints exceptions and I'm having some
> trouble with garbage collection.
>
> My decorator is:
>
> import sys
> def print_exception_decorator(fn):
> def decorator(self, *args, **kwds):
> try:
> return fn(*args, *
On 06/23/2010 01:40 PM, John Reid wrote:
> Hi,
>
> I've written a decorator that prints exceptions and I'm having some
> trouble with garbage collection.
>
> My decorator is:
>
> import sys
> def print_exception_decorator(fn):
> def decorator(self, *args, **kwds):
> try:
>
On Mar 3, 6:41 pm, Laszlo Nagy wrote:
> This is just an interesting code pattern that I have recently used:
>
> class CacheStorage(object):
> """Generic cache storage class."""
> @classmethod
> def get_factory(cls,*args,**kwargs):
> """Create factory for a given set of cache st
In article <[EMAIL PROTECTED]>,
M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>
>It is always good practice to provide default values for instance
>variables in the class definition, both to enhance readability and to
>allow adding documentation regarding the variables, e.g.
Actually, my company uses a
On Wed, 26 Nov 2008, Ben Finney wrote:
> John O'Hagan <[EMAIL PROTECTED]> writes:
> > insofar as one is only interested in accessing methods, is there an
> > difference in efficiency (for large enough number of methods and
> > arguments) between
> >
> > a) passing all arguments to __init__() and ac
On Tue, 25 Nov 2008 10:21:18 +0100, M.-A. Lemburg wrote:
> It is always good practice to provide default values for instance
> variables in the class definition, both to enhance readability and to
> allow adding documentation regarding the variables, e.g.
>
> class Class_a:
>
># Foo bar
>
John O'Hagan <[EMAIL PROTECTED]> writes:
> insofar as one is only interested in accessing methods, is there an
> difference in efficiency (for large enough number of methods and
> arguments) between
>
> a) passing all arguments to __init__() and accessing them via self
> within individual methods
On Nov 25, 8:49 pm, John O'Hagan <[EMAIL PROTECTED]> wrote:
> is there an
> difference in efficiency (for large enough number of methods and arguments)
> between
>
> a) passing all arguments to __init__() and accessing them via self within
> individual methods:
>
> class = Class(all_class_args)
>
On Tue, 25 Nov 2008, Rafe wrote:
> On Nov 25, 5:48 pm, John O'Hagan <[EMAIL PROTECTED]> wrote:
> > On Tue, 25 Nov 2008, Marc 'BlackJack' Rintsch wrote:
> > > On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote:
> > > > Is it better to do this:
> > > >
> > > > class Class_a():
> > > > def _
M.-A. Lemburg a écrit :
(snip)
It is always good practice to provide default values for
instance variables in the class definition, both to enhance
readability and to allow adding documentation regarding
the variables, e.g.
Your opinion. As far as I'm concerned, using class variables this way i
On Nov 25, 5:48 pm, John O'Hagan <[EMAIL PROTECTED]> wrote:
> On Tue, 25 Nov 2008, Marc 'BlackJack' Rintsch wrote:
> > On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote:
> > > Is it better to do this:
>
> > > class Class_a():
> > > def __init__(self, args):
> > > self.a = a
On Tue, 25 Nov 2008 10:48:01 +, John O'Hagan wrote:
> On Tue, 25 Nov 2008, Marc 'BlackJack' Rintsch wrote:
>> On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote:
>> > Is it better to do this:
>> >
>> > class Class_a():
>> >def __init__(self, args):
>> >self.a = args.a
>> >
On Tue, 25 Nov 2008, Marc 'BlackJack' Rintsch wrote:
> On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote:
> > Is it better to do this:
> >
> > class Class_a():
> > def __init__(self, args):
> > self.a = args.a
> > self.b = args.b
> > self.c = args.c
> >
snip
> It is always good practice to provide default values for
> instance variables in the class definition, both to enhance
> readability and to allow adding documentation regarding
> the variables, e.g.
>
> class Class_a:
>
> # Foo bar
> a = None
>
> # Foo baz
> b = None
snip
Those
On 2008-11-25 08:27, John O'Hagan wrote:
>
> Is it better to do this:
>
> class Class_a():
> def __init__(self, args):
> self.a = args.a
> self.b = args.b
> self.c = args.c
> self.d = args.d
> def method_ab(self):
>
On 25 Nov, 08:27, John O'Hagan <[EMAIL PROTECTED]> wrote:
> Is it better to do this:
>
> class Class_a():
> def __init__(self, args):
> self.a = args.a
> self.b = args.b
> self.c = args.c
> self.d = args.d
> def
On Tue, 25 Nov 2008 07:27:41 +, John O'Hagan wrote:
> Is it better to do this:
>
> class Class_a():
> def __init__(self, args):
> self.a = args.a
> self.b = args.b
> self.c = args.c
> self.d = args.d
> def method_ab(self):
>
On Jul 24, 2008, at 7:53 PM, King wrote:
The the class is not subclass of another one. Problem still persist.
The code is pretty huge and I am trying to post the information as
clear as possible.
Mark V. Shaney, from Dissociated Press, I presume?
--
PA.
http://alt.textdrive.com/nanoki/
--
ht
King skrev:
The the class is not subclass of another one. Problem still persist.
The code is pretty huge and I am trying to post the information as
clear as possible.
feel free to *add* stuff to the following example until it breaks, if
that's easier:
>>> class Spam:
... def __init__(se
No,
The the class is not subclass of another one. Problem still persist.
The code is pretty huge and I am trying to post the information as
clear as possible.
--
http://mail.python.org/mailman/listinfo/python-list
King a écrit :
The only methods I do have in class is __init__ and __str__.
Is your class subclassing another one ?
--
http://mail.python.org/mailman/listinfo/python-list
King wrote:
The only methods I do have in class is __init__ and __str__.
How ever inst1 and inst2 is coming from a dictionary where I stored
them with a unique id.
inst1 = stored[id]
inst2 = stored[id]
Is this makes a difference?
unlikely (well, if that's the literal code, both variables wil
The only methods I do have in class is __init__ and __str__.
How ever inst1 and inst2 is coming from a dictionary where I stored
them with a unique id.
inst1 = stored[id]
inst2 = stored[id]
Is this makes a difference? I will rip down the piece of code giving
me problem and post.
--
http://mail.p
King wrote:
Is this mean when you have overridden __str__ method then it comapre
with results of __str__ or else it will comapre whether they are the
same instances?
Comparisons uses __cmp__ or the rich comparison set; see
http://docs.python.org/ref/customization.html
for details.
Sets
On Jul 24, 6:50 pm, King <[EMAIL PROTECTED]> wrote:
> I am facing a problem where I am really confused about it.
>
> I am trying to compare to instances using:
>
> if inst1 == inst2
>
> These instances have a overridden method __str__ which returns same
> string. The condition result is true althou
On Jul 17, 5:34 pm, "Calvin Spealman" <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2008 at 2:56 AM, karthikbalaguru
>
> <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > I am new to python. I am trying to use the python files given to me
> > for bringing up a setup.
> > I get the following error while tryin
On Thu, Jul 17, 2008 at 2:56 AM, karthikbalaguru
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am new to python. I am trying to use the python files given to me
> for bringing up a setup.
> I get the following error while trying to use a python file -
> AttributeError : Classroom instance has no attribute
-On [20080717 09:01], karthikbalaguru ([EMAIL PROTECTED]) wrote:
>AttributeError : Classroom instance has no attribute 'desk_offset'
You are using a Classroom instance and probably assigning something to the
instance's variable/attribute 'desk_offset'. Except that the class Classroom
has no self.d
Tim Cook wrote:
On Thu, 2008-07-03 at 14:20 -0500, Larry Bates wrote:
I suspect there is some "misunderstanding" here. Why exactly do you think you
need to have your instances named with [] characters in them?
I often misunderstand. :-)
But, I am implementing specifications in Python tha
On Thu, 2008-07-03 at 14:20 -0500, Larry Bates wrote:
> I suspect there is some "misunderstanding" here. Why exactly do you think
> you
> need to have your instances named with [] characters in them?
>
I often misunderstand. :-)
But, I am implementing specifications in Python that are alre
Tim Cook wrote:
Hi All,
I have a need (if at all possible) to create instance names using '['
and ']', i.e. [at]=ClassA0(), [at0001]=ClassB2(), etc.
Of course Python tries to unpack a sequence when I do that. Is there
anyway to do this?
I do have a workaround but it is an ugly, nasty URL
On May 17, 1:09 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> On May 16, 4:46 am, "甜瓜" <[EMAIL PROTECTED]> wrote:
>
> > Howdy,
> > I wonder why below does not work.
>
> > a = object()
> > a.b = 1# dynamic bind attribute failed...
>
> > To make it correct, we have to create a new class:
>
On May 16, 4:46 am, "甜瓜" <[EMAIL PROTECTED]> wrote:
> Howdy,
> I wonder why below does not work.
>
> a = object()
> a.b = 1# dynamic bind attribute failed...
>
> To make it correct, we have to create a new class:
> class MyClass(object): pass
> a = MyClass()
> a.b = 1 # OK
>
> Doe
"Ìð¹Ï" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| > # an efficient 'Pair' class holding two objects
| > class Pair(object):
| >__slots__ = 'first', 'second'
| >
| > Instances of Pair take up even less room that 2-element tuples
| > because they don't carry the size informat
"甜瓜" <[EMAIL PROTECTED]> writes:
>> # an efficient 'Pair' class holding two objects
>> class Pair(object):
>>__slots__ = 'first', 'second'
>>
>> Instances of Pair take up even less room that 2-element tuples
>> because they don't carry the size information in the object.
>>
>> Now, if the obje
On May 16, 4:26 am, Peter Otten <[EMAIL PROTECTED]> wrote:
> 甜瓜 wrote:
> > I wonder why below does not work.
>
> > a = object()
> > a.b = 1# dynamic bind attribute failed...
>
> The implementation of slots depends on that behaviour:
>
> http://docs.python.org/ref/slots.html
>
> > Does t
On May 16, 10:21 am, castironpi <[EMAIL PROTECTED]> wrote:
> On May 16, 9:41 am, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On May 16, 8:56 am, castironpi <[EMAIL PROTECTED]> wrote:
>
> > > On May 16, 8:51 am, castironpi <[EMAIL PROTECTED]> wrote:
>
> > > > On May 16, 4:26 am, Peter Otten
On May 16, 9:41 am, castironpi <[EMAIL PROTECTED]> wrote:
> On May 16, 8:56 am, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On May 16, 8:51 am, castironpi <[EMAIL PROTECTED]> wrote:
>
> > > On May 16, 4:26 am, Peter Otten <[EMAIL PROTECTED]> wrote:
>
> > > > 甜瓜 wrote:
> > > > > I wonder
On May 16, 8:56 am, castironpi <[EMAIL PROTECTED]> wrote:
> On May 16, 8:51 am, castironpi <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On May 16, 4:26 am, Peter Otten <[EMAIL PROTECTED]> wrote:
>
> > > 甜瓜 wrote:
> > > > I wonder why below does not work.
>
> > > > a = object()
> > > > a.b = 1
On May 16, 4:16 am, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> "甜瓜" <[EMAIL PROTECTED]> writes:
> > Howdy,
> > I wonder why below does not work.
>
> > a = object()
> > a.b = 1# dynamic bind attribute failed...
>
> Because the default object class doesn't have a dict or other
> indicatio
On May 16, 8:51 am, castironpi <[EMAIL PROTECTED]> wrote:
> On May 16, 4:26 am, Peter Otten <[EMAIL PROTECTED]> wrote:
>
> > 甜瓜 wrote:
> > > I wonder why below does not work.
>
> > > a = object()
> > > a.b = 1# dynamic bind attribute failed...
>
> > The implementation of slots depends o
On May 16, 4:26 am, Peter Otten <[EMAIL PROTECTED]> wrote:
> 甜瓜 wrote:
> > I wonder why below does not work.
>
> > a = object()
> > a.b = 1# dynamic bind attribute failed...
>
> The implementation of slots depends on that behaviour:
>
> http://docs.python.org/ref/slots.html
>
> > Does t
2008/5/16 Hrvoje Niksic <[EMAIL PROTECTED]>:
> "甜瓜" <[EMAIL PROTECTED]> writes:
>
>> Howdy,
>> I wonder why below does not work.
>>
>> a = object()
>> a.b = 1# dynamic bind attribute failed...
>
> Because the default object class doesn't have a dict or other
> indication of state. It's
甜瓜 wrote:
> I wonder why below does not work.
>
> a = object()
> a.b = 1# dynamic bind attribute failed...
The implementation of slots depends on that behaviour:
http://docs.python.org/ref/slots.html
> Does this strange behavior break the LSP (Liskov substitution principle)?
Can y
"甜瓜" <[EMAIL PROTECTED]> writes:
> Howdy,
> I wonder why below does not work.
>
> a = object()
> a.b = 1# dynamic bind attribute failed...
Because the default object class doesn't have a dict or other
indication of state. It's a "pure" Python object whose only visible
properties are
"甜瓜" <[EMAIL PROTECTED]> writes:
> Howdy,
> I wonder why below does not work.
>
> a = object()
> a.b = 1# dynamic bind attribute failed...
>
> To make it correct, we have to create a new class:
> class MyClass(object): pass
> a = MyClass()
> a.b = 1 # OK
It's annoyingly diffic
mrstephengross schrieb:
>> class Foo:
>> foo = Foo()
>>
>> You have to live with that. Just do
>> Outer.foo = Outer.Parent()
>> after your class-statement to achieve the same result.
>
> Hmmm. Well, I see why that works. It's too bad, though. If I want to
> keep all executed code safely with
En Wed, 27 Feb 2008 16:52:57 -0200, mrstephengross
<[EMAIL PROTECTED]> escribi�:
>> class Foo:
>> foo = Foo()
>>
>> You have to live with that. Just do
>> Outer.foo = Outer.Parent()
>> after your class-statement to achieve the same result.
>
> Hmmm. Well, I see why that works. It's too bad
> class Foo:
> foo = Foo()
>
> You have to live with that. Just do
> Outer.foo = Outer.Parent()
> after your class-statement to achieve the same result.
Hmmm. Well, I see why that works. It's too bad, though. If I want to
keep all executed code safely within a "if __name__ == '__main__'"
blo
mrstephengross schrieb:
> I've got an interesting problem with my class hierarchy. I have an
> outer class, in which two nested classes are defined:
>
> class Outer:
> class Parent:
> def __init__ (self):
> print "parent!"
> class Child(Parent):
> def __init__ (self):
> Out
[EMAIL PROTECTED] a écrit :
> On Nov 5, 9:40 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
>
>>On Nov 5, 11:32 am, [EMAIL PROTECTED] wrote:
>>
>>
>>>suppose i want to
>>>make foo.childNodes[bar] available as foo[bar]
>>>(while still providing access to the printxml/printprettyxml()
>>>functions
>>>a
On Nov 5, 9:59 am, [EMAIL PROTECTED] wrote:
> On Nov 5, 9:40 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
>
> > On Nov 5, 11:32 am, [EMAIL PROTECTED] wrote:
>
> > > suppose i want to
> > > make foo.childNodes[bar] available as foo[bar]
> > > (while still providing access to the printxml/printprettyx
On Nov 5, 9:40 am, Paul McGuire <[EMAIL PROTECTED]> wrote:
> On Nov 5, 11:32 am, [EMAIL PROTECTED] wrote:
>
> > suppose i want to
> > make foo.childNodes[bar] available as foo[bar]
> > (while still providing access to the printxml/printprettyxml()
> > functions
> > and other functionality of dom/mi
On Nov 5, 11:32 am, [EMAIL PROTECTED] wrote:
> suppose i want to
> make foo.childNodes[bar] available as foo[bar]
> (while still providing access to the printxml/printprettyxml()
> functions
> and other functionality of dom/minidom instance).
>
> What is a good way to accomplish that?
define __get
[EMAIL PROTECTED] wrote:
> suppose i want to
> make foo.childNodes[bar] available as foo[bar]
> (while still providing access to the printxml/printprettyxml()
> functions
> and other functionality of dom/minidom instance).
>
> What is a good way to accomplish that?
Using element-tree. That alre
Danny wrote:
> I have created an instance method for an object using new.instancemethod.
> It works great. Now the questions are:
>
> 1) how do I dynamically inspect an object to determine if it has an
> instance method? (there is a class method with the same name)
Why would you want to do that?
On Aug 22, 10:23 am, Danny <[EMAIL PROTECTED]> wrote:
> 1) how do I dynamically inspect an object to determine if it has an instance
> method? (there is a class method with the same name)
class Foo:
def foo(self):
pass
x = Foo()
import types
>>> isinstance(x.foo, types.MethodType)
T
Em Sáb, 2006-04-15 às 04:03 +1000, Steven D'Aprano escreveu:
> Sometimes you want the default to mutate each time it is used, for example
> that is a good technique for caching a result:
>
> def fact(n, _cache=[1, 1, 2]):
> "Iterative factorial with a cache."
> try:
> return _cache
On Fri, 14 Apr 2006 13:30:49 -0300, Felipe Almeida Lessa wrote:
> Em Sex, 2006-04-14 às 09:18 -0700, wietse escreveu:
>> def __init__(self, name, collection=[]):
>
> Never, ever, use the default as a list.
Unless you want to use the default as a list.
Sometimes you want the default to mutat
Em Sex, 2006-04-14 às 13:30 -0300, Felipe Almeida Lessa escreveu:
> To solve your problem, change
> def __init__(self, name, collection=[]):
> BaseClass.__init__(self)
> self.name = name
> self.collection = collection # Will reuse the list
> to
> def __init__(self,
Em Sex, 2006-04-14 às 09:18 -0700, wietse escreveu:
> def __init__(self, name, collection=[]):
Never, ever, use the default as a list.
> self.collection = collection
This will just make a reference of self.collection to the collection
argument.
> inst.collection.append(i)
A
Bror Johansson wrote:
> Is there a good and general way to test an instance-object obj for having a
> class belonging to a certain "sub-tree" of the hierarchy with a common
> parent class C?
If I understand you correctly, isinstance ought to do the job:
class A(object):
pass
class B(A):
Bror Johansson:
>I have a class-hierarchy (fairly deep and fairly wide).
>
>Is there a good and general way to test an instance-object obj for having a
>class belonging to a certain "sub-tree" of the hierarchy with a common
>parent class C?
isinstance(obj,C)
--
René Pijlman
--
http://mail.pytho
Scott David Daniels wrote:
> Alex Martelli wrote: (in effect)
>>aptbase.drawables = weakref.WeakValueDictionary()
>> then in each __init__
>>aptbase.drawables[len(aptbase.drawables)] = self
>> then in show:
>>for o in aptbase.drawables.values():
>># render it
>
> The keys you a
Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > My favourite way to use weakref is slightly different: I would have
> >aptbase.drawables = weakref.WeakValueDictionary
> typo here:
> aptbase.drawables = weakref.WeakValueDictionary()
> > then in each __init__
> >
Alex Martelli wrote:
> My favourite way to use weakref is slightly different: I would have
>aptbase.drawables = weakref.WeakValueDictionary
typo here:
aptbase.drawables = weakref.WeakValueDictionary()
> then in each __init__
>aptbase.drawables[len(aptbase.drawables)] = self
> then in
1 - 100 of 130 matches
Mail list logo
