A Universe Set

J

jordan.nick

Has the addition of a Universe Set object ever been suggested. Like U
= set(0), so that any object was a member of U? Maybe this gets into
some crazy Cantorian stuff since U is in U. But it seems like it would
be useful and would have a nice symmetry with emptyset:set([]), that
is:

for any object a:
"a in set([])" returns False
"a in set(0)" returns True
 
R

Robert Kern

Has the addition of a Universe Set object ever been suggested. Like U
= set(0), so that any object was a member of U?

In [61]: class UniverseSet(object):
....: def __contains__(self, x):
....: return True
....:

In [62]: U = UniverseSet()

In [63]: 1 in U
Out[63]: True

In [64]: 2 in U
Out[64]: True

In [65]: 'something' in U
Out[65]: True

In [66]: U in U
Out[66]: True


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
 
S

Steve Holden

Has the addition of a Universe Set object ever been suggested. Like U
= set(0), so that any object was a member of U? Maybe this gets into
some crazy Cantorian stuff since U is in U. But it seems like it would
be useful and would have a nice symmetry with emptyset:set([]), that
is:

for any object a:
"a in set([])" returns False
"a in set(0)" returns True
... def __contains__(self, thing):
... return True
...
Of course the last eexample shows that your implementation may need to
change depending on how you view Russell's paradox ...

regards
Steve
 
J

Jorgen Grahn

Has the addition of a Universe Set object ever been suggested. Like U
= set(0), so that any object was a member of U?

In [61]: class UniverseSet(object):
....: def __contains__(self, x):
....: return True
....:

Yes. But note that being able to write it yourself is one thing, having it
in the Standard Library and known to anyone is another.

I have been craving for some similar things for a while, and I'm still not
sure if they are good ideas, or brain damage caused by studying functional
programming at Uni. For example:

- the wildcard object, which compares equal to everything else
- infinite xrange()s
- the black hole function 'def f(*args): pass'
- the identity function 'def f(x): return x'

/Jorgen
 
M

MonkeeSage

Jorgen said:
- infinite xrange()s

Fun. How about in-memory objects which use no memory, and
self-referential anonymous functions, and object states without
objects...

Regards,
Jordan
 
I

Istvan Albert

Jorgen said:
I have been craving for some similar things for a while, and I'm still not
sure if they are good ideas, or brain damage caused by studying functional
programming at Uni.

This is a self correcting situation, as ayone who understands why they
need this can surely write them using itertools and some simple
classes.

No Child Left Behind.
 
W

Wildemar Wildenburger

Jorgen said:
- the wildcard object, which compares equal to everything else
- infinite xrange()s
- the black hole function 'def f(*args): pass'
- the identity function 'def f(x): return x'

Any use cases for these?
 
D

Duncan Booth

Wildemar Wildenburger said:
Any use cases for these?

I guess the first one could be useful if you want to compare two data
structures but prune part of the structure in the comparison (e.g. in a
unit test assertion). So not forgetting that this only works when the
wildcard is on the left of the comparison:
def __eq__(self, other):
return True

dontcare = DontCareClass()
[1, dontcare, 3]==[1, 2, 3] True
[1, dontcare, 3]==[1, 4, 3] True
[1, dontcare, 3]==[1, 4, 2]
False

I think for more general use though it's a non-starter. If Python had it
builtin it should compare equal in *all* situations and what on earth
should aDict[dontcare] do?

I can think of one use for a black hole function, but it is very specific.
It would be kind of nice to have a variation on 'super' which traps
AttributeError and returns the black hole instead, or perhaps just an
optional third argument for a default to return (c.f. dict.get). So you
could write:

class C(object):
def method(self, arg):
super(C, self, blackhole).method(arg)
... whatever ...

and method would call any base class definition of method but not care if
there isn't one. The alternative to this is either to catch and ignore the
exception (which is a pain), or better to create a dummy base class which
implements the interface but doesn't propagate the calls.

I suppose the same argument could be made for any pattern of calling the
result of getattr when the attribute might not exist. Replace:

m = getattr(obj, key, None)
if m is not None:
m(something)
or:

if hasattr(obj, 'somekey'):
obj.somekey(whatever)

with:

getattr(obj, key, blackhole)(something)

The catch here is that the current pattern often has an 'else' clause as
well and you can't replace those ones with blackhole.
 
J

Jorgen Grahn

itertools.count()?

Oops! You're right. The itertools documentation even refers to the SML and
Haskell languages. And it contains itertools.izip(), another thing on my
wish list.

I have reasons to be Python 2.2 compatible, so I haven't really looked
through the nice things in 2.3 and up (generators are in __future__ in 2.2).
Stupid of me to overlook itertools, which I've read about here many times.

/Jorgen
 
J

Jorgen Grahn

Jorgen Grahn wrote:
Any use cases for these?

Like someone else wrote, for quick-and-dirty comparisons or lists and
dictionaries where I don't care about one part. I think I wanted it for
unittest's assertEqual(foo, bar) at one point.

self.assertEqual(['foo', 42, [], WILDCARD], my_result)

versus

self.assertEqual('foo', my_result[0])
self.assertEqual(42, my_result[1])
self.assertEqual([], my_result[2])
self.assertEqual(4, len(my_result))
# possibly assert that 'my_result' is a list-like
# object too

But I agree that the WILDCARD isn't the kind of object you want to spread
throughout your code; its behaviour is too odd.

Available in itertools, as someone pointed out.

I often find myself adding logging to functions by passing sys.stderr.write
as an argument to it. Passing blackhole is an elegant and fast way of
disabling logging.

I don't think I've used it. Maybe if you do a lot of manipulation of
functions and functors -- in some sense it's to function application what 0
is to addition, or 1 to multiplication.

/Jorgen
 
P

Paul McGuire

- the wildcard object, which compares equal to everything else

class MatchAny(object):
def __cmp__(self,other):
return 0

wild = MatchAny()

print wild == 1000
print 1000 == wild
print wild == (1,2,3)
print wild == 'abck'
print wild == wild

print wild != 1000
print 1000 != wild
print wild != (1,2,3)
print wild != 'abck'
print wild != wild


Prints:
True
True
True
True
True
False
False
False
False
False
 
P

Paul McGuire

Jorgen Grahn said:
Yes. But note that being able to write it yourself is one thing, having it
in the Standard Library and known to anyone is another.

Perhaps you could compile the submissions in this thread into an entry in
the Python Cookbook. Probably the next best thing to being in the stdlib,
and it might even make it into the next print edition (earning you a free
copy!).

-- Paul
 
S

skip

Paul> class MatchAny(object):
Paul> def __cmp__(self,other):
Paul> return 0

Paul> wild = MatchAny()

...

You're at the mercy of the comparison machinery implemented by individual
classes. Executing this script (using any of Python 2.3 through what's
currently in the SVN repository):

import datetime

class MatchAny(object):
def __cmp__(self,other):
return 0

wild = MatchAny()

print wild == datetime.datetime.now()
print datetime.datetime.now() == wild
print wild != datetime.datetime.now()
print datetime.datetime.now() != wild

yields

False
False
True
True

Skip
 
S

Simon Brunning

You're at the mercy of the comparison machinery implemented by individual
classes.

Plus, if you put a wildcard object into a set (or use it as a
dictionary key) you'll confuse yourself horribly.

I know I did. ;-)
 
J

Jorgen Grahn

[me]
[Paul]
Paul> class MatchAny(object):
Paul> def __cmp__(self,other):
Paul> return 0

Paul> wild = MatchAny()

FWIW, I define __eq__ in the one I (infrequently) use.
...

You're at the mercy of the comparison machinery implemented by individual
classes. Executing this script (using any of Python 2.3 through what's
currently in the SVN repository):
....

Oh. /Is/ there a way of making it work, then? If we ignore the problems
with having such objects in the first place, that is.

/Jorgen
 
D

Duncan Booth

Jorgen Grahn said:
- the wildcard object, which compares equal to everything else
[Paul]
Paul> class MatchAny(object):
Paul> def __cmp__(self,other):
Paul> return 0

Paul> wild = MatchAny()

FWIW, I define __eq__ in the one I (infrequently) use.

The advantage to using __eq__ is that it fails to work correctly less often
than __cmp__. Compare skip's example where comparison against datetime give
the wrong answer 100% of the time with __cmp__ and 50% of the time with
__eq__/__ne__:
def __cmp__(self,other):
return 0

def __eq__(self,other):
return True
def __ne__(self,other):
return False

True


...

Oh. /Is/ there a way of making it work, then? If we ignore the
problems with having such objects in the first place, that is.
In a contained environment, it can be made to work 'well enough'. So if you
are writing unit tests and want a wildcard element to include inside data
structures, AND you can guarantee that you always assert in the order
expected,actual, then you can probably get away with it. That's assuming
you remembered to use __eq__/__ne__ rather than __cmp__.

For an object safe to let out in the wild though there isn't any way to
implement it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top