IRC Logs

2008 9
Mo	Tu	We	Th	Fr	Sa	So
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30
◀	◂		▸	▶

<ph>

hi

<ph>

i'm delivering a Response(mimetype="application/csv") with werkzeug, is it possible to set a filename which will be shown to the user in the save dialog?

[08:04:26]

<plaes>

try adding filename=xxx

[08:05:01]

<plaes>

hrm.. wait

[08:06:24]

<ph>

filename does not work, but response.headers["Content-Disposition"] = "attachment;filename=somefile.csv" did the trick

[08:07:46]

<plaes>

yeah, I was trying to find a correct way to do it :P

[08:09:20]

<ph>

thanks anyway

[08:19:29]

<plaes>

hum.. what's a best way to install werkzeug on debian machine?

[08:30:04]

<ph>

debian testing has a package python-werkzeug which is the current 3.1 version

[11:13:31]

<plaes>

mitsuhiko: wasn't inyoka supposed to be open in September?

[11:14:45]

<hads>

It's still September :)

[11:15:06]

<plaes>

yeah, but I want to know what my options are :P

[11:29:51]

plaes: no options! muakakaka

[11:37:18]

isn't it eternally september?

[11:37:28]

~only in my heart~

[11:48:39]

asmodai: you're becoming strange as of late...

~can't it be love?~

probably

:D

it could also be drugs, so you might want to be cautious

[11:57:45]

No drugs for me matey.

[12:19:03]

birkenfeld: http://www.alexa.com/data/details/traffic_details/bitbucket.org?site0=bitbucket.org&site1=github.com&site2=pocoo.org&y=r&z=3&h=300&w=470&c=1&u[]=bitbucket.org&u[]=github.com&u[]=pocoo.org&x=2008-09-07T10%3A22%3A56.000Z&check=www.alexa.com&signature=bGXzaCdqEu0dGmC2hPCtGTXtqR0%3D&range=6m&size=Medium ^^

[12:19:04]

pocoo über alles

[12:27:02]

<mq>

mitsuhiko: pong (I was on a school trip the last few days)

[12:27:14]

wb mq :)

[12:27:21]

mitsuhiko: nice :)

[12:28:08]

mq: have you thought about utils.xxx while i was away?

[12:28:16]

because i want to get rid of that this week if possible

[12:29:45]

<mq>

mitsuhiko: no, I'nm not really into form handling. I have to take some time to learn wtforms etc soon, and was too busy last week.

[12:30:29]

<mq>

I hope that changes soon, so far this school year is really stressful -_-

[12:34:57]

is it possible to take a bsd library, adapt it and license the adaptation as gpl?

[12:35:22]

<mq>

I think it is.

[12:36:39]

isn't our licensing guy here?

[12:40:04]

mq: if you want to implement something simple: create a script that spell checks all translatable strings :)

[12:43:24]

mitsuhiko: actually, I like utils.xxx as a module name :)

[12:44:20]

:-)

[12:54:49]

<prencher^>

mitsuhiko - you can do whatever you want as far as relicensing BSD stuff, as long as you still attribue the original work to the original authors

[12:55:12]

<prencher^>

releasing your modifications as GPL to a BSD library is also thoroughly being a dick but that's another matter

[12:55:30]

<prencher^>

(see also the whole wifi thing between bsd and linux)

[12:59:55]

i'll be a dick in that case then :)

[13:00:33]

djangos forms?

[13:01:10]

dennda: diva forms

[13:01:17]

and elements of wtforms

[13:01:32]

prencher: btw. is the wtforms website down?

[13:01:55]

mitsuhiko: ah didn't now that diva had a form lib

[13:02:31]

apollo13: http://paste.pocoo.org/show/84644

[13:02:34]

mitsuhiko - why would you relicense it as GPL?

[13:02:45]

that's what I am asking too

[13:02:46]

prencher: because it's part of zine

[13:02:51]

prencher: and?

[13:02:58]

and will be tightly integrated into the rest of zine

[13:02:59]

ahm mitsuhiko: and?

[13:03:15]

<aa_>

cool, what software are we talking about?

[13:03:20]

apollo13: what's the point of BSDing then?

[13:03:25]

well if you can leave it as lib, there is now problem with leaving it as bas

[13:03:25]

<aa_>

the thing that will be re-released

[13:03:26]

bsd*

[13:03:37]

mitsuhiko: the point is that others can use this lib

[13:03:39]

apollo13: no. it's not a library :)

[13:03:48]

zine not

[13:03:52]

but the form lib can be

[13:03:58]

apollo13: no. too complex

[13:04:00]

<aa_>

ooh a new form lib

[13:04:02]

all that i18n and event emitting

[13:04:04]

mitsuhiko - that's a use case i can accept personally, and why I personally prefer BSD (it allows suchs things)

[13:04:12]

as long as you give credit it's fine by me

[13:04:26]

a big statue or something

[13:04:27]

:-)

[13:04:29]

prencher: well I think bsd is fine for lib but not enduser apps ;)

[13:04:44]

as for the website, it's on bitbucket for the time being (we've been flopping servers around for a bit, but putting up hg/trac on our own again soon)

[13:05:17]

apollo13 - sure, what im saying is that i think the use case mitsuhiko is presenting for relicensing the code is fine

[13:05:23]

as he's tightly integrating it, not just extending the library

[13:05:30]

yeah in that case

[13:05:38]

mitsuhiko: how is diva forms?

[13:05:44]

<aa_>

but he should extend it so we can all tightly integrate it without doing any work

[13:05:58]

<aa_>

and release that as BSD

[13:06:01]

<aa_>

mitsuhiko: shame on you!

[13:06:04]

apollo13: it has some interesting elements like validator nesting

[13:06:11]

<aa_>

mitsuhiko: forcing the rest of use to write code!

[13:06:12]

mitsuhiko - http://www.bitbucket.org/prencher/wtforms/wiki/Home

[13:06:22]

prencher: thanks. found it

[13:06:33]

so what to use for inyoka: django forms vs diva forms vs wtforms? (maybe vs formencode too)?

[13:06:35]

;)

[13:06:57]

oh come on, formencode is horrible

[13:07:20]

dunno never looked at it

[13:07:34]

mitsuhiko - got a link to diva forms?

[13:08:03]

prencher: http://code.cmlenz.net/diva/browser/trunk/diva/forms.py

[13:08:09]

and guess what i will change :)

[13:08:31]

data allows lists?

[13:08:46]

ähm multidicts

[13:08:54]

<mq>

genshi deps

[13:09:07]

oh that one.. yeah ive seen that one

[13:09:14]

i find its validation system weird

[13:09:16]

mq: stripped that already

[13:09:27]

<aa_>

prencher: about wtforms, can I get the data out of a form as a dict?

[13:09:40]

aa_ - uh...

[13:09:43]

form.data?

[13:09:46]

<aa_>

prencher: like thae validated converted data

[13:09:52]

^

[13:10:07]

<aa_>

prencher: man your api sucks

[13:10:14]

much like your mom

[13:10:22]

<aa_>

yeah yeah

[13:10:25]

<aa_>

but it does

[13:10:36]

formencode over there ->

[13:10:59]

<aa_>

yeah ok, but sucking less than formencode is not exactly "landing a man on mars" :)

[13:11:20]

:)

[13:11:28]

<aa_>

prencher: still, no uniformity.

[13:11:31]

guess who i'm trying to please with wtforms? i aint you, ill give you that hint

[13:11:39]

the people it's designed for, lovei t

[13:11:53]

<aa_>

prencher: yeah and my pet monkey like peanuts

[13:12:07]

<aa_>

prencher: but still, the API is confusing

[13:12:23]

<aa_>

can I set data directly?

[13:12:47]

<aa_>

and how do I get the raw form data?

[13:13:26]

form.data gives you a dict of all data fields, and field.data retrieves / manipulates data for each field? i see no confusion

[13:13:50]

mitsuhiko: I guess I dislike the validator approach, I still think there should be fields... think of widgets etc...

[13:14:05]

apollo13: yep. that's what i integrate right now

[13:14:12]

just that i drop widgets

[13:14:18]

for now?

[13:14:33]

I guess I might like zine.forms

[13:14:34]

<aa_>

apollo13: what is the field vs validator approach?

[13:14:36]

and like i've told you, data will be stored on the form purely going forward

[13:15:01]

<aa_>

prencher: well, I always get confused

[13:15:32]

aa_: look at the diva.forms example username = TextValidator(required=True) <-- how should this get displayed? as radiobutton?

[13:15:50]

it deals only with validation currently

[13:15:57]

<aa_>

apollo13: well, traditional thinking says that Validation and Display should be separate

[13:15:58]

you will need to write the whole html yourself

[13:16:27]

mitsuhiko: I'll update that page shortly; just wanted to drop what came to my mind when following the discussion: one thing I had in mind was a widget that allowed users to enter their jabber adress and get informed about new posts / new comments (not everybody has a feed reader)

[13:16:30]

still I like to have fields which do the validation and can be displayed too

[13:16:51]

<aa_>

apollo13: well, either you end up with 1. no html, 2. something that does some rendering eg wtforms, or 3. a mess like toscawidgets

[13:16:57]

does anybody think that is a valid use case? :-)

[13:17:14]

apollo13: i think instead of widgets i just provide templates:

[13:17:16]

aa_: I like option 2

[13:17:25]

{% from '_widgets.html' import input_field, radio_button %}

[13:17:34]

[13:17:35]

or something

[13:17:37]

<aa_>

apollo13: point is 2. can never cover all the options, and in some cases you end up using 2. like 1. anyway

[13:17:48]

<aa_>

mitsuhiko: that's what I mostly do

[13:18:09]

that's the approach wtforms takes as well.

[13:18:17]

aa_: indead, that's what we ended doing in inyoka, you are right armin's approach might be the best one

[13:18:21]

apollo13: with widgets you mean that {{ form.foo }} automatically renders into the widget. right?

prencher: 2 or 1?

both

mitsuhiko: yeah

__call__ is there to allow you to easily define such macros

[13:18:55]

(it'll create the most basic element it can, and fill e.g. id, name, value)

[13:19:00]

and extend it via kwargs

[13:19:10]

<aa_>

prencher: yeah but that's a bit nasty

[13:19:23]

<aa_>

template macros are the best thing for that I reckon

[13:19:24]

in your mind it is, for the rest of the real world its clean

[13:19:30]

<aa_>

prencher: maybe

[13:19:35]

<hads>

Seems to work for me.

[13:20:01]

<aa_>

prencher: so, how is wtforms coming along? ;)

[13:20:17]

<aa_>

prencher: form composition and nesting?

[13:21:00]

i implement stuff as i need it on the sites i develop

[13:23:51]

<aa_>

prencher: "open source developer bullshit excuse"?

[13:25:16]

why is it an excuse? i'm not developing this library for ANYBODY but myself and my team, i opensourced it *only* so a few people in here asking about it could use it if they wanted

[13:25:41]

<aa_>

prencher: nah wasn't being serious, it's just something you said to me once in an identical situation

[13:26:14]

<aa_>

prencher: and if it held then it holds now, so you can choose whether it does or doesn't :)

[13:27:31]

the difference is in your case it was about something you tried to push on others, people that use wtforms use it because they liked what i told them about it

[13:27:57]

<aa_>

prencher: nah, I am too old to push things on others.

[13:28:18]

calm down guys

[13:28:42]

<aa_>

mitsuhiko: nah, I think we are calm

[13:29:03]

it's okay mitsuhiko, he's just sulking because he didn't like what i said about *mmer!

[13:29:04]

<aa_>

mitsuhiko: but seriously, if you write wtforms+jinja integration, please don't GPL it :)

[13:29:12]

GPL is teh suck

[13:29:20]

*drive by comments*

[13:29:20]

for libraries i agree

[13:29:24]

not so for applications

[13:29:48]

mitsuhiko - wtforms.ext.jinja macro set? most welcome

[13:30:04]

<aa_>

prencher: so not true! :P glashammer (as wtforms) is internal to my company. I thought I was doing you a favour, but that's all. You hate it - fine. :)

[13:30:06]

if you build them like that, ill be happy to make them generic

[13:30:55]

asmodai: -V-/

[13:31:25]

<aa_>

yes wtforms.ext.jinja sounds perfect

[13:31:58]

<aa_>

except it won't work of course,because the features will be way outside the scope of wtforms (am guessing)

[13:32:15]

<aa_>

eg events, javasscript etc etc

[13:32:26]

<aa_>

i18n,

[13:32:38]

probably

[13:32:52]

<aa_>

having said that... they would fit perfectly into glashammer!

[13:33:05]

i did plan on writing some more general macros for jinja to come bundled

[13:33:29]

but yes, i ran into the same "issue"

[13:33:51]

it's just easier to use the __call__ rendering and then extend it with macros on a per-app basis

[13:34:08]

<aa_>

yeah, but I am too lazy for that

[13:34:27]

<aa_>

I wonder what java web developers use for forms

[13:34:35]

trust me

[13:34:38]

you do NOT want to know

[13:34:48]

<aa_>

prencher: can you give me a googleable term?

[13:34:50]

no really, forget you ever said that

[13:34:56]

<aa_>

or do I really really not want to know

[13:35:00]

<aa_>

oh ok

[13:35:30]

<aa_>

just going on a thing Eby wrote that "when trying to design an enterprise library, first always check how the java boys did it"

[13:35:47]

<aa_>

seems like sensible advice

[13:38:20]

and then do the opposite?

[13:38:36]

<aa_>

prencher: well, that wasn't his advice, but something like that, maybe

[13:38:49]

prencher: do you work with jee?

[13:38:53]

<aa_>

anyone used mod-wsgi on nginx

[13:39:04]

mitsuhiko: So: I keep a list of all notification systems, too. Except I didn't do that in the application but add an extra class "Listener" that keeps track of what notification system wants to be notified on what events

[13:39:05]

mitsuhiko - earlier in the year, unfortunately

[13:39:40]

aa_ - it can only handle one request at a time, just forget about it :)

[13:40:13]

<aa_>

prencher: yeah so I saw, but is that for real

[13:40:28]

<aa_>

like can't it multithread itself?

[13:41:54]

aa_ - nginx is pure event based

[13:43:11]

<aa_>

oh I see

[13:43:41]

<aa_>

classic use-case where pure event systems fail

[13:43:50]

<aa_>

when they have to call arbitrary blocking code

[13:43:55]

aa_ - the issue is, if the wsgi app blocks, the entire nginx app will block, so that given worker cant accept any more work

[13:44:02]

<aa_>

yeah

[13:44:19]

<aa_>

so can't you have 1. many workers, and 2. run the wsgi app in a thread

[13:44:20]

and if i recall, grumpy said a wsgi requst will always block (due to pythons design - though could be wrong)

[13:44:29]

<aa_>

yeah wsgi blocks

[13:44:57]

<aa_>

even twisted wsgi support has to call the wsgi app in a thread and wait

[13:45:05]

<aa_>

but no reason nginx shouldn't do the same

[13:45:26]

im not sure to be honest.. nginx mod_wsgi might perform as well as apache in prefork mod_wsgi embedded

[13:45:49]

i just distinctly recall there being some other issues, but i cant recall the specifics

[13:46:40]

it might make a very lightweight replacement for proxied apache prefork if that's not the case

[13:47:10]

but basically like twisted, you have to design your apps to be async through and through to work well with mod_wsgi

[13:47:13]

<aa_>

"proxied apache prefork" ?

[13:47:22]

<aa_>

am so cluless about web servers

[13:47:33]

mitsuhiko: in the example design you sketched: who calls the notify() function?

[13:47:36]

aa_ - sure, a lot of setups run a nginx in front, or another load balancer

[13:47:46]

and then proxy to an apache acting as an application server

[13:47:52]

<aa_>

oh

[13:48:07]

<aa_>

prencher: is that better than just using apache?

[13:48:08]

this prevents apache from melting the server

[13:48:14]

<aa_>

oh

[13:48:24]

oh apache as a frontend purely is perfectly fine

[13:48:28]

if you can give it some 400mb+

[13:48:32]

..nginx needs 3

[13:48:33]

<aa_>

yeikes

[13:48:44]

<aa_>

prencher: do you use mod-wsgi ?

[13:48:53]

<aa_>

prencher: I mean apache

[13:48:56]

and that frees up a good chunk of extra memory for extra instances of apache as an app platform

[13:48:57]

yup

[13:49:09]

<aa_>

prencher: how much ram in your server?

[13:49:20]

ive been using it since the first release grumpy made, so.. :P

[13:49:23]

dennda: the zine core or a zine plugin

[13:49:27]

<aa_>

prencher: I have 256 on this VM, and I think it's going really slowly

[13:49:40]

<aa_>

is zine==textpress?

[13:49:43]

aa_ - we ran a slicehost VPS for a year, 256

[13:49:45]

aa_: yes

[13:49:59]

<aa_>

oh man, textpress is dead! long live textpress!

[13:50:11]

aa_ - our main site had only two daemon wsgi workers (AS well as a wsgi daemon worker for trac/hg that idle timed out)

[13:50:12]

mitsuhiko: that way the message is send through all notification systems, whether they like it or not

[13:50:17]

and they could handle any laod we threw at them

[13:50:19]

(with nginx in front)

[13:50:20]

dennda: yes

[13:50:32]

mitsuhiko: is that really intended?

[13:50:37]

dennda: well. why not?

[13:50:49]

<aa_>

prencher: hmm, I just notice mod-wsgi+apache on this vm is about 20 times (timed) slower than using the werkzeug debug server

[13:51:00]

the notify() function can do the delivery handling too

[13:51:01]

then you're doing something really really wrong

[13:51:04]

or that VM sucks

[13:51:08]

eg: check which user wants the message in what way

[13:51:11]

<aa_>

and that's just a single request without having thrown anything at it

[13:51:21]

is that a XEN VM?

[13:51:41]

<aa_>

prencher: dunno, kvm I think, our guy is an uber geek

[13:51:52]

<aa_>

prencher: except he is a bit python clueless

[13:51:56]

WAH

[13:52:01]

lars ulrich on youtube

[13:52:02]

<aa_>

prencher: and its sunday so I can't ask him :(

[13:52:06]

http://www.youtube.com/watch?v=Dl2qocBpM1U

[13:52:15]

aa_ - nowadays, we don't need vps anymore as we just do web, we actually host on webfaction.. which proxy a frontend apache (which they give lots of memory) to your app servers

[13:52:27]

aa_ - our main site only uses two instances in embedded mode for about 30mb of ram

[13:53:05]

(they have a doubleup promo in relation to django 1.0 release, get 160mb ram / 20gb disk / 1.2tb bw for $9.50/mo)

[13:53:12]

runs great if you need some inexpensive hosting for python

[13:53:23]

and not runs great at the price, just runs great

[13:53:35]

mitsuhiko: then we basically have the same approach. the difference is that I used the class Listener (with some additional functionality) instead of a single function

[13:54:23]

mitsuhiko - the guy is a douche, but their newest album is great

[13:55:01]

aa_ - if you're not on xen for your vps you need to get it, basically

[13:55:13]

oldschool vms suck for perf

[13:55:20]

<hads>

KVM works nicely too.

[13:57:28]

can't say i know what they've been doing recently, but looks like they take advantage of hw virtualization now, so that's good at least

[13:58:23]

<hads>

Yeah, KVM only works with hardware virt. I run it on our server here.

[13:58:50]

hows its performance compared to XEN?

[13:59:37]

<hads>

I've not done side by side benchmarks but performance has been excellent.

[14:01:29]

<aa_>

prencher: do you serve static files from apache or direclty from nginx?

[14:01:39]

aa_ - from nginx, of course

[14:02:03]

(or in case of webfaction, from their frontend apache which does static, php and cgi and is optimized for that)

[14:02:09]

<aa_>

ok, I'll have to look into that

[14:03:38]

mitsuhiko: merged as you requested

[14:10:48]

<CIA-49>

Zine: mitsuhiko default * 486:5cba83b804cf /zine/templates/admin/reddit.html: Added missing template file

[14:12:55]

mitsuhiko - so im curious, how exactly are you going to use diva and wtforms in conjunction?

[14:12:59]

that just sounds weird

[14:13:33]

I think he'll pick what he likes from wtforms

[14:14:20]

prencher: i'm cherrypicking code and ideas of both libraries into a mini utility module

[14:14:21]

well obviously, but he wants the validation from diva and macros to do rendering

[14:14:43]

and the field system of newforms/wtforms

[14:14:48]

fm4 is strange: http://fm4.orf.at/supersonnig

[14:14:56]

that page has contents but the status code is 404

[14:15:00]

uh nifty

[14:15:25]

mitsuhiko - ingenius way to lock out ie6 with its 404s!

[14:22:38]

apollo13: clean_foo(...) is bound to the field foo right?

[14:22:40]

(newforms)

[14:23:06]

ahm form

[14:23:51]

validate on the form goes over the fields validates those and calls self.clean_field(data) if existend

[14:23:56]

or what do you mean?

[14:24:24]

apollo13: but the error if raised ends up as error in the field?

nope form.errors

['field']

if I get you right

okay it ends up in form._errors['fieldname'] to be percise

[14:26:09]

but putting it on the field might be a good idea

[14:26:24]

yeah. but that's what i mean

[14:26:34]

form.errors could get the field errors and the non-field errors then

[14:26:38]

because diva doesn't do that which sounds stupid

[14:27:58]

yeah

[14:31:02]

mitsuhiko: do you have time for a little love for sphinx' js some time?

[14:31:25]

birkenfeld: the keyword search?

[14:31:33]

yep

[14:32:04]

sure, i'll do that right after i finished that

[14:32:57]

thanks

[14:50:24]

mitsuhiko: so how shall I proceed with that notification stuff? I am a bit eager to get it in since I need it myself :-)

[14:50:41]

<maze>

http://www.youtube.com/watch?v=sfe6nY5qmQY

[14:51:34]

that's kinda cool: http://www.youtube.com/watch?v=DrQRS40OKNE

[14:52:06]

dennda: work out the concept, sketch up an api :)

[14:52:14]

hey I did ^^

[14:52:14]

write it in the trac, i'll give my comments to it

[14:52:17]

ok

[15:36:37]

<CIA-49>

Zine: mitsuhiko default * 487:4ed338fed3a1 /zine/utils/ (admin.py forms.py):

[15:36:37]

<CIA-49>

Zine: Added experimental form validation library based on diva's form system. It was

[15:36:37]

<CIA-49>

Zine: changed to a wtforms inspired form handling where there are fields (that handle

[15:36:37]

<CIA-49>

Zine: conversion of the data) and validators (that do the actual validation).

[15:37:16]

<plaes>

cool :)

[15:40:07]

:-)

[15:40:31]

wow, cool ;)

[15:44:38]

<CIA-49>

Zine: mitsuhiko default * 488:c3e90f178446 /zine/utils/forms.py: Improved docstrings and fixed as_field() in form lib.

[15:47:28]

example usage: http://paste.pocoo.org/show/zjWyUpc0KyP8LfEQN6yf/

oh lord

finally

I'll need that :-)

tux21b: look look :-)

[15:52:08]

mitsuhiko, wow looks good!

[15:55:19]

conversion: http://paste.pocoo.org/show/84657/

[15:55:45]

although i would like to have foo.0.bar instead of foo[0][bar]

[15:57:14]

why that?

[15:57:26]

What's wrong with foo[0][bar]?

[15:57:37]

he doesn't like brackets :-)

[15:59:10]

EnTeQuAk: longer to type and requires url encoding

[16:00:00]

&foo.bar.baz=42 is perfectly okay, &foo[bar][baz]=42 would have to be &foo%5Bbar%5D%5Bbaz%5D=42

not that nice

indeed

hmm, you're sure

mitsuhiko - that looks pretty coo, but also not that different from wtforms?

[16:04:15]

mitsuhiko - also, whats the behaviour of data if validate fails?

[16:04:36]

it stays as it was before

[16:04:45]

which is the initial data or an empty dict

[16:05:04]

mitsuhiko - so how are you going to fill the fields with form data that didnt validate?

[16:05:39]

the form fields will be filled with the submitted data

[16:05:44]

not with the cleaned data

[16:07:06]

so .data is the validated data, and only there if validate returns True?

[16:07:47]

i think i just leave the .data behavior undefined :)

[16:07:52]

unless validate works

[16:08:17]

i would strongly suggest you set data to None or an empty list in case of failure

[16:08:26]

consistent state is rather important

[16:10:31]

mitsuhiko - you also seem to be making the django "mistake," in that you need a field type even if all you want is a string field with a different validator

[16:11:28]

it also means each field type is rigid and needs to take e.g. min/max length, even when that could just be an additional validator

[16:11:50]

whether thats an issue for you is a different matter

[16:15:20]

prencher: what do you mean by "field type ven if all you want is a string field with a different validator"?

[16:15:33]

a StringField is a field that holds strings isn't it?

[16:15:42]

and validators just validate, they don't convert

[16:16:10]

mitsuhiko - and what if you want to validate that string field against a length, and check it's a valid email? it seems like thats tied to the field, or your example didnt show validators

[16:19:08]

prencher: that example doesn't show validators. sec

[16:20:53]

prencher: http://paste.pocoo.org/show/AdfnwYgmk6wl6rOOoCe3/

[16:21:09]

or you can also do

[16:21:13]

name.add_validator(a_validator_function)

[16:22:01]

that there gets ick as soon as you need multiple validators for one field

[16:23:50]

mitsuhiko - http://paste.pocoo.org/show/FYRM74yKTbiS7HTbOdCJ/ here's some "real" forms, i'd like to see how those would look in your api