How can I create customized classes that have similar properties as'str'?

[Licheng Fang]

I mean, all the class instances that equal to each other should be
reduced into only one instance, which means for instances of this
class there's no difference between a is b and a==b.

Thank you.

[Licheng Fang]

I find myself frequently in need of classes like this for two reasons.
First, it's efficient in memory. Second, when two instances are
compared for equality only their pointers are compared. (I think
that's how Python compares 'str's.

On Nov 24, 6:31 pm, Licheng Fang <fanglich...@gm ail.comwrote:

I mean, all the class instances that equal to each other should be
reduced into only one instance, which means for instances of this
class there's no difference between a is b and a==b.

Thank you.

[Bjoern Schliessmann]

Licheng Fang wrote:

I mean, all the class instances that equal to each other should be
reduced into only one instance, which means for instances of this
class there's no difference between a is b and a==b.

If you only want that if "a == b" is True also "a is b" is True,
overload the is_ attribute of your class. Personally, I don't see
any advantage in this.

Regards,
Björn

--
BOFH excuse #352:

The cables are not the same length.

[Bjoern Schliessmann]

Licheng Fang wrote:

I find myself frequently in need of classes like this for two
reasons. First, it's efficient in memory.

Are you using millions of objects, or MB size objects? Otherwise,
this is no argument.

BTW, what happens if you, by some operation, make a == b, and
afterwards change b so another object instance must be created?
This instance management is quite a runtime overhead.

Second, when two instances are compared for equality only their
pointers are compared.

I state that the object management will often eat more performance
than equality testing. Except you have a huge number of equal
objects. If the latter was the case you should rethink your program
design.

(I think that's how Python compares 'str's.

Generally not. In CPython, just very short strings are created only
once.

>>a=" "
b=" "
a is b

True

>>a=" "
b=" "
a is b

False

Regards,
Björn

--
BOFH excuse #430:

Mouse has out-of-cheese-error

[Licheng Fang]

On Nov 24, 7:05 pm, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n.. .@spamgourmet.c omwrote:

Licheng Fang wrote:

I find myself frequently in need of classes like this for two
reasons. First, it's efficient in memory.

Are you using millions of objects, or MB size objects? Otherwise,
this is no argument.

Yes, millions. In my natural language processing tasks, I almost
always need to define patterns, identify their occurrences in a huge
data, and count them. Say, I have a big text file, consisting of
millions of words, and I want to count the frequency of trigrams:

trigrams([1,2,3,4,5]) == [(1,2,3),(2,3,4) ,(3,4,5)]

I can save the counts in a dict D1. Later, I may want to recount the
trigrams, with some minor modifications, say, doing it on every other
line of the input file, and the counts are saved in dict D2. Problem
is, D1 and D2 have almost the same set of keys (trigrams of the text),
yet the keys in D2 are new instances, even though these keys probably
have already been inserted into D1. So I end up with unnecessary
duplicates of keys. And this can be a great waste of memory with huge
input data.

>
BTW, what happens if you, by some operation, make a == b, and
afterwards change b so another object instance must be created?
This instance management is quite a runtime overhead.

I probably need this class to be immutable.

Second, when two instances are compared for equality only their
pointers are compared.

I state that the object management will often eat more performance
than equality testing. Except you have a huge number of equal
objects. If the latter was the case you should rethink your program
design.

Yeah, counting is all about equal or not.

(I think that's how Python compares 'str's.

Generally not. In CPython, just very short strings are created only
once.

>a=" "
b=" "
a is b

True

>a=" "
b=" "
a is b

Wow, I didn't know this. But exactly how Python manage these strings?
My interpretator gave me such results:

>>a = 'this'
b = 'this'
a is b

True

>>a = 'this is confusing'
b = 'this is confusing'
a is b

False

False

Regards,

Björn

--
BOFH excuse #430:

Mouse has out-of-cheese-error

[Bjoern Schliessmann]

Licheng Fang wrote:

On Nov 24, 7:05 pm, Bjoern Schliessmann <usenet-

>BTW, what happens if you, by some operation, make a == b, and
afterwards change b so another object instance must be created?
This instance management is quite a runtime overhead.

I probably need this class to be immutable.

IMHO you don't need a change of Python, but simply a special
implementation (probably using metaclasses/singletons).

Wow, I didn't know this. But exactly how Python manage these
strings?

I don't know (use the source, Luke). :) Or perhaps there is a Python
Elder here that knows?

Regards,
Björn

--
BOFH excuse #165:

Backbone Scoliosis

[samwyse]

On Nov 24, 5:44 am, Licheng Fang <fanglich...@gm ail.comwrote:

Yes, millions. In my natural language processing tasks, I almost
always need to define patterns, identify their occurrences in a huge
data, and count them. [...] So I end up with unnecessary
duplicates of keys. And this can be a great waste of memory with huge
input data.

create a hash that maps your keys to themselves, then use the values
of that hash as your keys.

>>store = {}
def atom(str):

global store
if str not in store:
store[str] = str
return store[str]

>>a='this is confusing'
b='this is confusing'
a == b

True

>>a is b

False

>>atom(a) is atom(b)

True

[Marc 'BlackJack' Rintsch]

On Sat, 24 Nov 2007 13:40:40 +0100, Bjoern Schliessmann wrote:

Licheng Fang wrote:

>On Nov 24, 7:05 pm, Bjoern Schliessmann <usenet-

>Wow, I didn't know this. But exactly how Python manage these
strings?

I don't know (use the source, Luke). :) Or perhaps there is a Python
Elder here that knows?

AFAIK strings of length 1 and strings that would be valid Python
identifiers are treated this way.

Ciao,
Marc 'BlackJack' Rintsch

[Licheng Fang]

On Nov 24, 9:42 pm, Marc 'BlackJack' Rintsch <[e-mail] wrote:

On Sat, 24 Nov 2007 13:40:40 +0100, Bjoern Schliessmann wrote:

Licheng Fang wrote:

On Nov 24, 7:05 pm, Bjoern Schliessmann <usenet-

Wow, I didn't know this. But exactly how Python manage these
strings?

I don't know (use the source, Luke). :) Or perhaps there is a Python
Elder here that knows?

AFAIK strings of length 1 and strings that would be valid Python
identifiers are treated this way.

Ciao,
Marc 'BlackJack' Rintsch

Thanks. Then, is there a way to make python treat all strings this
way, or any other kind of immutable objects?

[Bruno Desthuilliers]

Licheng Fang a écrit :

I mean, all the class instances that equal to each other should be
reduced into only one instance, which means for instances of this
class there's no difference between a is b and a==b.

Here's a Q&D attempt - without any garantee, and to be taylored to your
needs.

_values = {} #id(instance) =value mapping
_instances = {} #hash(value) =instance mapping

class Value(object):
def __new__(cls, value):
try:
return _instances[hash(value)]
except KeyError:
instance = object.__new__( cls)
_values[id(instance)] = value
_instances[hash(value)] = instance
return instance

@apply
def value():
def fget(self):
return _values[id(self)]
def fset(self, ignore):
raise AttributeError( "%s.value is read only" % type(self))
def fdel(self):
raise AttributeError( "%s.value is read only" % type(self))
return property(**loca ls())
HTH