Re: I18N+Database Problem
AFAIK, django's i18n support is mainly for static strings in the code and templates. For keeping multiple translations of database content, you'll need something more. This might work for you: http://trac.studioquattro.biz/djangoutils/wiki/TranslationService I also started working on a translation service app last night. I'll share it if it turns into anything usefully :-) MWM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Question on django internals.
I'm making headway with ticket 122. However I have discovered a bug when porting the m2m_intermediary model test. The get_relatedobject_list methods are not being set. Can you tell me where in the code this is supposed to happen? I can see where it is happening for ManyToMany, but not for ManyToOne. Thanks! MWM
Re: Question on django internals.
On Tuesday 02 August 2005 04:20 am, Adrian Holovaty wrote: > On 8/1/05, Matthew Marshall <[EMAIL PROTECTED]> wrote: > > I'm making headway with ticket 122. However I have discovered a bug when > > porting the m2m_intermediary model test. The get_relatedobject_list > > methods are not being set. Can you tell me where in the code this is > > supposed to happen? I can see where it is happening for ManyToMany, but > > not for ManyToOne. > > Check out lines 48-50 of django/models/__init__.py. Good luck! > > Adrian Ah, thanks! I found the problem right away... I had made a copy of core/meta/ for working on this new API, but models/__init__.py was using isinstance on fields from the old meta module. Now to continue down the list of tests... MWM
Re: Ticket #122 - Rationale for changing, or not changing, model syntax
On Wednesday 17 August 2005 06:06 pm, Robin Munn wrote: > The argument that there's too much "magic" going on behind the scenes > leaves me puzzled. Isn't there already lots of "magic" going on > setting up the assorted get_foo_list() functions for ForeignKeys and > ManyToManyFields? Why not add a little bit more "magic", when the > result is something that feels so much more Pythonic to the end user? I would even say that this is very little 'magic' for what is accomplished. I think that it just _looks_ scary, because it uses inspect. However, the usage of inspect is mainly for redundancy, in order to better catch breakage. I know that the patch is almost 1000 lines long, but over 90% of that is just converting the models used internally and in the test framework. The meat of it is in lines 375-404 and 552-569 of model_api.r.389.diff. (which is attached to the ticket.) As what I did in this patch really doesn't need to be ingrained into django itself, I was intending to move it into a wrapper class this evening. This would allow the use of this new syntax without requiring any change to django, so those who really want the new syntax can have it. Unfortunately, this would not be something which a new django user would see, and I think that a first 'wow' impression is one of the advantages of this new syntax. MWM
Re: Ticket #122 - Rationale for changing, or not changing, model syntax
On Wednesday 17 August 2005 09:28 pm, Robin Munn wrote:
> On 8/17/05, Matthew Marshall <[EMAIL PROTECTED]> wrote:
> By that, do you mean an alternate class to inherit from? E.g., instead of
>
> class Person(meta.Model):
> fields = (
> meta.CharField('name', maxlength=50),
> )
>
> I would do
>
> class Person(meta.PythonicModel):
> name = meta.CharField(maxlength=50)
>
> ?
Pretty much, yes. I imagine it as more of:
from djangomodelwrapper import Model, fields
class Person(Model):
name = fields.CharField(maxlength=50)
So, it would be completely separate from django, and thus easier for me to
maintain. (I'm getting sick of my django install breaking every time I do an
update that modifies a model.)
> If that's what you mean, I'm about -0 on the idea. Its advantage is
> that no change to Django is required, so the documentation can stay
> the same, the tutorials can stay the same, and so on. Gradual ramp up.
> But the disadvantage is... the docs stay the same, the tutorials stay
> the same, and a new user doesn't immediately see the shiny "wow,
> that's awesome!" syntax.
Yeah, that is 100% what I was saying. Or at least, meant to say. I only
mentioned it because that is what I will do for my own use, should the syntax
not be included in django itself.
> I think SQLObject got a lot of things right, except for using the name
> MultipleJoin for what should have been called ForeignKey. The "Oh wow,
> you can just declare your fields using class-attribute creation"
> coolness was certainly one of the most attractive things about
> SQLObject. It would be a shame to lose that for Django.
My thoughts exactly. In fact, that is the primary reason why I would want
this included in django. For my own use, it really doesn't matter. I can
use the syntax with a wrapper, even it if isn't included.
MWM
Re: Ticket #122 - Rationale for changing, or not changing, model syntax
On Wednesday 17 August 2005 09:59 pm, Robin Munn wrote: > If/when you do write a wrapper, please post it to the ticket as well. > If we can't persuade Adrian and Jacob to see sense *wink*, it'll be > handy to have an alternative. Of course! I'll see how the current discussion on IRC turns out before working on it, however. MWM
Re: Ticket #122 - Rationale for changing, or not changing, model syntax
On Wednesday 17 August 2005 10:32 pm, Jacob Kaplan-Moss wrote: > Howdy everyone -- Hey Jacob! > I think I was the driving force behind rejecting this ticket -- > Adrian's still 50/50 as far as I know -- so let me explain why I > don't like it. I think that just about everything can be answered :) > The first problem I have with the new syntax for models is that it > makes it unclear what's a field and what's metadata:: [snip] Yes, that was a problem. But, as already mentioned, it was fixed a while ago. > Second, what if I want a field named "admin"? [snip] ditto > Third, from a semantic point of view it's just wrong. Consider:: > > class RegularOldPythonClass: > classVar = 14 > > def __init__(self): > self.instanceVar = 77 > > In the above example, ``classVar`` is, obviously, a class member and > ``instanceVar`` is a member of *an instance* of the class. There's > an important semantic distinction between instance variables and > class variables that I don't think I need to point out to everyone. > > Unfortunately, the proposed model syntax subverts this. In the > example above, ``field1`` is not a member of the Model class (try it > -- ``Model.field1`` will raise an ``AttributeError``); it's a member > of an *instance* of the ``Model`` class. So why are we defining it > as if it were a class variable? On the other hand, ``fields`` *is* a > class variable, so it makes sense to define it at the class level. Hmm... I guess this is really a matter of personal taste. If this really is a big deal, one way to fix it would be to place all of the fields in their own subclass, instead of the metadata. (This was proposed earlier.) > Finally, there's the "magic" aspects of dealing with something like:: > > class Model(meta.Model): > field = meta.CharField(...) > meta.ForeignKey(...) > > The "unadorned" ``ForeignKey`` simply doesn't make sense if you don't > understand the magic going on underneath, whereas a list of fields > makes perfect sense. I'm honestly less concerned with the crazyness > of the code than I am with the weird and non-standard syntax. > Nowhere else in Python does a non-assignment in a class result in a > class member being created. Blame Adrian for that one :-D Anyway, during the IRC discussion, everyone voted to take that out, so I guess it's not an issue. > In Python there's always a tension between clarity and the > conciseness you can achieve by doing cool tricks with metaclasses. > I'm all for getting rid of as much boilerplate code as possible -- > that's why Django exists in the first place -- but not at the expense > of clarity. I'd rather be more verbose and more clear than concise > and confusing (again, if I wanted concise I'd use Perl). I fully agree with you that readability is more important than writeability. However, I personally find this new method to be more readable. It makes the fieldnames stand out more, and greatly cuts down on the amount of non-alphanumeric characters. For myself, I don't care much whether it makes it into django or not. As I mentioned before, I would just use it via a wrapper. I _would_ like to see it included, however, because I think it will make things easier for others using django. IMHO, it also looks better to those checking the framework out :) So, it's really very subjective :P MWM
Re: Get rid of model modules?
+1 I have become used to this, but it was (perhaps needlessly) confusing at first. In a way, this wouldn't be as big as the model syntax change, as it could be done incrementally. There is nothing (AFAIK) stopping using both methods for a while. MWM On Thursday 15 September 2005 04:46 pm, Simon Willison wrote: > One thing that feels a little strange about Django is the way that > model classes (with many in a single application file) turn in to > modules when that application is installed. The reason for this is > the module level methods associated with a model: blogs.get_list(), > blogs.get_object() etc. > > An alternative could be to have those as class methods added to the > model classes themselves: > > from django.models.blog import Blog, Entry > > Blog.get_list() > Blog.get_object() > > Entry.get_iterator() > > etc... > > This is an enormous change to Django, but I feel it would improve the > usability of the framework. It would eliminate the need for > module_name, module_constants and exceptions (all could be handled as > class properties instead). It could also lead to the removal of > BlogNotFoundException and friends - they could be replaced by > exceptions based on nested classes: Blog.NotFound. > > I started thinking about this while trying to work out how to define > a new module-level method - I realised that class methods might be a > much better fit for that kind of thing. > > It's a really big change, even bigger than the recent model syntax > change because this change would mean re-writing views as well. > Still, I thought it would be worth bringing up here for discussion. > > Cheers, > > Simon Willison
'klass' in magic removal branch.
Minor nitpick, but could we use 'class_' instead of 'klass'? >From the 'Pythonic guidelines' in PEP 8: - If your public attribute name collides with a reserved keyword, append a single trailing underscore to your attribute name. This is preferable to an abbreviation or corrupted spelling. E.g. "class_" is preferable to "cls" or "klass". Not a big deal, but I thought it was worth asking for. MWM
Re: Dallas 1.1 sprint - dates?
I'm interested. Either weekend would work for me. MWM On Apr 2, 12:45 pm, Jeremy Dunck wrote: > Hey all, I was considering putting on a Dallas sprint for 1.1. I'm > not sure exactly when 1.1 will ship, but soon-ish, so I was thinking > about trying to make the sprint the weekend of 4/10 (Easter weeked) or > 4/17. > > Any preference? Who can make it or will consider making it? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Pick a value from list variable in templates
On Tuesday 04 March 2008 14:54:38 Jacob Kaplan-Moss wrote:
> Second, there's the question of weather this is a first-class
> language-level feature or a filter. If it's the former, there's a
> syntactic decision to be made; some have proposed something like ``{{
> foo.$bar }}``, but anything that looks like Perl is gonna get a
> reflexive -1 from most Pythonistas. ``{{ foo.{{ bar }} }}`` has been
> suggested too; that's extremely ugly.
What's wrong with ``{{ foo[bar] }}`` ?
That's how it's done in python, javascript, php, and others. Most people
writing html templates will be somewhat familiar with at least Javascript.
MWM
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
