On Fri, Dec 5, 2014 at 9:10 AM, Wolfgang Maier
wrote:
> which I read as there has been a stepwise transition between 2.5 and 2.7 so
> that 2.7 now behaves like Python 3 even without the __future__ statement.
> OTOH, I believe you, of course, if you're saying implicit relative imports
> are working
On 04.12.2014 22:30, Chris Angelico wrote:
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
wrote:
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses relative imports - inside
package.module1 is
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier
wrote:
> On 04.12.2014 19:05, Chris Angelico wrote:
>>
>>
>> With os.path it definitely is. With the actual code in question, it's
>> a Python 2.7 project that mostly uses relative imports - inside
>> package.module1 is "import module2" etc - and I wa
On 04.12.2014 19:05, Chris Angelico wrote:
With os.path it definitely is. With the actual code in question, it's
a Python 2.7 project that mostly uses relative imports - inside
package.module1 is "import module2" etc - and I was writing an
external script that calls on one of the modules.
What
On Fri, Dec 5, 2014 at 4:36 AM, Jean-Michel Pichavant
wrote:
> I know you specifically stated you didn't want to do this but
>
> import os
>
> os.path.isfile()
>
> is the best option imo, especially from the reader point of view ("Namespaces
> are one honking great idea").
With os.path it defini
On 12/03/2014 03:02 AM, Chris Angelico wrote:
>
> Throughout the code, I want to refer to "path.split()",
> "path.isfile()", etc, without the "os." in front of them. I could do
> either of these:
>
> import os.path as path
> from os import path
>
> Which one would you recommend? Does it depend o
On 12/04/2014 09:36 AM, Jean-Michel Pichavant wrote:
>
> I know you specifically stated you didn't want to do this but
>
> import os
>
> os.path.isfile()
>
> is the best option imo, especially from the reader point of view ("Namespaces
> are one honking great idea").
But, "Flat is better
- Original Message -
> From: "Chris Angelico"
> To: python-list@python.org
> Sent: Wednesday, 3 December, 2014 12:02:17 PM
> Subject: Style question: Importing modules from packages - 'from' vs 'as'
>
> When importing a module from a subpackage, it's sometimes convenient
> to refer to it
On 12/03/2014 12:02 PM, Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package nam
On 12/3/2014 6:02 AM, Chris Angelico wrote:
When importing a module from a subpackage, it's sometimes convenient
to refer to it throughout the code with a one-part name rather than
two. I'm going to use 'os.path' for the examples, but my actual
use-case is a custom package where the package name
On Dec 3, 2014 4:34 AM, "Chris Angelico" wrote:
>
> On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten <__pete...@web.de> wrote:
> > Don't repeat yourself, so
> >
> > from os import path
> >
> > always. On the other hand I have never thought about actual renames, e.
g.
> >
> > from os import path as std
On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten <__pete...@web.de> wrote:
> Don't repeat yourself, so
>
> from os import path
>
> always. On the other hand I have never thought about actual renames, e. g.
>
> from os import path as stdpath
>
> versus
>
> import os.path as stdpath
>
> I think I'd use t
Chris Angelico wrote:
> When importing a module from a subpackage, it's sometimes convenient
> to refer to it throughout the code with a one-part name rather than
> two. I'm going to use 'os.path' for the examples, but my actual
> use-case is a custom package where the package name is, in the
> ap
On 3 December 2014 at 22:02, Chris Angelico wrote:
>
> import os.path as path
> from os import path
>
Bah - deleted the list and sent directly to Chris ... time to go to bed.
The advantage of the former is that if you want to use a different name,
it's a smaller change. But the disadvantage of
On 2013-05-08 21:20, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
"A list of FooEntries"
"A list of FooEntrys"
"A list of FooEntry's"
"A list of FooEntry instances"
The first one certainly sounds the best, but it seems wierd to change
the spel
On 2013-05-09, Jussi Piitulainen wrote:
> Neil Cerutti writes:
>> If there's no chance for confusion between a class named
>> FooEntry and another named FooEntries, then the first attempt
>> seems best. Pluralize a class name by following the usual
>> rules, e.g., "strings" and "ints".
>
> Like "s
Neil Cerutti writes:
> If there's no chance for confusion between a class named FooEntry
> and another named FooEntries, then the first attempt seems best.
> Pluralize a class name by following the usual rules, e.g.,
> "strings" and "ints".
Like "strings" would be "foo entries". Which might work
On 2013-05-08, Denis McMahon wrote:
> On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
>
>> FooEntry is a class. How would you describe a list of these in a
>> docstring?
>>
>> "A list of FooEntries"
>>
>> "A list of FooEntrys"
>>
>> "A list of FooEntry's"
>>
>> "A list of FooEntry instan
Am 09.05.2013 02:38 schrieb Colin J. Williams:
On 08/05/2013 4:20 PM, Roy Smith wrote:
"A list of FooEntry's" +1
Go back to school. Both of you...
That is NOT the way to build a plural form...
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
On 09May2013 00:02, Steven D'Aprano
wrote:
| On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
| > "A list of FooEntry's"
|
| "Here come's an S! Quick, jam on an apostrophe!"
|
| This is called the grocer's apostrophe, and is universally held in
| contempt no matter what variant of English
On 08/05/2013 4:20 PM, Roy Smith wrote:
FooEntry is a class. How would you describe a list of these in a
docstring?
"A list of FooEntries" 0
"A list of FooEntrys" -1
"A list of FooEntry's" +1
"A list of FooEntry instances" No FooEntry is specified as a class.
The first one certainly so
On Wed, 08 May 2013 15:33:07 -0500, Skip Montanaro wrote:
> This one:
>
>> "A list of FooEntry instances"
>
> Besides the obvious spelling issues in the others, it's not immediately
> clear if the list contains just FooEntry instances, FooEntry classes
> (perhaps subclasses) or a mix of the two.
On Thu, May 9, 2013 at 6:20 AM, Roy Smith wrote:
> "A list of FooEntry's"
Only if you put another apostrophe in:
"A list of 'FooEntry's"
But the delimited style is almost never of use. I'd go for this only
if there were some sort of automated markup being applied - if the
word FooEntry were tur
On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
> FooEntry is a class. How would you describe a list of these in a
> docstring?
Which language are you writing your docstrings in? Obey the normal rules
of spelling, grammar and punctuation for your language, which I assume is
English.
>
On Wed, 08 May 2013 16:20:48 -0400, Roy Smith wrote:
> FooEntry is a class. How would you describe a list of these in a
> docstring?
>
> "A list of FooEntries"
>
> "A list of FooEntrys"
>
> "A list of FooEntry's"
>
> "A list of FooEntry instances"
>
> The first one certainly sounds the best,
On Wed, May 8, 2013 at 2:37 PM, John Downs wrote:
> On Wed, May 8, 2013 at 4:20 PM, Roy Smith wrote:
>>
>> FooEntry is a class. How would you describe a list of these in a
>> docstring?
>>
>> "A list of FooEntries"
>>
>> "A list of FooEntrys"
>>
>> "A list of FooEntry's"
>>
>> "A list of FooEntr
On Wed, May 8, 2013 at 4:20 PM, Roy Smith wrote:
> FooEntry is a class. How would you describe a list of these in a
> docstring?
>
> "A list of FooEntries"
>
> "A list of FooEntrys"
>
> "A list of FooEntry's"
>
> "A list of FooEntry instances"
>
> The first one certainly sounds the best, but it
This one:
> "A list of FooEntry instances"
Besides the obvious spelling issues in the others, it's not
immediately clear if the list contains just FooEntry instances,
FooEntry classes (perhaps subclasses) or a mix of the two. #4 makes
it clear.
Skip
--
http://mail.python.org/mailman/listinfo/p
On Tue, 17 Jul 2012 05:23:22 -0700, Michele Simionato wrote:
> The standard is to use `cls`. In the __new__ method you can use `mcl` or
> `meta`.
Thanks to everyone who answered.
I think I will stick with "meta" and "cls".
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Jul 17, 2012 at 12:10 AM, alex23 wrote:
> On Jul 17, 1:29 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> Here's a style question for you: in a metaclass, what should I call the
>> instance parameter of methods, "cls" or "self"?
>
> Maybe portmanteu it as "clasself"? :)
Wh
On Tue, Jul 17, 2012 at 6:23 AM, Michele Simionato
wrote:
> The standard is to use `cls`. In the __new__ method you can use `mcl` or
> `meta`.
I've also seen `mcs` a fair amount.
--
http://mail.python.org/mailman/listinfo/python-list
The standard is to use `cls`. In the __new__ method you can use `mcl` or `meta`.
--
http://mail.python.org/mailman/listinfo/python-list
On 7/16/2012 11:29 AM, Steven D'Aprano wrote:
Here's a style question for you: in a metaclass, what should I call the
instance parameter of methods, "cls" or "self"?
class ExampleMeta(type):
def method(self, *args): ...
I'm not quite sure if that feels right. On the one hand, self is the
E
On Wednesday, 14 March 2012 21:16:05 UTC, Terry Reedy wrote:
> On 3/14/2012 4:49 PM, Arnaud Delobelle wrote:
> > On 14 March 2012 20:37, Croepha wrote:
> >> Which is preferred:
> >>
> >> for value in list:
> >> if not value is another_value:
> >> value.do_something()
> >> break
>
> Do
On Thu, Mar 15, 2012 at 7:37 AM, Croepha wrote:
> Which is preferred:
>
> for value in list:
> if not value is another_value:
> value.do_something()
> break
>
> --or--
>
> if list and not list[0] is another_value:
> list[0].do_something()
>
> Comments are welcome, Thanks
General principle
> > Only use 'is' if you are looking for objects like True,
> > False, None or something that MUST be exactly the same object.
>
> I've rarely seen valid uses of 'is True' or 'is False'.
It can be useful when you think something might be None or False. Although,
I suppose you could always just us
On 14 March 2012 22:15, Prasad, Ramit wrote:
> Only use 'is' if you are looking for objects like True,
> False, None or something that MUST be exactly the same object.
I've rarely seen valid uses of 'is True' or 'is False'.
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
> >> Which is preferred:
> >>
> >> for value in list:
> >> if not value is another_value:
> >> value.do_something()
> >> break
>
> Do you really mean 'is' or '=='?
Let me expound on how 'is' and '==' are very different. It may work
for some comparisons but often not for others. Certain
On 3/14/2012 4:49 PM, Arnaud Delobelle wrote:
On 14 March 2012 20:37, Croepha wrote:
Which is preferred:
for value in list:
if not value is another_value:
value.do_something()
break
Do you really mean 'is' or '=='?
If you mean x is not y, write it that way.
'not x is y' can be mis
On 14 March 2012 20:37, Croepha wrote:
> Which is preferred:
>
> for value in list:
> if not value is another_value:
> value.do_something()
> break
>
> --or--
>
> if list and not list[0] is another_value:
> list[0].do_something()
Hard to say, since they don't do the same thing :)
I suspe
Gerald Britton wrote:
Nope. it's nothing to do with imports. It's about objects passed to
methods at run time. Complicated objects with many levels. Not about
modules at all.
Who is providing these objects ?
- Your code ? => as said before, you can fix your design with a proper
object
Gerald Britton wrote:
however, considering what
"import a.module.that.is.quite.nested as myModule"
Won't work since I get the objects at run time
myModule = __import__('whatever.module.imported.at.run.time', globals(),
locals(), [], -1)
See http://docs.python.org/library/function
Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter.
[snip]
1. You need to call this thing many times with different arguments, so
you wind up with:
x = some.deeply.nested.object.method(some.other.deeply.nested.object.value1)
y = some.deeply.nested.obj
On 1/30/11 1:13 PM, rantingrick wrote:
> On Jan 30, 12:53 pm, Stephen Hansen wrote:
>> OH MY GOD. How can someone be expected to understand what a function does!
>
> Yes, and also how decorators word and generators work, and ...
>
>> Be serious! You can't expect that of them.
>
> I don't. I don
On Sun, 30 Jan 2011 12:51:20 -0500, Gerald Britton wrote:
> Hi all,
>
> Today I was thinking about a problem I often encounter. Say that I have
> (seems I often do!) a deeply nested object, by which I mean object
> within object with object, etc.
>
> For example:
>
> x =
> some.deeply.ne
>
> I don't. I don't expect anyone to write 10 lines of obfuscation code
> when just two will suffice. Maybe you should join the perl group as
> they would proud!
But Stephen's 10 lines of somewhat obscure code actually works, and your two
lines of code doesn't. I know which one I would prefer.
On Jan 30, 12:53 pm, Stephen Hansen wrote:
> On 1/30/11 10:35 AM, rantingrick wrote:
>
> > Well congratulations Stephen, you win the obfuscation prize of the
> > year!
>
> Yes,
>
> On 1/30/11 10:09 AM, rantingrick wrote:
>
> > Here is how a pythonic local block would look
>
> > with this as localv
On 30/01/2011 17:51, Gerald Britton wrote:
Hi all,
Today I was thinking about a problem I often encounter. Say that I
have (seems I often do!) a deeply nested object, by which I mean
object within object with object, etc.
For example:
x = some.deeply.nested.object.method(some.other.deeply
On 1/30/11 10:35 AM, rantingrick wrote:
> Well congratulations Stephen, you win the obfuscation prize of the
> year!
Yes,
On 1/30/11 10:09 AM, rantingrick wrote:
> Here is how a pythonic local block would look
>
> with this as localvar:
> localvar.do_something()
verses
with my(this) as loca
On Jan 30, 12:23 pm, Stephen Hansen wrote:
> --- start
> from contextlib import contextmanager
>
> class Item(object): pass
>
> deeply = Item()
> deeply.nested = Item()
> deeply.nested.thing = Item()
>
> @contextmanager
> def my(thing):
> yield thing
>
> with my(deeply.nested.thing) as o:
>
On 1/30/11 9:51 AM, Gerald Britton wrote:
> 1. If you had to choose between approaches 1 and 2, which one would
> you go for, and why?
Neither. Ideally, I'd tweak the API around so the deeply nested
structure isn't something I need to access regularly. But! If you can't
do that, I'd do something l
In article ,
Gerald Britton wrote:
> 1. You need to call this thing many times with different arguments, so
> you wind up with:
>
> x =
> some.deeply.nested.object.method(some.other.deeply.nested.object.value1)
> y =
> some.deeply.nested.object.method(some.other.deeply.nested.object.val
On Jan 30, 11:51 am, Gerald Britton wrote:
[...]
> that I might confuse with the first. To make it look better I might do this:
>
> _o = some.deeply.nested.object
> _o.method(_o.value)
>
> which is fine, I suppose.
It is very fine. And you "supposed" correctly!
> Then, putting on my co
On Nov 25, 7:43 am, Paul Rubin wrote:
> Gerald Britton writes:
> > if v:
> > f()
>
> > I might, however, think more in a functional-programming direction.
> > Then I might write:
>
> > v and f()
>
> Python has conditional expressions. The above would be:
>
> f() if v else Non
Gerald Britton writes:
> if v:
> f()
>
> I might, however, think more in a functional-programming direction.
> Then I might write:
>
> v and f()
Python has conditional expressions. The above would be:
f() if v else None
using "and" is bug-prone.
--
http://mail.python.org/m
Gerald Britton writes:
> Writing in Python gives me the luxury of choosing different paradigms
> for similar operations. Lately I've been thinking about a minor
> detail that peaked my interest and am curious what others think:
>
> Say that I have some function "f" that I will execute if some va
Both paradigms are in the bash shell. Using a test switch (like -x for
executiable) mixed with an && or ||.
Example:
[-x /usr/bin/firefox ] || exit
I think it's very clear, to old hands, but not so much for a new or
intermediate users.
It certainly is the 'cleaner' form. Like the C styl
On Nov 24, 2010, at 1:46 PM, Gerald Britton wrote:
> Say that I have some function "f" that I will execute if some variable
> "v" evaluates true. Using a classical procedural approach, I might
> write:
>
>if v:
>f()
>
> I might, however, think more in a functional-programming direct
On Nov 24, 11:46 am, Gerald Britton wrote:
> Say that I have some function "f" that I will execute if some variable
> "v" evaluates true. Using a classical procedural approach, I might
> write:
>
> if v:
> f()
>
> I might, however, think more in a functional-programming direction.
> T
I said:
>> > My intent was to fix an obvious omission: a special case
>> was discussed in
>> > the "Augmented assignment statements" section, but an
>> almost-identical
>> > special case was omitted from the "Assignment statements" section.
After finally getting registered at bugs.python.o
John Posner wrote:
> [snip]
> >> > If the object is a class instance and the attribute reference
> occurs
> >> > on both sides of the assignment operator; for example::
> >> >
> >> > self.x = self.x + 1
> >> >
> >> > ... in the RHS expression, ``self.x`` is evaluated with
[snip]
>> > If the object is a class instance and the attribute reference
occurs
>> > on both sides of the assignment operator; for example::
>> >
>> > self.x = self.x + 1
>> >
>> > ... in the RHS expression, ``self.x`` is evaluated with
>> > ``getattr()``, which ca
John Posner wrote:
> On Mon Mar 16 03:42:42, I said:
>
>> RTFM, in section "Augmented assignment statements" of python301.chm:
>>
>> ---
>> For targets which are attribute references, the initial value is retrieved
>
>> with a getattr() and the result is assigned with a setattr(). Notice that
> t
On Mon Mar 16 03:42:42, I said:
> RTFM, in section "Augmented assignment statements" of python301.chm:
>
> ---
> For targets which are attribute references, the initial value is retrieved
> with a getattr() and the result is assigned with a setattr(). Notice that
the
> two methods do not necess
In article ,
Maxim Khitrov wrote:
>
>Very simple question on the preferred coding style. I frequently write
>classes that have some data members initialized to immutable values.
>For example:
>
>class Test(object):
>def __init__(self):
>self.some_value = 0
>self.another_value
On Mon, 16 Mar 2009 09:31:59 -, Aaron Brady
wrote:
[snippety snip]
Otherwise, either /1, every instance has its own entries for class
functions, and subsequent changes to the class don't affect existing
instances, or /2, every method call is of the form x.__class__.foo
( ). They're both b
On Mar 15, 9:54 pm, "Rhodri James"
wrote:
> On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady
> wrote:
>
>
>
>
>
> > On Mar 15, 1:50 pm, "Rhodri James"
> > wrote:
> >> On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
> >> wrote:
>
> >> > On Mar 15, 12:39 pm, John Posner wrote:
> >> >> (My apo
John Posner wrote:
Matthew Woodcraft said:
I doubt it's because anyone particularly wanted this
behaviour; it just
falls out of the way '+=' is defined.
At the point where 'inst.x += 1' is compiled,
Python doesn't know
whether 'inst.x' is going to turn out to be a class
attribute or an
inst
John Posner wrote:
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls()
Cls.
On Mon, 2009-03-16 at 04:02 +, Tim Wintle wrote:
> On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote:
Doh, reply out of thread there - I meant to reply to Rhodi's comment
further down.
> Is there any actual advantage to self.attribute picking up
> Class.attribute instead of raising a NameEr
On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote:
> (My apologies if the thread has already covered this.) I believe I understand
> the WHAT in this situation, but I don't understand the WHY ...
> Is there a beneficial effect of silently creating the instance attribute,
> which outweighs the
On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady
wrote:
On Mar 15, 1:50 pm, "Rhodri James"
wrote:
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
wrote:
> On Mar 15, 12:39 pm, John Posner wrote:
>> (My apologies if the thread has already covered this.) I believe I
>> understand the WH
Earlier, I said:
> I'll look into what the standard Python doc set says on this
> matter.
>
RTFM, in section "Augmented assignment statements" of python301.chm:
---
For targets which are attribute references, the initial value is retrieved with
a getattr() and the result is assigned with a se
John Posner wrote:
> Summary: I no longer suspect that "Python is broken". I *do* think that
> there's a situation that is potentially quite confusing:
>
> * In the statement "self.x = self.x + 1", the two "self.x" names can
> sometimes refer to different objects.
But this is fundamental to Py
On Mar 15, 1:50 pm, "Rhodri James"
wrote:
> On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
> wrote:
>
> > On Mar 15, 12:39 pm, John Posner wrote:
> >> (My apologies if the thread has already covered this.) I believe I
> >> understand the WHAT in this situation, but I don't understand the WH
Matthew Woodcraft said:
> I doubt it's because anyone particularly wanted this
> behaviour; it just
> falls out of the way '+=' is defined.
>
> At the point where 'inst.x += 1' is compiled,
> Python doesn't know
> whether 'inst.x' is going to turn out to be a class
> attribute or an
> instance a
M R A Barnett wrote:
> Aaron Brady wrote:
> [snip]
> > However, in my (opined) interpretation, 'list.append(...) is an in-
> > place operation' is a factual error. In-place operations -also-
> > rebind their 'argument' (FLOBW for lack of better words). 'append' is
> > a by-side-effect operation.
John Posner a écrit :
(My apologies if the thread has already covered this.) I believe I
understand the WHAT in this situation, but I don't understand the WHY
...
Given this class definition:
class Cls(object): x = 345
... I observe the following, using IDLE 2.6.1:
inst = Cls() Cls.x is inst
"Rhodri James" writes:
> But do you, though? The only occasion I can think of that I'd want
> the search to go past the instance is this "auto-initialisation",
> and frankly I'd rather do that in an __init__ anyway. Perhaps
> static methods or class methods work that way, I don't know how
> the
Rhodri James a écrit :
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
wrote:
On Mar 15, 12:39 pm, John Posner wrote:
(snip)
Is there a beneficial effect of silently creating the instance
attribute, which outweighs the detrimental effects: (1)
inconsistency, (2) the "surprising" decoupli
John Posner writes:
> My question is ... WHY does the interpreter silently create the
> instance attribute at this point, causing a "surprising decoupling"
> from the class attribute? WHY doesn't the interpreter behave as it
> would with a simple, non-instance variable:
> > python
> Python 2
On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady
wrote:
On Mar 15, 12:39 pm, John Posner wrote:
(My apologies if the thread has already covered this.) I believe I
understand the WHAT in this situation, but I don't understand the WHY
...
[snip]
My question is ... WHY does the interprete
On Mar 15, 12:39 pm, John Posner wrote:
> (My apologies if the thread has already covered this.) I believe I understand
> the WHAT in this situation, but I don't understand the WHY ...
>
> Given this class definition:
>
> class Cls(object):
> x = 345
>
> ... I observe the following, using
(My apologies if the thread has already covered this.) I believe I understand
the WHAT in this situation, but I don't understand the WHY ...
Given this class definition:
class Cls(object):
x = 345
... I observe the following, using IDLE 2.6.1:
>>> inst = Cls()
>>> Cls.x is inst.x
True
Aaron Brady wrote:
[snip]
However, in my (opined) interpretation, 'list.append(...) is an in-
place operation' is a factual error. In-place operations -also-
rebind their 'argument' (FLOBW for lack of better words). 'append' is
a by-side-effect operation. However colloquially it's mostly
accur
On Mar 15, 8:56 am, "Rhodri James"
wrote:
> On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
>
> wrote:
>
> [snip Gary Herron's explanation of instance attribute lookup
> falling back to class attribute lookup]
>
> > It seems clear to me that Maxim understood all this when he asked his
> >
Maxim Khitrov a écrit :
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(self):
On Sun, 15 Mar 2009 15:05:04 -, Matthew Woodcraft
wrote:
"Rhodri James" writes:
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
It seems clear to me that Maxim understood all this when he asked his
original question (you need to understand this subtlety to know why
the trick h
"Rhodri James" writes:
> On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
>> It seems clear to me that Maxim understood all this when he asked his
>> original question (you need to understand this subtlety to know why
>> the trick he was asking about only works for immutable values).
>
> It
On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft
wrote:
[snip Gary Herron's explanation of instance attribute lookup
falling back to class attribute lookup]
It seems clear to me that Maxim understood all this when he asked his
original question (you need to understand this subtlety to k
Gary Herron writes:
> Gary Herron wrote:
> No, you are still misinterpreting your results. But you can be forgiven
> because this is quite a subtle point about Python's attribute access.
>
> Here's how it works:
>
> On access, self.count (or self.anything) attempts to find "count" in
> the inst
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
wrote:
Gary Herron writes:
I think this code is in poor taste: it's clear that it will confuse
people (which is what Maxim was asking about in the first place).
Careful now -- I didn't write that. (Although I ag
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def inc(self):
s
Hallöchen!
Maxim Khitrov writes:
> [...]
>
> The advantage of doing this is that the assignments are evaluated
> once and thus the creation of that class is a bit faster. Access
> is still performed through self.some_value and
> self.another_value. Is there a reason to prefer the first style
> ov
On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft
wrote:
> Gary Herron writes:
> I think this code is in poor taste: it's clear that it will confuse
> people (which is what Maxim was asking about in the first place).
Yes, I see that now, thanks :)
- Max
--
http://mail.python.org/mailman/listin
On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron wrote:
>> Perhaps a different example would help explain what I'm trying to do:
>>
>> class Case1(object):
>> def __init__(self):
>> self.count = 0
>> self.list = []
>>
>> def inc(self):
>> sel
Gary Herron writes:
> But now you are not listening to what people are telling you. It has
> *nothing* to do with the mutability/immutability of the integer and the list
> your two classes create.
No! Did you run the code he posted? The immutability makes all the
difference.
> The difference
Maxim Khitrov wrote:
Perhaps a different example would help explain what I'm trying to do:
class Case1(object):
def __init__(self):
self.count = 0
self.list = []
def inc(self):
self.count += 1
self.list.append(sel
Maxim Khitrov wrote:
On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron wrote:
Maxim Khitrov wrote:
Very simple question on the preferred coding style. I frequently write
classes that have some data members initialized to immutable values.
For example:
class Test(object):
def __init__(se
On Sat, Mar 14, 2009 at 12:32 PM, Maxim Khitrov wrote:
> Very simple question on the preferred coding style. I frequently write
> classes that have some data members initialized to immutable values.
> For example:
>
> class Test(object):
> def __init__(self):
> self.some_value = 0
>
1 - 100 of 132 matches
Mail list logo
