Re: Dallas 1.1 sprint - dates?

[Matthew Marshall]

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

[Matthew Marshall]

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
-~--~~~~--~~--~--~---

Re: I18N+Database Problem

[Matthew Marshall]

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
-~--~~~~--~~--~--~---

Re: Ticket #122 - Rationale for changing, or not changing, model syntax

[Matthew Marshall]

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: Ticket #122 - Rationale for changing, or not changing, model syntax

[Matthew Marshall]

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: Question on django internals.

[Matthew Marshall]

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