[Python-ideas] Adding`Unpicklable` to the `collections` module

[Dima Tisnek]

Ahem, what happened to duck typing?

To me, the whole isinstance(datum, type) appears no more elegant than
the Java way (class implements this interface, implements that
interface, ad infinitum), anyhow it's not pythonic.
I have similar reservations about metaclass hacks.

On the other hand I am often confronted with similar problem:
  say I have a function foo(s): .... s.lower() .... which was written
to expect a string
  however all this function really cares about is that it's argument
can do .lower()
  what is the pythonic way to test for this?
  how to test that object can do .lower(), .startswith(), .decode(),
but not all methods of str/unicode?

  so far the best I can manage is let it be, don't test anything, just
let it throw an exception.
  does anyone know better?

d.

On 30 November 2010 06:14, Ram Rachum <cool-rr at cool-rr.com> wrote:
> Ram Rachum <cool-rr at ...| writes:
> | | I agree with putting whatever in the pickle module.
> | |
> | | If there were ever demand for json.Incompatible or whatever, there we
> | | have it.
> | |
> |
> | I think that naming it `pickle.Incompatible` would be the best indeed. The
> | reason I wanted to avoid having a positive `Pickleable` class is that people
> | might think that if something is an instance of it then it's pickleable, which
> | is false, since a list is "inherently pickleable" but a list containing a lock
> | object is not pickleable.
> |
> | So I think it will be best to have both a `pickle.Incompatible` and a
> | `pickle.Compatible`. The reason to have the negative is to let people inherit
> | from it, the reason to have the positive is to make `isinstance` calls more
> | natural. (i.e. avoid a double negative.)
> |
> | What do you think?
> |
> | Ram.
> |
>
> So... are people in favor of this idea?
>
>
> Ram.
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>