	*	Now talking on #django
	*	Topic for #django is: http://www.djangoproject.com/ || Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.|| Logs: http://loglibrary.com/show_page/latest/179
	*	Topic for #django set by JZ_ at Sat Jul 16 12:30:01 2005
	hugo-	hi
	mmarshall	hi hugo-
	*	adrian_h is back.
	adrian_h	back
	mmarshall	Ok everyone, we can start talking again ;)
	rmunn	adrian_h: You said you're split on #122. What are your main objections?
	*	ljoramo has quit ()
	*	adrian_h gathers thoughts
	rmunn	Take your time. :-)
	adrian_h	I don't like the fact that ForeignKeys are name-less attributes of the class (yes, I was the one who suggested that behavior in the first place)
	rmunn	That would be a little surprising for newbies, yeah.
	adrian_h	Before we open-sourced Django, the field name was required. Foreign keys used to look like this:
	adrian_h	meta.IntegerField('field_name', 'verbose name', rel=meta.ManyToOne(Poll))
	adrian_h	So I shortened that to "ForeignKey(Poll)" in preparation for open-sourcing
	*	Netminder likes the current state of fields FWIW.
	adrian_h	But the one thing that was lost in that was that now you have to "guess" what the field names are, for use in meta.admin.fields
	adrian_h	I talked about this with MikeLambert last night
	rmunn	I personally would have little objection to making ForeignKeys require a name again...
	hugo-	me too
	rmunn	It's orthogonal to the question of the SQLObject-like syntax, IMHO.
	rmunn	Actually, requiring ForeignKeys (and ManyToManyFields) to have a name would get rid of one of the more "magic" parts of the #122 patch.
	adrian_h	As I see it, the issues are related, because one solution can solve both problems
	adrian_h	Yeah, exactly
	rmunn	They're related, but independent: it would be quite feasible to implement one, or the other, or both, or neither.
	rmunn	One of those four is probably optimum, we just need to figure out which.
	rmunn	Another possibility: in mmarshall's email to the dev list, he mentioned writing a wrapper class for the new behavior.
	rmunn	I would suggest making the new behavior the default, but keeping a wrapper class ("meta.OldModel" perhaps) around to give the old "fields tuple" behavior.
	adrian_h	Yeah, that's possible...But there should be One Real Way of doing it
	adrian_h	Yes, we've discussed meta.OldModel (with exactly that name)
	rmunn	The documentation would mention the "fieldname = CharField()" syntax only, and the BackwardsIncompatibilities page would say "As a transition measure, use meta.OldModel until you've converted all your models".
	mmarshall	rmunn: That was what I tried to do at first, but there were some problems.
	rmunn	mmarshall: What problems did you run into?
	adrian_h	IIRC, the problem lies in the fact that django/models/__init__.py can't be duplicated
	adrian_h	i.e., we can't have multiple copies of it
	mmarshall	For one thing, the changes were not local meta.Model; they also required switching the first two arguments to the Field classes.
	rmunn	Ah yes, so that verbose_name could become the first positional arg.
	mmarshall	So I tried duplicating meta itself, resulting in a new can of worms.
	mmarshall	rmunn: Yes.
	mmarshall	At first, I had a hack to get around this, but it was messy, and prone to confuse people.
	rmunn	So if this is going to happen, it sounds like the simplest way is to just bite the bullet and say, "OK folks, revision ### is going to break all your models. Here's how to convert to the new syntax."
	adrian_h	Yeah...And, realistically, having to change models to use the "fieldname = class" syntax is only slightly more work than changing models to use "meta.OldModel"
	rmunn	How would you feel about the "fieldname = class" syntax if the decision was made that ForeignKeys must always be given a name?
	mmarshall	Yeah, it's really not that big of a deal.  Although, after converting all of the models in the tests and the django internals, as well as my own, I got a little sick of it.
	*	threeve has quit ()
	rmunn	Any other major objections?
	rmunn	That was to adrian_h, of course, not mmarshall. :-)
	rmunn	mmarshall: But it's a one-time price.
	adrian_h	My only other major objection is having to ask everybody to change model syntax
	adrian_h	Which isn't a huge problem, being that we haven't guaranteed backwards-compatibility
	rmunn	Well, there's no getting around that one.
	rmunn	It'll mostly depend on whether people want the new syntax or not.
	adrian_h	And yesterday's session update was backwards-incompatible, and people didn't complain too loudly...
	Netminder	adrian_h: very few people had gotten to sessions yet
	rmunn	If there are loud boos and very few cheers, you could always revert the patch...
	mmarshall	Yeah, but that wasn't as big of deal to change.
	rmunn	I, for one, would be cheering loudly. :-)
	Netminder	changing the model syntax is pretty big.
	adrian_h	Netminder: Yes, but the session change broke admin installations, because the admin now depends on sessions
	rmunn	Yeah, it is, which is why I'm trying to start discussion on the dev list.
	adrian_h	People haven't really spoken up about the model syntax, other than rmunn and mmarshall
	mmarshall	I have had a number of people mention it to me.
	rmunn	manuzhai was saying earlier in here that he planned to write a post to the dev list.
	*	Tybstar (n=tgerla@cpe-069-134-162-085.nc.res.rr.com) has joined #django
	Netminder	adrian_h: I'd probably be mildly against it, as I don't feel a "big gain" in the new syntax vs. the current and it'd be a good bit of work and relearnin'
	adrian_h	How does manuzhai feel about it?
	rmunn	loglibrary's not working, so I'll just copy and paste:
	rmunn	manuzhai: "will send a me too to the #122 thread once I get an email from it"
	adrian_h	Netminder: all right
	*	Tybstar returns
	adrian_h	Tybstar: How do you feel about the proposed model syntax change to use "fieldname = FieldClass"?
	mmarshall	When I came in earlier, he mentioned that #122 was 'shot down', and frowned.
	rmunn	manuzhai: "I for one like 'your' syntax better" (to mmarshall)
	Netminder	adrian_h: I heard some rumbles on the ticket about issues with the db layer.  Is that a show stopper or just something to get around?
	*	liquidx (n=liquidx@87.240.134.143) has joined #django
	hugo-	I don't think that it really is much change in the syntax. Actually that's the reason why I am a bit split on #122, too - I don't see much gain for the work
	Tybstar	adrian_h: i haven't really followed the discussion, unfortunately. i liked it on first glance, but i've really gotten attached to the current syntax.
	Netminder	yes, that's my thought too hugo- 
	hugo-	ok, sure, the new syntax would be nicer, but is it really that big a problem to use a list of fields instead of a list of attribute assignments?
	Tybstar	it's not a huge difference either way...
	rmunn	It's not a huge gain once you've gotten used to the fields = (...) syntax. I see it more as a big gain for newbies.
	hugo-	is  it really?
	Netminder	It's just... different.
	adrian_h	Netminder: There shouldn't be any issues with the DB layer with regard to the possible syntax change -- the syntax is abstracted
	Netminder	adrian_h: roger that.
	hugo-	if I think about what questions arise here in the channel, I don't think that _that_ part of Django really produces that much questions
	rmunn	Ah good, some real discussion at last. :-)
	adrian_h	Great point, hugo- 
	hugo-	there are other things like the settings file an dstuff like that :-)
	Tybstar	the model fields syntax isn't bad. the admin = syntax can be pretty hairy.
	Tybstar	i've seen lots of people have trouble wtih the (foo) != (foo,) thing in the admin = code
	rmunn	I've seen that too.
	hugo-	Tybstar: yeah, that's one thing I allways want to hit Guido over the head because of ;-)
	Netminder	the (foo,) syntax becomes second nature after a messup or two
	rmunn	I'd suggest a general rule-of-thumb: if something is supposed to be a list or tuple, and you get a string, automatically convert it.
	adrian_h	The one real problem I have with the model syntax is that it's not immediately apparent what the field name is for a ForeignKey and ManyToManyField, so people don't know what to use in admin.fields
	Tybstar	adrian_h: indeed
	Tybstar	takes some guesswork
	hugo-	Tybstar: especially since python will happily iterate over chars in a string if it expects a list :-)
	Tybstar	yes
	adrian_h	We can fix that with the model validator, with a message that says "That's an invalid field name. Here are the valid field names for this model", but that's still one step too much
	Tybstar	the pitfalls of a dynamically typed langage. :)
	hugo-	adrian_h: I would applaud a move that ForeignKey and friends need a obligatory first parameter that is the field name like other field types
	rmunn	That's what ticket #244 was about.
	hugo-	adrian_h: especially since that would make writing models for existing databases much more obvious
	hugo-	adrian_h: especially since the "name=" option for ForeignKey isn't (or at least wasn't) documented in the model reference :-)
	rmunn	Wow, discussion moved on while I was searching for that ticket.
	rmunn	I meant that http://code.djangoproject.com/ticket/244 was about being nicer to newbies.
	hugo-	rmunn: you need to configure --with-threads ;-)
	rmunn	Heh. I wish IRC had that sometimes... :-)
	adrian_h	:)
	adrian_h	hugo-: Would you applaud the move if it were in "fieldname = FieldClass" syntax?
	Netminder	irc --with-productivity would be nice
	mmarshall	Netminder: LOL
	rmunn	Netminder: :-D
	rmunn	Okay, let me see who seems to like or dislike the "fieldname = FieldClass" syntax.
	rmunn	I like it.
	rmunn	mmarhsall likes it.
	rmunn	adrian_h is split but leaning against (?)
	rmunn	Netminder isn't too enthusiastic.
	hugo-	adrian_h: I wouldn't mind if it was, as I don't have much models to change - but I still wouldn't see the reason to switch that part of the syntax. But I wouldn't actively object.
	rmunn	Tybstar liked it at first but is pretty indifferent.
	rmunn	hugo- doesn't much care.
	mmarshall	garthk likes it, manuzhai likes it
	hugo-	rmunn: doesn't much care with added a bit of puzzlement, please ;-)
	rmunn	Anyone object to how I've described them?
	adrian_h	I'm positively *for* requiring a name for ForeignKey and ManyToManyField, to make that explicit -- which is a related issue
	hugo-	adrian_h: that one I am quite positive about, too
	rmunn	adrian_h: I'm +1 on requiring a name as well.
	Netminder	rmunn: that's about right.  +1 on the requirement
	mmarshall	+1 on requiring a name here
	Tybstar	+1
	adrian_h	Wow, no opposition to the name requirement -- very cool
	rfc1149	count me in :) +1 on requiring a name
	Tybstar	sounds unaniniminninnious
	mmarshall	I normally specify a name anyway :P
	adrian_h	rfc1149: What do you think of the "fieldname=FieldClass" syntax?
	adrian_h	As an aside, can anybody on Windows confirm this bug? http://code.djangoproject.com/ticket/349
	rfc1149	i quite like the fieldname=FieldClass idea, but am a bit concerned that it will bite later.  using fields= leaves a lot of namespace for later use.
	adrian_h	rfc1149: The idea is that other (non-field) data would go in an inner class called "Meta"
	rfc1149	btw, i also would like to interpret "foo" as ("foo",) in settings where it makes sense
	rfc1149	oh, that would be very nice!
	rfc1149	(the inner Meta class, that is)
	rmunn	What I see is support for fieldname=FieldClass ranging from mild to enthusiastic, but I don't see any opposition stronger than mild.
	rmunn	Is there anyone who would positively scream if that was implemented?
	rmunn	Remember, it would be a backwards-incompatible change to the model syntax, so it would involve work (albeit a one-time effort) on your part to change your models.
	rfc1149	i do not yet have significant amounts of existing code, but i would not like it if an unthinking svn update would break all my code
	*	Netminder remains mildly against it.
	rfc1149	but i guess that is unavoidable :)
	adrian_h	Here's an example of the new syntax, so people have something to look at: http://django.pastebin.com/339441
	Netminder	I'd kinda grumble a bit while rewriting my todo app :)
	rfc1149	and it's still not yet released :)
	*	Boffbowsh (i=Boffbows@host-85-236-105-19.multiplaydsl.co.uk) has joined #django
	rfc1149	the field=FieldClass syntax really looks clean and natural
	rmunn	Boffbowsh: Have you looked at http://code.djangoproject.com/ticket/122 at all?
	rfc1149	and friendly to newbies.. i'm liking it more and more.
	hugo-	I'd prefer it if the inner class wasn't tacked on by magic but instead just be added via a __meta__ = something attribute
	Netminder	yeah, it's kinda nice.  My only objection would be the one time fee that we'd have to pay, but I think it would be worth it in the long run.
	Boffbowsh	yeah, i've taken a look, if thats'the fieldname = fielddef thing
	Boffbowsh	i agree it would be nice
	rmunn	I'm trying to get a feel for whether people would really like that syntax, really hate it, or be indifferent.
	Netminder	yeah, I'm not keen on the magic
	hugo-	field names with __ in front and back could be defined as "internal use" - that would match with python thinking
	Boffbowsh	but not at the expense of ease of maintenance of django, imo
	Netminder	+1 on hugo's line of thought
	Boffbowsh	yar
	rfc1149	Boffbowsh:  that's a good point
	rmunn	hugo-: Interesting idea.
	rfc1149	but i have not really heard adrian_h complain about it
	adrian_h	If we use fieldname=fielddef, the maintenance will be about the same as it is now
	rmunn	Perhaps __meta__ = dict(admin=Admin(), foo=Bar(), ...)
	rfc1149	see :)
	Boffbowsh	i don't mind having a slightly odd syntax (which isn't really that odd at all, there's just a slightly nicer way) if it means that the rest of the project is stable and easy to add new stuff to
	adrian_h	But the last patch to #122 (which allows model attributes without names) would be a headache to maintain
	Boffbowsh	not read it through thoruoghly as i was at work when it first cropped up
	rfc1149	i personally prefer Meta: ... above __meta__ = dict( ... )
	adrian_h	Using a class for Meta would be better, because you wouldn't have to use commas between attributes
	Netminder	hmm yeah
	adrian_h	Models themselves used to be dictionaries, a long time ago
	Boffbowsh	are there any benefits other than it looking nicer?
	hugo-	adrian_h: yeah, but the problem is with the way how you find out in your Poll class that there is an inner class Meta
	mmarshall	adrian_h: how would it be hard to maintain?
	rmunn	There seems to be pretty much unanimous consensus to require a name for ForeignKey and ManyToManyFields, so the headache-to-maintain patch can probably go away.
	Netminder	if it looks prettier but is painful to maintain, that's no good
	hugo-	there is no obvious connection between those two besides the scope - the internally needed assignments are done by magic
	adrian_h	mmarshall: I was referring to the magic no-name-for-ForeignKeys thing, but we've agreed to scrap that.
	*	rfc1149 goes to bed but looks forward to reading the rest of the discussion later
	*	Dagur (n=dagur@dsl-196-5.hive.is) has joined #django
	rmunn	rfc1149: Don't log out -- loglibrary is down.
	hugo-	and more specificially: there is no prior art in Python libraries for such magic that connects stuff implicitely just because of the scope they are in
	adrian_h	hugo-: You're talking about the internal "class Meta", right?
	hugo-	adrian_h: yep
	hugo-	I agree that it's cleaner syntax, though. <sigh> not an easy choice
	hugo-	the hacker in me would go the inner-class-way, the maintainer might shy away from it :-)
	Netminder	I'm still on the fence, but think maintainability is a key thing to think about
	Netminder	the syntax is quite nice though :)
	adrian_h	The maintenance for the inner class is simple -- internally (inside the metaclass call), it's just interpreted as another attribute on the object
	rmunn	I'm looking at things more from a usability perspective than a maintainability perspective, so that colors my perception.
	rmunn	Most of the tickets I file tend to be useability issues, if you've noticed.
	adrian_h	It's even probably a bit cleaner than the current internals
	adrian_h	rmunn: Yes, and they're much appreciated :)
	Dagur	Could someone tell me what this error means: 
	Dagur	ContentTypeDoesNotExist: ContentType does not exist for {'package__label__exact': 'jenga', 'python_module_name__exact': 'jengacats'}
	Dagur	I get it when I try to submit stuff in the admin panel
	rmunn	Dagur: Have you changed your model recently?
	Dagur	yeah
	hugo-	adrian_h: the nice thing about the current stuff is: it's all python data. The new stuff is more python code objects. It's easy to programmatically generate python data if there is much repetitive stuff in it - but it's much harder (although not impossible thanks to pythons structure) to dynamically construct code objets
	adrian_h	Dagur: run "django-admin.py sqlall jenga" and execute the "INSERT INTO content_types ... jenga" line in your database.
	rmunn	Did you update the database after changing the model?
	Dagur	it's a model I created for an existing database
	Dagur	I didn't try that
	Dagur	will do
	rmunn	Dagur: Then you'll need to run sqlall, like adrian_h said.
	rmunn	But you'll also need to add all the auth_* and core_* tables.
	hugo-	adrian_h: and since I am in a line of business where there are often very large repetitive strikes of code and field definitions, I am much in favor of easy generating things programmatically
	rmunn	So that the INSERT INTO statements have somewhere to put the data. :-)
	adrian_h	Dagur: After doing "django-admin.py init", just do "django-admin.py sqlinitialdata jenga"
	hugo-	adrian_h: so in that aspect the maintainer in me shys away from solutions that leave the data-path and go the code path, even though the hacker in me prefers to hack on the latter stuff
	hugo-	usually the maintainer in me kicks the butt of the hacker in me ...
	Dagur	ok i'm confused now
	rmunn	hugo-: I *think*, though I'm not sure, that mmarshall's patch contructs a "fields" tuple internally.
	rmunn	Dagur: Listen to adran_h, not me. He knows what he's talking about.
	Dagur	hehe ok
	*	rheinbot has quit (Remote closed the connection)
	*	Tybstar needs a viewsvn for his project
	adrian_h	Dagur: Run the command "django-admin.py init" if you haven't already done that. That creates Django's internal database tables.
	Netminder	Tybstar: see the one that slashzero put django_ajax on, it's free to all
	*	Tybstar ponders writing a django-based viewsvn
	adrian_h	Dagur: After you've done that, run "django-admin.py sqlinitialdata jenga" and execute that SQL in your database.
	adrian_h	Dagur: That's it.
	hugo-	Tybstar: use trac
	*	rheinbot (n=supybot@maxwell.servers.ljworld.com) has joined #django
	rmunn	hugo-: Trac's internal Subversion viewer annoys me a little.
	Tybstar	hugo-: looks kinda heavyweight
	rmunn	It doesn't let me see what the root of the repository is.
	rmunn	I have to guess what to put after "svn checkout".
	hugo-	Tybstar: it isn't - I use it for most of my repositories nowadays, it's easy to set up and run
	hugo-	rmunn: hey, there is a wiki in it, just add a description of the checkout path to the wiki :-)
	*	Notify: jacobkm is offline (kornbluth.freenode.net).
	Dagur	woo! it worked
	Dagur	thanks
	adrian_h	Dagur: No problem! Thanks for using Django
	Netminder	Dagur: drive through :)
	Dagur	^_^
	*	Tybstar can't make viewsvn work
	Dagur	I have another error for you guys :P
	adrian_h	Dagur: Go ahead
	Dagur	TypeError: got unexpected keyword argument 'id__iexactjengausers' 
	rmunn	hugo-: Not every project that uses Trac seems to do that, though. That's my main gripe. It's a pretty small one, as gripes go.
	Dagur	the problem is that the id fields are called ID (capitalized)
	adrian_h	Dagur: Where did that error happen?
	Dagur	i was submitting in the admin panel
	*	GvaderTH (i=grzegorz@mokotow.com) has left #django
	adrian_h	Dagur: Can you paste the full traceback to django.pastebin.com?
	Dagur	http://django.pastebin.com/339455  
	adrian_h	Thanks...I'm looking now
	Dagur	it's the id of a foreignkey table
	Dagur	not the table I'm updating
	*	wilsonian has quit ()
	Dagur	oops
	Dagur	id__iexactjengausers   <-- the jengausers part is something I added
	Dagur	it's supposed to say id__iexact
	adrian_h	OK, I was wondering about that :)
	Dagur	sorry, I was trying to figure out the table name
	adrian_h	No problem
	mmarshall	hugo-: My patch simply itenerates over all of the attributes.  If the attribute holds an instance of Field, it assigns the name (or rel_name, for relationship fields) from the attribute name, and adds it to a 'fields' list.  This list is then used just the same as the fields tuple is currently.
	adrian_h	mmarshall: Ideally it would just loop over all the attributes except the one (if given) named "Meta"
	rmunn	Dagur: Is that "iexact" a typo that's supposed to be "exact", or did you really mean "iexact"?
	mmarshall	adrian_h: Actually, that's what it does.
	*	GvaderTH (n=gregtech@mokotow.com) has joined #django
	adrian_h	mmarshall: Ah, cool
	adrian_h	rmunn: That iexact is within Django...I'm fixing now.
	hugo-	adrian_h: and so I can't name a field Meta? yuck.
	mmarshall	Also, if it comes accross an attribute that is neither a Field nor a function, it raises a helpful error.
	Dagur	rmunn: it's the django code that does that
	Dagur	I was just submitting a form
	mmarshall	hugo-: Originally I supported doing that, by optionally placing all fields in a subclass named 'Fields', but Adrian didn't like that.
	adrian_h	Dagur: "svn update" your code, and let me know whether the problem is fixed.
	Dagur	ok
	hugo-	hmm. the more I think it through, the more I would tend to -1 on the new field syntax
	mmarshall	hugo-: actually, you can still do that, just by giving the 'name' argument.
	Dagur	worked!
	adrian_h	Dagur: Thanks for pointing out that bug!
	adrian_h	Dagur: Sorry, I should've credited you in the commit message
	Dagur	np, my pleasure!
	adrian_h	hugo-: One solution to that might be to require that "class Meta" is a subclass of "meta.Meta" or something like that
	adrian_h	"class Meta(meta.Meta)" -- hehe
	rmunn	Ew, that's a little overboard.
	rmunn	What about "class __meta__: ..."
	adrian_h	Is that possible?
	hugo-	sure
	rmunn	I don't see why not, it's just another name in the namespace.
	adrian_h	Very cool -- I just tried it
	rmunn	Let me check and make sure.
	*	hugo- has a class named __proxy__ in one of his source files :-)
	rmunn	Oh, nevermind then.
	adrian_h	Now that's much better, namespace-wise
	rmunn	Anyone who's using double-underscores at the start and end of their field names is being unpythonic, IMHO.
	adrian_h	But it introduces more double underscores :-/
	Tybstar	i'd suggest against __meta__
	rmunn	Yeah, that's the downside.
	Tybstar	it implies python builtin magic
	hugo-	rmunn: ugh - python uses loads of __xxxx__ stuff - is it unpythonic? :-)
	Tybstar	_Meta would be better
	Netminder	eew
	rmunn	hugo-: Fields are public things, __xxxx__ is for private stuff.
	Netminder	I'd take __meta__ before _Meta
	hugo-	and there are special provisions in python with regard to __xxxxx fields - they are hidden in some aspects
	adrian_h	hugo-: That's actually an advantage in this case
	hugo-	rmunn: the meta stuff _is_ private to the model, not public :-)
	adrian_h	What about "class DjangoMeta"?
	hugo-	but the reason why I dislike the new stuff is that it doesn't allow me to do things like fields = tuple([IntegerField(name, default=0) for name in list_of_fieldnames]) or something similar as easily
	adrian_h	That's much less likely to be used as a field name
	Tybstar	Netminder: i don't necessarily like _Meta better than __meta__, but i'm afraid of collidiing with python internals someday
	rmunn	What I meant was that "class __meta__" won't interfere with anyone's DB field name, since you should be using double-underscores for DB fields (which are more "public" attributes).
	adrian_h	hugo-: Interesting point, but, realistically, why would you want to do that, other than laziness? Models don't change often enough for there to be a need for them to be dynamic like that.
	hugo-	sure, if I know about the inner workings I can hack around it - but I can't just take the public visible interface of the model and apply python code there
	hugo-	adrian_h: laziness is my second name ;-)
	adrian_h	hehe
	hugo-	adrian_h: and for a more serious reason: I am working in legacy apps areas where you get _large_ structures of many very similar fields
	hugo-	if you have to write models with 100 or more fields and most of them are booleans or moneytypes or some choice of a handfull of possibilities, you crave for automatted solutions
	Tybstar	my cat just caught a blue jay.
	adrian_h	hugo-: "print ','.join(["IntegerField(%s, default=0)" % name for name in list_of_fieldnames])"
	hugo-	adrian_h: nooo - I hate generated code, programmatic solutions should just manipulate data
	hugo-	so to do the same with the new stuff I would write a loop that does a load of setattr(...)
	hugo-	it's not impossible, it's just not as easy and simple as with data structures
	adrian_h	hugo-: setattr wouldn't even work, because the metaclass runs when the class is *defined*
	hugo-	ah, yes, forgotten that one
	adrian_h	I must say, the new syntax is sexy
	rmunn	I suppose you could construct a dict and feed it to meta.Model.__new__(cls, bases, attrs). Ew.
	rmunn	I don't even know if that would work.
	hugo-	rmunn: yep, with metaclasses that would be a - rather ugly, I must say - option
	adrian_h	Or dynamically construct a class and dynamically set its parent class after it's been constructed?
	hugo-	sure, you can allways call the metaclass manually and construct the class instance by using the metaclass. It's a bit hacky and doesn't sound like really maintainable code, though ;-)
	rmunn	adrian_h: The metaclass magic happens before the class object is created, so I don't think that would work.
	*	manuzhai (n=manuzhai@i249181.upc-i.chello.nl) has joined #django
	rmunn	hugo-: You'd have to really deeply grok metaclasses to do that.
	manuzhai	soooo, is this were the #122 discussion is taking place?
	adrian_h	hugo-: What about a helper function for cases like yours? meta.create_model_from_dynamic_field_list(), except with a better name
	rmunn	hugo-: In other words, don't try it unless you're Dutch. :-)
	adrian_h	manuzhai: Yes, indeed
	rmunn	manuzhai: Yes.
	hugo-	rmunn: the main problem is that stuff like that would be code that only I would maintain because my coworkers _never_ will grok it ;-)
	manuzhai	rmunn: hey, don't fuck with the Dutch!!!
	rmunn	manuzhai: No no, it's a compliment.
	manuzhai	ok
	hugo-	rmunn: hey, I am living near the dutch border, so I am at least halfway competent ;-)
	manuzhai	so what are we actually talking about? :P
	rmunn	Only Guido van Rossum (and his brother) are smart enough to understand some of this stuff. :-)
	adrian_h	hugo-: What do you think of the helper function idea above?
	hugo-	adrian_h: if you find a better name ;-)
	adrian_h	create_model_from_dynamic_field_list_for_hugo()
	adrian_h	:)
	hugo-	lol
	rmunn	That's what, 30 characters long?
	rmunn	40.
	adrian_h	At least this isn't PHP, where there's actually a performance penalty for using long variable names
	Boffbowsh	so glad to be moving over to python from php
	Boffbowsh	had to do a bit of php today, felt so... spaghetti like
	adrian_h	manuzhai: We're debating this syntax: http://django.pastebin.com/339441
	Tybstar	why the hell does viewcvs want TK??
	*	rmunn boggles. TK?
	adrian_h	The current question on the table is whether "class Meta" is a good name. It would conflict with a field named "Meta"
	hugo-	hmm. maybe if the mechanisms are made more transparent - define a set of functions to construct a model and then define the transformations that are used for transforming the class definition using _those_ functions into a model
	manuzhai	adrian_h: how is your current position?
	adrian_h	manuzhai: I'm getting more and more interested in the new syntax
	hugo-	that way the new syntax works nicely and somehugo with the need for programmatically creating models can use the documented "lower level"
	adrian_h	hugo-: That's a good solution
	adrian_h	A lower-level API for creating models
	manuzhai	adrian_h: that's good
	hugo-	actually that's the way Lispers often do this: build a set of base functions and define new syntax on top of it. They have macros, we have metaclasses for the syntax stuff
	rmunn	mmarshall's patch would need some serious rewriting, then.
	Tybstar	this is the suck.
	rmunn	Tybstar: Ouch. What distro?
	Tybstar	rmunn: it's a fedora machine
	Tybstar	i wish viewsvn worked
	Netminder	there's your problem :)
	Tybstar	heh
	hugo-	yikes. that's even worse than debians often-weird-dependencies :-)
	*	Tybstar wishes slashzero were here
	Tybstar	i just can't quite get viewsvn working
	BleSS	why i get this error? AttributeError: 'NoneType' object has no attribute 'status_code'
	*	rmunn *heart*s Synaptic
	adrian_h	BleSS: Your view has to return an HttpResponse object
	*	Notify: jacobkm is online (kornbluth.freenode.net).
	*	jacobkm (n=jacob@74.57.cm.sunflower.com) has joined #django
	Boffbowsh	BleSS: your get_object or whatever returned no object
	Boffbowsh	hence the Nojne
	Boffbowsh	*None
	adrian_h	That's a good case for a better error message.
	Boffbowsh	ahh, ok
	rmunn	adrian_h: Special-case check to see if None was returned from the view?
	adrian_h	rmunn: Yes
	mmarshall	rmunn: My patch is very simple; even stupidly simple now that the no-name-for-ForeignKeys thing is no longer needed.
	hugo-	since None is the implicit value for functions that are missing the return alltogether, I think that special case check would be usefull
	Boffbowsh	nn all
	*	proteusguy (n=proteusg@dsl027-163-201.atl1.dsl.speakeasy.net) has joined #django
	*	Boffbowsh has quit ()
	*	Dagur (n=dagur@dsl-196-5.hive.is) has left #django
	*	cmlenz has quit ()
	BleSS	adrian_h, whatever view has th reuturn an HttpResponse object? (my view simply add data to data base)
	manuzhai	BleSS: you should redirect then
	adrian_h	BleSS: Yes, every view has to return an HttpResponse object, so your users actually get a page. If you want to redirect, use HttpResponseRedirect('/path/to/new/page')
	hugo-	ok, so if the new syntax will be a combination of a documented model-creation API plus a compact class-based syntax on top of it, it get's a +1 from me
	BleSS	thanks
	adrian_h	hugo-: Yay
	hugo-	that should satisfy both the hacker and the maintainer in me ;-)
	*	jvoorhis (n=user@cpe-24-93-226-82.neo.res.rr.com) has joined #django
	jvoorhis	adrian_h: hi
	adrian_h	Hi jvoorhis 
	jvoorhis	good work on the tutorial
	*	ljoramo (n=ljoramo@69-25-223-154.acsol.net) has joined #django
	adrian_h	jvoorhis: Thanks -- is everything going smoothly for you?
	jvoorhis	yes, except for python gotchas
	adrian_h	ah
	jvoorhis	a tuple is like a constant array, i guess
	Netminder	the sooner we make the change the better IMHO
	adrian_h	Netminder: Yes
	adrian_h	jacobkm: Hello
	manuzhai	adrian_h: could you or jacobkm look at my patch for #289?
	jacobkm	Howdy, adrian
	jacobkm	Looks like the logging bot has been broken for a few days :(
	adrian_h	Yeah :-(
	rmunn	Who set up the loglibrary logging in the first place?
	jacobkm	I did
	rmunn	So you're the one who can fix it (if it can be fixed).
	jacobkm	Yup
	jacobkm	I'm trying to figure out what's wrong right now.
	rmunn	I've got to go soon, but I'll save a copy of this IRC discussion in case anyone wants to look at what was said about #122.
	Netminder	I think loglibrary is having issues
	Netminder	I don't think there's anything we can do
	jacobkm	Hunh
	rmunn	Actually, most of it has already scrolled off the top of my scrollback buffer.
	jvoorhis	adrian_h: one thing i did not like was that the form on the details template has to be aware that it lives at polls/
	jacobkm	I was afraid of that.
	rmunn	Did anyone else manage to save the discussion from earlier?
	manuzhai	does anyone else think the CherryPy page on the wiki is pointless?
	adrian_h	manuzhai: Yeah, I just saw that and am tempted to delete it
	hugo-	rmunn: I can put the log from the discussion as a comment on #122 if you want
	manuzhai	I am, too
	adrian_h	rmunn: I've got the discussion
	manuzhai	please do so
	manuzhai	it seems like FUD
	hugo-	my scrollback buffer is big enough
	rmunn	Yes, please do.
	jacobkm	CherryPy page: gone
	manuzhai	hugo-: an attachment to #122 might be better
	mrproper	What is a closure & how does one use a closure in Python?  (I have an idea of closure from Javascript and event listeners)
