New submission from João Bernardo jbv...@gmail.com:
Hi, I'm working on a class which implements the __contains__ method but the way
I would like it to work is by generating an object that will be evaluated later.
It'll return a custom object instead of True/False
class C:
def
Georg Brandl ge...@python.org added the comment:
an object is true is a short way of saying bool(obj) is True. So the docs
match the behavior.
Returning the actual object instead of True/False from the in operator is a
feature request.
--
assignee: docs@python -
nosy: +georg.brandl
João Bernardo jbv...@gmail.com added the comment:
@Georg Brandl
Oh sorry, now I see... true != True
But still, why is that the default behavior? Shouldn't it use whatever the
method returns?
--
type: enhancement - behavior
versions: +Python 3.2
___
Changes by João Bernardo jbv...@gmail.com:
--
type: behavior - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13667
___
___
Georg Brandl ge...@python.org added the comment:
Well, usually what you want *is* a boolean indicating whether the element is in
the collection or not.
Being able to overload in, mostly for metaprogramming purposes, is a request
that probably nobody thought of when implementing in.
Benjamin Peterson benja...@python.org added the comment:
I think the idea has some merit. I think it should be well vetted on
python-ideas, though. One thing that will certianly weigh against it is that
implementation would not be trivial.
--
___
João Bernardo jbv...@gmail.com added the comment:
I see that every other comparison operator (, , =, =, ==, !=) except for
`is` work the way I expect and is able to return anything.
e.g.
numpy.arange(5) 3
array([ True, True, True, False, False], dtype=bool)
I didn't checked the code (and
Benjamin Peterson benja...@python.org added the comment:
2011/12/28 João Bernardo rep...@bugs.python.org:
João Bernardo jbv...@gmail.com added the comment:
I see that every other comparison operator (, , =, =, ==, !=) except for
`is` work the way I expect and is able to return anything.
João Bernardo jbv...@gmail.com added the comment:
Using my poor grep abilities I found that on Objects/typeobject.c
(I replaced some declarations/error checking from the code with ...)
static int
slot_sq_contains(PyObject *self, PyObject *value) {
...
func = lookup_maybe(self,
Georg Brandl ge...@python.org added the comment:
It's defined that way because it's a slot returning a bool, so it doesn't need
to return anything except for 0 or 1.
Changing this to return a PyObject would mean that every extension module (i.e.
module written in C) that defines a custom
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
-1 on this proposal. It has everyone paying a price for a questionable feature
that would benefit very few.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
Alex Gaynor alex.gay...@gmail.com added the comment:
For what it's worth I proposed this on -ideas a while ago, the sticking points
were what does `not in` do (no one had an answer anyone was happy with for
this), and do we need a way to override it from the other perspective (e.g. if
I want
João Bernardo jbv...@gmail.com added the comment:
The problem with `not in` is because it must evaluate the result. It's not just
another operator like == and !=.
Looks like we're suffering from premature optimization and now it would break a
lot of code to make it good.
For my application,
Changes by Benjamin Peterson benja...@python.org:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13667
___
14 matches
Mail list logo
