From jmillikin at gmail.com Sun Apr 6 03:42:29 2008 From: jmillikin at gmail.com (John Millikin) Date: Sat, 5 Apr 2008 18:42:29 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201337k7bdf54b3o1fd333a648261657@mail.gmail.com> <3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> Message-ID: <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> I've written a rough draft of a PEP for standard library inclusion, attached to this email. Comments/improvements welcome - I tried to leave most of the differences between modules in the "Issues" section. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20080405/8183605a/attachment.htm -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: json pep.txt Url: http://mail.python.org/pipermail/web-sig/attachments/20080405/8183605a/attachment.txt From fumanchu at aminus.org Sun Apr 6 04:01:37 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Sat, 5 Apr 2008 19:01:37 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com><5c06fa770803201337k7bdf54b3o1fd333a648261657@mail.gmail.com><3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com><5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com><6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com><6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com><5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> Message-ID: John Millikin wrote: > I've written a rough draft of a PEP for standard library inclusion, > attached to this email. Comments/improvements welcome - I tried to > leave most of the differences between modules in the "Issues" section. Re: Representation of Fractional Numbers, there are two solutions. If you return decimals, people using JS on the other end are going to call float(d). If you return floats, people not using JS on the other end are going to go use a different library. I suggest the former is more acceptable than the latter for a stdlib offering. Allowing the caller of parse() to choose would be even better. Robert Brewer fumanchu at aminus.org From jmillikin at gmail.com Sun Apr 6 05:54:01 2008 From: jmillikin at gmail.com (John Millikin) Date: Sat, 5 Apr 2008 20:54:01 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> Message-ID: <3283f7fe0804052054y6ee363fl370d3f6b3360aa9a@mail.gmail.com> (messed up CC on last email, re-sending to list) On Sat, Apr 5, 2008 at 7:01 PM, Robert Brewer wrote: > Re: Representation of Fractional Numbers, there are two solutions. If you > return decimals, people using JS on the other end are going to call > float(d). If you return floats, people not using JS on the other end are > going to go use a different library. I suggest the former is more acceptable > than the latter for a stdlib offering. Allowing the caller of parse() to > choose would be even better. I don't understand what you mean, here. generate ([decimal.Decimal ('1.1')]) -> '[1.1]', so a JavaScript user calling eval() on it would get a standard JavaScript float object without having to call float() explicitly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20080405/e527cee3/attachment.htm From fumanchu at aminus.org Sun Apr 6 08:45:10 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Sat, 5 Apr 2008 23:45:10 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804052054y6ee363fl370d3f6b3360aa9a@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com><3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com><5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com><6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com><6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com><5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com><3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <3283f7fe0804052054y6ee363fl370d3f6b3360aa9a@mail.gmail.com> Message-ID: John Millikin wrote: > On Sat, Apr 5, 2008 at 7:01 PM, Robert Brewer wrote: > > Re: Representation of Fractional Numbers, there are two solutions. If you > > return decimals, people using JS on the other end are going to call float(d). > > If you return floats, people not using JS on the other end are going to go > > use a different library. I suggest the former is more acceptable than the > > latter for a stdlib offering. Allowing the caller of parse() to choose > > would be even better. >? > I don't understand what you mean, here. generate ([decimal.Decimal ('1.1')]) > -> '[1.1]', so a JavaScript user calling eval() on it would get a standard > JavaScript float object without having to call float() explicitly. Sorry, I wasn't describing what anyone would do in Javascript. Pythonistas receiving JSON numbers from a JS *sender*, who want Python floats, can call float(d) if they like if you hand them a Decimal object. Annoying but easy. People receiving JSON numbers from, say, a Python sender, can't call Decimal(f) if you hand them a float instance, at least not reliably. So they'll either go use some other jsonlib (bad) or start passing numbers in strings (worse). Robert Brewr fumanchu at aminus.org From Ronny.Pfannschmidt at gmx.de Mon Apr 7 15:28:49 2008 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Mon, 7 Apr 2008 15:28:49 +0200 Subject: [Web-SIG] [proposal] merging jsonrpc into xmlrpc Message-ID: <20080407152849.536662e4@ronnyger.mine.nu> Hi, since json-rpc and xml-rpc basically do the same and the only difference is the content-type (json is more concise), i propose to create a single xml/json-rpc module. I did the a semilar proposal to stdlib-sig, they told me to ask in web-sig about the details cause of json. --- Ronny Pfannschmidt From graham.dumpleton at gmail.com Tue Apr 8 00:36:58 2008 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Tue, 8 Apr 2008 08:36:58 +1000 Subject: [Web-SIG] [proposal] merging jsonrpc into xmlrpc In-Reply-To: <20080407152849.536662e4@ronnyger.mine.nu> References: <20080407152849.536662e4@ronnyger.mine.nu> Message-ID: <88e286470804071536j3afaddc0w36f2e620e8f48478@mail.gmail.com> 2008/4/7 Ronny Pfannschmidt : > Hi, > > since json-rpc and xml-rpc basically do the same > and the only difference is the content-type (json is more concise), > i propose to create a single xml/json-rpc module. > > I did the a semilar proposal to stdlib-sig, > they told me to ask in web-sig about the details cause of json. To repeat something I said on list a while back, this time phrased properly to correctly refer to JSON-RPC. :-) The problem with the JSON-RPC 1.0 specification was that it wasn't always as clear as could have been. As a result different server side implementations interpreted or implemented it differently, as did the JavaScript clients. I'll admit that it has been a while since I looked at it and maybe things have improved, but certainly it used to be the case that finding a JavaScript library that talked to a specific server side implementation wasn't always easy. End result was that the JavaScript library would often only work with the specific web framework it was originally designed for and nothing else. The problem areas were, different interpretations of what could be supplied in an error response. Whether an integer, string or arbitrary object should be used as the id attribute in a request. Finally, some JavaScript clients would only work with a server side implementation which provided introspection methods as they would dynamically create a JavaScript proxy object based on a call of the introspection methods. Unfortunately the JSON-RPC 1.1 draft specification didn't necessarily make things better. Rather than creating a proper layered specification which separated lower level transport and encoding concerns from higher level application concepts such as introspection they bundle it all together. Thus they try to enforce that a server must support introspection even though doing so may be totally impractical depending on what the JSON-RPC server adapter is hooking in to. They also introduced all this muck about having to support both positional and named parameters at the same time. The JSON-RPC 1.1 specification was also never really completed and left out details such as standard error codes etc that there were proposing be specified. Thus my question is, what version of the JSON-RPC specification are you intending to support? Also what form would the error response take so that it works with a suitable number of JSON-RPC clients? Are you prepared to go and test it with a sufficient range of clients to make sure Python implemented server side interops properly? Graham From mdipierro at cs.depaul.edu Tue Apr 8 19:09:26 2008 From: mdipierro at cs.depaul.edu (Massimo Di Pierro) Date: Tue, 8 Apr 2008 12:09:26 -0500 Subject: [Web-SIG] google appengine Message-ID: <6CF6B2EE-A75D-4D40-A48A-AD77B299F264@cs.depaul.edu> You probably read that google has released appengine: http://www.youtube.com/watch?v=bfgO-LXGpTM but they have disabled video responses. So here is mine anyway. http://www.vimeo.com/875433 Massimo From pywebsig at xhaus.com Tue Apr 8 23:01:01 2008 From: pywebsig at xhaus.com (Alan Kennedy) Date: Tue, 8 Apr 2008 22:01:01 +0100 Subject: [Web-SIG] [proposal] merging jsonrpc into xmlrpc In-Reply-To: <88e286470804071536j3afaddc0w36f2e620e8f48478@mail.gmail.com> References: <20080407152849.536662e4@ronnyger.mine.nu> <88e286470804071536j3afaddc0w36f2e620e8f48478@mail.gmail.com> Message-ID: <4a951aa00804081401p61312ba2w7b1c46bc9f4c2cab@mail.gmail.com> [Ronny] >> since json-rpc and xml-rpc basically do the same >> and the only difference is the content-type (json is more concise), >> i propose to create a single xml/json-rpc module. [Graham] > The problem with the JSON-RPC 1.0 specification was that it wasn't > always as clear as could have been. > > Unfortunately the JSON-RPC 1.1 draft specification didn't necessarily > make things better. > The JSON-RPC 1.1 > specification was also never really completed and left out details > such as standard error codes etc that there were proposing be > specified. All valid concerns. I think that the JSON-RPC initiative lost its way a little. They tried to model things such as encoding and decoding an object graph, using object references, etc, which IMHO is a step too far for the usages JSON-RPC would get, and is more CORBA than XML-RPC. The maintainer of the JSON-RPC.org site was looking for someone to take it over for a while; I think someone might have taken it over last year. [Graham] > Are you > prepared to go and test it with a sufficient range of clients to make > sure Python implemented server side interops properly? Interestingly, the reference implementation for JSON-RPC is a server written in python[1]. http://json-rpc.org/wiki/python-json-rpc Perhaps python's best interests in this case are better served by letting that reference implementation drive the JSON-RPC standards process[2]? If that is the case, then it is counter-productive to add a competing module to the python standard library. Regards, Alan. [1] But it's a shame they didn't write it on WSGI: then their services could have run on the Google compute cloud ;-) [2] Perhaps some pythonista from Web-SIG is most appropriate to advise how JSON-RPC should move forward? After all, we're more accustomed to server-side stuff than those javascript folks ;-) From ianb at colorstudy.com Wed Apr 9 00:06:40 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 08 Apr 2008 17:06:40 -0500 Subject: [Web-SIG] [proposal] merging jsonrpc into xmlrpc In-Reply-To: <4a951aa00804081401p61312ba2w7b1c46bc9f4c2cab@mail.gmail.com> References: <20080407152849.536662e4@ronnyger.mine.nu> <88e286470804071536j3afaddc0w36f2e620e8f48478@mail.gmail.com> <4a951aa00804081401p61312ba2w7b1c46bc9f4c2cab@mail.gmail.com> Message-ID: <47FBEC70.3070108@colorstudy.com> Alan Kennedy wrote: > [1] But it's a shame they didn't write it on WSGI: then their services > could have run on the Google compute cloud ;-) Indeed. After seeing a BaseHTTPServer JSON-RPC server go up on the Python Cookbook I wrote a WSGI server and made it into a tutorial: http://pythonpaste.org/webob/jsonrpc-example.html (but it's not a maintained library -- at least I won't be maintaining it). > [2] Perhaps some pythonista from Web-SIG is most appropriate to advise > how JSON-RPC should move forward? After all, we're more accustomed to > server-side stuff than those javascript folks ;-) Let it die? It is more complicated than necessary, when instead you could just make each function a URL of its own, and POST the arguments and get back the response, with 500 Server Error for errors. It's hard to spec that up because it's too simple. OHM (http://pythonpaste.org/ohm/) follows this model of exposing a service. Ian From pywebsig at xhaus.com Wed Apr 9 03:02:35 2008 From: pywebsig at xhaus.com (Alan Kennedy) Date: Wed, 9 Apr 2008 02:02:35 +0100 Subject: [Web-SIG] [proposal] merging jsonrpc into xmlrpc In-Reply-To: <47FBEC70.3070108@colorstudy.com> References: <20080407152849.536662e4@ronnyger.mine.nu> <88e286470804071536j3afaddc0w36f2e620e8f48478@mail.gmail.com> <4a951aa00804081401p61312ba2w7b1c46bc9f4c2cab@mail.gmail.com> <47FBEC70.3070108@colorstudy.com> Message-ID: <4a951aa00804081802t41aab729v4ff5c2de348c82a0@mail.gmail.com> [Alan] >> [2] Perhaps some pythonista from Web-SIG is most appropriate to advise >> how JSON-RPC should move forward? After all, we're more accustomed to >> server-side stuff than those javascript folks ;-) [Ian] > Let it die? It is more complicated than necessary, when instead you could > just make each function a URL of its own, and POST the arguments and get > back the response, with 500 Server Error for errors. It's hard to spec that > up because it's too simple. > > OHM (http://pythonpaste.org/ohm/) follows this model of exposing a service. Mmmm, very RESTful. Access to the requested HTTP method is a fundamental for RESTful services. I find it interesting that Java's HttpServletRequest has a .getMethod(), but no .setMethod(). Which means that one has to implement method overrides[1] by carrying the override value through means other than the request object itself. Whereas in WSGI, I can simply do: environ['REQUEST_METHOD'] = environ['HTTP-X-HTTP-METHOD-OVERRIDE'] I've heard WSGI described as "python's servlet API". It's not that; it's better. Regards, Alan. [1] http://code.google.com/apis/gdata/basics.html#Updating-an-entry From fumanchu at aminus.org Wed Apr 9 07:52:56 2008 From: fumanchu at aminus.org (Robert Brewer) Date: Tue, 8 Apr 2008 22:52:56 -0700 Subject: [Web-SIG] [proposal] merging jsonrpc into xmlrpc In-Reply-To: <47FBEC70.3070108@colorstudy.com> References: <20080407152849.536662e4@ronnyger.mine.nu> <88e286470804071536j3afaddc0w36f2e620e8f48478@mail.gmail.com><4a951aa00804081401p61312ba2w7b1c46bc9f4c2cab@mail.gmail.com> <47FBEC70.3070108@colorstudy.com> Message-ID: Ian Bicking wrote: > Alan Kennedy wrote: > > Perhaps some pythonista from Web-SIG is most appropriate to advise > > how JSON-RPC should move forward? After all, we're more accustomed to > > server-side stuff than those javascript folks ;-) > > Let it die? It is more complicated than necessary, when instead you > could just make each function a URL of its own, and POST the arguments > and get back the response, with 500 Server Error for errors. It's hard > to spec that up because it's too simple. Yup. We just built one of those at work, with the added bonus that a GET of the same URI returns an HTML form for submitting the right JSON in a POST. The HTML also shows function metadata (args and return type). A GET on the parent path returns a bunch of links to GET the children. Handy and almost RESTful if you squint and call each function a "resource". I'd still rather have real resources that align with application state, but it makes for a good transition strategy from existing RPC mechanisms. Robert Brewer fumanchu at aminus.org From ianb at colorstudy.com Wed Apr 9 19:05:30 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 09 Apr 2008 12:05:30 -0500 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201337k7bdf54b3o1fd333a648261657@mail.gmail.com> <3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> Message-ID: <47FCF75A.5080109@colorstudy.com> > parse (bytes_or_string) > generate (obj, indent = None, ascii_only = True, encoding = 'utf-8') I strongly prefer we stick to the conventional names of dump/dumps/load/loads, for consistency with other serialization libraries already in Python. Ian From benji at benjiyork.com Wed Apr 9 19:27:05 2008 From: benji at benjiyork.com (Benji York) Date: Wed, 09 Apr 2008 13:27:05 -0400 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <47FCF75A.5080109@colorstudy.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201337k7bdf54b3o1fd333a648261657@mail.gmail.com> <3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> Message-ID: <47FCFC69.6040900@benjiyork.com> Ian Bicking wrote: >> parse (bytes_or_string) >> generate (obj, indent = None, ascii_only = True, encoding = 'utf-8') > > I strongly prefer we stick to the conventional names of > dump/dumps/load/loads, for consistency with other serialization > libraries already in Python. +1 -- Benji York http://benjiyork.com From duncan.mcgreggor at gmail.com Wed Apr 9 19:28:54 2008 From: duncan.mcgreggor at gmail.com (Duncan McGreggor) Date: Wed, 9 Apr 2008 12:28:54 -0500 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <47FCFC69.6040900@benjiyork.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <47FCFC69.6040900@benjiyork.com> Message-ID: <4327dfbd0804091028ld594a25xedf882af9f427620@mail.gmail.com> On Wed, Apr 9, 2008 at 12:27 PM, Benji York wrote: > Ian Bicking wrote: > >> parse (bytes_or_string) > >> generate (obj, indent = None, ascii_only = True, encoding = 'utf-8') > > > > I strongly prefer we stick to the conventional names of > > dump/dumps/load/loads, for consistency with other serialization > > libraries already in Python. > > +1 +1 for me too. From pywebsig at xhaus.com Wed Apr 9 20:38:29 2008 From: pywebsig at xhaus.com (Alan Kennedy) Date: Wed, 9 Apr 2008 19:38:29 +0100 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804081624g46f58083kf8f3b01898af128f@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <4a951aa00804081336k3e41913o9d3eebfd71c6c206@mail.gmail.com> <3283f7fe0804081624g46f58083kf8f3b01898af128f@mail.gmail.com> Message-ID: <4a951aa00804091138s12a83b5akf49d29f46135cda8@mail.gmail.com> [John] > I'm interested in whether you generally use JSON to communicate with a > JavaScript client, or another JSON library. Both the demjson and simplejson > libraries are written with the assumption that they are to be used to > interact with JavaScript. Answer #1: My motive is simply to implement the JSON spec, in a [j|p]ythonic way. If the ideal of JSON is to be realised, then the producer of the document is not relevant: it is only the document itself that matters. Answer #2: I'm working (i.e. day job) with JSON at the moment: a javascript client talking to a java server. The JS guy had a problem last week with a sample JSON document I gave him to prototype on. I wrote the sample by hand (it later became my freemarker template), and so inadvertently left in a hard-to-spot dangling comma, from all the copying and pasting. That broke his javascript library; he solved the problem by passing it through a PHP JSON codec on his local Apache. It worked, i.e. his problem disappeared, but he didn't know why (the PHP lib had eliminated the dangling comma). Which all goes to confirm, IMHO, that you should be liberal in what you consume and strict in what you produce. [John] > You mentioned in an earlier e-mail that jyson supports reading arrays with > trailing commas -- is this intentional, or accidental? Do you read them with > Python or JavaScript semantics? Went out of my way to accept them, with python semantics. Javascript semantics differ. Last time I tested, FireFox and IE interpreted "[1,2,3,]" differently as [1,2,3] and [1,2,3,null]. Although that may have changed during the meanwhilst. [Alan] > > 2. To have a native-code implementation, customised for jython. [John] > Did you encounter any particular issues related to implementing a JSON > library in Jython that would affect how a standard library implementation's > API should be designed? Jython is changing rapidly. It is evolving from a 2.2 stage ("from __future__ import generators") to a 2.5 stage in one leap. Jython 2.5 is built with java 1.5 (1.5 is where java grew annotations and generics). Between 2.2. and 2.5, python has grown Decimal's, generator comprehensions, decorators, context managers, bi-directional generators, etc. I prefer for a pure java implementation of a JSON codec to remain flexible in terms of the way that it maps "fundamental" JSON types into the jython type hierarchy and interpreter machinery[1]. I'm beginning to think that any putative JSON API should permit the user to specify which class will be used to instantiate JSON objects. If the users can specify their own classes, that might go a long way way resolve issues such as "I need my javascript client to communicate Numbers representing radians to my python server which uses Decimal because it works better with my geo-positioning library". Standard libraries should provide their own set of default instantiation classes, which the user could override. Regards, Alan. [1] There is an argument that a pure java JSON parser for jython is not worth the effort, in performance terms at least. JVM optimisation is very sophisticated these days, and it is conceivable that pure python (byte)code could run as fast or faster on a JVM than equivalent java code. Think PyPy. So maybe a single well-designed pure-python JSON module in the cpython standard library is the way to go. From jmillikin at gmail.com Wed Apr 9 21:14:39 2008 From: jmillikin at gmail.com (John Millikin) Date: Wed, 9 Apr 2008 12:14:39 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <47FCF75A.5080109@colorstudy.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <3283f7fe0803201548l7d986513w2189791665b0c3d8@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> Message-ID: <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> On Wed, Apr 9, 2008 at 10:05 AM, Ian Bicking wrote: > I strongly prefer we stick to the conventional names of dump/dumps/load/loads, for consistency with other serialization libraries already in Python. > On Wed, Apr 9, 2008 at 10:27 AM, Benji York wrote: > +1 > On Wed, Apr 9, 2008 at 10:28 AM, Duncan McGreggor wrote: > +1 for me too. > PEP updated to use dump/dumps/load/loads On Wed, Apr 9, 2008 at 11:38 AM, Alan Kennedy wrote: > Answer #2: I'm working (i.e. day job) with JSON at the moment: a > javascript client talking to a java server. The JS guy had a problem > last week with a sample JSON document I gave him to prototype on. I > wrote the sample by hand (it later became my freemarker template), and > so inadvertently left in a hard-to-spot dangling comma, from all the > copying and pasting. That broke his javascript library; he solved the > problem by passing it through a PHP JSON codec on his local Apache. It > worked, i.e. his problem disappeared, but he didn't know why (the PHP > lib had eliminated the dangling comma). Which all goes to confirm, > IMHO, that you should be liberal in what you consume and strict in > what you produce. > Sounds like a case *for* strict parsing, in my opinion. PHP's loose parsing made it difficult to figure out why the JSON was invalid. If trailing comma handling is to try to work around copy-paste errors, -1 from me. > I'm beginning to think that any putative JSON API should permit the > user to specify which class will be used to instantiate JSON objects. > If the users can specify their own classes, that might go a long way > way resolve issues such as "I need my javascript client to communicate > Numbers representing radians to my python server which uses Decimal > because it works better with my geo-positioning library". Standard > libraries should provide their own set of default instantiation > classes, which the user could override. > This is the float v. Decimal thing again -- load(s) might grow a parameter for that, since it's hard to be both fast and correct. But what is the use case for overriding the mappings for other JSON types, like arrays or objects? If given the choice, I'd rather have a very simple API in the stdlib that can be wrapped or implemented by third parties if they need something weird, than a large API that is difficult to implement fully. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: json pep.txt Url: http://mail.python.org/pipermail/web-sig/attachments/20080409/011bb38b/attachment-0001.txt From pywebsig at xhaus.com Thu Apr 10 02:48:11 2008 From: pywebsig at xhaus.com (Alan Kennedy) Date: Thu, 10 Apr 2008 01:48:11 +0100 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> Message-ID: <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> [Alan] >> [hand written JSON containing a] hard-to-spot dangling comma, from all the >> copying and pasting. That broke his javascript library; he solved the >> problem by passing it through a PHP JSON codec on his local Apache. It >> worked, i.e. his problem disappeared, but he didn't know why (the PHP >> lib had eliminated the dangling comma). Which all goes to confirm, >> IMHO, that you should be liberal in what you consume and strict in >> what you produce. [John] > Sounds like a case *for* strict parsing, in my opinion. PHP's loose > parsing made it difficult to figure out why the JSON was invalid. If > trailing comma handling is to try to work around copy-paste errors, -1 > from me. No, the PHP lib did exactly what it should, IMHO. The PHP lib was liberal in what it consumed (a dangling comma), and strict in what it produced (no dangling comma). It accepted my broken document with a dangling-comma, and emitted a strictly conformant document with the offending comma removed, which enabled my co-worker to proceed with his job. +1 from me. Other opinions? Alan. From bob at redivi.com Thu Apr 10 03:16:34 2008 From: bob at redivi.com (Bob Ippolito) Date: Wed, 9 Apr 2008 18:16:34 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> Message-ID: <6a36e7290804091816g207aa81bx3a59187319673c51@mail.gmail.com> On Wed, Apr 9, 2008 at 5:48 PM, Alan Kennedy wrote: > [Alan] > >> [hand written JSON containing a] hard-to-spot dangling comma, from all the > > >> copying and pasting. That broke his javascript library; he solved the > >> problem by passing it through a PHP JSON codec on his local Apache. It > >> worked, i.e. his problem disappeared, but he didn't know why (the PHP > >> lib had eliminated the dangling comma). Which all goes to confirm, > >> IMHO, that you should be liberal in what you consume and strict in > >> what you produce. > > [John] > > > Sounds like a case *for* strict parsing, in my opinion. PHP's loose > > parsing made it difficult to figure out why the JSON was invalid. If > > trailing comma handling is to try to work around copy-paste errors, -1 > > from me. > > No, the PHP lib did exactly what it should, IMHO. The PHP lib was > liberal in what it consumed (a dangling comma), and strict in what it > produced (no dangling comma). > > It accepted my broken document with a dangling-comma, and emitted a > strictly conformant document with the offending comma removed, which > enabled my co-worker to proceed with his job. > > +1 from me. > > Other opinions? simplejson would give you an error and tell you exactly where the problem was, but there isn't currently a non-strict mode and honestly nobody has asked for it. -bob From ianb at colorstudy.com Thu Apr 10 04:20:12 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 09 Apr 2008 21:20:12 -0500 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803201743n41223392n57378cc6d937a87b@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> Message-ID: <47FD795C.6020804@colorstudy.com> Alan Kennedy wrote: > [John] >> Sounds like a case *for* strict parsing, in my opinion. PHP's loose >> parsing made it difficult to figure out why the JSON was invalid. If >> trailing comma handling is to try to work around copy-paste errors, -1 >> from me. > > No, the PHP lib did exactly what it should, IMHO. The PHP lib was > liberal in what it consumed (a dangling comma), and strict in what it > produced (no dangling comma). > > It accepted my broken document with a dangling-comma, and emitted a > strictly conformant document with the offending comma removed, which > enabled my co-worker to proceed with his job. I prefer liberal, with an option to turn on warnings or be strict. Potentially warnings could be turned on by default, and turned off with the warnings module. (Is there a way to have a warning raise an exception by default? I only know of the command-line option to the interpreter.) Ian From jmillikin at gmail.com Thu Apr 10 05:04:04 2008 From: jmillikin at gmail.com (John Millikin) Date: Wed, 9 Apr 2008 20:04:04 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <47FD795C.6020804@colorstudy.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <47FD795C.6020804@colorstudy.com> Message-ID: <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> On Wed, Apr 9, 2008 at 7:20 PM, Ian Bicking wrote: > I prefer liberal, with an option to turn on warnings or be strict. > Potentially warnings could be turned on by default, and turned off with > the warnings module. (Is there a way to have a warning raise an > exception by default? I only know of the command-line option to the > interpreter.) > I forgot about the warnings module. For "exception by default" behavior, the library can call warnings.simplefilter ("error", JSONWarning) on initialization. Then we just define various subclasses of JSONWarning for the different warning types (trailing comma, illegal whitespace, NaN etc). If users want to ignore some or all of the warnings, they can specify which (or all). Best of all, it wouldn't require long parameter lists. From bob at redivi.com Thu Apr 10 07:15:21 2008 From: bob at redivi.com (Bob Ippolito) Date: Wed, 9 Apr 2008 22:15:21 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <47FD795C.6020804@colorstudy.com> <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> Message-ID: <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> On Wed, Apr 9, 2008 at 8:04 PM, John Millikin wrote: > On Wed, Apr 9, 2008 at 7:20 PM, Ian Bicking wrote: > > I prefer liberal, with an option to turn on warnings or be strict. > > Potentially warnings could be turned on by default, and turned off with > > the warnings module. (Is there a way to have a warning raise an > > exception by default? I only know of the command-line option to the > > interpreter.) > > > I forgot about the warnings module. > > For "exception by default" behavior, the library can call > warnings.simplefilter ("error", JSONWarning) on initialization. Then > we just define various subclasses of JSONWarning for the different > warning types (trailing comma, illegal whitespace, NaN etc). If users > want to ignore some or all of the warnings, they can specify which (or > all). Best of all, it wouldn't require long parameter lists. That sounds like a really bad idea, if there is an option to change the behavior it shouldn't live in module state. -bob From jmillikin at gmail.com Thu Apr 10 08:01:07 2008 From: jmillikin at gmail.com (John Millikin) Date: Wed, 9 Apr 2008 23:01:07 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <47FD795C.6020804@colorstudy.com> <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> Message-ID: <3283f7fe0804092301j1b18990g6b094e29a31f7730@mail.gmail.com> On Wed, Apr 9, 2008 at 10:15 PM, Bob Ippolito wrote: > That sounds like a really bad idea, if there is an option to change > the behavior it shouldn't live in module state. > Would you rather have strictness controls as parameters? demjson currently has seventeen of those. Maybe we could have loads(bytes) and loads_broken(bytes, allow_trailing_comma, allow_all_whitespace, allow_comments, ...) functions, one for parsing JSON, the other for parsing garbage. There's no real way to hide or remove the complexity in parsing invalid data, so both warnings and parameters will cause the implementation to be much larger, but at least having to call warnings.filter ("ignore", JSONWarning) might serve to make some users think twice. From bob at redivi.com Thu Apr 10 09:12:28 2008 From: bob at redivi.com (Bob Ippolito) Date: Thu, 10 Apr 2008 00:12:28 -0700 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804092301j1b18990g6b094e29a31f7730@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <47FD795C.6020804@colorstudy.com> <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> <3283f7fe0804092301j1b18990g6b094e29a31f7730@mail.gmail.com> Message-ID: <6a36e7290804100012h4e495451x14814da8b3a8e732@mail.gmail.com> On Wed, Apr 9, 2008 at 11:01 PM, John Millikin wrote: > On Wed, Apr 9, 2008 at 10:15 PM, Bob Ippolito wrote: > > That sounds like a really bad idea, if there is an option to change > > the behavior it shouldn't live in module state. > > > Would you rather have strictness controls as parameters? demjson > currently has seventeen of those. Maybe we could have loads(bytes) and > loads_broken(bytes, allow_trailing_comma, allow_all_whitespace, > allow_comments, ...) functions, one for parsing JSON, the other for > parsing garbage. There's no real way to hide or remove the complexity > in parsing invalid data, so both warnings and parameters will cause > the implementation to be much larger, but at least having to call > warnings.filter ("ignore", JSONWarning) might serve to make some users > think twice. > Yeah just like sys.setdefaultencoding, look at how well that worked out. simplejson has a number of options that you can pass to loads and dumps, but if you don't explicitly use any of them it does what most people want by default. I don't see a "loose=True" being much worse, I probably wouldn't allow people to pick and choose exactly which garbage to allow (except for the spec ambiguities that it already gives you control over). -bob From ianb at colorstudy.com Thu Apr 10 09:25:40 2008 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 10 Apr 2008 02:25:40 -0500 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <3283f7fe0804092301j1b18990g6b094e29a31f7730@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <47FD795C.6020804@colorstudy.com> <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> <3283f7fe0804092301j1b18990g6b094e29a31f7730@mail.gmail.com> Message-ID: <47FDC0F4.7010400@colorstudy.com> John Millikin wrote: > On Wed, Apr 9, 2008 at 10:15 PM, Bob Ippolito wrote: >> That sounds like a really bad idea, if there is an option to change >> the behavior it shouldn't live in module state. >> > Would you rather have strictness controls as parameters? demjson > currently has seventeen of those. Maybe we could have loads(bytes) and > loads_broken(bytes, allow_trailing_comma, allow_all_whitespace, > allow_comments, ...) functions, one for parsing JSON, the other for > parsing garbage. There's no real way to hide or remove the complexity > in parsing invalid data, so both warnings and parameters will cause > the implementation to be much larger, but at least having to call > warnings.filter ("ignore", JSONWarning) might serve to make some users > think twice. What reason is there for all the different flags? Why not just strict and loose? -- Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org From pywebsig at xhaus.com Thu Apr 10 10:22:47 2008 From: pywebsig at xhaus.com (Alan Kennedy) Date: Thu, 10 Apr 2008 09:22:47 +0100 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <6a36e7290804091816g207aa81bx3a59187319673c51@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803201819m39c31819kdf35262a6f3c857b@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <6a36e7290804091816g207aa81bx3a59187319673c51@mail.gmail.com> Message-ID: <4a951aa00804100122j38be4740q6b6b75a4fdb723e@mail.gmail.com> [Bob] > simplejson would give you an error and tell you exactly where the > problem was, Another good point. Other JSON modules should follow simplejson's lead, and provide access to the location in the document where the lexical or parse error occurred, so that the offending document can be opened in a text editor to determine the source of the problem, and perhaps fix it. This should also apply to "junk" after the document object, i.e. JSON expressions present in the document after the main document has been successfully parsed. A strict interpretation of the spec is that such "junk" is not permitted, and makes the JSON document broken, even though the main object representation is valid. Simplejson has an option for the user to control this, and jyson does too; I don't know about the others. [Bob] > but there isn't currently a non-strict mode and honestly > nobody has asked for it. If we only need "strict mode", then why do all of our parsers have options? Isn't "permissive mode" just a way of setting all of the parse options to liberal, in one go? Alan. From benji at benjiyork.com Thu Apr 10 15:05:05 2008 From: benji at benjiyork.com (Benji York) Date: Thu, 10 Apr 2008 09:05:05 -0400 Subject: [Web-SIG] Time a for JSON parser in the standard library? In-Reply-To: <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> References: <6a36e7290803161147m60a26eeajd514faca98b3e436@mail.gmail.com> <6a36e7290803231449u45f6ed8fm68d6d5c265dfb48e@mail.gmail.com> <5c06fa770803241117y5cf13501h6434f3de778d84fb@mail.gmail.com> <3283f7fe0804051842p1cdd607ay61d8b530038eb02c@mail.gmail.com> <47FCF75A.5080109@colorstudy.com> <3283f7fe0804091214p581f9646lab449fe72e8b7989@mail.gmail.com> <4a951aa00804091748x19f10e74mb5a59a900dd8cb9f@mail.gmail.com> <47FD795C.6020804@colorstudy.com> <3283f7fe0804092004w4f53825bn49f7fab05584e0b@mail.gmail.com> <6a36e7290804092215n6b5bd3bcn4953abea8171338c@mail.gmail.com> Message-ID: <47FE1081.6060200@benjiyork.com> Bob Ippolito wrote: > On Wed, Apr 9, 2008 at 8:04 PM, John Millikin wrote: >> For "exception by default" behavior, the library can call >> warnings.simplefilter ("error", JSONWarning) on initialization. Then >> we just define various subclasses of JSONWarning for the different >> warning types (trailing comma, illegal whitespace, NaN etc). If users >> want to ignore some or all of the warnings, they can specify which (or >> all). Best of all, it wouldn't require long parameter lists. > > That sounds like a really bad idea Indeed. -- Benji York http://benjiyork.com From mdipierro at cs.depaul.edu Thu Apr 24 07:45:41 2008 From: mdipierro at cs.depaul.edu (Massimo Di Pierro) Date: Thu, 24 Apr 2008 00:45:41 -0500 Subject: [Web-SIG] web2py on appengine Message-ID: I thought you may be interested in these two video tutorials 1) how to use web2py on the Google appengine http://www.vimeo.com/932708 2) a minimalist version using only the shell http://www.vimeo.com/933216 (requires version in svn trunk, http://code.google.com/p/web2py)