I thought about something -
>
> I think that the performance penalty may be rather small - remember
> that in programs which do not change strings, there would never be a
> need to copy the string data at all. And since I think that usually
> most of the dict lookups are for method or function name
On 10/31/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...
> And I'm going to point out why you are wrong.
I still don't think so. I think that I need to reclarify what I mean.
> > About the users-changing-my-internal-data issue:
...
> You can have a printout before it dies:
> "I'm crashing your
Noam Raphael <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have slept quite well, and talked about it with a few people, and I
> still think I'm right.
And I'm going to point out why you are wrong.
> About the users-changing-my-internal-data issue:
>
> > Again, user semantics. Tell your users not
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> [...]
> >>Perhaps I didn't make it clear. The difference between wxPython's Grid
> >>and my table is that in the table, most values are *computed*. This
> >>means that there's no point in changing the values themselves. They
> >>
Hello,
I have slept quite well, and talked about it with a few people, and I
still think I'm right.
About the users-changing-my-internal-data issue:
> Again, user semantics. Tell your users not to modify entries, and/or
> you can make copies of objects you return. If your users are too daft
>
On 10/31/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > It allows everything in Python to be both mutable and hashable,
>
> I don't understand, since it's already the case. Any user-defined object
> is at the same time mutable and hashable.
By default, user-defined objects are equal iff they
Josiah Carlson wrote:
[...]
>>Perhaps I didn't make it clear. The difference between wxPython's Grid
>>and my table is that in the table, most values are *computed*. This
>>means that there's no point in changing the values themselves. They
>>are also used frequently as set members (I can describe
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> It seems that we both agree that freezing is cool (-; . We disagree on
> whether a copy-on-write behaviour is desired. Your arguments agains
> copy-on-write are:
> 1. It's not needed.
> 2. It's complicated to implement.
>
> But first of all
> It allows everything in Python to be both mutable and hashable,
I don't understand, since it's already the case. Any user-defined object
is at the same time mutable and hashable.
And if you want the hash value to follow the changes in attribute
values, just define an appropriate __hash__ method
Hello,
It seems that we both agree that freezing is cool (-; . We disagree on
whether a copy-on-write behaviour is desired. Your arguments agains
copy-on-write are:
1. It's not needed.
2. It's complicated to implement.
But first of all, you didn't like my use cases. I want to argue with that.
>
Noam Raphael <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I have thought about freezing for some time, and I think that it is a
> fundamental need - the need to know, sometimes, that objects aren't
> going to change.
I agree with this point.
> This is mostly the need of containers. dicts need to
Hello,
I have thought about freezing for some time, and I think that it is a
fundamental need - the need to know, sometimes, that objects aren't
going to change.
This is mostly the need of containers. dicts need to know that the
objects that are used as keys aren't going to change, because if the
Paolino wrote:
> Is __hash__=id inside a class enough to use a set (sets.Set before 2.5)
> derived class instance as a key to a mapping?
It is __hash__=lambda self:id(self) that is terribly slow ,it needs a
faster way to state that to let them be useful as key to mapping as all
set operations w
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> I think having dicts and sets automatically invoke freeze would be a
> >> mistake,
> >> because at least one of the following two cases would behave unexpectedly:
> >
> > I'm pret
Josiah Carlson wrote:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I think having dicts and sets automatically invoke freeze would be a
>> mistake,
>> because at least one of the following two cases would behave unexpectedly:
>
> I'm pretty sure that the PEP was only aslomg if one would freeze t
[Barry Warsaw]
> I've had this PEP laying around for quite a few months. It was
inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects.
* FWIW, the _as_immutable() protocol was dropped from sets.py for a
reason. User reports indicated that
On Oct 23, 2005, at 6:43 PM, Barry Warsaw wrote:
> I've had this PEP laying around for quite a few months. It was
> inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP,
> uploaded
> a sample patch (albe
I'm not sure I understood completely the idea but deriving freeze
function from hash gives hash a wider importance.
Is __hash__=id inside a class enough to use a set (sets.Set before 2.5)
derived class instance as a key to a mapping?
Sure I missed the point.
Regards Paolino
___
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I think having dicts and sets automatically invoke freeze would be a mistake,
> because at least one of the following two cases would behave unexpectedly:
I'm pretty sure that the PEP was only aslomg if one would freeze the
contents of dicts IF the dict
Christopher Armstrong <[EMAIL PROTECTED]> wrote:
>
> On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Should dicts and sets automatically freeze their mutable keys?"
> >
> > Dictionaries don't have mutable keys,
>
> Since when?
>
> Maybe you meant something else? I can't think of any
On 10/24/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Should dicts and sets automatically freeze their mutable keys?"
>
> Dictionaries don't have mutable keys,
Since when?
class Foo:
def __init__(self):
self.x = 1
f = Foo()
d = {f: 1}
f.x = 2
Maybe you meant something else? I ca
Barry Warsaw wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplete), and I'm posting i
Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a bit incomplet
On 10/23/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I've had this PEP laying around for quite a few months. It was inspired
> by some code we'd written which wanted to be able to get immutable
> versions of arbitrary objects. I've finally finished the PEP, uploaded
> a sample patch (albeit a b
24 matches
Mail list logo
