Ticket #122: modeldiscuss.txt

File modeldiscuss.txt, 31.9 KB (added by hugo <gb@…>, 14 years ago)

IRC discussion about the model syntax

1        *       Now talking on #django
2        *       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
3        *       Topic for #django set by JZ_ at Sat Jul 16 12:30:01 2005
4        hugo-   hi
5        mmarshall       hi hugo-
6        *       adrian_h is back.
7        adrian_h        back
8        mmarshall       Ok everyone, we can start talking again ;)
9        rmunn   adrian_h: You said you're split on #122. What are your main objections?
10        *       ljoramo has quit ()
11        *       adrian_h gathers thoughts
12        rmunn   Take your time. :-)
13        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)
14        rmunn   That would be a little surprising for newbies, yeah.
15        adrian_h        Before we open-sourced Django, the field name was required. Foreign keys used to look like this:
16        adrian_h        meta.IntegerField('field_name', 'verbose name', rel=meta.ManyToOne(Poll))
17        adrian_h        So I shortened that to "ForeignKey(Poll)" in preparation for open-sourcing
18        *       Netminder likes the current state of fields FWIW.
19        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
20        adrian_h        I talked about this with MikeLambert last night
21        rmunn   I personally would have little objection to making ForeignKeys require a name again...
22        hugo-   me too
23        rmunn   It's orthogonal to the question of the SQLObject-like syntax, IMHO.
24        rmunn   Actually, requiring ForeignKeys (and ManyToManyFields) to have a name would get rid of one of the more "magic" parts of the #122 patch.
25        adrian_h        As I see it, the issues are related, because one solution can solve both problems
26        adrian_h        Yeah, exactly
27        rmunn   They're related, but independent: it would be quite feasible to implement one, or the other, or both, or neither.
28        rmunn   One of those four is probably optimum, we just need to figure out which.
29        rmunn   Another possibility: in mmarshall's email to the dev list, he mentioned writing a wrapper class for the new behavior.
30        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.
31        adrian_h        Yeah, that's possible...But there should be One Real Way of doing it
32        adrian_h        Yes, we've discussed meta.OldModel (with exactly that name)
33        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".
34        mmarshall       rmunn: That was what I tried to do at first, but there were some problems.
35        rmunn   mmarshall: What problems did you run into?
36        adrian_h        IIRC, the problem lies in the fact that django/models/__init__.py can't be duplicated
37        adrian_h        i.e., we can't have multiple copies of it
38        mmarshall       For one thing, the changes were not local meta.Model; they also required switching the first two arguments to the Field classes.
39        rmunn   Ah yes, so that verbose_name could become the first positional arg.
40        mmarshall       So I tried duplicating meta itself, resulting in a new can of worms.
41        mmarshall       rmunn: Yes.
42        mmarshall       At first, I had a hack to get around this, but it was messy, and prone to confuse people.
43        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."
44        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"
45        rmunn   How would you feel about the "fieldname = class" syntax if the decision was made that ForeignKeys must always be given a name?
46        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.
47        *       threeve has quit ()
48        rmunn   Any other major objections?
49        rmunn   That was to adrian_h, of course, not mmarshall. :-)
50        rmunn   mmarshall: But it's a one-time price.
51        adrian_h        My only other major objection is having to ask everybody to change model syntax
52        adrian_h        Which isn't a huge problem, being that we haven't guaranteed backwards-compatibility
53        rmunn   Well, there's no getting around that one.
54        rmunn   It'll mostly depend on whether people want the new syntax or not.
55        adrian_h        And yesterday's session update was backwards-incompatible, and people didn't complain too loudly...
56        Netminder       adrian_h: very few people had gotten to sessions yet
57        rmunn   If there are loud boos and very few cheers, you could always revert the patch...
58        mmarshall       Yeah, but that wasn't as big of deal to change.
59        rmunn   I, for one, would be cheering loudly. :-)
60        Netminder       changing the model syntax is pretty big.
61        adrian_h        Netminder: Yes, but the session change broke admin installations, because the admin now depends on sessions
62        rmunn   Yeah, it is, which is why I'm trying to start discussion on the dev list.
63        adrian_h        People haven't really spoken up about the model syntax, other than rmunn and mmarshall
64        mmarshall       I have had a number of people mention it to me.
65        rmunn   manuzhai was saying earlier in here that he planned to write a post to the dev list.
66        *       Tybstar (n=tgerla@cpe-069-134-162-085.nc.res.rr.com) has joined #django
67        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'
68        adrian_h        How does manuzhai feel about it?
69        rmunn   loglibrary's not working, so I'll just copy and paste:
70        rmunn   manuzhai: "will send a me too to the #122 thread once I get an email from it"
71        adrian_h        Netminder: all right
72        *       Tybstar returns
73        adrian_h        Tybstar: How do you feel about the proposed model syntax change to use "fieldname = FieldClass"?
74        mmarshall       When I came in earlier, he mentioned that #122 was 'shot down', and frowned.
75        rmunn   manuzhai: "I for one like 'your' syntax better" (to mmarshall)
76        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?
77        *       liquidx (n=liquidx@ has joined #django
78        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
79        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.
80        Netminder       yes, that's my thought too hugo-
81        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?
82        Tybstar it's not a huge difference either way...
83        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.
84        hugo-   is  it really?
85        Netminder       It's just... different.
86        adrian_h        Netminder: There shouldn't be any issues with the DB layer with regard to the possible syntax change -- the syntax is abstracted
87        Netminder       adrian_h: roger that.
88        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
89        rmunn   Ah good, some real discussion at last. :-)
90        adrian_h        Great point, hugo-
91        hugo-   there are other things like the settings file an dstuff like that :-)
92        Tybstar the model fields syntax isn't bad. the admin = syntax can be pretty hairy.
93        Tybstar i've seen lots of people have trouble wtih the (foo) != (foo,) thing in the admin = code
94        rmunn   I've seen that too.
95        hugo-   Tybstar: yeah, that's one thing I allways want to hit Guido over the head because of ;-)
96        Netminder       the (foo,) syntax becomes second nature after a messup or two
97        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.
98        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
99        Tybstar adrian_h: indeed
100        Tybstar takes some guesswork
101        hugo-   Tybstar: especially since python will happily iterate over chars in a string if it expects a list :-)
102        Tybstar yes
103        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
104        Tybstar the pitfalls of a dynamically typed langage. :)
105        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
106        rmunn   That's what ticket #244 was about.
107        hugo-   adrian_h: especially since that would make writing models for existing databases much more obvious
108        hugo-   adrian_h: especially since the "name=" option for ForeignKey isn't (or at least wasn't) documented in the model reference :-)
109        rmunn   Wow, discussion moved on while I was searching for that ticket.
110        rmunn   I meant that http://code.djangoproject.com/ticket/244 was about being nicer to newbies.
111        hugo-   rmunn: you need to configure --with-threads ;-)
112        rmunn   Heh. I wish IRC had that sometimes... :-)
113        adrian_h        :)
114        adrian_h        hugo-: Would you applaud the move if it were in "fieldname = FieldClass" syntax?
115        Netminder       irc --with-productivity would be nice
116        mmarshall       Netminder: LOL
117        rmunn   Netminder: :-D
118        rmunn   Okay, let me see who seems to like or dislike the "fieldname = FieldClass" syntax.
119        rmunn   I like it.
120        rmunn   mmarhsall likes it.
121        rmunn   adrian_h is split but leaning against (?)
122        rmunn   Netminder isn't too enthusiastic.
123        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.
124        rmunn   Tybstar liked it at first but is pretty indifferent.
125        rmunn   hugo- doesn't much care.
126        mmarshall       garthk likes it, manuzhai likes it
127        hugo-   rmunn: doesn't much care with added a bit of puzzlement, please ;-)
128        rmunn   Anyone object to how I've described them?
129        adrian_h        I'm positively *for* requiring a name for ForeignKey and ManyToManyField, to make that explicit -- which is a related issue
130        hugo-   adrian_h: that one I am quite positive about, too
131        rmunn   adrian_h: I'm +1 on requiring a name as well.
132        Netminder       rmunn: that's about right.  +1 on the requirement
133        mmarshall       +1 on requiring a name here
134        Tybstar +1
135        adrian_h        Wow, no opposition to the name requirement -- very cool
136        rfc1149 count me in :) +1 on requiring a name
137        Tybstar sounds unaniniminninnious
138        mmarshall       I normally specify a name anyway :P
139        adrian_h        rfc1149: What do you think of the "fieldname=FieldClass" syntax?
140        adrian_h        As an aside, can anybody on Windows confirm this bug? http://code.djangoproject.com/ticket/349
141        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.
142        adrian_h        rfc1149: The idea is that other (non-field) data would go in an inner class called "Meta"
143        rfc1149 btw, i also would like to interpret "foo" as ("foo",) in settings where it makes sense
144        rfc1149 oh, that would be very nice!
145        rfc1149 (the inner Meta class, that is)
146        rmunn   What I see is support for fieldname=FieldClass ranging from mild to enthusiastic, but I don't see any opposition stronger than mild.
147        rmunn   Is there anyone who would positively scream if that was implemented?
148        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.
149        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
150        *       Netminder remains mildly against it.
151        rfc1149 but i guess that is unavoidable :)
152        adrian_h        Here's an example of the new syntax, so people have something to look at: http://django.pastebin.com/339441
153        Netminder       I'd kinda grumble a bit while rewriting my todo app :)
154        rfc1149 and it's still not yet released :)
155        *       Boffbowsh (i=Boffbows@host-85-236-105-19.multiplaydsl.co.uk) has joined #django
156        rfc1149 the field=FieldClass syntax really looks clean and natural
157        rmunn   Boffbowsh: Have you looked at http://code.djangoproject.com/ticket/122 at all?
158        rfc1149 and friendly to newbies.. i'm liking it more and more.
159        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
160        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.
161        Boffbowsh       yeah, i've taken a look, if thats'the fieldname = fielddef thing
162        Boffbowsh       i agree it would be nice
163        rmunn   I'm trying to get a feel for whether people would really like that syntax, really hate it, or be indifferent.
164        Netminder       yeah, I'm not keen on the magic
165        hugo-   field names with __ in front and back could be defined as "internal use" - that would match with python thinking
166        Boffbowsh       but not at the expense of ease of maintenance of django, imo
167        Netminder       +1 on hugo's line of thought
168        Boffbowsh       yar
169        rfc1149 Boffbowsh:  that's a good point
170        rmunn   hugo-: Interesting idea.
171        rfc1149 but i have not really heard adrian_h complain about it
172        adrian_h        If we use fieldname=fielddef, the maintenance will be about the same as it is now
173        rmunn   Perhaps __meta__ = dict(admin=Admin(), foo=Bar(), ...)
174        rfc1149 see :)
175        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
176        adrian_h        But the last patch to #122 (which allows model attributes without names) would be a headache to maintain
177        Boffbowsh       not read it through thoruoghly as i was at work when it first cropped up
178        rfc1149 i personally prefer Meta: ... above __meta__ = dict( ... )
179        adrian_h        Using a class for Meta would be better, because you wouldn't have to use commas between attributes
180        Netminder       hmm yeah
181        adrian_h        Models themselves used to be dictionaries, a long time ago
182        Boffbowsh       are there any benefits other than it looking nicer?
183        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
184        mmarshall       adrian_h: how would it be hard to maintain?
185        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.
186        Netminder       if it looks prettier but is painful to maintain, that's no good
187        hugo-   there is no obvious connection between those two besides the scope - the internally needed assignments are done by magic
188        adrian_h        mmarshall: I was referring to the magic no-name-for-ForeignKeys thing, but we've agreed to scrap that.
189        *       rfc1149 goes to bed but looks forward to reading the rest of the discussion later
190        *       Dagur (n=dagur@dsl-196-5.hive.is) has joined #django
191        rmunn   rfc1149: Don't log out -- loglibrary is down.
192        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
193        adrian_h        hugo-: You're talking about the internal "class Meta", right?
194        hugo-   adrian_h: yep
195        hugo-   I agree that it's cleaner syntax, though. <sigh> not an easy choice
196        hugo-   the hacker in me would go the inner-class-way, the maintainer might shy away from it :-)
197        Netminder       I'm still on the fence, but think maintainability is a key thing to think about
198        Netminder       the syntax is quite nice though :)
199        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
200        rmunn   I'm looking at things more from a usability perspective than a maintainability perspective, so that colors my perception.
201        rmunn   Most of the tickets I file tend to be useability issues, if you've noticed.
202        adrian_h        It's even probably a bit cleaner than the current internals
203        adrian_h        rmunn: Yes, and they're much appreciated :)
204        Dagur   Could someone tell me what this error means:
205        Dagur   ContentTypeDoesNotExist: ContentType does not exist for {'package__label__exact': 'jenga', 'python_module_name__exact': 'jengacats'}
206        Dagur   I get it when I try to submit stuff in the admin panel
207        rmunn   Dagur: Have you changed your model recently?
208        Dagur   yeah
209        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
210        adrian_h        Dagur: run "django-admin.py sqlall jenga" and execute the "INSERT INTO content_types ... jenga" line in your database.
211        rmunn   Did you update the database after changing the model?
212        Dagur   it's a model I created for an existing database
213        Dagur   I didn't try that
214        Dagur   will do
215        rmunn   Dagur: Then you'll need to run sqlall, like adrian_h said.
216        rmunn   But you'll also need to add all the auth_* and core_* tables.
217        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
218        rmunn   So that the INSERT INTO statements have somewhere to put the data. :-)
219        adrian_h        Dagur: After doing "django-admin.py init", just do "django-admin.py sqlinitialdata jenga"
220        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
221        hugo-   usually the maintainer in me kicks the butt of the hacker in me ...
222        Dagur   ok i'm confused now
223        rmunn   hugo-: I *think*, though I'm not sure, that mmarshall's patch contructs a "fields" tuple internally.
224        rmunn   Dagur: Listen to adran_h, not me. He knows what he's talking about.
225        Dagur   hehe ok
226        *       rheinbot has quit (Remote closed the connection)
227        *       Tybstar needs a viewsvn for his project
228        adrian_h        Dagur: Run the command "django-admin.py init" if you haven't already done that. That creates Django's internal database tables.
229        Netminder       Tybstar: see the one that slashzero put django_ajax on, it's free to all
230        *       Tybstar ponders writing a django-based viewsvn
231        adrian_h        Dagur: After you've done that, run "django-admin.py sqlinitialdata jenga" and execute that SQL in your database.
232        adrian_h        Dagur: That's it.
233        hugo-   Tybstar: use trac
234        *       rheinbot (n=supybot@maxwell.servers.ljworld.com) has joined #django
235        rmunn   hugo-: Trac's internal Subversion viewer annoys me a little.
236        Tybstar hugo-: looks kinda heavyweight
237        rmunn   It doesn't let me see what the root of the repository is.
238        rmunn   I have to guess what to put after "svn checkout".
239        hugo-   Tybstar: it isn't - I use it for most of my repositories nowadays, it's easy to set up and run
240        hugo-   rmunn: hey, there is a wiki in it, just add a description of the checkout path to the wiki :-)
241        *       Notify: jacobkm is offline (kornbluth.freenode.net).
242        Dagur   woo! it worked
243        Dagur   thanks
244        adrian_h        Dagur: No problem! Thanks for using Django
245        Netminder       Dagur: drive through :)
246        Dagur   ^_^
247        *       Tybstar can't make viewsvn work
248        Dagur   I have another error for you guys :P
249        adrian_h        Dagur: Go ahead
250        Dagur   TypeError: got unexpected keyword argument 'id__iexactjengausers'
251        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.
252        Dagur   the problem is that the id fields are called ID (capitalized)
253        adrian_h        Dagur: Where did that error happen?
254        Dagur   i was submitting in the admin panel
255        *       GvaderTH (i=grzegorz@mokotow.com) has left #django
256        adrian_h        Dagur: Can you paste the full traceback to django.pastebin.com?
257        Dagur   http://django.pastebin.com/339455 
258        adrian_h        Thanks...I'm looking now
259        Dagur   it's the id of a foreignkey table
260        Dagur   not the table I'm updating
261        *       wilsonian has quit ()
262        Dagur   oops
263        Dagur   id__iexactjengausers   <-- the jengausers part is something I added
264        Dagur   it's supposed to say id__iexact
265        adrian_h        OK, I was wondering about that :)
266        Dagur   sorry, I was trying to figure out the table name
267        adrian_h        No problem
268        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.
269        adrian_h        mmarshall: Ideally it would just loop over all the attributes except the one (if given) named "Meta"
270        rmunn   Dagur: Is that "iexact" a typo that's supposed to be "exact", or did you really mean "iexact"?
271        mmarshall       adrian_h: Actually, that's what it does.
272        *       GvaderTH (n=gregtech@mokotow.com) has joined #django
273        adrian_h        mmarshall: Ah, cool
274        adrian_h        rmunn: That iexact is within Django...I'm fixing now.
275        hugo-   adrian_h: and so I can't name a field Meta? yuck.
276        mmarshall       Also, if it comes accross an attribute that is neither a Field nor a function, it raises a helpful error.
277        Dagur   rmunn: it's the django code that does that
278        Dagur   I was just submitting a form
279        mmarshall       hugo-: Originally I supported doing that, by optionally placing all fields in a subclass named 'Fields', but Adrian didn't like that.
280        adrian_h        Dagur: "svn update" your code, and let me know whether the problem is fixed.
281        Dagur   ok
282        hugo-   hmm. the more I think it through, the more I would tend to -1 on the new field syntax
283        mmarshall       hugo-: actually, you can still do that, just by giving the 'name' argument.
284        Dagur   worked!
285        adrian_h        Dagur: Thanks for pointing out that bug!
286        adrian_h        Dagur: Sorry, I should've credited you in the commit message
287        Dagur   np, my pleasure!
288        adrian_h        hugo-: One solution to that might be to require that "class Meta" is a subclass of "meta.Meta" or something like that
289        adrian_h        "class Meta(meta.Meta)" -- hehe
290        rmunn   Ew, that's a little overboard.
291        rmunn   What about "class __meta__: ..."
292        adrian_h        Is that possible?
293        hugo-   sure
294        rmunn   I don't see why not, it's just another name in the namespace.
295        adrian_h        Very cool -- I just tried it
296        rmunn   Let me check and make sure.
297        *       hugo- has a class named __proxy__ in one of his source files :-)
298        rmunn   Oh, nevermind then.
299        adrian_h        Now that's much better, namespace-wise
300        rmunn   Anyone who's using double-underscores at the start and end of their field names is being unpythonic, IMHO.
301        adrian_h        But it introduces more double underscores :-/
302        Tybstar i'd suggest against __meta__
303        rmunn   Yeah, that's the downside.
304        Tybstar it implies python builtin magic
305        hugo-   rmunn: ugh - python uses loads of __xxxx__ stuff - is it unpythonic? :-)
306        Tybstar _Meta would be better
307        Netminder       eew
308        rmunn   hugo-: Fields are public things, __xxxx__ is for private stuff.
309        Netminder       I'd take __meta__ before _Meta
310        hugo-   and there are special provisions in python with regard to __xxxxx fields - they are hidden in some aspects
311        adrian_h        hugo-: That's actually an advantage in this case
312        hugo-   rmunn: the meta stuff _is_ private to the model, not public :-)
313        adrian_h        What about "class DjangoMeta"?
314        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
315        adrian_h        That's much less likely to be used as a field name
316        Tybstar Netminder: i don't necessarily like _Meta better than __meta__, but i'm afraid of collidiing with python internals someday
317        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).
318        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.
319        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
320        hugo-   adrian_h: laziness is my second name ;-)
321        adrian_h        hehe
322        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
323        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
324        Tybstar my cat just caught a blue jay.
325        adrian_h        hugo-: "print ','.join(["IntegerField(%s, default=0)" % name for name in list_of_fieldnames])"
326        hugo-   adrian_h: nooo - I hate generated code, programmatic solutions should just manipulate data
327        hugo-   so to do the same with the new stuff I would write a loop that does a load of setattr(...)
328        hugo-   it's not impossible, it's just not as easy and simple as with data structures
329        adrian_h        hugo-: setattr wouldn't even work, because the metaclass runs when the class is *defined*
330        hugo-   ah, yes, forgotten that one
331        adrian_h        I must say, the new syntax is sexy
332        rmunn   I suppose you could construct a dict and feed it to meta.Model.__new__(cls, bases, attrs). Ew.
333        rmunn   I don't even know if that would work.
334        hugo-   rmunn: yep, with metaclasses that would be a - rather ugly, I must say - option
335        adrian_h        Or dynamically construct a class and dynamically set its parent class after it's been constructed?
336        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 ;-)
337        rmunn   adrian_h: The metaclass magic happens before the class object is created, so I don't think that would work.
338        *       manuzhai (n=manuzhai@i249181.upc-i.chello.nl) has joined #django
339        rmunn   hugo-: You'd have to really deeply grok metaclasses to do that.
340        manuzhai        soooo, is this were the #122 discussion is taking place?
341        adrian_h        hugo-: What about a helper function for cases like yours? meta.create_model_from_dynamic_field_list(), except with a better name
342        rmunn   hugo-: In other words, don't try it unless you're Dutch. :-)
343        adrian_h        manuzhai: Yes, indeed
344        rmunn   manuzhai: Yes.
345        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 ;-)
346        manuzhai        rmunn: hey, don't fuck with the Dutch!!!
347        rmunn   manuzhai: No no, it's a compliment.
348        manuzhai        ok
349        hugo-   rmunn: hey, I am living near the dutch border, so I am at least halfway competent ;-)
350        manuzhai        so what are we actually talking about? :P
351        rmunn   Only Guido van Rossum (and his brother) are smart enough to understand some of this stuff. :-)
352        adrian_h        hugo-: What do you think of the helper function idea above?
353        hugo-   adrian_h: if you find a better name ;-)
354        adrian_h        create_model_from_dynamic_field_list_for_hugo()
355        adrian_h        :)
356        hugo-   lol
357        rmunn   That's what, 30 characters long?
358        rmunn   40.
359        adrian_h        At least this isn't PHP, where there's actually a performance penalty for using long variable names
360        Boffbowsh       so glad to be moving over to python from php
361        Boffbowsh       had to do a bit of php today, felt so... spaghetti like
362        adrian_h        manuzhai: We're debating this syntax: http://django.pastebin.com/339441
363        Tybstar why the hell does viewcvs want TK??
364        *       rmunn boggles. TK?
365        adrian_h        The current question on the table is whether "class Meta" is a good name. It would conflict with a field named "Meta"
366        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
367        manuzhai        adrian_h: how is your current position?
368        adrian_h        manuzhai: I'm getting more and more interested in the new syntax
369        hugo-   that way the new syntax works nicely and somehugo with the need for programmatically creating models can use the documented "lower level"
370        adrian_h        hugo-: That's a good solution
371        adrian_h        A lower-level API for creating models
372        manuzhai        adrian_h: that's good
373        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
374        rmunn   mmarshall's patch would need some serious rewriting, then.
375        Tybstar this is the suck.
376        rmunn   Tybstar: Ouch. What distro?
377        Tybstar rmunn: it's a fedora machine
378        Tybstar i wish viewsvn worked
379        Netminder       there's your problem :)
380        Tybstar heh
381        hugo-   yikes. that's even worse than debians often-weird-dependencies :-)
382        *       Tybstar wishes slashzero were here
383        Tybstar i just can't quite get viewsvn working
384        BleSS   why i get this error? AttributeError: 'NoneType' object has no attribute 'status_code'
385        *       rmunn *heart*s Synaptic
386        adrian_h        BleSS: Your view has to return an HttpResponse object
387        *       Notify: jacobkm is online (kornbluth.freenode.net).
388        *       jacobkm (n=jacob@74.57.cm.sunflower.com) has joined #django
389        Boffbowsh       BleSS: your get_object or whatever returned no object
390        Boffbowsh       hence the Nojne
391        Boffbowsh       *None
392        adrian_h        That's a good case for a better error message.
393        Boffbowsh       ahh, ok
394        rmunn   adrian_h: Special-case check to see if None was returned from the view?
395        adrian_h        rmunn: Yes
396        mmarshall       rmunn: My patch is very simple; even stupidly simple now that the no-name-for-ForeignKeys thing is no longer needed.
397        hugo-   since None is the implicit value for functions that are missing the return alltogether, I think that special case check would be usefull
398        Boffbowsh       nn all
399        *       proteusguy (n=proteusg@dsl027-163-201.atl1.dsl.speakeasy.net) has joined #django
400        *       Boffbowsh has quit ()
401        *       Dagur (n=dagur@dsl-196-5.hive.is) has left #django
402        *       cmlenz has quit ()
403        BleSS   adrian_h, whatever view has th reuturn an HttpResponse object? (my view simply add data to data base)
404        manuzhai        BleSS: you should redirect then
405        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')
406        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
407        BleSS   thanks
408        adrian_h        hugo-: Yay
409        hugo-   that should satisfy both the hacker and the maintainer in me ;-)
410        *       jvoorhis (n=user@cpe-24-93-226-82.neo.res.rr.com) has joined #django
411        jvoorhis        adrian_h: hi
412        adrian_h        Hi jvoorhis
413        jvoorhis        good work on the tutorial
414        *       ljoramo (n=ljoramo@69-25-223-154.acsol.net) has joined #django
415        adrian_h        jvoorhis: Thanks -- is everything going smoothly for you?
416        jvoorhis        yes, except for python gotchas
417        adrian_h        ah
418        jvoorhis        a tuple is like a constant array, i guess
419        Netminder       the sooner we make the change the better IMHO
420        adrian_h        Netminder: Yes
421        adrian_h        jacobkm: Hello
422        manuzhai        adrian_h: could you or jacobkm look at my patch for #289?
423        jacobkm Howdy, adrian
424        jacobkm Looks like the logging bot has been broken for a few days :(
425        adrian_h        Yeah :-(
426        rmunn   Who set up the loglibrary logging in the first place?
427        jacobkm I did
428        rmunn   So you're the one who can fix it (if it can be fixed).
429        jacobkm Yup
430        jacobkm I'm trying to figure out what's wrong right now.
431        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.
432        Netminder       I think loglibrary is having issues
433        Netminder       I don't think there's anything we can do
434        jacobkm Hunh
435        rmunn   Actually, most of it has already scrolled off the top of my scrollback buffer.
436        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/
437        jacobkm I was afraid of that.
438        rmunn   Did anyone else manage to save the discussion from earlier?
439        manuzhai        does anyone else think the CherryPy page on the wiki is pointless?
440        adrian_h        manuzhai: Yeah, I just saw that and am tempted to delete it
441        hugo-   rmunn: I can put the log from the discussion as a comment on #122 if you want
442        manuzhai        I am, too
443        adrian_h        rmunn: I've got the discussion
444        manuzhai        please do so
445        manuzhai        it seems like FUD
446        hugo-   my scrollback buffer is big enough
447        rmunn   Yes, please do.
448        jacobkm CherryPy page: gone
449        manuzhai        hugo-: an attachment to #122 might be better
450        mrproper        What is a closure & how does one use a closure in Python?  (I have an idea of closure from Javascript and event listeners)
Back to Top