On Thu, Apr 18, 2019 at 6:16 PM Gregory Ewing
wrote:
>
> Arup Rakshit wrote:
> > What protocols I need to
> > learn, to define a custom immutable class ?
>
> That depends on how strictly you want to enforce immutability.
>
> The easiest thing is not to enforce it at all and simply refrain
> from m
Arup Rakshit wrote:
What protocols I need to
learn, to define a custom immutable class ?
That depends on how strictly you want to enforce immutability.
The easiest thing is not to enforce it at all and simply refrain
from mutating it. This is very often done.
You can provide some protection a
Hi All,
Thanks for explaining it so nice way. I got it now. What protocols I need to
learn, to define a custom immutable class ?
Thanks,
Arup Rakshit
a...@zeit.io
> On 16-Apr-2019, at 10:54 PM, Dennis Lee Bieber wrote:
>
> On Tue, 16 Apr 2019 13:13:18 +0530, Arup Rakshit declaimed the
>
On Tue, Apr 16, 2019 at 5:44 PM Arup Rakshit wrote:
>
> Hi,
>
> I am reading a sweet introduction about Python object from [3.1. Objects,
> values and
> types](https://docs.python.org/3/reference/datamodel.html#objects-values-and-types).
> And here the author is said about the Object values nic
On Fri, Nov 25, 2016, at 06:33, Ned Batchelder wrote:
> A Python implementation can choose when to reuse immutable objects and
> when not to. Reusing a value has a cost, because the values have to
> be kept, and then found again. So the cost is only paid when there's
> a reasonable chance that the
On Fri, 25 Nov 2016 10:37 pm, Ned Batchelder wrote:
> And: floats are rarely checked for equality, and very very very rarely
> used as dict keys, so there's no gain by short-circuiting the equality
> check.
You cannot short-circuit the equality check, at least not without giving up
IEEE-754 seman
On Friday, November 25, 2016 at 7:17:08 AM UTC-5, BartC wrote:
> On 25/11/2016 11:24, Nikunj wrote:
> >
> > Out of curiosity, I wanted to understand the reason behind having different
> > memory location for two identical floats . This is unlike ints or strings.
> > Tried googling but couldn't fi
On 25/11/2016 11:24, Nikunj wrote:
Out of curiosity, I wanted to understand the reason behind having different
memory location for two identical floats . This is unlike ints or strings.
Tried googling but couldn't find anything concrete. Any links or references
would be appreciated!
Do you
On Friday, November 25, 2016 at 6:34:00 AM UTC-5, Ned Batchelder wrote:
> On Friday, November 25, 2016 at 6:24:47 AM UTC-5, Nikunj wrote:
> > Hi All,
> >
> > Out of curiosity, I wanted to understand the reason behind having different
> > memory location for two identical floats . This is unlike i
On Friday, November 25, 2016 at 6:24:47 AM UTC-5, Nikunj wrote:
> Hi All,
>
> Out of curiosity, I wanted to understand the reason behind having different
> memory location for two identical floats . This is unlike ints or strings.
> Tried googling but couldn't find anything concrete. Any links o
Am 29.10.2012 16:20 schrieb andrea crotti:
Now on one hand I would love to use only immutable data in my code, but
on the other hand I wonder if it makes so much sense in Python.
You can have both. Many mutable types distinguish between them with
their operators.
To pick up your example,
On Oct 31, 1:45 am, Neal Becker wrote:
> rusi wrote:
> > On Oct 29, 8:20 pm, andrea crotti wrote:
> >
> >> Any comments about this? What do you prefer and why?
>
> > Im not sure how what the 'prefer' is about -- your specific num
> > wrapper or is it about the general question of choosing mutabl
rusi wrote:
> On Oct 29, 8:20 pm, andrea crotti wrote:
>
>> Any comments about this? What do you prefer and why?
>
> Im not sure how what the 'prefer' is about -- your specific num
> wrapper or is it about the general question of choosing mutable or
> immutable types?
>
> If the latter I would
On Oct 29, 8:20 pm, andrea crotti wrote:
> Any comments about this? What do you prefer and why?
Im not sure how what the 'prefer' is about -- your specific num
wrapper or is it about the general question of choosing mutable or
immutable types?
If the latter I would suggest you read
http://en.wi
On Mon, 29 Oct 2012 15:45:59 -0700, Chris Kaynor wrote:
> On Mon, Oct 29, 2012 at 3:30 PM, Steven D'Aprano
> wrote:
>> On Mon, 29 Oct 2012 17:05:07 +, andrea crotti wrote:
>>
>>> I meant how do I create new immutables classes myself, I guess that's
>>> possible writing C extensions but I don'
On Mon, 29 Oct 2012 15:20:02 +, andrea crotti wrote:
> I have a philosofical doubt about immutability, that arised while doing
> the SCALA functional programming course.
"Philosophical". Like most words derived from the ancient Greeks, the "F"
sound uses "ph" rather than "f".
> Now suppose
On Mon, Oct 29, 2012 at 3:30 PM, Steven D'Aprano
wrote:
> On Mon, 29 Oct 2012 17:05:07 +, andrea crotti wrote:
>
>> I meant how do I create new immutables classes myself, I guess that's
>> possible writing C extensions but I don't see in pure Python..
>
> Well, you can't *quite* make a truly i
On Tue, 30 Oct 2012 06:36:52 +1100, Chris Angelico wrote:
> On Tue, Oct 30, 2012 at 6:23 AM, Ian Kelly
> wrote:
>> _MyImmutableClass = namedtuple('MyImmutableClass', 'field1 field2
>> field3 field4')
>>
>> class MyImmutableClass(_MyImmutableClass):
>
> Question: Is it clearer to take advantage o
On Mon, 29 Oct 2012 17:05:07 +, andrea crotti wrote:
> I meant how do I create new immutables classes myself, I guess that's
> possible writing C extensions but I don't see in pure Python..
Well, you can't *quite* make a truly immutable class in pure-Python,
because if *your* Python code can
On Mon, Oct 29, 2012 at 1:36 PM, Chris Angelico wrote:
> Question: Is it clearer to take advantage of the fact that the base
> class can be an arbitrary expression?
>
> class MyImmutableClass(namedtuple('MyImmutableClass', 'field1 field2
> field3 field4')):
>
> You lose the unnecessary temporary a
On Tue, Oct 30, 2012 at 6:23 AM, Ian Kelly wrote:
> _MyImmutableClass = namedtuple('MyImmutableClass', 'field1 field2
> field3 field4')
>
> class MyImmutableClass(_MyImmutableClass):
Question: Is it clearer to take advantage of the fact that the base
class can be an arbitrary expression?
class M
On Mon, Oct 29, 2012 at 10:12 AM, andrea crotti
wrote:
> Also because how doi I make an immutable object in pure Python?
I sometimes use namedtuples for this.
from collections import namedtuple
MyImmutableClass = namedtuple('MyImmutableClass', 'field1 field2 field3 field4')
If you want default
On Mon, Oct 29, 2012 at 12:46 PM, Paul Rubin wrote:
> andrea crotti writes:
>> Also because how doi I make an immutable object in pure Python?
>
> Numbers in Python are already immutable. What you're really looking for
> is a programming style where you don't bind any variable more than once.
N
On 10/29/2012 1:05 PM, andrea crotti wrote:
I meant how do I create new immutables classes myself, I guess that's
possible writing C extensions but I don't see in pure Python..
If you mean class with immutable instances, mutate new instances in
__new__ instead of __init__ and write a custom .
On 10/29/2012 12:05 PM, andrea crotti wrote:
> I meant how do I create new immutables classes myself, I guess that's
> possible writing C extensions but I don't see in pure Python..
The short answer is: you don't, not really, except by using NamedTuple
if that gives you what you want.
The longer
On 10/29/2012 11:20 AM, andrea crotti wrote:
I have a philosofical doubt about immutability, that arised while doing
the SCALA functional programming course.
In real life, the physical world, things have mutable state, at least
down to the atomic level. Do you only want to model mathematical w
andrea crotti writes:
> Also because how doi I make an immutable object in pure Python?
Numbers in Python are already immutable. What you're really looking for
is a programming style where you don't bind any variable more than once.
This gives rise to a programming style that Python can support
2012/10/29 Chris Angelico :
> On Tue, Oct 30, 2012 at 2:55 AM, Paul Rubin wrote:
>> andrea crotti writes:
>>> and we want to change its state incrementing the number ...
>>> the immutability purists would instead suggest to do this:
>>> def increment(self):
>>> return NumWrapper(self
2012/10/29 Jean-Michel Pichavant :
>
>
> In an OOP language num.increment() is expected to modify the object in place.
> So I think you're right when you say that functional languages technics do
> not necessarily apply to Python, because they don't.
>
> I would add that what you're trying to sugg
On Tue, Oct 30, 2012 at 2:55 AM, Paul Rubin wrote:
> andrea crotti writes:
>> and we want to change its state incrementing the number ...
>> the immutability purists would instead suggest to do this:
>> def increment(self):
>> return NumWrapper(self.number + 1)
>
> Immutability puris
- Original Message -
> 2012/10/29 Jean-Michel Pichavant :
> >
> > "return NumWrapper(self.number + 1) "
> >
> > still returns a(nother) mutable object.
> >
> > So what's the point of all this ?
> >
> > JM
> >
>
> Well sure but it doesn't modify the first object, just creates a new
> one.
andrea crotti writes:
> and we want to change its state incrementing the number ...
> the immutability purists would instead suggest to do this:
> def increment(self):
> return NumWrapper(self.number + 1)
Immutability purists would say that numbers don't have "state" and if
you're tr
On 29/10/2012 15:20, andrea crotti wrote:
I have a philosofical doubt about immutability, that arised while doing
the SCALA functional programming course.
Now suppose I have a simple NumWrapper class, that very stupidly does:
class NumWrapper(object):
def __init__(self, number):
s
2012/10/29 andrea crotti :
>>
>
> Well sure but it doesn't modify the first object, just creates a new
> one. There are in general good reasons to do that, for example I can
> then compose things nicely:
>
> num.increment().increment()
>
> or I can parallelize operations safely not caring about th
2012/10/29 Jean-Michel Pichavant :
>
> "return NumWrapper(self.number + 1) "
>
> still returns a(nother) mutable object.
>
> So what's the point of all this ?
>
> JM
>
Well sure but it doesn't modify the first object, just creates a new
one. There are in general good reasons to do that, for examp
- Original Message -
> I have a philosofical doubt about immutability, that arised while
> doing
> the SCALA functional programming course.
>
> Now suppose I have a simple NumWrapper class, that very stupidly
> does:
>
> class NumWrapper(object):
> def __init__(self, number):
>
That is why I don't like the use of @property. Even though the
decorator is a nice short-hand notation, it is more confusing in my
oppinion. So someone is more likely still call the property as a
function when looking at:
class C:
@property
def data(self):
return 42
rather than if
Georg Brandl wrote:
> Steve Holden wrote:
>> Georg Brandl wrote:
>>> Steve Holden wrote:
>> [...]
>>>
Would it make sense, in the single argument case, to default the doc
value to fget.__doc__ to support that use case, or should we just not
create read-only properties by using proper
Nick Maclaren wrote:
> In article <[EMAIL PROTECTED]>,
> Robert Kern <[EMAIL PROTECTED]> writes:
> |> Nick Maclaren wrote:
> |> > The way that I read it, Python allows only values (and hence types)
> |> > to be immutable, and not class members. The nearest approach to the
> |> > latter is to use
Steve Holden wrote:
> Georg Brandl wrote:
>> Steve Holden wrote:
> [...]
>>
>>>Would it make sense, in the single argument case, to default the doc
>>>value to fget.__doc__ to support that use case, or should we just not
>>>create read-only properties by using property as a decorator?
>>
>>
>>
Georg Brandl wrote:
> Steve Holden wrote:
[...]
>
>>Would it make sense, in the single argument case, to default the doc
>>value to fget.__doc__ to support that use case, or should we just not
>>create read-only properties by using property as a decorator?
>
>
> This is actually already the ca
Steve Holden wrote:
> Georg Brandl wrote:
>> Nick Maclaren wrote:
>>
>>>In article <[EMAIL PROTECTED]>,
>>>"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>>|>
>>>|> identical? you only applied @property to one of the methods, and then
>>>you're
>>>|> surprised that only one of the methods were tu
Georg Brandl wrote:
> Nick Maclaren wrote:
>
>>In article <[EMAIL PROTECTED]>,
>>"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>|>
>>|> identical? you only applied @property to one of the methods, and then
>>you're
>>|> surprised that only one of the methods were turned into a property?
>>
>>I w
Bruno Desthuilliers a écrit :
> Georg Brandl a écrit :
(snip)
>>
>> That's another sign that property isn't intended to be used as a
>> decorator.
>> Normally, decorators wrap functions with other functions.
>
>
> Normally, decorators take a function and return anything appropriate.
>
>> proper
Georg Brandl a écrit :
> Steve Holden wrote:
>
>
Thanks very much. And, what's more, I have even found its documentation!
Whatsnew2.2. The 2.4.2 reference is, er, unhelpful.
>>>
>>>
>>>Is it?
>>>
>>>http://docs.python.org/lib/built-in-funcs.html
>>>
>>>documents "property" quite well.
>
Georg Brandl a écrit :
> Nick Maclaren wrote:
>
>>In article <[EMAIL PROTECTED]>,
>>"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>|>
>>|> identical? you only applied @property to one of the methods, and then
>>you're
>>|> surprised that only one of the methods were turned into a property?
>>
>>
Nick Maclaren wrote:
> In article <[EMAIL PROTECTED]>,
> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> |>
> |> identical? you only applied @property to one of the methods, and then
> you're
> |> surprised that only one of the methods were turned into a property?
>
> I wasn't expecting EITHER to
Duncan Booth wrote:
> Georg Brandl wrote:
>
>> In my opinion property isn't really meant to be used as a decorator since
>> it's impossible to create a read-write property. The decorator pattern
>> doesn't really fit here.
>>
> I agree that property isn't currently intended to be used as a decora
Georg Brandl wrote:
> In my opinion property isn't really meant to be used as a decorator since
> it's impossible to create a read-write property. The decorator pattern
> doesn't really fit here.
>
I agree that property isn't currently intended to be used as a decorator,
but it isn't actually *i
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> writes:
|>
|> well, I completely fail to see how the following is compatible with the
|> interpretation "attaches a non-default property, but doesn't do anything
|> else":
Because I was using a decorator and defining an attribut
Nick Maclaren wrote:
> I wasn't expecting EITHER to be turned INTO a property - I was expecting
> both methods to be the same, but one would have non-default properties
> attached to it.
> |> that's what the documentation
> |> says, and that's what your code is doing.
>
> Er, no, it doesn't. Wh
Fredrik Lundh wrote:
> Bruno Desthuilliers wrote:
>
>
>>>class fred :
>>>@property
>>>def joe (self) :
>>>print "Inside /joe\n"
>>
>>
>>properties dont work properly on old-style classes (lookup 'new-style
>>classes' on python.org, in the documentation menu), hence the strange
>>b
Nick Maclaren schreef:
>
> Most especially since it isn't working very well for me, and I am trying
> to track down why. When I run:
> class fred :
> @property
> def joe (self) :
> print "Inside /joe\n"
>
> a = fred()
> a.joe()
>
> I get:
>
> Inside joe
>
> Traceback (most rec
In article <[EMAIL PROTECTED]>,
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
|>
|> identical? you only applied @property to one of the methods, and then you're
|> surprised that only one of the methods were turned into a property?
I wasn't expecting EITHER to be turned INTO a property - I was ex
Bruno Desthuilliers wrote:
>> class fred :
>> @property
>> def joe (self) :
>> print "Inside /joe\n"
>
>
> properties dont work properly on old-style classes (lookup 'new-style
> classes' on python.org, in the documentation menu), hence the strange
> behaviour you observe.
propert
Nick Maclaren wrote:
> |> a property looks like an attribute, not a method, so you're trying to call
> whatever
> |> your "joe()" method returns.
>
> Well, yes, that was pretty obvious - but what was NOT obvious is why it
> should do that for one of two identical methods.
identical? you only ap
Nick Maclaren wrote:
> In article <[EMAIL PROTECTED]>,
> Sion Arrowsmith <[EMAIL PROTECTED]> writes:
> |>
> |> Actually, there's an almost throw-away mention in
> |> http://docs.python.org/ref/descriptor-invocation.html
> |> which gives you what you need (although not, I have to say, in an
> |> ea
In article <[EMAIL PROTECTED]>,
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
|>
|> a property looks like an attribute, not a method, so you're trying to call
whatever
|> your "joe()" method returns.
Well, yes, that was pretty obvious - but what was NOT obvious is why it
should do that for one of
Nick Maclaren wrote:
> class fred :
>@property
>def joe (self) :
>print "Inside /joe\n"
>
> a = fred()
> a.joe()
>
> Traceback (most recent call last):
> File "crap.py", line 14, in
>a.joe()
> TypeError: 'NoneType' object is not callable
>
> VERY weird - I could understand it
In article <[EMAIL PROTECTED]>,
Sion Arrowsmith <[EMAIL PROTECTED]> writes:
|>
|> Actually, there's an almost throw-away mention in
|> http://docs.python.org/ref/descriptor-invocation.html
|> which gives you what you need (although not, I have to say, in an
|> easily digestible form).
Thanks ver
In article <[EMAIL PROTECTED]>,
"Gerard Flanagan" <[EMAIL PROTECTED]> writes:
|>
|> There are (unofficial) documentation wikis here:
|>
|> pytut.infogami.com
|> pyref.infogami.com
|> pyfaq.infogami.com
Thanks very much.
|> You might like to consider adding the information you perce
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>Sion Arrowsmith wrote:
>> What I've not seen documented anywhere is the:
>>@property
>>def fset(self, value):
>>...
>> idiom. It's not obvious from the documentation of the property
>> function that it can be used as a decorator
Steve Holden wrote:
>>>Thanks very much. And, what's more, I have even found its documentation!
>>>Whatsnew2.2. The 2.4.2 reference is, er, unhelpful.
>>
>>
>> Is it?
>>
>> http://docs.python.org/lib/built-in-funcs.html
>>
>> documents "property" quite well.
>>
> I can't really agree that "
Sion Arrowsmith wrote:
> What I've not seen documented anywhere is the:
>@property
>def fset(self, value):
>...
> idiom. It's not obvious from the documentation of the property
> function that it can be used as a decorator like this.
probably because it cannot be used
Nick Maclaren wrote:
> In article <[EMAIL PROTECTED]>,
> Georg Brandl <[EMAIL PROTECTED]> writes:
> |> >
> |> > Thanks very much. And, what's more, I have even found its documentation!
> |> > Whatsnew2.2. The 2.4.2 reference is, er, unhelpful.
> |>
> |> Is it?
> |>
> |> http://docs.python.org/li
Georg Brandl wrote:
> Nick Maclaren wrote:
>
>>In article <[EMAIL PROTECTED]>,
>>Robert Kern <[EMAIL PROTECTED]> writes:
>>|> Nick Maclaren wrote:
>>|> > The way that I read it, Python allows only values (and hence types)
>>|> > to be immutable, and not class members. The nearest approach to the
Nick Maclaren <[EMAIL PROTECTED]> wrote:
>Georg Brandl <[EMAIL PROTECTED]> writes:
>|> [ attributions lost ]
>|> > Thanks very much. And, what's more, I have even found its documentation!
>|> > Whatsnew2.2. The 2.4.2 reference is, er, unhelpful.
>|> Is it?
>|> http://docs.python.org/lib/built-in-
Nick Maclaren wrote:
> The way that I read it, Python allows only values (and hence types)
> to be immutable,
I don't understand this sentence. Some types are immutable, some are
not. This has nothing to do with "values" (FWIW, everything in Python is
an object, there's no 'primitive type' vs 'obj
> Sigh. No. It's terrible. What it documents is the use of the property
> FUNCTION. It does not document what properties ARE, and how they interact
> with the rest of the language. Until you know that, it is so ambiguous
> as to be almost totally useless - and it is THAT information that needs
In article <[EMAIL PROTECTED]>,
Georg Brandl <[EMAIL PROTECTED]> writes:
|> >
|> > Thanks very much. And, what's more, I have even found its documentation!
|> > Whatsnew2.2. The 2.4.2 reference is, er, unhelpful.
|>
|> Is it?
|>
|> http://docs.python.org/lib/built-in-funcs.html
|>
|> documen
Nick Maclaren wrote:
> In article <[EMAIL PROTECTED]>,
> Robert Kern <[EMAIL PROTECTED]> writes:
> |> Nick Maclaren wrote:
> |> > The way that I read it, Python allows only values (and hence types)
> |> > to be immutable, and not class members. The nearest approach to the
> |> > latter is to use t
In article <[EMAIL PROTECTED]>,
Robert Kern <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> > The way that I read it, Python allows only values (and hence types)
|> > to be immutable, and not class members. The nearest approach to the
|> > latter is to use the name hiding conventions.
|> >
Nick Maclaren wrote:
> The way that I read it, Python allows only values (and hence types)
> to be immutable, and not class members. The nearest approach to the
> latter is to use the name hiding conventions.
>
> Is that correct?
You can also make properties that don't allow writing.
class Foo(
73 matches
Mail list logo
