| 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@87.240.134.143) 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)
|
|---|