On Thu, Jul 29, 2010 at 1:54 PM, M.-A. Lemburg wrote:

Antoine Pitrou wrote:

...

On Thu, 29 Jul 2010 13:35:41 +0200 Tarek Ziadé wrote:

...

Hello,

What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps

How about letting json use the __reduce__ protocol instead?

How would you then write a class that works with both pickle and json ?

IMO, we'd need a separate method to return a JSON version of the object, e.g. .__json__(). I'm not sure how deserialization could be handled, since JSON doesn't support arbitrary object types.

As I told Oleg, I think its OK not to have a round trip like Pickle. The use case I have is to express a structure in Json, but loading it back can be done in a custom, explicit process. It cannot be triggered from the json package itself since it cannot know that a given Json structure was built through a specific class. Cheers Tarek

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source  (#1, Jul 29 2010)

...

...

...

Python/Zope Consulting and Support ...        http://www.egenix.com/ mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

---

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

  eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg           Registered at Amtsgericht Duesseldorf: HRB 46611               http://www.egenix.com/company/contact/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Tarek Ziadé | http://ziade.org

On Thu, Jul 29, 2010 at 7:54 AM, M.-A. Lemburg wrote:

Antoine Pitrou wrote:

...

On Thu, 29 Jul 2010 13:35:41 +0200 Tarek Ziadé wrote:

...

Hello,

What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps

How about letting json use the __reduce__ protocol instead?

+1. I think this is a very sensible idea. Note that Tarek's request was not for a magic method like __repr__ that would return an easy to parse string. Instead, the request was for a method that would return an object that can be serialized instead of the original object and will carry enough data to restore the original object.

How would you then write a class that works with both pickle and json ?

Hopefully, for most types json would be able to use a unmodified __reduce__ method. If his is not enough, the reduce protocol already has an extension mechanism. For example, an object may implement obj.__reduce_ex__('json') that would return json-friendly tuple instead of pickle oriented obj.__reduce__().

IMO, we'd need a separate method to return a JSON version of the object, e.g. .__json__(). I'm not sure how deserialization could be handled, since JSON doesn't support arbitrary object types.

I am afraid this was the turning point in this thread after which the discussion went (IMO) in the wrong direction. Again, the OP's request was for a method that would return an object that json or another simple serializer (say yaml) could handle, not for a method that will return json string.

On Thu, Jul 29, 2010 at 1:41 PM, Antoine Pitrou wrote:

On Thu, 29 Jul 2010 13:35:41 +0200 Tarek Ziadé wrote:

...

Hello,

What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps

How about letting json use the __reduce__ protocol instead?

Maybe that's because I've never used it, but I find this protocol is very complex for this simple use case

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Tarek Ziadé | http://ziade.org

Georg Brandl wrote:

Am 29.07.2010 13:35, schrieb Tarek Ziadé:

...

Hello,

What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps

So, it __json__ is provided, its used for serialization instead of the object itself:

...

...

...

import json class MyComplexClass(object): .... def __json__(self): .... return 'json' .... o = MyComplexClass() json.dumps(o) '"json"'

You can do this with a very short subclass of the JSONEncoder:

class MyJSONEncoder(JSONEncoder): def default(self, obj): return obj.__json__() # with a useful failure message

Does that also work with the JSON C extension ?

I don't think it needs to be built into the default encoder.

-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 29 2010)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

Georg Brandl wrote:

Am 29.07.2010 14:31, schrieb M.-A. Lemburg:

...

Georg Brandl wrote:

...

Am 29.07.2010 13:35, schrieb Tarek Ziadé:

...

Hello,

What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps

So, it __json__ is provided, its used for serialization instead of the object itself:

...

...

> import json > class MyComplexClass(object): .... def __json__(self): .... return 'json' .... > o = MyComplexClass() > json.dumps(o) '"json"'

You can do this with a very short subclass of the JSONEncoder:

class MyJSONEncoder(JSONEncoder): def default(self, obj): return obj.__json__() # with a useful failure message

Does that also work with the JSON C extension ?

I think so. The C encoder gets the default function as an argument.

Then that sounds like the right way forward. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 29 2010)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Thu, Jul 29, 2010 at 10:39 PM, Tarek Ziadé wrote:

On Thu, Jul 29, 2010 at 2:22 PM, Georg Brandl wrote: ..

...

You can do this with a very short subclass of the JSONEncoder:

class MyJSONEncoder(JSONEncoder):    def default(self, obj):        return obj.__json__()  # with a useful failure message

I don't think it needs to be built into the default encoder.

Yes, but you need to customize in that case the encoding process and own it.

Having a builtin recognition of __json__ would allow you to pass your objects to be serialized to any third party code that uses a plain json.dumps.

For instance, some web kits out there will automatically serialize your objects into json strings when you want to do json responses. e.g. it becomes a builtin adapter

I'll channel PJE here and point out that this kind of magic-method based protocol proliferation is exactly what a general purpose generic-function implementation is designed to avoid (i.e. instead of having json.dumps check for a __json__ magic method, you'd just flag json.dumps as a generic function and let people register their own overloads). Each individual time this question comes up people tend to react with "oh, that's too complicated and overkill, but magic methods are simple, so let's just define another magic method". The sum total of all those magic methods starts to accumulate into a lot of complexity of its own though :P Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Thu, Jul 29, 2010 at 11:11 PM, Antoine Pitrou wrote:

On Thu, 29 Jul 2010 22:51:11 +1000 Nick Coghlan wrote:

...

Each individual time this question comes up people tend to react with "oh, that's too complicated and overkill, but magic methods are simple, so let's just define another magic method". The sum total of all those magic methods starts to accumulate into a lot of complexity of its own though :P

I don't agree. __json__ only matters to people who do JSON encoding/decoding. Other people can safely ignore it.

Which is exactly the attitude I was talking about: for each individual case, people go "oh, I understand magic methods, those are easy". It's the overall process of identifying the need for and gathering consensus on magic methods that is unwieldy (and ultimately fails to scale, leading to non-extensible interfaces by default, with pretty printing being the classic example, and JSON serialisation the latest).

And I don't see how generic functions bring less cognitive overhead. (they actually bring more of it, since most implementations are more complicated to begin with)

Mostly because the fully fledged generic implementations like PEAK-rules tend to get brought into discussions when they aren't needed. Single-type generic dispatch is actually so common they gave it a name: object-oriented programming. All single-type generic dispatch is about is having a registry for a particular operation that says "to perform this operation, with objects of this type, use this function". Instead of having a protocol that says "look up this magic method in the object's own namespace" (which requires a) agreement on the magic name to use and b) that the original author of the type in question both knew and cared about the operation the application developer is interested in) you instead have a protocol that says "here is a standard mechanism for declaring a type registry for a function, so you only have to learn how to register a function once". Is it really harder for people to learn how to write things like: json.dumps.overload(mytype, mytype.to_json) json.dumps.overload(third_party_type, my_third_party_type_serialiser) than it is for them to figure out that implementing a __json__ method will allow them to change how their object is serialised? (Not to mention that a __json__ method can only be used via monkey-patching if the type you want to serialise differently came from a library module rather than your own code). The generic function registration approach is incidentally discoverable via dir(json.dumps) to see that a function provides the relevant generic function registration methods. Magic method protocols can *only* be discovered by reading documentation. Function registration is a solved problem, with much better solutions than the ad hoc YAMM (yet-another-magic-method) approach we currently use. We just keep getting scared away from the right answer by the crazily complex overloading schemes that libraries like PEAK-rules allow. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Thu, Jul 29, 2010 at 5:39 PM, Antoine Pitrou wrote:

...

...

I don't agree. __json__ only matters to people who do JSON encoding/decoding. Other people can safely ignore it.

Which is exactly the attitude I was talking about: for each individual case, people go "oh, I understand magic methods, those are easy". It's the overall process of identifying the need for and gathering consensus on magic methods that is unwieldy (and ultimately fails to scale, leading to non-extensible interfaces by default, with pretty printing being the classic example, and JSON serialisation the latest).

Why do you want to gather consensus? There is a single json serialization module in the stdlib and it's obvious that __json__ can/should be claimed by that module.

Actually, your argument could be returned: if you use generic functions (such as @json.dumps.overload), alternative json serializers won't easily be able to make use of the information, while they could access the __json__ method like the standard json module does.

...

Is it really harder for people to learn how to write things like:

    json.dumps.overload(mytype, mytype.to_json)     json.dumps.overload(third_party_type, my_third_party_type_serialiser)

It is certainly more annoying and less natural than:    def __json__(self): ....

Sure, generic functions as a paradigm appear more powerful, more decoupled, etc. But in practice __magic__ methods are sufficient for most uses. Practicality beats purity.

That may be why in all the years that the various generic functions libraries have existed, they don't seem to have been really popular compared to the simpler convention of defining fixed method names.

(besides, it wouldn't necessarily be json.dumps that you overload, but some internal function of the json module; making it even less intuitive and easily discoverable)

...

The generic function registration approach is incidentally discoverable via dir(json.dumps) to see that a function provides the relevant generic function registration methods. Magic method protocols can *only* be discovered by reading documentation.

If help(json.dumps) includes a small blurb about __json__, it makes the information at least as easily discoverable as invoking dir(json.dumps).

Besides, I don't find it shocking if documentation problems have to be solved through documentation.

Regards

Antoine.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

I'd be -1 on an __json__ method. From the perspective of someone who works on Django, the big issue we have is how do you specify how a model (something from the database) should be serialized to JSON. Often people suggest something like __json__ that the Django serializer (which uses the json module) could pick up on, however this is usually rejected: objects tend to have multiple serializations based on context. Unlike pickle, which is usually used for internal consumption, json is usually intended for the wide world, and generally you want to expose different data to different clients. For example an event's json might include a list of attendees for an authenticated client, but an unauthenticated client should only see a list of titles. For this reason Django has always rejected such an approach, in favor of having a per-serialization specification. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me

On Sat, Jul 31, 2010 at 11:17 AM, Greg Ewing wrote:

Suppose I write a class Foo, and as a convenience to my users, I want to give it the ability to be json-serialised. If that is done using a generic function, then I need to put a call in my module to register it. But that makes my module dependent on the json-serialising module, even for applications which don't use json at all.

The alternative is just to provide the function but don't register it. But using that approach, every application that *does* use json would be responsible for registering all the functions for all the classes that need to be serialised, including those in library modules that it may not be directly aware of. This doesn't seem like a good situation either.

Hence why most generic function proposals are accompanied by proposals for lazy module import hooks (i.e. delaying the registration until the relevant module is imported). However, the simpler approach is just to recommend that single-dispatch generic functions default to a particular method. "magic method" vs "generic function" isn't actually an either-or decision: it is quite possible to have the latter rely on the former in its default "unrecognised type" implementation, while still providing the type registration infrastructure that allows an application to say "no, I don't want that behaviour in this case, I want to do something different". To be honest, there are actually some more features I would want to push for in ABCs (specifically, a public API to view an ABC's type registry, as well as a callback API to be notified of registration changes) before seriously proposing an official generic function implementation in the standard library. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Sat, 31 Jul 2010 13:50:16 +0200 Tarek Ziadé wrote:

On Sat, Jul 31, 2010 at 3:31 AM, Nick Coghlan wrote: ...

...

To be honest, there are actually some more features I would want to push for in ABCs (specifically, a public API to view an ABC's type registry, as well as a callback API to be notified of registration changes) before seriously proposing an official generic function implementation in the standard library.

funny hazard, I was proposing to PEP 3319 authors about having the _abc_registry attribute somehow exposed.

Rather than exposing the registry object itself (which is an implementation detail), how about exposing lookup operations on this registry? Regards Antoine.

On Sat, 31 Jul 2010 18:17:42 +0200 Tarek Ziadé wrote:

...

Rather than exposing the registry object itself (which is an implementation detail), how about exposing lookup operations on this registry?

Sure but how ? global functions ?

Functions of the abc module, yes. Regards Antoine.

Thank you for explaining generic functions so clearly. Is there a good module out there implementing them without “crazily complex overloading schemes”? Regards

There is an extremely bare bones implementation used internally by pkgutil's emulation of the standard import process

Ah, I stumbled upon that this week actually, but did not understand how it worked nor why it was useful since there’s only one decorated function and only one registered type. Thanks for pointing it, I may play with it to get a better understanding and see the possibilities. Regards

You can check out my implementation of generic functions and methods in Python [1]. There are no byte code hacks, no frame introspection, support for function and method dispatching by one or more positional arguments. [1]: pypi.python.org/pypi/generic On Fri, Jul 30, 2010 at 2:46 AM, Éric Araujo wrote:

Thank you for explaining generic functions so clearly.

Is there a good module out there implementing them without “crazily complex overloading schemes”?

Regards

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Andrey Popp phone: +7 911 740 24 91 e-mail: 8mayday@gmail.com

...

...

Each individual time this question comes up people tend to react with "oh, that's too complicated and overkill, but magic methods are simple, so let's just define another magic method". The sum total of all those magic methods starts to accumulate into a lot of complexity of its own though :P

I don't agree. __json__ only matters to people who do JSON encoding/decoding. Other people can safely ignore it.

Which is exactly the attitude I was talking about: for each individual case, people go "oh, I understand magic methods, those are easy". It's the overall process of identifying the need for and gathering consensus on magic methods that is unwieldy (and ultimately fails to scale, leading to non-extensible interfaces by default, with pretty printing being the classic example, and JSON serialisation the latest).

...

And I don't see how generic functions bring less cognitive overhead. (they actually bring more of it, since most implementations are more complicated to begin with)

Mostly because the fully fledged generic implementations like PEAK-rules tend to get brought into discussions when they aren't needed. Single-type generic dispatch is actually so common they gave it a name: object-oriented programming. All single-type generic dispatch is about is having a registry for a particular operation that says "to perform this operation, with objects of this type, use this function". Instead of having a protocol that says "look up this magic method in the object's own namespace" (which requires a) agreement on the magic name to use and b) that the original author of the type in question both knew and cared about the operation the application developer is interested in) you instead have a protocol that says "here is a standard mechanism for declaring a type registry for a function, so you only have to learn how to register a function once".

Is it really harder for people to learn how to write things like:

json.dumps.overload(mytype, mytype.to_json) json.dumps.overload(third_party_type, my_third_party_type_serialiser)

than it is for them to figure out that implementing a __json__ method will allow them to change how their object is serialised? (Not to mention that a __json__ method can only be used via monkey-patching if the type you want to serialise differently came from a library module rather than your own code).

The generic function registration approach is incidentally discoverable via dir(json.dumps) to see that a function provides the relevant generic function registration methods. Magic method protocols can *only* be discovered by reading documentation.

Function registration is a solved problem, with much better solutions than the ad hoc YAMM (yet-another-magic-method) approach we currently use. We just keep getting scared away from the right answer by the crazily complex overloading schemes that libraries like PEAK-rules allow.

+1 on your entire diagnosis. If peak-rules is too complicated and perhaps unmaintained then the focus should be on cooking up a better generic function library. The complaints against peak-rules comes up frequently enough and this shows that there is a need for a generic function library because people do use peak-rules. The problem is not with the concept but only (perhaps) with this particular implementation (disclaimer: I'm perfectly happy with peak-rules). Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown

On Thu, 29 Jul 2010 15:25:20 +0200 Tarek Ziadé wrote:

That makes sense. OTHO, if we drop the idea of having a __magical__ method, we could have an collections' ABC instead, called JSONSerializable, with one method to override,

This is more about declaring the interface rather than adding yet another __magic__ method

That's a nice OOP pattern to have imho

Python is supposed to be duck-typed. It would be strange to add a couple of random exceptions to that general rule. Moreover, having to *both* derive an existing class and implement the single method defined on that class is one complication too many. And I don't see how `__json__` is more annoying than e.g. `to_json`. Regards Antoine.

On Thu, Jul 29, 2010 at 3:42 PM, Tarek Ziadé wrote:

...

And I don't see how `__json__` is more annoying than e.g. `to_json`.

Its easier to override

On Thu, Jul 29, 2010 at 3:51 PM, Antoine Pitrou wrote:

Le jeudi 29 juillet 2010 à 15:47 +0200, Tarek Ziadé a écrit :

...

On Thu, Jul 29, 2010 at 3:42 PM, Tarek Ziadé wrote:

...

...

And I don't see how `__json__` is more annoying than e.g. `to_json`.

Its easier to override

Could you expand a little bit?

If you want to override to_json in a subclass, to slightly adapt it, its easier because the __json__ name is mangled by Python

2010/7/29 Tarek Ziadé :

On Thu, Jul 29, 2010 at 3:51 PM, Antoine Pitrou wrote:

...

Le jeudi 29 juillet 2010 à 15:47 +0200, Tarek Ziadé a écrit :

...

On Thu, Jul 29, 2010 at 3:42 PM, Tarek Ziadé wrote:

...

...

And I don't see how `__json__` is more annoying than e.g. `to_json`.

Its easier to override

Could you expand a little bit?

If you want to override to_json in a subclass, to slightly adapt it, its easier because the __json__ name is mangled by Python

I believe that mangling will not be performed if the identifier ends with more than one underscore. So __json__ won't be mangled. Regards, -- Alex twitter.com/alexconrad

Le jeudi 29 juillet 2010 à 15:42 +0200, Tarek Ziadé a écrit :

On Thu, Jul 29, 2010 at 3:34 PM, Antoine Pitrou wrote:

...

On Thu, 29 Jul 2010 15:25:20 +0200 Tarek Ziadé wrote:

...

That makes sense. OTHO, if we drop the idea of having a __magical__ method, we could have an collections' ABC instead, called JSONSerializable, with one method to override,

This is more about declaring the interface rather than adding yet another __magic__ method

That's a nice OOP pattern to have imho

Python is supposed to be duck-typed. It would be strange to add a couple of random exceptions to that general rule. Moreover, having to *both* derive an existing class and implement the single method defined on that class is one complication too many.

Not sure to follow here, since ABCs are about having an object supporting a series of methods no matter what are the parent classes. e.g. this is closer to the concept of "interfaces".

IOW you don't need to derive from a parent class, you just to need to provide a given set of methods, and ABC provides a ways to check that an object has that signature.

Ok, but then how does it avoid having a __magic__ method? You can't use a normal name such as "to_json" because then an existing class with that method could be wrongly inferred as implementing your new ABC, and break existing code. Besides, defining an ABC for a single, module-specific method sounds rather overkill. This reminds of me of projects plagued by an overuse of interfaces for every possible concept. Regards Antoine.

...

Besides, defining an ABC for a single, module-specific method sounds rather overkill. This reminds of me of projects plagued by an overuse of interfaces for every possible concept.

Thats what Iterator did in ABC though.

Well, it could be argued that testing for an Iterator is useful for a significant variety of code, while testing for a JSONSerialiazable doesn't have an use case outside of the json module itself. Besides, it remains to be seen if anyone will use the Iterator ABC instead of directly looking up the __next__ method. I'm not convinced that all of the ABCs bundled with the stdlib are really useful, apart from showcasing the potentialities of ABCs. Regards Antoine.

On Thu, 29 Jul 2010 14:47:34 +0200 Daniel Fetchinson wrote:

...

What about adding in the json package the ability for an object to provide a different object to serialize ? This would be useful to translate a class into a structure that can be passed to json.dumps

So, it __json__ is provided, its used for serialization instead of the object itself:

...

...

...

import json class MyComplexClass(object): ... def __json__(self): ... return 'json' ... o = MyComplexClass() json.dumps(o) '"json"'

Have a look at turbojson [1], the jsonification package that uses peak.rules [2] and which comes with turbogears [3]. It does exactly what you propose.

That it uses PEAK-Rules is probably a good reason to avoid it. Also, AFAIK, TurboGears have stopped using turbojson and relies on [simple]json instead. Regards Antoine.

On Thu, 29 Jul 2010 15:19:56 +0200 Daniel Fetchinson wrote:

...

That it uses PEAK-Rules is probably a good reason to avoid it.

Why?

I might be mistaken, but it seems to me that it isn't maintained anymore (or perhaps that's RuleDispatch, which is from the same author). It doesn't seem to have had a stable release in years. Regards Antoine.

On Thu, 29 Jul 2010 22:59:52 +1000 Nick Coghlan wrote:

*For those following along at home that may not be familiar with the names of various Python developers, PJE is Phillip J. Eby, the author of peak.rules (amongst many other things).

Many of which unmaintained or even incompatible with recent Python versions (due to, for example, ugly bytecode hacks). Regards Antoine.

On Thu, 29 Jul 2010 10:29:34 -0400 Scott Dial wrote:

It's unclear to me that not having been changed in a year constitutes "unmaintained" especially since PJE seems quite responsive on the PEAK mailing list. So, please restrain yourself unless you have something more to say than FUD about PJE and PEAK-Rules.

Well, sorry if I mixed up PEAK-Rules and RuleDispatch (which, again, are similar libraries from the same author). The fact that RuleDispatch has been unmaintained, though, has been a source of problems for some people and projects. Regards Antoine.

I'm uncomfortable with the __foo__ style proposed. Details and "what I would do" below. On 30Jul2010 12:06, Greg Ewing wrote: | Mike Graham wrote: | >Since there isn't really any magic going on, why use a __foo__ name? | >The majority of __foo__ names are for things you shouldn't reference | >yourself | | To my mind, the main reason is to avoid name clashes. Protocol | methods often may need to be added to just about any class, | and using a __foo__ name greatly reduces the chance of it | coinciding with some pre-existing class-specific method. Might not the adder of a class specific method make the same argument? If they really want a class _specific_ method, ought thy not to be using the __foo style, thus avoiding clashes anyway? The __json__ name make me uncomfortable; to my mind __foo_ names belong to the language in order to implement/override stuff like [], not to a library hook. | Anyway, you don't call it yourself in this case either -- it's | called by the proposed json-serialising framework. I'm curious; what's the special benefit to JSON here? I don't mean JSON is unpopular or horrible, but I can see people going to a __xml__ hook for a proposed XML serialisation framework, and __sql__ for db storage, and ... I'm doing a little serialisation myself for another purpose. My code gets classes that want serialisation to register themselves with the serialisation module thus: # DB is a NodeDB instance, which can store various objects DB.register_type(class, tobytes, frombytes) where class is the class desiring special serialisation and tobytes and frombytes are callables; tobytes takes an instance of the class and returns the byte serialisation and frombytes does the reverse. No special names needed and no __foo__ special name reservation. Why wouldn't one just extend the json module with a "serialise this" and "unserialise this" type registry? Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ You can listen to what everybody says, but the fact remains that you've got to get out there and do the thing yourself. - Joan Sutherland