Re: [AUDIT] Enable Django Quick Start / Database Evolution Support
On 5/31/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > > Jacob Kaplan-Moss wrote: > > On May 25, 2006, at 11:27 AM, lazaridis_com wrote: > > > >> At this point, Django's persistency layer seems intresting, but the > >> evaluation uncovered a few weaknesses, most importantly the lack of > >> schema evolution support: > > > > This is actually one of the accepted Summer of Code projects for > > Django, so the best answer is perhaps to way until the end of the > > summer to see what happens with it. > > I cannot wait so long and additionally I sense several problems for the > SoC project: > > http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution While we appreciate your enthusiasm, your contributions might be better received if you took some time to more thoroughly understand the Django project and its community. It seems that you have an interest in analyzing various software for what you find to be "flaws"; while any useful and well-crafted contribution to the project is welcome regardless of the motivation of its author, it seems that your motivation is leading you to hasty conclusions and unnecessary actions. Many of the points you raise regarding Django are either trivial or downright mistaken; furthermore, your attempt to independently replicate work that has already been spoken for and due for completion (as a Summer of Code project) is effort better spent elsewhere. Take a step back, see what other people are doing and how they're doing it, take note of what tends to be appreciated and what tends to be criticized, and you'll be on your way. :-) --~--~-~--~~~---~--~~ 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: Enable Django Quick Start / Database Evolution Support
On 6/1/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > You can try this EnergyKey > > http://www30.webSamba.com/SmartStudio > > This may be help you. > > Now I always use EnergyKey, it helps me so much in my work. > > very intresting tool! There's an interesting phenomenon you may wish to add to your "audit" knowledge; it's called "spam". http://en.wikipedia.org/wiki/Spam_%28electronic%29 --~--~-~--~~~---~--~~ 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: RFC: Django history tracking
On 6/14/06, Uros Trebec <[EMAIL PROTECTED]> wrote: > > 2.1. Basic models: > To enable history tracking Bob has to create a sub-class for those > models that he will like to track: > > class Post(models.Model): > author = models.CharField(maxlength=100) > title = models.CharField(maxlength=100) > content = models.TextField() > date = models.dateField() > > class History: > pass A minor quibble: "History" would be called an "inner class" in this case; a "subclass" would be a class that inherits from another class, like "Post" in this example (being a subclass of Model). Other than that, neat stuff! :-) --~--~-~--~~~---~--~~ 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: Proposal: default escaping (and branch request)
On 6/20/06, Simon Willison <[EMAIL PROTECTED]> wrote: > > On 20 Jun 2006, at 16:25, James Bennett wrote: > > > Security by annoyance is security that people learn to hate and turn > > off as soon as they can, so in the end it doesn't really make them any > > more secure than they were before. > > Agreed - which is why I want to try it in a branch and see if it's > actually annoying :) The problem is that the only ones testing that branch would be those already inclined towards default-on autoescaping; those of us who are against it *already know* it would be annoying. :-p --~--~-~--~~~---~--~~ 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: Proposal: default escaping
On 6/21/06, oefe <[EMAIL PROTECTED]> wrote:
>
> Agreed.
> To prevent XSS vulnerabilities because someone forgot to specify the
> escaping rule, I would suggest that templates should, maybe even must
> specify their escaping. For example, require each template to contain a
> special {% autoescape %} tag at the beginning, e.g. {%
> autoescape html %}. If the designer doesn't want any auto-escaping, she
> should say so: {% autoescape off %} (or plaintext, if you prefer).
Oh ye gods, please no. :-)
This is exactly what James was referring to as "security by
annoyance"; forcing me to place a boilerplate like that at the top of
every template is going to get frustrating, fast.
--~--~-~--~~~---~--~~
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: Sniffing around django
On 6/27/06, toth anna <[EMAIL PROTECTED]> wrote: > > Is there any (elegant) opportunity for a "container level > logic". For example, there can be only 5 from a specific > type of item, and inserting a new, we have to delete oldest > object. > Or when saving an object, container "splits" it, and creates > two instead (from my example, if "date period" object > contains a year boundary, i have to split it), without > affecting "caller". You should be able to get the behavior you want by overriding the save() method on your models. --~--~-~--~~~---~--~~ 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: Sniffing around django
On 6/27/06, toth anna <[EMAIL PROTECTED]> wrote: > > Tom Tobin <[EMAIL PROTECTED]>: > > You should be able to get the behavior you want by > overriding the > > save() method on your models. > > Is there any usable examples somewhere for me? Here's the general idea: http://www.djangoproject.com/documentation/models/save_delete_hooks/ In the save() method, place whatever logic you want to run before you call the "real" save() via super(). --~--~-~--~~~---~--~~ 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: Sniffing around django
On 6/27/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > On 6/27/06, toth anna <[EMAIL PROTECTED]> wrote: > > > > Tom Tobin <[EMAIL PROTECTED]>: > > > You should be able to get the behavior you want by > > overriding the > > > save() method on your models. > > > > Is there any usable examples somewhere for me? > > Here's the general idea: > > http://www.djangoproject.com/documentation/models/save_delete_hooks/ > > In the save() method, place whatever logic you want to run before you > call the "real" save() via super(). Argh. I *really* have to keep better track of which list I'm posting/replying to; this thread belongs on django-users. :-) --~--~-~--~~~---~--~~ 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: Auto-escaping patch
On 7/16/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> I have put an initial version of the auto-escaping patch I mentioned
> yesterday into ticket #2359. I'll briefly describe what it does below.
> The patch includes changes to the core and a test suite for the
> auto-escaping changes (which is about half the patch).
Reading through the changes, it looks pretty good (and a +0 from me)
-- with my quibbles noted below. :-)
> What are the issues at the moment?
> --
> Now we get to the things I want to sort out before going much further.
>
> (1) Any violent (or even just passionate) objections to using terms like
> "safe" and mark_safe()?
> - Should we use Simon's original proposal of escaped and
> mark_escaped()? I feel "safe" is a bit more consistent with the
> behaviour (an opposite-but-similar term to Perl's "tainted").
Here's a double-barreled passionate objection: 1) Templates aren't
always going to be used for outputting HTML; the term "safe" loses
meaning in non-HTML contexts. 2) "Safe" conveys a moral tone, IMHO;
"escaped" comes across as much more neutral.
> (4) Should generic views use SafeContext by default?
> - I haven't touched this yet, but it's not an insane idea. I
> guess most people will divide along the same lines as those
> wanting auto-escaping on or off by default. The waverers will be
> those favouring consistency over all. I'm not a big enough
> generic views user to really have a vote in this one.
Definitely not; this goes back to "don't screw with my data unless
instructed to".
> (5) Adrian, Jacob: do you guys still want "off by default"?
> - I *really* don't care what the answer is here, but I would
> rather not have to change things after porting everything under
> contrib/ .
>
> - For people thinking it's auto-escaping or nothing, {%
> autoescape on %} at the beginning of a template (and {%
> endautoescape %}) at the end is not a huge imposition.
Changing to "on by default", as I've stated in the past, turns this
whole proposal into a *vehement* -1 from me. I'll let Adrian/Jacob
speak for themselves, but I think this has already been discussed
extensively and shot down.
--~--~-~--~~~---~--~~
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: new field idea
On 7/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi django-developers, > > I had the need for a field type similar to USStateField: an > OlympicNationField which takes 3 uppercase letters to the official olympic > nation abbrevation. I would feel better using ISO 3166-1 country codes (see http://en.wikipedia.org/wiki/ISO_3166-1 ). --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
Jacob sits a couple of seats over from me, and he's on his way out the door; he says he'll take a look as soon as he gets home. :-) On 7/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > It looks like I just got blacklisted when I tried to post the > compilation of tutorails that i mentioned on the user list. Any chance > I can get unblacklisted? I can also send the wiki formatted file for > anyone to post for me. > > I assume it happened because the list is mostly a list of links. Any > help would be appreciated. > > Chris --~--~-~--~~~---~--~~ 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: Akismet spam filtering for Trac
On 7/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Don't mean to pester but is there a way for me to post the list on the > wiki? Like I said, I think I'm blocked now. :( Ouch, I'm sorry. :-( I'm sure Jacob meant to get back to you, but I know he's been insanely busy with preparations for OSCON (which he's attending at the moment). I'll bug him again for you. :-) --~--~-~--~~~---~--~~ 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: Consider releasing a .95 beta
On 7/27/06, Joe <[EMAIL PROTECTED]> wrote: > > Adrian Holovaty wrote: > > > > There's no real reason, other than the fact that the core developers > > all use (and are happy with) the Subversion/development versions of > > Django, with which we've been enjoying the great changes to Django > > over the past few months. We're working on the .95 release as I type > > this, though. > > Hey, I'm with you 100%. I would use the development version if I > could. Unfortunately, my project manager thinks 'development' means > 'broken'. You know how those pesky project managers can be :) In line with other sentiments I've expressed here in the past: IMHO, this means your *project manager* is addled, not Django's release process. If you can understand that the development version is stable enough to use, but your project manager can't, your project manager doesn't deserve his title. :p --~--~-~--~~~---~--~~ 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: Consider releasing a .95 beta
On 7/27/06, Joe <[EMAIL PROTECTED]> wrote: > > > Tom Tobin wrote: > > In line with other sentiments I've expressed here in the past: IMHO, > > this means your *project manager* is addled, not Django's release > > process. If you can understand that the development version is stable > > enough to use, but your project manager can't, your project manager > > doesn't deserve his title. :p > > Yeah, but I'm not going to tell him that. The only option I have is to > ask for a release! Pick a subversion revision number -- the latest at the moment is 3463, and just tell him that it's Django 0.94, where is the revision number, thus Django 0.943463. ;-) --~--~-~--~~~---~--~~ 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: Consider releasing a .95 beta
On 7/27/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > On 7/27/06, Joe <[EMAIL PROTECTED]> wrote: > > > > > > Tom Tobin wrote: > > > In line with other sentiments I've expressed here in the past: IMHO, > > > this means your *project manager* is addled, not Django's release > > > process. If you can understand that the development version is stable > > > enough to use, but your project manager can't, your project manager > > > doesn't deserve his title. :p > > > > Yeah, but I'm not going to tell him that. The only option I have is to > > ask for a release! > > Pick a subversion revision number -- the latest at the moment is 3463, > and just tell him that it's Django 0.94, where is the > revision number, thus Django 0.943463. ;-) Or, bugfix style: Django 0.94.3463 Or, alternately, just Django 0.3463. (Tell him we had a LOT of releases while he wasn't looking.) --~--~-~--~~~---~--~~ 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: Consider releasing a .95 beta
On 7/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Tom Tobin wrote: > > On 7/27/06, Joe <[EMAIL PROTECTED]> wrote: > > > In line with other sentiments I've expressed here in the past: IMHO, > > this means your *project manager* is addled, not Django's release > > process. If you can understand that the development version is stable > > enough to use, but your project manager can't, your project manager > > doesn't deserve his title. :p > > You are criticising a project manager that isn't confortable using a > development svn branch in a production envirment. > > > WOW. > > > You are a moron! > > > > First, the django developers are quite egotistical if they are claiming > that there nightly .95 build is stable, when at any time they could > introduce a bug. The whole point of a release is to do proper testing > and you can say "yes, we froze the code and did tons of testing so we > feel it is stable". > NOT "yeah i hack it everynight and I'm so awsome i never write a > single bug (and my poop doesn't stink -- James Bennett)". > > I thought the whole point of .95 was to get the framework where there > wouldn't be any backward incompatabilitys example(meta.blah vs > model.blah), not a feature race. Between this and your prior message on this thread, I have cause to congratulate you: you are the first poster on either Django list to make it into my killfile. Considering that your immature behavior is highly unusual among community participants, I suspect you may be the last for quite some time. --~--~-~--~~~---~--~~ 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: Default escaping -- again!
On 7/27/06, Luke Plant <[EMAIL PROTECTED]> wrote:
>
> Unless I missed something, the default escaping proposal hasn't been
> committed. And I've had an idea that I don't think came up, that I
> thought was perhaps worth throwing into the mix.
>
> Basically, {{ }} does escaping automatically, and {! !} doesn't.
>From what I recall of conversations on the subject, default behavior
will not be changed to auto-escape. Auto-escaping, under whatever
proposal is accepted, will require some form of action to enable.
--~--~-~--~~~---~--~~
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: the template system's whitespace handling
On 8/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > As someone who spends most of my day job working in Djangos' template > system, I can say that I would also prefer the same evaluation as Gary > 99% of the time. I really think it should be the default. I have to concur with Jeff; while my day job primarily involves models and views, the default template behavior vis-a-vis whitespace and template tags drives me fairly crazy in my personal projects. ^_^ I understand, theoretically speaking, the potential need for preserving every last line of whitespace . . . but I'm having a hard time coming up with a practical use case where Gary's proposed evaluation would cause a problem. --~--~-~--~~~---~--~~ 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: the template system's whitespace handling
On 8/4/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
>
> In Rails, template tags can have an extra hyphen at the end to denote
> the fact that they should consume the newline right after the tag. So:
>
> {% some_tag %}
>
> Would look like this:
>
> {% some_tag -%}
I can't help but feel that this syntax is ugly and, furthermore, easy
to miss while scanning through a template. I wouldn't mind having to
set something once in my root-level template (e.g., {% chomp %}{%
endchomp %}) if it was picked up by child templates inheriting from
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Proposal: manipulator-aware validators in post-MR
After two far too-long days at work, far too much head-to-desk banging at home, and a rather stupid aha-I've-got-it, oh-wait-I-don't, I-need-sleep on Django-users, I've come to the conclusion that post-MR Django doesn't support manipulator-aware validators. This was possible in pre-MR-removal versions of Django by defining a method on a model starting with ``_manipulator_validator``; one could then access the original object via ``self.original_object`` in the method. I'd like to restore this ability to Django trunk; there are a couple of ways I could go about this, and I'd like input as to which would be cleaner: 1) Have a do-nothing ``ManipulatorValidator`` class to subclass from; ``django.fields.Field.get_manipulator_fields`` would then set a ``manipulator`` attribute on instances derived from this class, enabling the __call__ method to access the manipulator. 2) Write manipulator-aware functions with arguments ``(manipulator, field_data, all_data)`` instead of the standard ``(field_data, all_data)``, and set a ``takes_manipulator`` attribute on the validator (which could be a class attribute or a function decoration); test for this attribute in ``django.fields.Field.get_manipulator_fields``, and if it exists and evaluates to True, wrap the function with the manipulator passed in and expose only ``(field_data, all_data)``. I've already gotten the first case working, and I'll tackle the second after work tomorrow; I'll report back with my thoughts after comparing the two. Thoughts? --~--~-~--~~~---~--~~ 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: Proposal: manipulator-aware validators in post-MR
On 8/9/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I've already gotten the first case working, and I'll tackle the second > after work tomorrow; I'll report back with my thoughts after comparing > the two. I actually implemented the second case (a ``takes_manipulator`` decoration) last night as well, and I'm leaning towards it as feeling cleaner right now. Also, I thought I'd add that you *can* implement manipulator-aware validators in trunk, as `pointed out by Matthew on Django-users`__; the key problem is that they don't work in the admin, which is what my solution aims to solve (and, furthermore, the existing method seems convoluted and messy IMHO). .. __: http://groups.google.com/group/django-users/msg/a76be4c94631ec80 --~--~-~--~~~---~--~~ 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: Proposal: manipulator-aware validators in post-MR
On 8/9/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > I'd like to restore this ability to Django trunk; there are a couple > of ways I could go about this, and I'd like input as to which would be > cleaner: I came up with a third possible way of handling this (which is nearly identical to the second): instead of wrapping validators that have a ``takes_manipulator`` attribute, would there be an issue with introspecting for the number of arguments to a validator, and wrapping if there are three (or, for a method, four)? --~--~-~--~~~---~--~~ 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: Thoughts on extensibility of the admin app
On 8/11/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 8/11/06, Karl Guertin <[EMAIL PROTECTED]> wrote: > > I'll admit that I haven't really looked into how the admin system > > works post-magic removal but I could work 90% of the extensions I want > > if I could 1. register a callback for changes to a particular model > > and 2. Inject javascript into a particular page in the admin > > interface. > > Not arguing with the idea of making the admin friendlier to > extensibility, but... > > #1 should be possible with a custom save() method on the model > (testing in the save() method for 'if self.id' will tell you whether a > new instance is being created or an existing one is being edited -- no > ID means you're dealing with a new instance). > > #2 is possible with the 'js' option in the Admin inner class: > http://www.djangoproject.com/documentation/model_api/#js Or even more flexibly for #2, you can override the template for a given app or a given model, and stick the Javascript in there. (The ``js`` option is going away in favor of this, IIRC.) --~--~-~--~~~---~--~~ 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: Proposal: manipulator-aware validators in post-MR
On 8/11/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > On 8/9/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > > I'd like to restore this ability to Django trunk; there are a couple > > of ways I could go about this, and I'd like input as to which would be > > cleaner: > > I came up with a third possible way of handling this (which is nearly > identical to the second): instead of wrapping validators that have a > ``takes_manipulator`` attribute, would there be an issue with > introspecting for the number of arguments to a validator, and wrapping > if there are three (or, for a method, four)? Replying to myself once again . . . :-p I've created ticket #2535, which has an attached patch for implementing my proposal using currying and introspection for the number of arguments. With the patch applied, giving the validator access to the manipulator is as easy as adding an extra parameter:: def my_validator(manipulator, field_data, all_data): model = manipulator.model if manipulator.change: original_object = manipulator.original_object # . . . do stuff . . . --~--~-~--~~~---~--~~ 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: Trac and Akismet rejected spam
On 8/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have the same. I've tried to clean up the main wiki page and it > rejects the changes. Core-dev-types: would it be okay to whitelist these guys? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Are you getting caught in the Django Trac's spam filter? Read this.
It seems I've been designated the "Django spam maven"; what this means for you, if you've been getting caught in the Django Trac's spam filters, is that you need to write me and let me know your IP address (or the typical range of IP addresses you use) so I can whitelist you. Once I do this, you won't trigger the "Akismet rejected spam" or any other spam-rejection errors. Tom Tobin [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: [patch] URLField says all links to Wikipedia are invalid
On 8/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Akismet thinks this bug is spam, so I cannot submit it to Trac. If you're being locked out due to the spamfilter (and this goes for anyone else), please email me with your IP (or IP range) or, if you have a wide dynamic IP range, the longest part of your hostname that will stay the same. I'll get you whitelisted ASAP. --~--~-~--~~~---~--~~ 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: 3 patches I've added
On 8/28/06, Joel Heenan <[EMAIL PROTECTED]> wrote: > > I have noticed there is a great number of patches like mine that don't > ever seem to be reviewed and all seemed to be assigned to Adrian but > he seems to be concentrating on new features at the moment. As someone > who wants to contribute to Django and is happy to fix these bugs > should I just keep going submitting these patches or is there someone > I should enter into a dialogue with about getting them committed? http://www.djangoproject.com/documentation/faq/#i-submitted-a-bug-fix-in-the-ticket-system-several-weeks-ago-why-are-you-ignoring-my-patch In summary: the core devs are really busy, and if they haven't done anything with your ticket it just means that they haven't gotten a chance to go over it in detail. If a ticket is definitely unsuited for Django, they would have closed it immediately. >From my own experience watching Django's timeline, the core developers tend to go on "rampages" every so often and address many tickets at once; if you submitted these tickets recently, there's a good chance they'll get some love next time that happens. :-) --~--~-~--~~~---~--~~ 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: Template variable evaluation for True/False ?
On 8/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I would agree if you take 'False' as a real string which shouldn't evaluate
> to False, but I had the following templatetag called:
>
> {% mytag "some string" False %}
>
> Which now resolved in an error:
I'm wondering why you need to pass the literal value False into a
templatetag in the first place; if you're testing whether something
evaluates to boolean True or False, why can't you handle that inside
the tag's logic? Or if you *really* needed to pass either, why can't
you handle the conversion from some pre-defined string (e.g., 'T' or
'True' or whatnot) in said logic?
--~--~-~--~~~---~--~~
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: Feel proud today, very very proud especially of 0.95 and MR
On 8/31/06, antonio <[EMAIL PROTECTED]> wrote: > > Anyhow, this week, we completed our migration to 0.95 and magic removal > which was painful but has shown us how much more great work you guys > have been up to. Before the move, we were running on a hacked version > of 0.91 that we had spent some cycles optimizing, mostly around ORM > caching, and my big fear was that when we rolled live with MR, we were > going to see all sorts of crazy slow-downs. Again, I am thrilled to > have been proven wrong. The site is looking fantastic, I must say. More than anything else, though, I'm thrilled that the Microsoft Clippy-esque pestering-Tabblo-face is gone. ;-) --~--~-~--~~~---~--~~ 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: Escaping in templates...
On 4/16/07, James Bennett <[EMAIL PROTECTED]> wrote: > > Short and sweet: since we're already planning some > backwards-incompatible changes for the next release, how about we > hammer out auto-escaping of template output while we're at it? Even > those of us who don't like it (myself included) are probably at the > point of accepting that we have to do it eventually, so why don't we > get it out of the way? I haven't been participating much on Django-dev over the last few months, but this made me go "eep?". I'm still -1 on autoescaping as implemented in the latest patch in #2359; the terminology used is strongly HTML-centric (e.g., ``convert_to_words.is_safe`` -- safe from what?). We should be using naming that makes it explicit that this is for HTML escaping, since Django templates see a wide range of application (e.g., emails, CSV files, Javascript . . .). If that's fixed, I'll consider myself -0 if autoescaping is off by default, and -1 otherwise. I still consider autoescaping to be a poor substitute for actually *knowing your code*, but I get the feeling at this point that the social pressure in its favor is going to win out. --~--~-~--~~~---~--~~ 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: Escaping in templates...
On 4/17/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > > > I'm still -1 on autoescaping as implemented in the latest patch in > > #2359; the terminology used is strongly HTML-centric (e.g., > > ``convert_to_words.is_safe`` -- safe from what?). We should be using > > naming that makes it explicit that this is for HTML escaping, since > > Django templates see a wide range of application (e.g., emails, CSV > > files, Javascript . . .). > > > > If that's fixed, I'll consider myself -0 if autoescaping is off by > > default, and -1 otherwise. I still consider autoescaping to be a poor > > substitute for actually *knowing your code*, but I get the feeling at > > this point that the social pressure in its favor is going to win out. > > Malcolm hasn't tried to implement a general escaping framework to escape > mail, xml, pdf or else. It's only html escaping. So I don't see why > the terminology shouldn't be from html. > > A general escaping framework has been rejected, IIRC. First, Django is a > web development framework, and as such mostly produces html. Second, the > main motivation for auto-escape is to have a safeguard against scripting > attacks, and this is also for html. I think you misunderstood me; I'm not saying there should be a general-output escaping framework. I'm saying that if there *is* an HTML escaping framework, the object/variable naming should make it clear that we're dealing with HTML-specific escaping where such code comes into contact with the general templating system. Setting "is_safe" on a filter doesn't tell me a thing about what it's "safe" from; setting "is_html_safe" *does* give me an idea about what's going on. > Maybe in your case "knowing your code" is fine, but even within django > missing escapes have shown up as bugs in the past. This is the number one > reason of cross site scripting holes. I don't think this line of argument is ever going to reach resolution between the pro and con camps regarding auto-escaping, so I'm not really trying to argue that point here (my strongly-held views notwithstanding). I'm trying to make sure that whatever auto-escaping implementation *does* get accepted is tolerable. :-) --~--~-~--~~~---~--~~ 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: + Important: Repent, Completely trust in God only and, Love Him with all of your heart.
On 5/14/07, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Tuesday 15 May 2007 01:09:08 Secret wrote: > > There is a section below with the title "Atheism and Evolution are > > WRONG." > > > > All those who have sinned deserve to suffer in Hell forever. "Pride" > > is an example of a terrible sin. > > As a Christian, I am extremely embarrassed by this kind of inappropriate > and inconsiderate "evangelism" (regardless of whether or not I agree > with what the guy wrote, and whether he had good intentions in sending > it etc.). I imagine the atheists on this list find it even more > annoying, so I wanted to preemptively apologise on behalf of the > Christians for this. (Apologising for what other people have done > seems to be all the rage these days, why not me :-) If you're not part of the problem, there's no need to apologize; we atheists just click our "spam" buttons and hope the filters learn better for next time. ;-) --~--~-~--~~~---~--~~ 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: <% include %> should support select_template like sytax too
On 11/28/05, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > <% include template_name %> includes the named template which is like > get_template of the Python API for loading templates, for consistancy we > should have a comma seperated template list similer to select_template. > (Untested) Patch attached. Please submit patches (along with tickets) to Django's Trac at http://code.djangoproject.com/
Re: <% include %> should support select_template like sytax too
On 11/28/05, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > On 11/28/05, Tom Tobin <[EMAIL PROTECTED]> wrote: > > Please submit patches (along with tickets) to Django's Trac at > > http://code.djangoproject.com/ > > Done: http://code.djangoproject.com/ticket/949 Thanks! The Trac makes it much easier to keep, well, *track* of what's going on. :-)
Re: <% include %> should support select_template like sytax too
On 11/28/05, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Just that I felt dropping a mail on the list gives a little more visibility > and opportunity to get feedbacks, than just filing a ticket, which only a > handful of core-thus-busy developers monitor. Hmm, I actually have the opposite impression (albeit which may be entirely wrong); I think the Trac actually has very high visibility -- being that it's prominently linked/featured on the project website -- and is closely monitored by many of the developers and users (based on my observations from IRC, etc). If anyone wants to correct me here, please do. :-)
Random Tag
I'd be interested in feedback on ticket #919, which implements a "random" tag which parallels the functionality of the random filter. I'd also be curious as to where the best place would be to implement a possible helper class for the weighted random option, as I was considering making the weighted functionality available to the random filter as well. Thanks! :-)
Re: Random Tag
On 11/29/05, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > What is the use case of this tag? This looks like logic, template in > philosophy dictates the layout of the data generated in the views. Putting > weights for example, is it not more of a logic than presentation? Some measure of logic is naturally inescapable in templates. I decided to implement this particular tag as I was facing scenarios where keeping the parts to be randomly alternated in models, to be pulled in through the random filter, was sheer overkill (e.g., alternating between a handful of taglines, images, or color codes), and in many of these cases it seemed simply odd to not have display-related information directly in the template (e.g., again, color codes). > One common reason not to include such features which may not be used too > much, is code bloat: more things to fix and maintain, every change in > template system will have to be migrated to the 100 or so lines of code that > you are adding. I sincerely believe there is enough potential for widespread use for inclusion, else I would have simply retained it in my own extensions. > Putting weights in blocks may be better than clubbing them together? > You don't have to worry about the syncing order and number of weights listed > in top random block with the blocks specified. You then have to worry that you haven't missed a block, although I grant that it might be best in such a case to simply assume that undefined weights are automatically "1" if other blocks have weights defined. I also find it visually unpleasing to have a weight argument in two possible tags (here, "random" and "or"); if the weights were not defined in the random block, I would rather see entirely separate "choice" / "endchoice" subblocks defined (an alternative I initially considered, and rejected as increasing tag clutter unnecessarily). Finally, a benefit of having all weights together is that it is easier to tell at a glance what the total weight is, and read the "ratio" (e.g., 1,4,5 is simply a 1:4:5 ratio). > Looking at the patches listed on tracker I cant stop being amazed about how > clean most of them look. Kudos the elegant design of django. I don't know if this is meant as a compliment towards my submission, but I certainly agree that Django's structure makes it quite easy both to use and extend. :-)
Re: Random Tag
On 11/29/05, Tom Tobin <[EMAIL PROTECTED]> wrote: > I'd be interested in feedback on ticket #919, which implements a > "random" tag which parallels the functionality of the random filter. I've split out a weighted random class, `RandWeight`, that lives in `django.utils.randweight`. I'm not certain anymore that this is a good candidate for a filter, as it needs to be initially "built" before it can return any items. While a tag doing such can build its sequence once and simply return an item on each pageview, a filter would (if I understand correctly) incur the overhead of building the weighted sequence from scratch each time. Is there a way around this that I'm missing? And if not, should I still keep the weighted functionality split out in its own class (e.g., for use in custom views, etc.)? (I haven't posted a new patch yet, pending feedback.)
Re: Random Tag
On 12/2/05, Tim Keating <[EMAIL PROTECTED]> wrote: > > -1 from me. As a *user*, I would much rather just generate random > content inside of my view code. I'm surprised this makes you -1 rather than -0; do you hate it that much? :-) > I'd like to point out the cited example > (random photo on Flickr) can't be done with this technique, since this > is baked into the template. It really depends on the site; if you're drawing from a truly large number of random photos, it's not really feasible for the tag; on the other hand, it's perfect for a site which rotates among a small, static number of photos.
Re: Random Tag
On 12/3/05, Tim Keating <[EMAIL PROTECTED]> wrote: > > "Hate" is too strong a word. However, I do feel that this is not a > positive addition. > My apologies, I hate to be negative about someone else's hard work. Don't worry, I'm merely poking back in jest; I asked for criticism in the first place, and in a way I consider negative criticism *better* in that it forces one to address the criticism in either one's work (i.e., seeking to correct or even abandon one's work) or one's defense (i.e., being able to explain why one disagrees with the criticism). > We already have the ability to generate randomized *content* by writing > some fairly simple Python, and that's what it sounds like the intent of > this tag is. However, based on my (admittedly, highly subjective) > perception of the three-tiered architecture, templates are not the > place for generating content. It isn't that I object to adding logic to > the template layer -- some logic is inevitable because some form of > code is the easiest way to perform certain layout tasks (e.g. > assembling a table). If this tag was meant as a way to scramble your > LAYOUT, then I would be right behind it, but I don't see anyone > suggesting that as a way for this to be used. (Nor do I imagine there's > a real demand for that functionality :-) I'll give you the original case that led me to create this tag: in the course of porting a website to Django, I found myself having a difficult time when I wanted to rotate among a small, fixed number of taglines (e.g., Slashdot's "News for nerds"). Defining these as a model seemed like ridiculous overkill; they were rarely going to change. Furthermore, as part of what I considered the site's *layout*, they felt odd not being defined inside of the template. I hope this makes my rationale more clear, even if you don't agree with my solution. :-)
Re: magic-removal q
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > > Basically, promote Admin settings to a full inner class, rather than > nesting it in meta. It would still end up in meta though. +1; the improvement in readability would be welcome. The Admin declarations are too visually messy at the moment, IMHO.
Dojo Licensing
Since the idea of incorporating Dojo as Django's AJAX toolkit was brought up, I've been researching the toolkit; I must admit that I'm bothered by statements from the project regarding its licensing on the Dojo-interest mailing list -- specifically, claims by the project about the Academic Free License. So what the hell does this have to do with Django, now that Dojo is apparently dual-licensed AFL/BSD? The Dojo project seems to have an odd way of interpreting software relicensing. They adhere to the positions of the AFL's creator, Larry Rosen, who in turn claims that the AFL is GPL-compatible, even though the AFL has restrictions that the GPL does not possess (e.g., patent defense) and thus not compatible according to the FSF. Rosen in general claims that one can release AFL-licensed code under *any* other license so long as you *also* abide by the terms of the AFL (which, according to Rosen, may be buried in the codebase and not explicitly "up front"); IANAL, but it is my understanding that one can only relicense code if the new license's terms are a superset of the old license's terms. If we import Dojo, we want to make *very* certain that Dojo is 100% cleanly-BSD licensed and not affected in whole or in part by "submarine" AFL licensing. If you would like to research the relevant discussions from Dojo-interest, some good starting points on Google are "site:http://dojotoolkit.org/pipermail/dojo-interest/"; plus "license", "licensing", "gpl", "afl", or "bsd". Thoughts? Am I just being paranoid? :-)
Re: Proposal: Django should support unicode strings
On 1/10/06, Antonio Cavedoni <[EMAIL PROTECTED]> wrote: > > Maybe we could start a "unicode" branch right after "magic-removal" > is merged back into the trunk? +1 to that; I'd rather not see magic-removal last forever as a "catch-all", diverging further and further from trunk. :-)
Re: ifequal support for AND OR
On 1/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello,
> In my recent project I have been finding myself wishing that the {%
> ifequal %} tag had support for AND OR.
Have you considered passing a boolean into the template from the view
with the corresponding value? I don't think the omission of complex
AND/OR logic was an oversight; I believe it's a deliberate attempt to
keep templates from becoming jammed full of business logic.
Re: Proposal: Django namespace simplification
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I like this a lot! SimpleContext is good...Other thoughts? BaseContext?
magic-removal admin URLs / model names: singular or plural?
I opened ticket [1259] as it seems that there's a mismatch in magic-removal between aspects of the admin interface regarding model names being referenced as singular or plural. I believe there was recent discussion on standardizing to singular model names; if someone can confirm which way this is supposed to go, I'll try to whip up a patch. :-)
Re: Making models validation-aware
On 1/22/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I've been messing with manipulator code in magic-removal, and it > struck me that we could avoid a lot of the boilerplate, cruft and > newbie confusion by making models validation-aware. +1; this would even be useful in non-standard scenarios. E.g., I have a cronjob for my feed aggregator which is regularly pulling in potentially bad data; being able to leverage the admin/form validation code here would be great.
Re: Typo on magic-removal sql migration script?
On 1/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > I haven't been following the magic removal branch closely, but here: > http://code.djangoproject.com/wiki/RemovingTheMagic > > There is a migration script for mysql. This line looks wrong: > ALTER TABLE auth_groups_permissions RENAME TO auth_group_permissions; > > Rename to the same name? > Perhaps: > ALTER TABLE auth_groups_permissions RENAME TO auth_group_permission; That in particular should be: ALTER TABLE auth_groups_permissions RENAME TO auth_group_permissions; which the wiki currently shows. The "permissions" is plural as it's pulled from the name of the ManyToManyField as defined in its model -- which, in this case, is "permissions". That raises a wider question: do we want to singularize those field names as well? It's more of a cosmetic issue, as it doesn't affect the core of the table-name-generating code -- but it would induce more breakage as applied to the various contrib/etc. models, so better to do it in magic-removal if at all.
Re: Django auth magic
On 2/3/06, Brian William Kaplan <[EMAIL PROTECTED]> wrote: > > I'm not able to write the patch because Django is placing too many > restrictions on what I can do as far as this. Err, simply because some people are raising concerns about the proposed implementation? Or do you mean something to do with the structure of the software itself? If the former, I hope you'll realize that this *is* a collaborative project . . . .
Re: How about converting python config files to text config files
On 2/9/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 2/10/06, limodou <[EMAIL PROTECTED]> wrote: > > > > I'v summited a ticket > http://code.djangoproject.com/ticket/1337 for this. > > > > What do you think about? > > -1 from me. I second that -1; by the logic in that ticket, we might as well rewrite the module definitions in a config.ini format since end users might want to fiddle with the modules in a given deployed app. :-p Seriously, though, I don't see Python's syntax as an obstacle for casual config tweaking. I'm guessing the use-case in the ticket is concerned with those who might someday be making use of Django with ready-to-run plug-in applications (whether from django.contrib or third parties), with little concern for playing with models, views, and the like. A basic settings.py is nothing but variable assignments with strings and tuples; as for urls.py, plug-in apps will likely handle all the heavy regex lifting on their own end, leaving the installing user to drop a simple include line into the file. I'm not sure if a user who isn't comfortable doing even that much should be installing Django on their own. ;-) --~--~-~--~~~---~--~~ 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: How about converting python config files to text config files
On 2/12/06, limodou <[EMAIL PROTECTED]> wrote: > > I don't want to touch this subject more. If you don't understand I'll > explain it again: I think we understand what you're saying; the problem is that we don't agree. ;-) As others have pointed out, it is perfectly acceptable to create your own configuration files, in your own custom format for your automated tool, and have the Django config modules read them in. Once you set up the Django config modules properly to do this, you would never have to touch them again (barring backwards-incompatible changes or whatnot -- and maybe not even then, depending on how you set things up). Where we run into an issue is your request for such a mechanism to be foisted upon Django itself; as the string of -1 comments thus far indicates, we specifically *want* and *prefer* Django's config files to be Python modules. Again, this does not in any way stop you from implementing your solution; we just aren't going to make it part of Django proper. :-)
Food for Thought: Yahoo User Interface Library
I know things have been fairly set on Dojo as of late, but I thought I'd give a heads-up as to Yahoo's new offering, the Yahoo User Interface Library. It's BSD 3-clause licensed, and seems to cover AJAX, visual effects, and widgets. http://developer.yahoo.net/yui/
Re: Food for Thought: Yahoo User Interface Library
On 2/14/06, limodou <[EMAIL PROTECTED]> wrote: > > On 2/15/06, Tom Tobin <[EMAIL PROTECTED]> wrote: > > > > http://developer.yahoo.net/yui/ > > > Yeah, I'v seen it also. It sounds good and the documents are also > well. But the widgets seems not very rich. Yeah, I've been noticing mixed reaction since the release; I haven't had a chance to play with it myself, but I figured I'd throw it out there for comparison's sake. If nothing else, we get to say we're satisfied that Dojo still does the job better. ;-)
Model API: blank=True vs. null=True for non-string fields; redundancy
There currently seems to be a bit of redundancy with regards to the "blank" and "null" field options; tickets #1043 and #1353 seem to be the inverse of one another, each addressing that one must specify both blank=True and null=True to get the expected behavior (i.e., being able to specify and save a blank/null value) for non-string fields. This IMHO violates the DRY principle; only one of these options should be required. Is there a scenario in which it would be useful to only specify one of these options, and not the other, for non-string fields? I can't imagine one offhand; one would either be able to save null values but be unable to enter them in the admin interface, or be able to enter them (as blank form fields) but be unable to save them. If only one of these options should be preserved for non-string fields, which? (In this case, I vote "null".) --~--~-~--~~~---~--~~ 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: Model API: blank=True vs. null=True for non-string fields; redundancy
On 2/18/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Saturday 18 February 2006 23:27, Tom Tobin wrote: > > Is there a scenario in which it would be > > useful to only specify one of these options, and not the other, for > > non-string fields? > > I have legacy data which requires allowing nulls in a date field, but I > never want to allow nulls to be entered using the admin interface. Hmm; while it would be good to support edge cases like that, I think the default should make general-use cases easier. Maybe null=True should automatically set blank=True for non-string fields, but still allow one to then explicitly set blank=False? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
"Invisible" form errors
When working with and troubleshooting forms, it can be a common mistake to have a particular field be required yet not present in the form. Currently, such a case will lead to a "please correct the error(s) below" message without those errors in question actually being displayed, as the errors are tied to display with their fields and cannot display if the field is not present in the form. As a solution, I worked up the patch in #1352; it adds an `error_dict_invisible` attribute to forms, and alters the relevant admin template to take advantage of this attribute. Thoughts, criticism, etc? --~--~-~--~~~---~--~~ 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: Model API: blank=True vs. null=True for non-string fields; redundancy
On 2/20/06, hugo <[EMAIL PROTECTED]> wrote: > > >There currently seems to be a bit of redundancy with regards to the > >"blank" and "null" field options > > So I am -1 on the proposal to get rid of one of those two. Every > combination (even null=True and blank=False - think about legacy data) > makes sense. And it is not a repetition, as both work on different > layers. What are your thoughts on the modified proposal stated in my reply to Luke (i.e., keep both, but have blank automatically set to True when null=True and then allow the explicit setting of blank=False)? As for every combination making sense, this may be the case — but instances when blank and null are set to the inverse of one another will be quite rare IMHO (especially the inverse of your example: blank=True and null=False, although perhaps some custom manipulator magic would come into play there), and the default case should make life easier for those 90%+ cases where one expects that being able to save null values implies that one should be able to submit blank form values. --~--~-~--~~~---~--~~ 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: Model API: blank=True vs. null=True for non-string fields; redundancy
On 2/20/06, hugo <[EMAIL PROTECTED]> wrote: > > blank=True with implicit null=True isn't probably what users would > expect when applying it to charfields. And having a rule where > charfields have null=False in combination with blank=True and > non-charfields have null=True with blank=True is rather icky - > context-sensitive defaults are bound to irritate. I myself have > blank=True quite often with charfields, much more often than with > non-charfields, so I think I am still -1 on that one. I never intended it to apply to charfields, but I see your and Luke's point regarding the context-sensitive defaults; it still feels like a non-optimal situation to me, but perhaps one without an optimal solution at the moment. Oh well, proposal withdrawn. :-) --~--~-~--~~~---~--~~ 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: [Changeset] r2386 - django/branches/magic-removal/django/core
On 2/24/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Friday 24 February 2006 23:36, [EMAIL PROTECTED] wrote: > > > magic-removal: Removed 'init-minimal', which wasn't doing anything > > useful > > It seems to be used by runtests.py...was this an oversight Adrian? Yeah, that one caught me by surprise too, especially considering that Adrian said the following only a few weeks ago in another thread: On 1/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I really like your idea of "init" and "init-minimal" -- that > accomplishes the clean split of auth/core into regular apps while > keeping it just as easy to install the basics. Let's do it! Did something change in our thinking here? --~--~-~--~~~---~--~~ 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: [Changeset] r2386 - django/branches/magic-removal/django/core
On 2/24/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > As I was creating init-minimal I thought it would actually do > something, but as I reorganized the modules, it looked more and more > like it wasn't needed at all. (I certainly thought it would be > necessary before I started though.) Some of the tests still rely on > django.contrib.contenttypes, but like I said in the comments, that > should probably be done in the setup for tests that rely on it. I > don't think init-minimal serves any purpose other than that, and as > such Adrian did the right thing for the long run. There is the matter > of the broken tests though ;-) Okay then; init-minimal, we had only a short time to get to know you . . . we'll miss you so! ::sniff:: :-D --~--~-~--~~~---~--~~ 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: Generic View - Proposed Patch for 'template_model_name'
On 2/25/06, ChaosKCW <[EMAIL PROTECTED]> wrote: > > Hi > > I have raised the following ticket: > http://code.djangoproject.com/ticket/1399 > > I propose adding a new paramter to the list_detail.py generic view to > allow you to name your model/objects to something other than 'object' > or 'object_list'. > > I prospose and feel that more meaning names make templates more meaning > full, more intuitive and this better to read, code and debug. Err . . . they *are* supposed to be *generic* views, right? :-) This would *subtract* from the usefulness of a given template using this; your particular object's name is hardcoded into the template, making reuse harder. I'm somewhere between -0 and -1 on this. --~--~-~--~~~---~--~~ 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: Generic View - Proposed Patch for 'template_model_name'
On 2/25/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > How likely is it that you will reuse that for a different type of > object? Even if you do, it is pretty likely that any object which has > the same interface as my 'person' example could be called > 'person' (even if it was really 'Customer', say) without confusion. There are instances where objects have *partially* similar interfaces, and template bits are pulled in with the include tag, e.g., you might have a set of fields on several types of objects for each of which you'd like to use an identical, tweaked rendering. > The suggestion would help improve consistency for templates used by > custom views and templates used by generic views (unless I'm the only > one who uses specific rather than generic names in templates). I tend towards generic names simply because it makes swapping out and reusing template bits, and/or renaming models, easier. I suppose I've come to rest at -0; I still don't find it a fantastic idea, but I can't see how it would particularly *harm* anything I'm doing. :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: Regular Expression Field Lookups
Having found myself fiending for regular expression lookups in Django, I implemented the behavior in ticket #1465. It has a few caveats: case-sensitive regexes only work in PostgreSQL, PCRE-ish regexes only work in PostgreSQL and sqlite (the other backends use POSIX "extended" regexes), and regular expressions aren't available at all in the ADO/MSSQL backend. Furthermore, it implements a slightly backwards-incompatible change with regards to the admin interface: regular expression searches can be performed by placing the search phrase between slashes (e.g., /like this/). Thoughts, criticism, etc? --~--~-~--~~~---~--~~ 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: Proposal: Regular Expression Field Lookups
On 3/6/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > On Mar 4, 2006, at 3:36 PM, Tom Tobin wrote: > > Furthermore, it implements a slightly > > backwards-incompatible change with regards to the admin interface: > > regular expression searches can be performed by placing the search > > phrase between slashes (e.g., /like this/). > > I'm -1 on this; the admin interface isn't designed for people who > know what regexes are, and exposing the inconsistencies of different > db engines to those types of people is double-bad. Point taken; there's nothing stopping someone from plugging the functionality into the admin on a given install if they want it for development purposes, but having it there by default for 99% of users would add little in return for the mental overhead. > Other than that, your patch looks really good. It needs > documentation updates and tests before it can be checked in. I'll > write 'em when I get a chance, but if you're anxious you can always > write 'em yourself. > > That's actually a good point for anyone with patches who's still > paying attention: if you include docs and tests with your patches, > you'll decrease your wait time hugely. Yeah, I really ought to comb back over my submissions and address that. :-) --~--~-~--~~~---~--~~ 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: Django on python.org
On 3/7/06, Luke Plant <[EMAIL PROTECTED]> wrote: > > The new python site went live: http://www.python.org/ > > And Django is on the front page. Sweet. Although it would irk me a bit less if they dropped the silly "mega-" prefix. :-p --~--~-~--~~~---~--~~ 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: Fixing edit_inline on magic-removal
On 3/8/06, Christopher Lenz <[EMAIL PROTECTED]> wrote: > > The patch reverts some changes (such as the removal of core fields) > which were never really completed. While I'm aware that a much > improved version of edit_inline is on the way (using Dojo/AJAX and > all that), I think that the branch should be merged back into trunk > before that work is finished, i.e. that that stuff happens on a new > branch after magic-removal has been merged. While I'm a *huge* advocate of getting MR wrapped up and merged before it achieves sentience and takes over half the Internet, I'd rather have any breakage happen here and now rather than post-merge. I hate to say it, but a feature-freeze date for MR may be in order: if something backwards-incompatible hasn't been proposed and agreed upon before then, it doesn't go (and gets postponed to trunk, perhaps for post-1.0), and everything post-freeze is pure implementation and bugfixes. --~--~-~--~~~---~--~~ 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: proposal: endif, endfor etc assume whatever follows in tag is comment
On 3/13/06, Kieran Holland <[EMAIL PROTECTED]> wrote:
>
> I don't like the idea of arbitrary content in template tags either but does
> your "definite no" also apply to this old idea:
>
> {% endif %}{# endif start_process #}
>
> I think comments should be encouraged in templates and the
> comment/endcomment tag set is almost prohibitively verbose at times. HTML
> has special tags for comments too, so I don't think it is too programmerish.
+1 -- I liked this idea when it first came up, and I still like it.
:-p Comment syntax shouldn't be judged by the same rules as other
programmatic constructs; comments should be easy to throw down (and
remove) rapidly in any text editor, and I can't help but think that
the current comment syntax lends itself more towards use in an IDE
than vim, emacs, or [insert your favorite editor].
--~--~-~--~~~---~--~~
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: proposal: endif, endfor etc assume whatever follows in tag is comment
On 3/14/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Kieran Holland wrote:
> >>>
> >>> {% endif %}{# endif start_process #}
> >> I think that original idea is cleaner: {% endif start_process %}.
> >
> > Perhaps in this case, but I would prefer we don't do special-case
> > solutions to what is a more general problem. What about other tags:
> > ifequal? for? block?
>
> Good thinking. Let's do all endXXX tags with an optional comment.
I might be wrong, but I believe Kieran was arguing *against* such behavior. :-)
--~--~-~--~~~---~--~~
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: Django releases
On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > * Wait for newforms-admin to be done, merge it, and release 1.0 (well, > a series of beta/rcs, then final). This has been "plan A" all along. +1; this is The Right Thing. > * Release an interim release right away to respond to this supposed > "outcry" for a release. I've been opposed to this all along because I > don't the quality of something released just to get folks to shut up > will be all that high. A snapshot with an "official" number will > likely do more harm than good. -0; this is silly and wastes time, but isn't as actively harmful as ... > * Start a "train release" schedule: schedule a couple of 1.0 betas, a > rc or two, and then a final release. Features that are done by the > dates get released, those that aren't, don't. Make these dates > aggressive but not crazy. And -- here's the controversial part -- make > newforms-admin an "optional" part. If it's done, awesome; if not, > include it in the next release. The current admin has some bugs, yes, > but it's usable enough. As long as we advertised that it's on the way > out we shouldn't have too much trouble. -1. Releasing 1.0 with a major feature's implementation already depreciated seems like The Wrong Thing, no matter what project we're talking about. Echoing others: once we're past 1.0, this sort of aggressive timeline would be fine for minor releases. --~--~-~--~~~---~--~~ 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: pluralize filter bug(?!)
On Tue, Jun 10, 2008 at 7:13 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> However, I'm happy to defer to
> someone with a higher degree in grammarnazism.
With that in mind, I whipped out my copies of the Chicago Manual of
Style and Garner's Modern American Usage last night.
And came up short. :/
Reading through all the entries for "plurals", "numerals", "count
nouns", and the like yielded nothing useful. I'm strongly inclined
towards making anything other than the integer "1" be plural, but
there are oddities:
1) Decimals between 0 and 1: is it "0.5 meter" ("one-half meter") or
"0.5 meters" ("point-five meters")?
2) Negative 1: "-1 dollar" or "-1 dollars"?
3) The decimal "1.0": "1.0 second" ("one second") or "1.0 seconds"
("one-point-oh seconds", perhaps in deference to the significant
digit)?
I'm almost ready to burn an Ask MetaFilter question on this. ^_^
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Django community aggregator and non-English posts
The Django community aggregator includes non-English posts, which are unfortunately pure noise for those of us who don't understand other languages. Can we either restrict the aggregator to English posts, or at least create sub-feeds for English and non-English posts? I don't mean to tread on the toes of those making non-English posts, but English is the lingua franca of most open-source development (including Django); non-English posts are of dubious usefulness to the Django community at-large. By no means do I suggest that these individuals cease posting; I only question whether those posts belong in the aggregator. --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:01 AM, pi song <[EMAIL PROTECTED]> wrote: > Are they real posts? I thought just spam. They certainly *look* like real posts, but I can't understand anything outside of the technical (English) terms used. :) --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:05 AM, Arien <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 10:58 AM, Tom Tobin <[EMAIL PROTECTED]> wrote: >> >> The Django community aggregator includes non-English posts, which are >> unfortunately pure noise for those of us who don't understand other >> languages. Can we either restrict the aggregator to English posts, or >> at least create sub-feeds for English and non-English posts? >> >> I don't mean to tread on the toes of those making non-English posts, >> but English is the lingua franca of most open-source development >> (including Django); non-English posts are of dubious usefulness to the >> Django community at-large. [...] > > -0 on the general idea and that last sentence is plain false: > > http://www.jacobian.org/writing/2008/jan/30/arc/ Is it? The one language Django developers *around the world* are most likely to have *in common* is ... English. The language used in common for open-source developers from Brazil to Bulgaria is ... English. I'm *not* saying Django shouldn't support local languages or Unicode (which was the point of contention in that post)! I'm saying that *for the community as a whole*, English is how we all communicate with one another, and that an aggregator for that community at-large should contain English posts. Maybe non-English posts should go into a separate, secondary feed; maybe we should have a feed per language, as well as a language-agnostic "firehose" feed. Having *only* a firehose feed, as we do now, is a problem. --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:31 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I propose an option on the side of the page that asks whether or not > to translate the posts into english. The google translator is fairly > effective and a lot of the russian posts I have looked at have bee > very good(at least as good as they can be in. A slighty mangled > state). Interesting idea (using Google translation); an alternate "firehose" feed using that might be one option. --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 11:33 AM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > > It is not a problem. Just skip non-English posts at all. English is > international language of cource but not the one. Except it *is* a problem when I'm forced to deal with a regular influx of what is, to me, *noise* in my aggregator. I've come fairly close to actually unsubscribing from the Django aggregator over this; I thought I'd see if anything could be done before I lose what is otherwise an excellent resource. Again: I'm not suggesting that everyone speaks English, or that everyone should suddenly start posting in English even when their intended audience is local. I'm pointing out that the *core* language of the Django community is English (or have we been speaking something else on django-users and django-dev?), and that the primary feed should be English. I'd be *fine* with alternate-language feeds being available; I'd even be roughly +0 on making an English-only feed the "alternate". --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:02 PM, Arien <[EMAIL PROTECTED]> wrote: > > The non-English posts are clearly useful to the Django community as a > whole, as it appears that the majority of its members don't speak > English as their native tongue. I'm totally fine with non-English feeds being available. >> Having *only* a [language-agnostic] firehose feed, as we do now, is a >> problem. > > Why? Because, as I've mentioned earlier: users effectively get noise in their feeds. For any post in a language other than English, *the vast majority* of the Django community won't be able to read it. I'm not only talking about native English speakers here; why should we expect that a native Portuguese speaker will be able to read a Russian post? --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:04 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > I'll look into setting up language-specific feeds (and a general > non-English one). If it's easy, I'll do it. If not, anyone is welcome > to look at the djangoproject.com source and submit a patch; I'll > happily accept it. If you can't easily do it, I'll look into it; this is my bitch/gripe, after all. :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Djangochatter [WAS: Django community aggregator and non-English posts]
On Fri, Jun 13, 2008 at 12:07 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > There's an aggregator, IRC log, various mailing list archives, wiki > articles, ticket comments, localized community sites, the list goes on > and on. In the spirit of community-oriented sites (like djangosites, > djangosnippets, etc), I'd like to propose djangochatter, a site > dedicated to aggregated, managing and distributing communication > taking place in the Django community. > > Essentially, it could pull together information from *all* those > various sources, index it for searching, provide feeds for various > tags and keywords (users would have to tag entries manually). In light > of this discussion, I expect it could also reasonably auto-detect the > text's language, so users could sign up for a feed for whatever > language(s) they can understand. Mmm ... I like. There's a *lot* that goes on out there, and it tends to be in several different places; having something slurp it all up and spit it back out to-order would be nice. The Sphinx search engine (not to be confused with the documentation tool of the same name) would be a perfect fit, methinks; it's been doing a phenomenal job indexing disparate nuggets of data and serving them up in an integrated search for our new project at the Onion. > I don't have time to head this up, but I think it would be extremely > useful for everybody. I know I've spoken with a few people about this > in the past, but is anybody interested in heading this up? I'd love to > see it happen, and I'm more than willing to take part in discussions, > but I just can't dedicate myself too much to it at the moment. Ugh, time. I have a bad habit of assuming I have more of that resource available than I ultimately do. :) I'd definitely like to help, but I don't think I could assume a driving role at this point. (Chicago Djangonauts, languishing taghelpers patch, proper multiple time zone support ... meh!) Maybe a mailing list for now? --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:27 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > -100 > > Non-English post isn't noise! > > Some English posts has more less profit then non-English ones. *To me*, someone who can't read them, yes, they're noise. I'm sorry. If I can't read it, it does nothing for me but take up space and time. For someone who can read them, they are certainly *not* noise. --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:23 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > There is existing multi-lingual aggregator http://djangosearch.com/ That's just been mentioned in the new "djangochatter" thread as well ... very interesting. Continuing over there. --~--~-~--~~~---~--~~ 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: Community search [was: Django community aggregator and non-English posts]
On Fri, Jun 13, 2008 at 12:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Also for anyone interested, there's this: > > http://djangosearch.com/ Well. Damn. That looks like what we're talking about here. I wonder if it indexes everything the "official" aggregator does? --~--~-~--~~~---~--~~ 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: Djangochatter [WAS: Django community aggregator and non-English posts]
Bah, simultaneous thread-splitting. Send any replies to the other "djangochatter" thread. On Fri, Jun 13, 2008 at 12:23 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > On Fri, Jun 13, 2008 at 12:07 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: >> >> There's an aggregator, IRC log, various mailing list archives, wiki >> articles, ticket comments, localized community sites, the list goes on >> and on. In the spirit of community-oriented sites (like djangosites, >> djangosnippets, etc), I'd like to propose djangochatter, a site >> dedicated to aggregated, managing and distributing communication >> taking place in the Django community. >> >> Essentially, it could pull together information from *all* those >> various sources, index it for searching, provide feeds for various >> tags and keywords (users would have to tag entries manually). In light >> of this discussion, I expect it could also reasonably auto-detect the >> text's language, so users could sign up for a feed for whatever >> language(s) they can understand. > > Mmm ... I like. There's a *lot* that goes on out there, and it tends > to be in several different places; having something slurp it all up > and spit it back out to-order would be nice. The Sphinx search engine > (not to be confused with the documentation tool of the same name) > would be a perfect fit, methinks; it's been doing a phenomenal job > indexing disparate nuggets of data and serving them up in an > integrated search for our new project at the Onion. > > >> I don't have time to head this up, but I think it would be extremely >> useful for everybody. I know I've spoken with a few people about this >> in the past, but is anybody interested in heading this up? I'd love to >> see it happen, and I'm more than willing to take part in discussions, >> but I just can't dedicate myself too much to it at the moment. > > Ugh, time. I have a bad habit of assuming I have more of that > resource available than I ultimately do. :) I'd definitely like to > help, but I don't think I could assume a driving role at this point. > (Chicago Djangonauts, languishing taghelpers patch, proper multiple > time zone support ... meh!) Maybe a mailing list for now? > --~--~-~--~~~---~--~~ 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: Django community aggregator and non-English posts
On Fri, Jun 13, 2008 at 12:32 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 1:23 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote: >> There is existing multi-lingual aggregator http://djangosearch.com/ > > I didn't realize djangosearch broke articles down by language, > complete with individual feeds! Looks like that's one problem down. > Combine that with Jacob's quick-and-dirty custom search, and maybe > we've already got all the bases covered. I think someone's got a time machine and isn't sharing. --~--~-~--~~~---~--~~ 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: Djangochatter [WAS: Django community aggregator and non-English posts]
On Fri, Jun 13, 2008 at 12:36 PM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Fri, Jun 13, 2008 at 1:23 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: >> Ugh, time. I have a bad habit of assuming I have more of that >> resource available than I ultimately do. :) I'd definitely like to >> help, but I don't think I could assume a driving role at this point. >> (Chicago Djangonauts, languishing taghelpers patch, proper multiple >> time zone support ... meh!) Maybe a mailing list for now? > > So ... a new mailing list to discuss how to address the > ever-increasing number of communication outlets? Sounds like a great > idea. :( I don't know what it would take to manage something like that > though, so whatever works. Hey, it helps me segment my incoming mail. ;) Google Groups makes new mailing lists trivial. Although this may all be moot if that djangosearch site pans out as useful. --~--~-~--~~~---~--~~ 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: Experimental Git repository available
On Thu, Jun 19, 2008 at 11:39 AM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I've published an experimental Git clone of Django's SVN repository > (created with git-svn). If you're a Git user and want to use this > repository, be my guest. Please still upload patches to Trac for > review, but mention you're using my clone so I can more easily apply > patches from you. Also let me know if you publish your clones > anywhere; I'll add 'em as remotes. Noted this on the appropriate wiki page (and cleaned up the section on DVCS mirrors): http://code.djangoproject.com/wiki/DjangoBranches --~--~-~--~~~---~--~~ 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: Experimental Git repository available
On Thu, Jun 19, 2008 at 4:27 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > El jue, 19-06-2008 a las 14:03 -0700, Michael Elsdörfer escribió: >> FWIW (I'm currently playing around with all three of them), bazaar >> appears to support pushing into svn as well. > > Yes, with bzr-svn. Didn't play too much with that one. But Bazaar is > slow, *really* slow. I settled on Bazaar after extensively using both Git and Mercurial; it's *not* that slow, and it keeps getting faster with aggressive monthly releases. (But alas, this isn't the right place for DVCS advocacy.) ^_^ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
Thanks to some happy signal magic, I've come up with a "DateTimeZoneField" that takes a "time_zone" argument; time_zone can be a tzinfo instance or a field lookup to a zoneinfo string (e.g., "America/Chicago"). The field can then consume any sort of datetime object, and will always spit back a timezone-aware datetime object (i.e., one with a tzinfo instance attached). This works wonderfully *except* for the PostgreSQL backends; since those backends actually use settings.TIME_ZONE to munge the data coming in and out of the database, things get pathological fast when changing settings.TIME_ZONE or database backends. I propose that the PostgresSQL backends start acting like the other backends regarding time zones: they should start ignoring them completely (i.e., use a plain TIMESTAMP [WITHOUT TIME ZONE], and stop using SET TIME ZONE on connections), and leave time zone handling to appropriate Fields. All PostgresSQL supports in terms of *storage* is a fixed time zone offset, not the actual zoneinfo name; this isn't very useful, and causes problems such as the above. --~--~-~--~~~---~--~~ 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: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Wed, Jun 25, 2008 at 11:17 AM, Ramiro Morales <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 25, 2008 at 1:12 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > >> >> I propose that the PostgresSQL backends start acting like the other >> backends regarding time zones: they should start ignoring them >> completely (i.e., use a plain TIMESTAMP [WITHOUT TIME ZONE], and stop >> using SET TIME ZONE on connections), and leave time zone handling to >> appropriate Fields. All PostgresSQL supports in terms of *storage* is >> a fixed time zone offset, not the actual zoneinfo name; this isn't >> very useful, and causes problems such as the above. >> > > Is this related to ticket [1]1480?. Somewhat, yes; chiefly ticket #2626, though (which I originally reported, and now updated to reflect the proposal above). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Community representation, or, #django user "Magus-" needs to go far away
I don't spend much time in #django on Freenode, but for a moment, I'd like you to check the logs of that channel. http://oebfare.com/logger/django/ Specifically, I'd like you to note interactions with user "Magus-" (with trailing dash). I think we have a representation problem on our hands. If this guy is the first person most users encounter, they're going to have a *very* different view of the Django community than I consider ideal. I've heard from several individuals that they've migrated from Ruby on Rails *specifically because* our community was nicer; "Magus-" threatens that. I've had an awful experience speaking with Magus; one of my co-workers at The Onion has, as well. But don't take my word for it; check those logs. This guy has to go. --~--~-~--~~~---~--~~ 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: Community representation, or, #django user "Magus-" needs to go far away
On Wed, Jun 25, 2008 at 4:48 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Calling someone else out publically is a move of last resort, and one > that should be avoided at all costs. ::sigh:: I'm sorry; after this and another spat on the ChiPy list, I think I'm not very good at the whole tactful-resolution thing. :-( I'll try starting from scratch (starting with contacting Collin directly) in a few days. Meh. --~--~-~--~~~---~--~~ 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: Ordered ManyToMany
On Thu, Jun 26, 2008 at 9:05 AM, Mike Scott <[EMAIL PROTECTED]> wrote: > I understand there are some complexities involved, but essentially its > just creating a uniform javascript API to use - not unlike the may we > have a uniform database api. That's a gross understatement. :-) The various Javascript toolkits vary wildly in their implementations; any API attempting to unify them would necessarily become a toolkit-onto-itself, which is *way* out of Django's scope. Many of us probably wish that our favorite toolkit would simply be blessed for the admin and whatnot (yay jQuery!), but that would likely become the largest flamewar in Django history. :p --~--~-~--~~~---~--~~ 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: Spam detection
On Fri, Jun 27, 2008 at 11:36 AM, rskm1 <[EMAIL PROTECTED]> wrote: > >> Help me out here: how can I make it more obvious? You missed that; >> others often do to. Can you share with me some insights on how you >> missed it? > > I'll chime in. Basic rule of thumb for GUIs: > * If it's going to fail _ANYWAY_, just GRAY IT OUT!! > > In other words, make the form-input fields of the > http://code.djangoproject.com/simpleticket > page simply NOT APPEAR, or be DISABLED, if there is no user logged-in. > > That would make the message about registering and being logged-in > pretty much IMPOSSIBLE to miss =). And nobody will ever again see the > error page about attempting to create a new ticket anonymously. +1; this makes worlds of sense. :-) --~--~-~--~~~---~--~~ 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: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Fri, Jun 27, 2008 at 5:55 AM, Antti Haapala <[EMAIL PROTECTED]> wrote: > > > On 25 kesä, 19:12, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > >> All PostgresSQL supports in terms of *storage* is >> a fixedtimezoneoffset, not the actual zoneinfo name; this isn't >> very useful, and causes problems such as the above. > > Actually, in PostgreSQL TIMESTAMP WITH TIME ZONE does NOT store the > TIME ZONE! I found it out the hard way yesterday. Well, it stores the *offset*, which is virtually useless in real-world applications. All PostgreSQL TIMESTAMPs are stored internally as UTC. Since Django does everything with naive datetimes (a *huge* mistake IMHO, and what I'm trying to correct), the Postgres backend stores these in the database as per settings.TIME_ZONE, with that offset. It also retrieves as per that offset, back into naive datetimes. If you change settings.TIME_ZONE, you now get different naive datetimes back with no way to distinguish them. If you want to use multiple time zones at the same time ... good luck, you'll need it. ^_^ Check out the code in Bulbs (The Onion's open source code snippets) for my current crack at this problem; we're about to push a major site live with my "DateTimeZoneField", and I'd love to see something similar make its way into Django: https://launchpad.net/bulbs It could use better documentation, which is on my to-do list as soon as the APIs stabilize a tad. --~--~-~--~~~---~--~~ 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: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Mon, Jun 30, 2008 at 4:29 AM, Antti Haapala <[EMAIL PROTECTED]> wrote: > > 2008/6/27 Tom Tobin <[EMAIL PROTECTED]>: >> >> Well, it stores the *offset*, which is virtually useless in real-world >> applications. > > I haven't tested on 8.3, but on 8.2 it does not. In PostgreSQL, the datatype > "timestamp" corresponds to python naive datetimes. > "timestamp with time zone" instead means: "convert the given input from to > UTC; default to client timezone if none specified explicitly. > When outputting, convert to the client's local time zone." Django uses "TIMESTAMP WITH TIME ZONE" in the "creation" module for the PostgreSQL backends. But yes, PostgreSQL behaves as you describe. > In addition, the time zones are returned in offset format because SQL99 > mandates that :/. If we don't use "WITH TIME ZONE", the offset isn't part of the returned format. > But PostgreSQL never really stores zones, which AFAIK is a violation of the > SQL99 optional feature that specifies timestamp with tz. AFAIK SQL99 doesn't specify storing full zoneinfo-style time zones; PostgreSQL can store offsets, which (as outlined) are fairly useless. >> Since Django does everything with naive datetimes (a *huge* mistake >> IMHO --), > > I second that. However, python time zone aware datetimes are not without > problems either, and those should be considered in Django too. > However, I have yet to publish the blog entry that I've written about it. Well the problem with Python's time zone support is that *it's not there*; the datetime object can take a "tzinfo" argument which should be a tzinfo object ... and then they leave it up to you to implement anything useful. These batteries certainly *weren't* included, alas. Thankfully, both dateutil and pytz have support for zoneinfo-style (i.e., proper) time zones; my code uses dateutil, but I'm considering adding support for pytz as well. If you have a blog entry's worth of thoughts on this, I'd love to see it. ^_^ Once we've been running our time zone code for a few weeks (and I've made the corresponding tweaks), I'd like to write up a full article on the topic. --~--~-~--~~~---~--~~ 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: Community representation, or, #django user "Magus-" needs to go far away
On Tue, Jul 1, 2008 at 4:25 AM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > why should he be more polite? He follows the policy of 'teaching to > fish' rather than spoonfeeding. I have several times got flamed by > him for getting impatient and giving the answer. I would say that he > is the single most important person in the channel. He has even taken > the trouble of writing a script whereby he can generate almost > instantaneous references to the *relevant* docs. It is easy to give > direct answers - difficult, irritating and time consuming to 'teach > to fish'. Let him be as rude as he wants, as long as he is there. Stepping back for a moment from the way I approached this issue — which I readily admit was the wrong way to do it, and which I apologize to the community for — and the parties in question, I'm concerned with the general sentiment expressed in this thread. It is quite understandable to be grateful to someone for performing a difficult task; it's another thing to allow that gratitude to mute necessary criticism. I think there's room in our community for both charity *and* civility; if we can improve, we *should* improve. --~--~-~--~~~---~--~~ 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: Community representation
On Wed, Jul 2, 2008 at 7:17 AM, Arien <[EMAIL PROTECTED]> wrote: > > Can we get back to our regular program now and move personal problems > to private communication, please? Thank you. Insofar as referencing particular individuals goes, I agree. I should have raised any issues with particular community members in private, and I ask that others do the same. That said — I do think it would be nice to outline just exactly what is, and isn't, over the line for *anyone*; if we have a yardstick, we can measure, as opposed to this vague "I know it when I see it" pornography-like property of rudeness that everyone seems to disagree on. I honestly don't know if this is the right mailing list for such a discussion; it's certainly not "development of django", but a case might be made that it's "development of the community". I *do* want to have that discussion, however; I'd just like to know where to have it before continuing. --~--~-~--~~~---~--~~ 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: Community representation
On Thu, Jul 3, 2008 at 9:26 AM, phillc <[EMAIL PROTECTED]> wrote: > > random person: "i need help" > magus: gives technical answer > random person: does understand python > magus: points to docs > random person: you are rude 1) Let's stop referring to specific people, mmkay? I made that mistake, had it pointed out that it was a mistake, and want to make good on not repeating that mistake. 2) The sort of interaction you outline is *not at all* what *I'm* talking about when I feel that someone is being rude. But again, this is the sort of thing I want to understand: what *do* people mean? I consider rudeness to encompass behaviors such as yelling, disparaging remarks, and using a condescending tone. Pretty simple, IMHO. Refusing to help someone who doesn't understand the first thing about Python is *not* being rude; it's merely recognizing that the other person is in the wrong place, and that your time could be better spent helping others. --~--~-~--~~~---~--~~ 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: tickets and use of the 1.0 milestones
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <[EMAIL PROTECTED]> wrote: >> Even if these sorts of features have a patch and are "Ready for checkin," >> that does not mean they get a 1.0 milestone. They still take core >> developer time to review and commit, time that also needs to be >> focused on higher priority tickets. > > Just out of curiosity, could we fix that bottleneck by appointing more > developers to be core developers? I think that Just Happens once someone has been consistently making quality contributions over a long period. (Other than Whiskey-Media-era Jacob, I don't know how any of them do it; I think you need to take the super-Django-soldier serum first.) ^_^ --~--~-~--~~~---~--~~ 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: ModelForm Choices with session data
On Sat, Jul 5, 2008 at 3:10 AM, Keir <[EMAIL PROTECTED]> wrote: > I have recently been working on my first project in Django and have > encountered a small problem when using ModelForm. Here's my ModelForm > class You're on the wrong list. ^_^ For support questions, you want django-users. The terms "users" and "developers" in this case are probably a tad confusing; everyone *using* Django is a developer of some sort, so many naturally write "django-developers" for help, not realizing that the term is meant to refer to developing Django *itself*. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
