Re: [Web-SIG] Generator-Based Applications: Marrow HTTPd Example
I like this a lot! On Jan 10, 2011, at 6:25 AM, Alice Bevan–McGregor wrote: Howdy! Here's a rewritten (and incomplete, but GET and HEAD requests work fine) marrow.server.http branch [1] that illustrates a simple application [2] and protocol implementation [3]. Most notably, examine the 'resume' method [4]. The 'basic' example yields a future instance and uses the data as the response body. Note that this particular rewrite is not complete, nor has it been profiled and optimized; initial benchmarks (using the 'benchmark' example) show a reduction of ~600 RSecs from the 'draft' branch, which is substantial, but hasn't been traced to a particular segment of code or design decision yet. The server is now -extremely- easy to read and follow, with all code acting in a linear way. (Application worker threading has been removed from this branch as well; the server is once again purely async.) - Alice. [1] https://github.com/pulp/marrow.server.http/tree/generator [2] https://github.com/pulp/marrow.server.http/blob/generator/examples/basic.py [3] https://github.com/pulp/marrow.server.http/blob/generator/marrow/server/http/protocol.py [4] https://github.com/pulp/marrow.server.http/blob/generator/marrow/server/http/protocol.py#L177-226 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 (aka Web3)
My experience in various communities suggests that naming the new totally-bw-incompat thing the same as the old thing weakens both the new thing and the old thing, I share the same experience. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 (aka Web3)
I fully support it! Massimo On Sep 15, 2010, at 6:03 PM, Chris McDonough wrote: A PEP was submitted and accepted today for a WSGI successor protocol named Web3: http://python.org/dev/peps/pep-0444/ I'd encourage other folks to suggest improvements to that spec or to submit a competing spec, so we can get WSGI-on-Python3 settled soon. - C ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Web Framework
Have you looked into T3? http://www.vimeo.com/2462041 http://web2py.appspot.com/t3/default/wiki/main If you know web2py it is based on it and uses the same syntax. This is an old app, to be considered experimental and we working on a new/improved version for it. https://launchpad.net/t4 Still it may be close to what you are looking for. Massimo On May 31, 2009, at 11:30 AM, Omar Munk wrote: Hello I'm Pynthon and I'm 14 years old. I'm coming from Holland so my English isn't very good. I'm looking for a good Python webframework. I liked Web2Py but it always can be better. I don't need a full admin app included. I just want to code it in my text editor just like PHP. Do you guys know a framework with: A good documentation. Not to overkill like Django Easy and simple Just something like PHP but without the dirty style. I like Karrigell but it looks like it's dead do you know a clone of it? Not need a VPS to host it, just a server that has Python. I know it's almost impposbile but I seached everywhere! And creating your own is that hard? Thanks, Pynthon ATT1..txt ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Web Framework
Hey, this is more complex than web2py:
@bobo.query('/')
def hello():
return Hello world!
In web2py you do not need the first line. ;-)
Massimo
On Oct 5, 2009, at 11:35 AM, Jim Fulton wrote:
On Sun, May 31, 2009 at 12:30 PM, Omar Munk omar.webs...@gmail.com
wrote:
Hello
I'm Pynthon and I'm 14 years old. I'm coming from Holland so my
English
isn't very good. I'm looking for a good Python webframework. I
liked Web2Py
but it always can be better. I don't need a full admin app
included. I just
want to code it in my text editor just like PHP. Do you guys know a
framework with:
A good documentation.
Not to overkill like Django
Easy and simple
Just something like PHP but without the dirty style.
I like Karrigell but it looks like it's dead do you know a clone of
it?
Not need a VPS to host it, just a server that has Python.
I know it's almost impposbile but I seached everywhere! And
creating your
own is that hard?
Bobo's main goal is simplicity:
http://bobo.digicool.com/
Jim
--
Jim Fulton
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Getting back to WSGI grass roots.
Hi Graham, Me being an outsider who contributed nothing to the process, I hope you'll reconsider. I really appreciate your work and I trusted the process more with you in it. Massimo On Sep 23, 2009, at 9:11 PM, P.J. Eby wrote: At 11:47 AM 9/24/2009 +1000, Graham Dumpleton wrote: After almost two years of trying to get WSGI for Python 3.0 to fly, I really do think it is time for me to give up. I did say a while back I would try one last push and this has been it. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
Thank you Armin this makes things clear to me ( a newbie hre). On Sep 22, 2009, at 3:29 AM, Armin Ronacher wrote: - my initial plan was going bytes everywhere. Turns out, on Python 3 this is nearly impossible to do because the majority of the standard library went an unicode path, even where bytes would be more appropriate (like cgi.FieldStorage, urllib.parse etc.) I would have taken the same stand. - Graham, Robert (and now me as well) try to get charset guessing for URLs going, decide on latin1 for the HTTP headers. latin1 could be re-decoded by the application if it really thinks it wanted utf-8 for instance. (Like cookie headers, only I guess only there) If wsgi guesses the charset before will the application always be able to derive the original strings? - One idea is enforcing unicode for all Python versions - One idea is going unicode for Python 3 and bytestrings for Python 2 For what it matters I prefer the latter option. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
+1 On Sep 22, 2009, at 10:45 AM, Armin Ronacher wrote: Hi, And Clover schrieb: This is absolutely the opposite of what I want as an application author. I want to hand out my WSGI application that uses UTF-8 and know that wherever it is deployed the non-ASCII characters will go through without getting mangled. I could not agree more. Probably the best way is indeed using native strings for each Python version, where native strings are unicode the server should latin1 decode it and SCRIPT_NAME / PATH_INFO will be called wsgi.raw_script_name and wsgi.raw_path_info and be properly quoted. Regards, Armin ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO
Hello Ian,
I really like your proposal.
Massimo
On Sep 22, 2009, at 9:22 PM, Ian Bicking wrote:
OK, I mentioned this in the last thread, but... I can't keep up with
all this discussion, and I bet you can't either.
So, here's a rough proposal for WSGI and unicode:
I propose we switch primarily to native strings: str on both
Python 2 and 3.
Specifically:
environ keys: native
environ CGI values: native
wsgi.* (that is text): native
response status: native
response headers: native
wsgi.input remains byte-oriented, as does the response app_iter.
I then propose that we eliminate SCRIPT_NAME and PATH_INFO. Instead
we have:
wsgi.script_name
wsgi.path_info (I'm not entirely set on these names)
These both form the original path. It is not URL decoded, so it
should be ASCII. (I believe non-ASCII could be rejected by the
server, with Bad Request? A server could also choose to treat it as
UTF8 or Latin1 and encode unsafe characters to make it ASCII) Thus
to re-form the URL, you do:
environ['wsgi.url_scheme'] + '://' + environ['HTTP_HOST'] +
environ['wsgi.script_name'] + environ['wsgi.path_info'] + '?' +
environ['QUERY_STRING']
All incoming headers will be treated as Latin1. If an application
suspects another encoding, it is up to the application to transcode
the header into another encoding. The transcoded value should not
be put into the environ. In most cases headers should be ASCII, and
Latin1 is simply a fallback that allows all bytes to be represented
in both Python 2 and 3.
Similarly all outgoing headers will be Latin1. Thus if you (against
good sense) decide to put UTF8 into a cookie, you can do:
headers.append(('Set-Cookie',
unicode_text.encode('UTF8').decode('latin1')))
The server will then decode the text as latin1, sending the UTF8
bytes. This is lame, but non-ASCII in headers is lame. It would be
preferable to do:
headers.append(('Set-Cookie',
urllib.quote(unicode_text.encode('UTF8'
This sends different text, but is highly preferable. If you wanted
to parse a cookie that was set as UTF8, you'd do:
parse_cookie(environ['HTTP_COOKIE'].encode('latin1').decode('utf8'))
Again, it would be better to do;
parse_cookie(urllib.unquote(environ['HTTP_COOKIE']).decode('utf8'))
Other variables like environ['wsgi.url_scheme'],
environ['CONTENT_TYPE'], etc, will be native strings. A Python 3
hello work app will then look like:
def hello_world(environ):
return ('200 OK', [('Content-type', 'text/html; charset=utf8')],
['Hello World!'.encode('utf8')])
start_response and changes to wsgi.input are incidental to what I'm
proposing here (except that wsgi.input will be bytes); we can decide
about themseparately.
Outstanding issues:
Well, the biggie: is it right to use native strings for the environ
values, and response status/headers? Specifically, tricks like the
latin1 transcoding won't work in Python 2, but will in Python 3. Is
this weird? Or just something you have to think about when using
the two Python versions?
What happens if you give unicode text in the response headers that
cannot be encoded as Latin1?
Should some things specifically be ASCII? E.g., status.
Should some things be unicode on Python 2?
Is there a common case here that would be inefficient?
--
Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
ATT1..txt
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
+1 On Sep 21, 2009, at 8:28 PM, Mark Nottingham wrote: +1. There is no one answer for these issues (e.g., URI-IRI conversion can lose information), so low-level infrastructure like WSGI shouldn't be making choices for people. On 22/09/2009, at 5:31 AM, P.J. Eby wrote: At 11:23 AM 9/21/2009 -0700, Robert Brewer wrote: I still don't see why the environ should have multiple versions of anything. It's not as if the HTTP request gives us multiple Request- URI's. There's a single processing step that has to happen somewhere: decoding the bytes of the Request-URI to unicode. For the vast majority of apps, it should only happen once. Twice is acceptable to me for some apps. As I pointed out in the linked email, doing that as soon as possible (i.e. in the WSGI origin server) allows URI's to be compared as character strings more easily. If you deploy a piece of middleware that transcodes (based on more information than servers want to deal with), it had better be nearly first in the stack so routing works reliably. The problem with this whole approach is that it's not composable. You can't stick in an application under a router that uses a different method for grokking its subtree of the URI space, unless it knows what's been done to the URI and can un-do it. Maybe I'm missing something here, but the only way I see to preserve composability here is to use latin-1 or bytes. The fundamental problem is that, like it or not, HTTP headers are actually byte strings. The *only* reason we ever supported unicode in WSGI was to handle platforms where there's no such thing as a non- unicode string, and there we made it explicit that it's just a way of manipulating *bytes*, not unicode. ISTM that very few (if any) of the proposals floating around for modifying WSGI are taking this concept into account. Most of them sound to me like people saying, yeah, but this particular hack will work for *my* apps... so everybody else must be doing something stupid. But WSGI was built on the principle of *equally inconveniencing everyone*, specifically to avoid an impossible attempt at consensus between incompatible ways of doing things. (E.g., nine million request/response APIs.) So, if the only problem we're going to cause by using bytes everywhere is to make everyone need to change their routing code on Python 3, I vote +1000. ;-) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/mnot%40mnot.net -- Mark Nottingham http://www.mnot.net/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Request for Comments on upcoming WSGI Changes
+1 On Sep 20, 2009, at 11:25 PM, Chris McDonough wrote: I'll try to digest some of this, currently I'm pretty clueless. Personally, I find it a bit hard to get excited about Python 3 as a web application deployment platform. This is of course a personal judgment (I don't mean to slight Python 3) but at this point, I'll think I'll probably be writing software that targets 2.X exclusively for at least the next five years. Given this point of view, it would be extremely helpful if someone could explain to people with the same outlook why we should want to deal with Unicode strings in any WSGI specification. WSGI is a fairly low-level protocol aimed at folks who need to interface a server to the outside world. The outside world (by its nature) talks bytes. I fear that any implied conversion of environment values and iterable return values to Unicode will actually eventually make things harder than they are now. I realize that it would make middleware implementors lives harder to need to deal in bytes. However, at this point, I also believe that middleware kinda should be hard. We have way too much middleware that shouldn't be middleware these days (some written by myself). Anyway, for us slower (and maybe wrongly fearful) folks, could someone summarize the benefits of having a WSGI specification that requires Unicode. Bonus points for an explanation that does not boil down to it will be compatible with Python 3. - C Armin Ronacher wrote: Hello everybody, Thanks to Graham Dumpleton and Robert Brewer there is some serious progress on WSGI currently. I proposed a roadmap with some PEP changes now that need some input. Summary: WSGI 1.0 stays the same as PEP 0333 currently is WSGI 1.1 becomes what Ian and I added to PEP 0333 WSGI 2.0 becomes a unicode powered version of WSGI 1.1 WSGI 3.0 becomes WSGI 2.0 just without start_response WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python 3 because of changes in the standard library that no longer work with a byte-only approach. The PEPs themselves are here: http://bitbucket.org/ianb/wsgi-peps/ Neither the wording not the changes in there are anywhere near final. Graham wrote down two questions he wants every major framework developer to be answered. These should guide the way to new WSGI standards: 1. Do we keep bytes everywhere forever in Python 2.X, or try to introduce unicode there at all to at least mirror what changes might be made to make WSGI workable in Python 3.X? 2. Do we skip WSGI 1.X completely for Python 3.X and go straight to WSGI 2.0 for Python 3.X? I added a new question I think should be asked too: 3. Do we skip WSGI 2.0 as specified in the PEP and go straight to WSGI 3.0 and drop start_response? The following things became pretty clear when playing around with various specifications on Python 3: - Python 3 no longer implicitly converts between unicode and byte strings. This covers comparisons, the regular expression engine, all string functions and many modules in the stdlib. - The Python 3 stdlib radically moved to unicode for non unicode things as well (the http servers, http clients, url handling etc.) - A byte only version of WSGI appears unrealistic on Python 3 because it would require server and middleware implementors to reimplement parts of the standard library to work on bytes again. - unicode support can be added for WSGI on both Python 2.x and Python 3.x without removing functionality. Browsers are already doing a similar encoding trick as proposed by Graham Dumpleton to handle URLs. - Python 2.x already accepts unicode strings for many things such as URL handling thanks to the fact that unicode and byte strings are surprisingly interchangeable. - cgi.FieldStorage and some other parts is now totally broken on Python 3 and should no longer be used in 3.0 and 3.1 because it reads the response body into memory. This currently affects WebOb, Pylons and TurboGears. I sent this mail to every major framework / WSGI implementor so that we get input even if you're missing the discussion on web-sig. Regards, Armin ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/chrism%40plope.com ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cs.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] python3 wsgi. Re: WSGI 1 Changes [ianb's and my changes]
Charming as ever. ;-) the code had a typo , sorry, I fixed it. http://web2py.com/examples/static/sneaky.py http://web2py.com/examples/static/sneaky3.py I am not making a statement about any of the proposals. I am just saying: here is a multithreaded web server that works with python 3.0 in less than 300 lines of code. it can be used for testing ideas. I acknowledge you are the wsgi experts, that is why I sent it t you. If you have any specific critique that will make it better, please let me know, or just ignore me. It is a work in progress (its features and speed and discussed in the doc string) and I hope it can be useful. Massimo On Sep 19, 2009, at 3:55 AM, Armin Ronacher wrote: Hi, Massimo Di Pierro schrieb: I liked your idea very much Rene' , so I made this Can you please stop that before you do any more damage? Your code is not even anywhere close to what was discussed and has tons of errors and ugly bits and pieces in there. Again. An example does not bring us anything because we already know the implications of each proposal. Regards, Armin ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Unicode in Python 3
I agree
I was forced to write two files. The problems where
1)
b'' vs ''
(could be solved using eval('b') if python3 else eval()
but ugly)
2)
try:...:except Exeption,e: vs try:...except Exception as e.
(no way around it)
3)
it would have required a lot of if statements to convert str-
bytes because bytes do have .find.
(it is not a technical problem but makes code way less readable).
On Sep 19, 2009, at 9:01 AM, René Dudfield wrote:
On Sat, Sep 19, 2009 at 2:26 PM, Georg Brandl g.bra...@gmx.net
wrote:
René Dudfield schrieb:
Here is a snippet from the compat.py we used to port pygame to
support
python2.3 through 3.1
How is that related?
Rather than using a 2to3 tool - which then makes you have two
versions
of your code, making the code work in python 2.x and 3.x. 2to3
outputs python2.x incompatible code - when it doesn't have to.
Sorry, but I think you do not express the intent of 2to3 correctly
here.
It is not meant to provide a one-time conversion, so that you then
have to maintain two codebases, it is meant to be run over your 2.x
code
every time you want to distribute a version for Python 3, or even
transparently in the distutils build process. This of course means
that
the 2.x code needs to be written with 3.x and the conversion in mind.
My point is: using b'' stops those that choose to have one code base.
Not everyone can use 2to3, but for those that can: great!
There is no 2to3 for extension modules. There is no 2to3 distutils
mod to run 2to3 automatically at this time(correct me if I'm wrong).
People are creating separate branches for py3k... and those projects
that do that seem to let the py3k version rot. You still need to
debug, and support multiple versions of code... since 2to3 generates
multiple versions. If someone sends you a patch for the 3.0 version
you need to either reverse it yourself or find someone to do it for
you... same thing with bug reports and tracebacks.
There's some points for why 2to3 is not ok for every project.
Writing code that runs unchanged on 2.x (where x 6) and 3.x may
seem
nice, but forces you to do unnecessary workarounds, e.g. in exception
handlers.
Well, I'm sure there are cases where it would cause unnecessary
workarounds... however with the right compat.py and compat.h setup it
hasn't been too hard in my experience in porting this way.
There is an easy workaround for the exceptions changes...
# define geterror in your compatibility module.
def geterror ():
return sys.exc_info()[1]
Now you can write:
except ImportError:
e = geterror()
Instead of these:
#py2
except ImportError, e:
pass
#py3k
except ImportError as e:
pass
Arguments against using bytes (and using unicode instead).
So I'm -1 on using b'' all over the place since it's not in both
versions of python, and makes it impossible for code bases to
share
the same code for multiple versions of python.
That would not matter much because the high-level applications
never see
what's under the hood. Besides web2py all frameworks and
libraries I
know about are using unicode internally anyways.
It would mean code bases need to support b'' - which is not
compatible
with python2.
b'' is supported as of Python 2.6.
Georg
ah yes. I guess I meant the python2 series. Python2.5 is still the
most popular python... with 2.6 catching up(or passing it) in
popularity. So that should be changed to:
It would mean code bases need to support b'' - which is not
compatible with = python2.5.4
... anyway, just something to consider.
ps. my facebook account on this email address was just banned. I
swear I didn't rant about how tornado sucks!
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] web2py on appengine
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) ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] google appengine
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 ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Time a for JSON parser in the standard library?
I agree. simplejson is used by web2py as well. Massimo On Mar 10, 2008, at 8:37 AM, Mark Ramm wrote: Is it time there was a JSON codec included in the python standard library? I would definitely support the incusion of a JSON library in the standard lib. And, I think that it should be simplejson which is used by TurboGears, Pylons, and bundled with Django. Choosing a Python JSON Translator http://blog.hill-street.net/?p=7 This blog is a year old, and isn't quite accurate anymore. in particular simplejson sprouted some optional C code, and is now a lot faster. --Mark Ramm ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Time a for JSON parser in the standard library?
It would also be nice to have a common interface to all modules that do serialization. For example pickle, cPickle, marshall has dumps, so json should also have dumps. Massimo On Mar 10, 2008, at 9:51 PM, Mark Ramm wrote: Well, so fix this. How hard can it be? A google search for jsonlib rfc turns up this article: http://jmillikin.blogspot.com/2008/02/python-json-catastrophe.html And it looks like the two issues with simplejson are: 1) decoding JSON with unicode code-points outside the Basic Multilingual Plane 2) Decoding the json 1.1 as a python float rather than a decimal I think the author could very well be incorrect in believing that the spec requires using a decimal, so that just leaves the Unicode issue, which isn't very clearly defined in the article, but ought to be reasonably easy to fix. The spec isn't as clear as it could be about a lot of issues, but I've had no problems with simplejson and interoperability with the various javascript libraries. I've also used simplejson with one or two of the ruby json libraries, flex's json lib, and a couple of libraries for other languages, with no particular issues. That's not to say there are no bugs, but I don't think there are too many issues buried in there. --Mark ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] new in trunk. please read
There is a new version in code.google.com/p/web2py trunk. For Niccolo: I think I fixed the problem with uploading large files. Could you please run some tests to confirm memory usage. For voltron: The pidfile is now deleted on exit. Mind that in your pyamf hander you have to replace request.body with request.body.read() Now request.body is a temporary file to deal with large inputs. For anybody using XMLRPC: Do not use the example appliance. Use def handler(): response.xmlrpc(request,methods) where methods is the list of exposed methods. If not clear, ASK ME. For my students: you get points if you test this and report bugs/typos/correction/etc (or just confirm that nothing breaks) by Monday. The GUI now shows a graph of incoming requests. Use web2py.py -h for help on how to use SSL/HTTPS. Massimo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] wsgiref for python 2.4?
Could somebody discuss pros and cons of cherrypy wsgiserver vs paste httserver? Massimo On Feb 7, 2008, at 10:53 AM, Adam Atlas wrote: http://pypi.python.org/pypi/wsgiref It wouldn't hurt to look at CherryPy's WSGIServer anyway. I think it's generally a lot more efficient/scalable than the BaseHTTPServer-based implementation in wsgiref, and it's reasonably lightweight (one .py file, 1311 lines). http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver/__init__.py On 7 Feb 2008, at 11:48, Chris Withers wrote: Hi All, The subject line kindof says it all, but is there a wsgiref for python 2.4? Failing that, what's the lightest-weight wesgi server available for python 2.4? cheers, Chris ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] web2py 1.20 is out
web2py 1.20 is out. www.web2py.com New features include the inclusion of a web based testing framework - a screenshot is here: http://web2py.googlegroups.com/web/test.tiff pyamf howto, rest support, handler for lighttpd/fcgi, WIKI helper, etc. AND it is always backward compatible. The source code is also on code.google.com/p/web2py Here are a dozen of ready made applications which you can install from the web interface. http://mdp.cti.depaul.edu/appliances Massimo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Removal of Cookie in Python 3.0 OK?
web2py uses it cookie too but probably it would not take much to port it to cookielib. It would be great if you could provide an example of usage of cookielib.Cookie vs cookie.SimpleCookie. In particular, I cannot find any example of how to serialize a cookielib.Cookie into the corresponding http header entry. Massimo On Feb 3, 2008, at 5:58 PM, René Dudfield wrote: Here's some usages of Cookie that show quite wide use still: http://www.google.com/codesearch?q=lang%3Apython+%22import+Cookie%22 From the first few pages: mailman, zope, trac, roundup, cherrypy, chandler, turbogears, myghty, paste, moin, mod_python etc. Not that that's the only reason why you wouldn't remove it... just backing up Ians assertion that Lots of web frameworks use it. cu. On Feb 4, 2008 10:41 AM, Ian Bicking [EMAIL PROTECTED] wrote: Brett Cannon wrote: As part of the standard library cleanup for Python 3.0, it has been suggested to me that the Cookie module be removed. The rationale for this is that most of the module is already deprecated and cookielib does a better job for cookie support anyway. I just wanted to see if anyone here had strong objections (along with reasons) as to why the module should be kept around in some form or another. I think most frameworks still use the Cookie module. The cookielib module is more oriented to the client side. It doesn't seem to have the same parsing functions that you'd use on the server side (though maybe they are there and just not documented because they also exist in the Cookie module). Ian ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/renesd% 40gmail.com ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ mdipierro%40cti.depaul.edu ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] cwd and mod_wsgi
Does anybody know how to change the current working directory in apache with mod_wsgi? Thanks Massimo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Gluon 1.12
Hello everybody. Just wanted to let you know that Gluon 1.12 (GPL2) is out with lots of new stuff: better database administrative interface, JSON, CSV, RTF, RSS, etc. (find examples in the web page) http://mdp.cti.depaul.edu We also have a google group: http://groups.google.com/group/gluon?hl=en a wiki: http://www.bithawk.net/cgi-bin/moin.cgi/GluonNotes a youtube video: http://www.youtube.com/watch?v=VBjja6N6IYk and a cookbook tutorial: http://mdp.cti.depaul.edu/examples/static/ cookbook.pdf and a sample controller for registration/authentication: http:// gluon.googlegroups.com/web/identity.py Notice: The Linux version requires Python2.5 and sqlite3 or postgresql. The Windows and Mac binary version should have no dependencies. Thanks to everybody who is contributing. Massimo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Gluon again
You probably refer to the fact that validators and helpers are upper case. That is because they are not functions but objects. In fact validators have an internal state (the parameters for the validation, the translated error messages etc.) and helpers have an internal state (because they are aware of form they may contain, their variables and their errors). Example a=FORM(TABLE(TR(TD(INPUT(_name='field',requites=IS_NOT_EMPTY(,TR (TD(INPUT(_type='submit') if a.accepts(request.vars,session): if a.errors:... At its fundamental level I tried to make Gluon similar to Django. For two reasons. I know Django (I taught a class on Django here ad DePaul) and I liked it but I found it has too many functions and too many modules to remember. So I decided to follow a convention over configuration approach a la RoR. In Gluon you do not need to import Gluon's modules in your code nor you need to explicitly call the template renderer, for example. Same logic as Django but simpler to use I believe. Massimo To answer your first question: I teach computer science, mostly numerical applications to science and finance, occasionally networking stuff and security. You can say I came from a C++ background. My most important work is fermiqcd a C++ library of parallel lattice quantum chromodynamics. On Oct 22, 2007, at 11:57 PM, Joshua Simpson wrote: On 10/22/07, Massimo Di Pierro [EMAIL PROTECTED] wrote: it shows step by step how to build a web app to store recipes and group them by category. It is a first draft so there are may be some english some typos. Sorry. I'm going to check this out. Are you from a primarily C background? Your builtin functions look, at least in naming convention, suspiciously like macros. Your controller design seems to borrow heavily from Django, but I suppose that's a good thing. Cheers, I always like to look at new frameworks. Josh -- - http://stderr.ws/ ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Gluon again
I posted a Gluon tutorial here http://mdp.cti.depaul.edu/examples/static/cookbook.pdf it shows step by step how to build a web app to store recipes and group them by category. It is a first draft so there are may be some english some typos. Sorry. Massimo P.S. I'll never stress it enough. Gluon is GPL2, it is not a commercial product. The reason I am emailing you about this is because I know I can find experts here and I hope you can help me find bugs so that I can fix them and improve Gluons. If there is functionality that you need and you think is not there, just let me know and I will see what I can do. I would also love to see an ajax enthusiast take the challenge to write the first ajax app using Gluon, scriptaculous and json. I do provide some free email support if you sign up on the Gluon google group. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Gluon 1.6
I have a new version of Gluon out (known bugs fixed) and a video http://www.youtube.com/watch?v=VBjja6N6IYk Thank you to those who expressed interest. I would like to stress that this is a open source project released under GPL2 and I could really use community input to make it better (for example I did not have time to test it with mod_wsgi, I use paste httpserver). I say this since the project wikipedia page has been shut down, claiming this is a commercial product, which is not. Massimo ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
