On Wed, Aug 22, 2018 at 10:39 AM, Steven D'Aprano
wrote:
> On Wed, 22 Aug 2018 03:58:29 +1000, Chris Angelico wrote:
>
>> On Wed, Aug 22, 2018 at 2:38 AM, Marko Rauhamaa
>> wrote:
>>> Gregory Ewing :
>>>
Marko Rauhamaa wrote:
> Lexically, there is special access:
>
>class C:
On Wed, 22 Aug 2018 03:58:29 +1000, Chris Angelico wrote:
> On Wed, Aug 22, 2018 at 2:38 AM, Marko Rauhamaa
> wrote:
>> Gregory Ewing :
>>
>>> Marko Rauhamaa wrote:
Lexically, there is special access:
class C:
def __init__(self, some, arg):
c = self
On Wed, Aug 22, 2018 at 2:38 AM, Marko Rauhamaa wrote:
> Gregory Ewing :
>
>> Marko Rauhamaa wrote:
>>> Lexically, there is special access:
>>>
>>>class C:
>>>def __init__(self, some, arg):
>>>c = self
>>>class D:
>>>def method(self):
>>>
Gregory Ewing :
> Marko Rauhamaa wrote:
>> Lexically, there is special access:
>>
>>class C:
>>def __init__(self, some, arg):
>>c = self
>>class D:
>>def method(self):
>>access(c)
>>access(some)
>>
On Tue, 21 Aug 2018 00:36:56 +, Dan Sommers wrote:
[...]
(Not that I do this using "inner classes", but I do often want to use
a class as a container for functions, without caring about "self" or
wrapping everything in staticmethod.)
>>>
>>> Isn't that what modules are for? (I
On Mon, 20 Aug 2018 22:55:26 +0300, Marko Rauhamaa wrote:
> Dan Sommers :
>
>> On Mon, 20 Aug 2018 14:39:38 +, Steven D'Aprano wrote:
>>> I have often wished Python had proper namespaces, so I didn't have to
>>> abuse classes as containers in this way :-(
>>>
>>> (Not that I do this using
On Mon, 20 Aug 2018 22:55:26 +0300, Marko Rauhamaa wrote:
> Dan Sommers :
>
>> On Mon, 20 Aug 2018 14:39:38 +, Steven D'Aprano wrote:
>>> I have often wished Python had proper namespaces, so I didn't have to
>>> abuse classes as containers in this way :-(
>>>
>>> (Not that I do this using
Marko Rauhamaa wrote:
Lexically, there is special access:
class C:
def __init__(self, some, arg):
c = self
class D:
def method(self):
access(c)
access(some)
access(arg)
That's only because
Dan Sommers :
> On Mon, 20 Aug 2018 14:39:38 +, Steven D'Aprano wrote:
>> I have often wished Python had proper namespaces, so I didn't have to
>> abuse classes as containers in this way :-(
>>
>> (Not that I do this using "inner classes", but I do often want to use
>> a class as a container
Steven D'Aprano :
> On Mon, 20 Aug 2018 11:40:16 +0300, Marko Rauhamaa wrote:
>
>>class C:
>>def __init__(self, some, arg):
>>c = self
>>class D:
>>def method(self):
>>access(c)
>>access(some)
>>
On Tue, Aug 21, 2018 at 2:12 AM, Dan Sommers wrote:
> On Mon, 20 Aug 2018 14:39:38 +, Steven D'Aprano wrote:
>
>> If a class' methods don't use self, it probably shouldn't be a class.
>
> Agreed.
>
>> I have often wished Python had proper namespaces, so I didn't have to
>> abuse classes as
On Mon, 20 Aug 2018 14:39:38 +, Steven D'Aprano wrote:
> If a class' methods don't use self, it probably shouldn't be a class.
Agreed.
> I have often wished Python had proper namespaces, so I didn't have to
> abuse classes as containers in this way :-(
>
> (Not that I do this using "inner
On Mon, 20 Aug 2018 11:40:16 +0300, Marko Rauhamaa wrote:
>class C:
>def __init__(self, some, arg):
>c = self
>class D:
>def method(self):
>access(c)
>access(some)
>access(arg)
>
>
On Mon, 20 Aug 2018 15:58:57 +0300, Marko Rauhamaa wrote:
[...]
>> The point is that creating a class object every time you want a closure
>> is pointlessly wasteful. There is *no benefit whatsoever* in doing
>> that. If you think there is, then it's probably because you're trying
>> to write
Gregory Ewing :
> Marko Rauhamaa wrote:
>> Some of these chores are heavier, some of them are lighter. But where
>> I have used Python, performance hasn't been a bottleneck. It it were,
>> I'd choose different approaches of implementation.
>
> The point is that creating a class object every time
Marko Rauhamaa wrote:
Some of these chores are heavier, some of them are lighter. But where I
have used Python, performance hasn't been a bottleneck. It it were, I'd
choose different approaches of implementation.
The point is that creating a class object every time you want a
closure is
On Mon, Aug 20, 2018 at 7:05 PM, Gregory Ewing
wrote:
> Marko Rauhamaa wrote:
>>
>> Chris Angelico :
>>
>>> 3) Every invocation of method() has to execute the class body, which
>>> takes time.
>>
>>
>> That's what happens with every method invocation in Python regardless.
>
>
> No, it doesn't!
Marko Rauhamaa wrote:
Chris Angelico :
3) Every invocation of method() has to execute the class body, which
takes time.
That's what happens with every method invocation in Python regardless.
No, it doesn't! Invoking a method involves creating a bound method
object, which is very small and
Gregory Ewing :
> Marko Rauhamaa wrote:
>> At least some of the methods of inner classes are closures (or there
>> would be no point to an inner class).
>
> In Python there is no such thing as an "inner class" in the Java
> sense. You can nest class statements, but that just gives you
> a class
Marko Rauhamaa wrote:
At least some of the methods of inner classes are closures (or there
would be no point to an inner class).
In Python there is no such thing as an "inner class" in the Java
sense. You can nest class statements, but that just gives you
a class that happens to be an
Chris Angelico :
> On Sun, Aug 19, 2018 at 11:54 PM, Marko Rauhamaa wrote:
>>> 3) Every invocation of method() has to execute the class body, which
>>> takes time.
>>
>> That's what happens with every method invocation in Python regardless.
>
> No. You have to execute the *class body*. Every
On Sun, Aug 19, 2018 at 11:54 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>> 2) You can't identify these objects as being of the same type (since
>> they're not).
>
> That's a feature, not a bug. Type membership checking goes against
> duck-typing.
Oh, so it would be better for Python if every
Chris Angelico :
> On Sun, Aug 19, 2018 at 10:28 PM, Marko Rauhamaa wrote:
>> The most useful use of inner classes is something like this:
>>
>> class Outer:
>> def method(self):
>> outer = self
>>
>> class Inner:
>> def spam(self, a, b):
>>
On Sun, Aug 19, 2018 at 10:28 PM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Sun, 19 Aug 2018 11:43:44 +0300, Marko Rauhamaa wrote:
>>> At least some of the methods of inner classes are closures (or there
>>> would be no point to an inner class).
>>
>> [...]
>>
>> (2) Whether or not the
Steven D'Aprano :
> On Sun, 19 Aug 2018 11:43:44 +0300, Marko Rauhamaa wrote:
>> At least some of the methods of inner classes are closures (or there
>> would be no point to an inner class).
>
> [...]
>
> (2) Whether or not the methods of an inner class are closures depends on
> the methods, not
On Sun, 19 Aug 2018 11:43:44 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Sun, 19 Aug 2018 00:11:30 +0300, Marko Rauhamaa wrote:
>>
>>> In Python programming, I mostly run into closures through inner
>>> classes (as in Java).
>>
>> Inner classes aren't closures.
>
> At least some of
Chris Angelico :
> On Sun, Aug 19, 2018 at 9:03 AM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> *headscratch*
>>>
>>> So this is okay:
>>>
>>> def f():
>>> for i in range(5):
>>> def g(): ...
>>>
>>> But this isn't:
>>>
>>> class C:
>>> for i in range(5):
>>> def
Steven D'Aprano :
> On Sun, 19 Aug 2018 00:11:30 +0300, Marko Rauhamaa wrote:
>
>> In Python programming, I mostly run into closures through inner classes
>> (as in Java).
>
> Inner classes aren't closures.
At least some of the methods of inner classes are closures (or there
would be no point to
On Sun, Aug 19, 2018 at 9:03 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> *headscratch*
>>
>> So this is okay:
>>
>> def f():
>> for i in range(5):
>> def g(): ...
>>
>> But this isn't:
>>
>> class C:
>> for i in range(5):
>> def m(self): ...
>>
>> I've missed
Chris Angelico :
> *headscratch*
>
> So this is okay:
>
> def f():
> for i in range(5):
> def g(): ...
>
> But this isn't:
>
> class C:
> for i in range(5):
> def m(self): ...
>
> I've missed something here.
No, you got it right.
Marko
--
On Sun, Aug 19, 2018 at 11:13 AM, Steven D'Aprano
wrote:
> Obviously there is some (small) complexity cost to automating it. I
> didn't specify what a fair number of methods would be (my example showed
> four, but that was just an illustration, not real code). In practice I
> wouldn't even
On Sun, 19 Aug 2018 00:11:30 +0300, Marko Rauhamaa wrote:
> In Python programming, I mostly run into closures through inner classes
> (as in Java).
Inner classes aren't closures.
Its also quite expensive to be populating your application with lots of
classes used only once each, which is a
On Sun, Aug 19, 2018 at 7:11 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>> Your acceptance of closures is a perfect proof of how magic stops
>> looking like magic once you get accustomed to it.
>
> Actually, that's a very good observation. You should stick with a
> smallish kernel of primitives
Chris Angelico :
> Your acceptance of closures is a perfect proof of how magic stops
> looking like magic once you get accustomed to it.
Actually, that's a very good observation. You should stick with a
smallish kernel of primitives and derive the universe from them.
Anyway, functions as
On Sun, Aug 19, 2018 at 6:28 AM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>>> In a word, steer clear of metaprogramming.
>>
>> [...]
>> (2) if you mean what you say, that means no decorators,
>
> Correct. I don't find decorators all that useful or tasteful.
>
>> no closures,
>
> Closures I
Steven D'Aprano :
>> In a word, steer clear of metaprogramming.
>
> [...]
> (2) if you mean what you say, that means no decorators,
Correct. I don't find decorators all that useful or tasteful.
> no closures,
Closures I consider ordinary programming. Nothing meta there.
> no introspection
On Sat, 18 Aug 2018 00:33:26 +0300, Marko Rauhamaa wrote:
> Chris Angelico :
>> Programming is heavily about avoiding duplicated work.
>
> That is one aspect, but overcondensing and overabstracting programming
> logic usually makes code less obvious to its maintainer.
That may very well be
On Sat, Aug 18, 2018 at 7:33 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>> Programming is heavily about avoiding duplicated work.
>
> That is one aspect, but overcondensing and overabstracting programming
> logic usually makes code less obvious to its maintainer. It is essential
> to find
Chris Angelico :
> Programming is heavily about avoiding duplicated work.
That is one aspect, but overcondensing and overabstracting programming
logic usually makes code less obvious to its maintainer. It is essential
to find coding idioms that communicate ideas as clearly as possible. In
some
On Fri, 17 Aug 2018 15:19:05 +0200, Peter Otten wrote:
> You usually do not want many identical (or very similar) methods because
> invoking the right one is then errorprone, too, and you end up with an
> interface that is hard to maintain. At some point you may need to
> introduce subtle changes
On Fri, 17 Aug 2018 11:49:01 +, Jon Ribbens wrote:
> On 2018-08-17, Steven D'Aprano
> wrote:
>> On the other hand, your objection to the following three idioms is as
>> good an example of the Blurb Paradox as I've ever seen.
>
> Do you mean the Blub Paradox? If so, you're misunderstanding
Frank Millman wrote:
> I find that using a separate method per subclass does exactly what I want,
> and that part of my project has been working stably for some time.
I think that approach is fine. Do not let a tool have you bend over
backwards. Do not give in to pylint's nagging when you are
Chris Angelico wrote:
> On Fri, Aug 17, 2018 at 9:49 PM, Jon Ribbens
> wrote:
>>> "Code running directly under the class" describes every use of the class
>>> keyword (except those with an empty body). If you write:
>>>
>>> class Spam:
>>> x = 1
>>>
>>> you are running code under the
On Fri, Aug 17, 2018 at 9:49 PM, Jon Ribbens wrote:
>> "Code running directly under the class" describes every use of the class
>> keyword (except those with an empty body). If you write:
>>
>> class Spam:
>> x = 1
>>
>> you are running code under the class. This is not just a
On 2018-08-17, Steven D'Aprano wrote:
> On the other hand, your objection to the following three idioms is as
> good an example of the Blurb Paradox as I've ever seen.
Do you mean the Blub Paradox? If so, you're misunderstanding or at
least misapplying it.
>> * code running directly under
"Dan Sommers" wrote in message news:pl622a$a1f$1...@blaine.gmane.org...
On Fri, 17 Aug 2018 09:46:01 +0200, Frank Millman wrote:
> It is just a slight annoyance (to me) that pylint complains about the
> subclass methods when they are called from the Field class. I don't
> mind adding 10 stub
On Fri, 17 Aug 2018 09:46:01 +0200, Frank Millman wrote:
> It is just a slight annoyance (to me) that pylint complains about the
> subclass methods when they are called from the Field class. I don't
> mind adding 10 stub methods to the Field class to keep it happy, but I
> do not get the feeling
"Steven D'Aprano" wrote in message news:pl5qbk$r7k$5...@blaine.gmane.org...
On Fri, 17 Aug 2018 08:14:02 +0200, Frank Millman wrote:
> I find that using a separate method per subclass does exactly what I
> want, and that part of my project has been working stably for some time.
You might
On Fri, 17 Aug 2018 08:14:02 +0200, Frank Millman wrote:
> How would you extend it without a long chain of
> if isinstance(v, str):
> [perform checks for str]
> elif isinstance(v, int)
> [perform checks for int]
> etc
> etc
>
> I find that using a separate method per
On Wed, 15 Aug 2018 10:44:57 +, Jon Ribbens wrote:
> Obviously what I'm objecting to is not the presence of a loop, it's the
> presence of many obscure, bodgey and/or broken features all lumped
> together:
> * using @abstractmethod without metaclass=ABCMeta
I'll cop to that one -- it was
"D'Arcy Cain" wrote in message
news:6b4b8587-46c0-19b0-c538-efdf396f0...@vybenetworks.com...
On 2018-08-14 04:58 AM, Frank Millman wrote:
> As an example, I have a master class defining a unit of data (i.e. the
> value of a column) retrieved from a database. I have separate
> sub-classes for
On 2018-08-14 04:58 AM, Frank Millman wrote:
> "D'Arcy Cain" wrote in message
>> I am also getting a funny smell from your description. Are you sure
>> that you need to redefine the methods? Perhaps you just need to define
>> some class variables and use one method. You can also define your
On 2018-08-15, Steven D'Aprano wrote:
> On Tue, 14 Aug 2018 15:18:13 +, Jon Ribbens wrote:
>> On 2018-08-14, Steven D'Aprano
>> wrote:
>>> # === process abstract methods en masse ===
>>> for name in "method_a method_b method_c method_d".split():
>>> @abstractmethod
>>>
On Tue, 14 Aug 2018 15:18:13 +, Jon Ribbens wrote:
> On 2018-08-14, Steven D'Aprano
> wrote:
>> If there really are a lot of such missing methods, I'd consider writing
>> something like this:
>>
>> class A:
>> def __init__(self, ...):
>> ...
>>
>> # === process abstract
"Frank Millman" wrote in message news:pku0qd$ua5$1...@blaine.gmane.org...
Pylint is flagging a lot of lines as errors that I would consider to be
acceptable.
I have an abstract class ClassA with a number of concrete sub-classes.
ClassA has a method which invokes 'self.method_b()' which is
On 8/14/2018 5:05 AM, Thomas Jollans wrote:
On 2018-08-14 09:38, Frank Millman wrote:
Hi all
Pylint is flagging a lot of lines as errors that I would consider to be
acceptable.
I have an abstract class ClassA with a number of concrete sub-classes.
ClassA has a method which invokes
On 2018-08-14, Steven D'Aprano wrote:
> If there really are a lot of such missing methods, I'd consider writing
> something like this:
>
> class A:
> def __init__(self, ...):
> ...
>
> # === process abstract methods en masse ===
> for name in "method_a method_b method_c
On Tue, 14 Aug 2018 10:58:17 +0200, Frank Millman wrote:
>> > I have an abstract class ClassA with a number of concrete
>> > sub-classes. ClassA has a method which invokes 'self.method_b()'
>> > which is defined separately on each sub-class. Pylint complains that
>> > "Instance of 'ClassA' has no
"Thomas Jollans" wrote in message
news:53faf0ef-4054-53fa-6179-a862495ea...@tjol.eu...
On 2018-08-14 09:38, Frank Millman wrote:
> Hi all
>
> Pylint is flagging a lot of lines as errors that I would consider to be
> acceptable.
>
> I have an abstract class ClassA with a number of concrete
On 2018-08-14 09:38, Frank Millman wrote:
> Hi all
>
> Pylint is flagging a lot of lines as errors that I would consider to be
> acceptable.
>
> I have an abstract class ClassA with a number of concrete sub-classes.
> ClassA has a method which invokes 'self.method_b()' which is defined
>
"D'Arcy Cain" wrote in message
news:865ed61a-cf1d-959f-f77e-dc586fe6e...@vybenetworks.com...
On 2018-08-14 03:38 AM, Frank Millman wrote:
> Hi all
>
> Pylint is flagging a lot of lines as errors that I would consider to be
> acceptable.
>
> I have an abstract class ClassA with a number of
On 2018-08-14 03:38 AM, Frank Millman wrote:
> Hi all
>
> Pylint is flagging a lot of lines as errors that I would consider to be
> acceptable.
>
> I have an abstract class ClassA with a number of concrete sub-classes.
> ClassA has a method which invokes 'self.method_b()' which is defined
>
Hi all
Pylint is flagging a lot of lines as errors that I would consider to be
acceptable.
I have an abstract class ClassA with a number of concrete sub-classes.
ClassA has a method which invokes 'self.method_b()' which is defined
separately on each sub-class. Pylint complains that
63 matches
Mail list logo
