removing "milestone" field in Trac

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, The milestone field came up again in IRC discussion tonight between Julien and Paul and I -- namely, that it doesn't seem all that useful and causes noise in Trac. It might have made sense back when we had more feature-driven releases and a

Re: django test-runner annoyances

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/13/2011 08:46 AM, mvr wrote: > Why doesn't the django test management command / test builder allow > fully-qualified package names instead of just app-relative ones? > > At work we've been using the method below to monkey-patch the test >

Re: #7198 - Better error message when app is missing models.py

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gary, On 09/12/2011 12:04 AM, Gary Wilson Jr. wrote: > I'm a fan of not requiring a models.py, as IMHO it shouldn't be any > different than other common files found in an app e.g. urls.py, > templatetags dir, etc. If I don't need any models for

Re: CSRF token not validated?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jens, On 09/12/2011 10:20 AM, Jens Diemer wrote: > > I wonder that the CSRF token send from the client didn't be validated. Well, it is sanitized to only alphanumeric characters, but you're right that the length is never checked. > Don't know

Re: https://www.djangoproject.com/download/ is down!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/11/2011 12:46 PM, Wim Feijen wrote: > The download page for Django is down. > > I also filed a ticket, so this is a duplicate message. Thanks for the alert, but it seems to be up for me, and "downforeveryoneorjustme.com" confirms that its up.

Re: Improved password hashing for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2011 09:54 PM, Paul McMillan wrote: > In conjunction with Justine Tunney, Isaac Kelly and Russell KM, I'd > like to introduce our plan of attack for including significantly > better password hashing in Django 1.4. One of the key goals with

Re: class based views: object instead of dictionary as context?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/02/2011 01:01 AM, Greg Donald wrote: > Planning for designers to work in code is an extreme edge case. In 15 > years of web development I've never once worked with a single designer > who was interested in touching any code. As far as my own

Re: Form Rendering API Proposal

Hi Chris, On 07/09/2011 02:50 AM, Chris Beaven wrote: > If we're going to keep things simple, why are we introducing the idea of > inline "using" templates? That's a good question. I wouldn't be gutted at all if we dropped inline-using from the initial scope, too, because I really think separate

Re: Thoughts on solution to forward references in MySQL (#3615)

Hi Russell and Jim, On 07/06/2011 05:34 PM, Russell Keith-Magee wrote: > On Thu, Jul 7, 2011 at 5:05 AM, Jim D. wrote: >> * There's a DB feature can_defer_constraint_checks . I couldn't find much >> by way of documentation or or usage of this feature. But I was trying to

Re: Form Rendering API Proposal

On 06/23/2011 04:43 PM, Jacob Kaplan-Moss wrote: > 1. Performance: it looks, to me, like rending a basic form is going to > cause dozens of template includes and dozens of sub-renders (the form > loads a form template which loads row templates which load widget > templates). That's dozens of disk

Re: WTForm should be inbuilt to Django, and make admin & others use it.

On Jun 20, 12:13 pm, Andre Terra wrote: > Have we moved forward with this issue at all? What is its current status? I also maintain an external package that implements fieldsets (django- form-utils [1]). Both django-form-utils and WTForm take the approach of adding a Python

Re: Logging configuration and handle_uncaught_exception

In case anyone's interested in this but isn't following the ticket, I've attached an updated patch there using a variant of Vinay's suggestion, and with some shim code to address backwards-compatibility concerns. Reviews welcome. Ticket is at https://code.djangoproject.com/ticket/16288 Carl --

Re: Logging configuration and handle_uncaught_exception

Hi Julien, On 06/17/2011 12:08 PM, Julien Phalip wrote: > Just noting that another "filtering" functionality has recently been > added to trunk [1]. It is a different kind of filtering than what's > being discussed here -- it is to filter out sensitive information from > error reports when

Re: Logging configuration and handle_uncaught_exception

Hi Matt, On 06/17/2011 07:48 AM, Matt Bennett wrote: > Since logging Filters are not specific to an individual logger or > handler, I've just called it DebugFalseFilter. It's not a pretty name, > but I couldn't come up with anything better - I decided it should > convey what the filter allows

Re: Logging configuration and handle_uncaught_exception

On 06/16/2011 08:47 AM, Russell Keith-Magee wrote: > The behavior that is implemented in the 500 handler is a bit > convoluted, but it was designed to be a drop-in replacement for the > behavior that existed in 1.2 -- i.e., server error emails were not > sent in DEBUG mode. I remember looking at

Re: Undocumented feature for INSTALLED_APPS settings

On 06/12/2011 03:35 PM, Aymeric Augustin wrote: > I checked the SVN history. This "feature" was never documented, even > before the reorganization at r8506. It appears in > django/conf/__init__.py when magic-removal is merged (r2809). > > We just discussed it on IRC, and the consensus is that it

Re: Deprecation policy for IE6

On 06/09/2011 05:32 AM, Idan Gazit wrote: > I'm looking at admin tickets, and I realize that some defined policy > for when we can safely start to break IE6 would be very helpful. > > I'd like to simply declare that going forward, the admin need not > work perfectly in IE6. That leaves our

Re: 5-for-1?

Hi Stephen, On 06/07/2011 02:37 AM, Stephen Burrows wrote: > Hi - is the 5-for-1 deal still active on ticket reviews? [1] > If so, I've reviewed the following tickets: > > 3624 > 16152 > 16157 > 16158 > 16166 > > And would love it if someone could have a look at ticket 14082 [2]. > > If not,

Re: support for custom django-admin commands written as packages

Hi Marwan, On 06/05/2011 10:15 AM, Marwan Al-Sabbagh wrote: > Hello, > Currently one can create a custom command by implementing a Command > object in a python module such as > "polls/management/commands/closepoll.py". It would be great if Django > also supported these commands being

Re: Django and the new EU anti-cookie law

On 05/27/2011 08:18 AM, Hanne Moa wrote: > "From 26th May 2011 websites in the UK need to ask for permission > before they can set cookies not required for ‘essential’ means" > > http://blog.silktide.com/2011/05/cookie-law-makes-most-uk-websites-illegal-what-you-need-to-know/ > > What cookies in

Re: Template.origin

On 05/24/2011 11:53 AM, Jeremy Dunck wrote: > I was wondering how people would feel about template origin being an > attribute of the Template instance. > > The point to me would be to make it easier to see which location a > template is coming from; I think the compile_string func could do it--

Re: RFC: Templatetag API for form rendering

On 05/24/2011 09:35 AM, Gregor Müllegger wrote: >> Which templates are involved in a form layout? > > This is not yet defined in detail. I would suggest a schema like: > > forms/layouts//.html > > Resulting in templates for the layout "table" like: > > forms/layouts/table/row.html >

Re: RFC: Templatetag API for form rendering

Hi Gregor, On 05/24/2011 09:25 AM, Gregor Müllegger wrote: > > Yes, defining a global default is really useful, we shouldn't skip that. Yep, I'm definitely converted to that position ;-) >> For the case-by-case override, though, I'd still much rather write >> >> {% form "table" %} >> {%

Re: TemplateResponse and decorator_from_middleware

Hi Luke, On 05/23/2011 05:14 PM, Luke Plant wrote: > On 23/05/11 18:33, Carl Meyer wrote: >>> It is not nearly as invasive as the other changes you suggested. >>> However, it does fix the failing tests in my project (i.e. fixes >>> csrf_protect), and leaves Templ

Re: TemplateResponse and decorator_from_middleware

On 05/23/2011 11:31 AM, Luke Plant wrote: > I think your core idea is quite interesting. I haven't had time to think > through all the implications. > > It does make the result of what is returned from view functions rather > obscure, and this could affect things like testing. I don't think

Re: TemplateResponse and decorator_from_middleware

Hi Luke, On May 11, 7:00 pm, Luke Plant wrote: > Yeah, I guess I was seeing TemplateResponse as the culprit, on the basis > of Last In First Out, but maybe it's decorators we need to be worrying > about. > > I've actually documented a specific instance of #15855 in the

Re: RFC: Templatetag API for form rendering

Hi Jonathan, On 05/23/2011 04:30 AM, Jonathan Slenders wrote: > 1. Like Carl said, I always prefer template tags which alter the > context to create a scope. (I hate {% url ... as varname %}) > > {% form "table" %} > {% renderform my_form %} > {% endform %} Well, in any case, not all

Re: RFC: Templatetag API for form rendering

On 05/22/2011 08:54 PM, Russell Keith-Magee wrote: > My argument: I'm trying to think of another example in Django's > template language where the template tag is an "action" in this way. > To my reading, outside of the tags used for logic (for, if, etc), and > tags that define a contextual block

Re: RFC: Templatetag API for form rendering

On 05/22/2011 07:22 PM, Russell Keith-Magee wrote: > On Mon, May 23, 2011 at 6:21 AM, Carl Meyer <c...@oddbird.net> wrote: >> Just had a quick conversation with Gregor and Chris Beaven on IRC; >> based on a comment of Chris', we discussed the possibility of ditching >&g

Re: RFC: Templatetag API for form rendering

On 05/22/2011 07:18 PM, Russell Keith-Magee wrote: > I like this. Simple, covers all the common use cases that I can see. > My only feedback here would be mostly bikeshedding -- the fact that {% > form %} is a configuration action, and {% renderform %} is the > rendering action. It feels to me

Re: RFC: Templatetag API for form rendering

Just had a quick conversation with Gregor and Chris Beaven on IRC; based on a comment of Chris', we discussed the possibility of ditching the {% formlayout %} tag in favor of specifying the layout as an argument to the {% form %} block tag. E.g. instead of >     {% form %} >         {% formlayout

Re: RFC: Composite fields API

Hi Michal, I'm looking forward to seeing this project take shape! Comments below: On 05/12/2011 06:41 AM, Michal Petrucha wrote: [..] > The constructor of a CompositeField will require at least two > positional parameters, each positional parameter will be a single > atomic field. The order of

Re: TemplateResponse and decorator_from_middleware

On 05/11/2011 05:37 PM, Luke Plant wrote: > The only solution I can see that isn't awful is providing two views - a > default and documented one that has all the right decorators applied, > and one that is obviously 'use at own risk', called something like > 'login_unsafe', for which we document

Re: #1342 Allow customization of MAX_SHOW_ALL_ALLOWED. Reopen or new ticket?

Hi Jim, On 05/10/2011 02:09 PM, Jim D. wrote: > I'm looking at a five-year-old ticket here (http:// > code.djangoproject.com/ticket/1342) that suggests MAX_SHOW_ALL_ALLOWED > in the admin be configurable. As of now it is hard coded at 200 in > contrib/admin/views/main.py . > > The ticket is, in

Re: model fields options

Hi Eduardo, On 05/06/2011 12:22 PM, legutierr wrote: > You're probably right about this, but (while we are on the subject) > aren't there some things that shouldn't be part of the model field > options that currently are? Why is help_text part of the field > definition? This is a ui-specific

Re: deprecation of AUTH_PROFILE_MODULE

On 05/02/2011 11:38 AM, Jeremy Dunck wrote: > Given a blank slate, what would Auth look like these days? And can we > work towards that? Now, why you gotta get all constructive and forward-thinking and stuff? ;-) Here's my list of core ideal-contrib.auth desiderata that I keep seeing crop up in

Re: deprecation of AUTH_PROFILE_MODULE

On 05/02/2011 07:15 AM, Russell Keith-Magee wrote: >>> what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile() >>> or removing the suggestion to use it from the docs in 1.4 release? >>> There are broader issues with extending User model but I think this one >>> can be handled

Re: ModelForm validation - a better way?

On 04/29/2011 10:02 AM, Yishai Beeri wrote: > Of course, cleanup need not be simplistic. In fact, I think the common > coder would never expect a CM to actually save an object on __exit__ - > and will be surprised by the proposed behavior. Could be - the name "finish()" was intended to give the

Re: ModelForm validation - a better way?

Hi Johannes, On 04/29/2011 09:02 AM, Johannes Dollinger wrote: > Here's my take on the API: > > def my_view(request): > form = MyModelForm(request.POST or None) > try: > with form.finish() as obj: > obj.user = request.user > return redirect(obj) > except

Re: ModelForm validation - a better way?

Hi Yishai, On 04/29/2011 08:53 AM, Yishai Beeri wrote: > First, the logic tied into the context manager does not match the > idiomatic use of context managers in Python. One expects a context > manager to "clean up" on exit, rather than *save* a new object. I'd argue it's not totally off base.

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Lior, (moved from another thread) On Apr 29, 12:16 am, Lior Sion wrote: > I looked at the sample you wrote on the other thread (unique together > on username and date, and having a null username with a given date) of > when the old behavior is the right one and it didn't

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Mikhail, On Apr 24, 7:46 am, Mikhail Korobov wrote: > The issue is not only with unique_together indeed. Please correct me if I'm > wrong, but it seems there is no way currently to use model validation with > fields dependent on each other when one of these fields is

Re: ModelForm validation - a better way?

Hi Lior, thanks for commenting. On 04/29/2011 12:16 AM, Lior Sion wrote: > I think that forcing programmers to remember quite a long process of > for validation each time is a wrong approach, especially if only done > to support backward code that behaves in "unnatural" way. I'm not sure why you

ModelForm validation - a better way?

Hi all, We have a number of tickets open (at least #12028, #13249, #13091, #15326, and #15860 -- #13091 is the active one) reporting problems with unique_together constraints in our attempts to validate arbitrary partial models, when validating a ModelForm with some fields excluded. Eduardo

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

On 04/28/2011 07:12 PM, legutierr wrote: > I'm up for working on the new idiom now. I've put this much time into > it, I don't want to waste the momentum. What's the approach you are > thinking of, and how can I get started in the implementation? Much appreciated. I have a half-written post

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Eduardo, On 04/28/2011 06:36 PM, legutierr wrote: > This is extraordinarily discouraging. I can understand why. I've also spent a number of hours thinking about this, reviewing the patch, considering alternatives, coming up with cases that might break, etc. I'd like to set aside those sunk

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Eduardo, On 04/28/2011 12:35 PM, legutierr wrote: > I just added a new patch in response to Carl's comments on the ticket. > > http://code.djangoproject.com/ticket/13091 So, in the process of reviewing and tweaking this patch for commit, I checked in the #django-dev IRC channel for any other

Re: Permission Duplication

Hi Valentin, On 04/27/2011 10:33 PM, Valentin Golev wrote: > 1. I've run into something that seems like a bug. If it really is a bug, > I'll file a ticket, if it's not, please clarify the behaviour, and, in > this case, I think a better error message will be awesome. > > Basically, if there are

Re: Use cases for a OneToMany field

Hi Charlie, On 04/27/2011 02:35 PM, Charlie DeTar wrote: [snip] > Is this something that others see value in? Cause I sure think it > would be awesome. I actually think that sounds quite useful; I'd never thought of that alternative to reverse FKs when you don't want to modify the model that

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

On 04/27/2011 02:02 PM, legutierr wrote: > Ok, I'll create a patch soon (with tests + documentation) that > hopefully works for you. I don't think it will be very complicated > implementation-wise, just a few additional lines, I think. With > regards to the documentation, I'll add a note here:

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Eduardo, On 04/26/2011 02:47 PM, legutierr wrote: >> With your proposed change, if I happen to have a FavoriteBirthdayPresent >> in the database for a given year with an empty "username" field, it >> would incorrectly prevent any user from creating their own >> FavoriteBirthdayPresent for that

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/19/2011 01:47 AM, Ivan Sagalaev wrote: > OK, may be not reverse OneToOne… What I mean is that although it seems > natural to treat all relations equally they are actually used for > different use cases where different defaults make sense. For example: > > - Reverse many-to-one

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/19/2011 04:58 AM, Johannes Dollinger wrote: >> Do you have real-world use-cases in mind that require per-relation >> manager configuration? I can't think of any uses I've run across >> that weren't workable with a single default manager used by all >> relations. > > The only time I used a

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

Hi Florian, On 04/23/2011 08:18 AM, Florian Apolloner wrote: > Nice, something like that would be great. One of my bigger problems > regarding modelforms lately was that I wanted something like: "If you > don't fill out the user it's set to the current user", in the admin, > with as little

Re: "unique_together" only validated in modelform.is_valid() if ALL of the referenced fields (Ticket #13091)

On 04/22/2011 02:42 AM, legutierr wrote: > However, in the case of a tuple of fields that are "unique together", > the proper behavior should be that if *any* of those fields are > editable in the form, the constraint should be validated by > is_valid(). In the current implementation, *all* of

Re: Help review tickets, get a prize!

On 04/20/2011 05:38 PM, Jacob Kaplan-Moss wrote: > * It clearly *is* a bug, and there seems to be a fair bit of > information (steps to reproduce, the traceback, etc.); these I quickly > mark "accepted", fix the metadata, and move on. So you don't necessarily reproduce it yourself before

Re: Help review tickets, get a prize!

Hi Tino, On 04/20/2011 05:14 PM, TiNo wrote: > It takes me, being a newbie at reviewing tickets, quite some more time. > Would you (or any other core dev / speed reviewer) mind sharing your > workflow? Any scripts to create environments at certain revisions or > something alike? Or to quickly run

Re: Help review tickets, get a prize!

On 04/20/2011 04:27 PM, Alex Gaynor wrote: > Consider me in on the 5-1 offer. Same here. Carl -- 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

Re: RFC: new backports policy

On 04/20/2011 04:37 PM, Tobias McNulty wrote: > I'd be more comfortable if the policy stated that any new bugs > introduced by the last release would be backported to that release. > It's possible that "major functionality bugs in newly-introduced > features" will equate to virtually the same

Re: Admin search behavior changed from 1.2.5 to 1.3

Hi Ryan, On 04/20/2011 10:42 AM, Ryan K wrote: > Today I discovered behavior similar to that originally reported in > #15819 (http://code.djangoproject.com/ticket/15819). I've updated it > with a simple way to reproduce the issue. Could anyone confirm this > behavior? It's nothing major but it

Re: RFC: new backports policy

On 04/19/2011 05:24 PM, Luke Plant wrote: > Another issue with regards to backporting bug fixes that Jacob didn't > mention is the fact that bug fixes often introduce subtle regressions > and backwards incompatibilities. > > Personally, I find that backporting a fix very often takes only a >

Re: Right way to do formfield-less fields?

On 04/19/2011 09:44 AM, Jonas H. wrote: > On 04/10/2011 03:14 PM, Jonas H. wrote: >> What's the preferred way to do a custom model field that has no >> corresponding formfield? Intuitively, I'd say raise a >> NotImplementedError, but that would make the whole model unusable in the >> admin even

Re: #14891, a.k.a. "related managers don't work how we claim they do"

Hi Johannes, On 04/18/2011 01:45 PM, Johannes Dollinger wrote: > Deprecate `use_for_related_fields` and always use the default manager > for related managers. Then add the possibility to specify custom > mangers for individual relations: > > ForeignKey(Foo, related_manager=RSpecialManager)

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 04:35 PM, Ivan Sagalaev wrote: > Not exactly… I mean that when use_for_related_fields is set explicitly > Django should respect it. Right now, as I understand from your first > mail, it doesn't work as False when set to False. So I agree that this > should definitely be fixed. > >

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 12:47 PM, Luke Plant wrote: >> So - do we (A) fix the behavior to match our documented semantics, note >> it in the release notes, and hope for the best? Or (B) bow to >> backwards-compatibility and change the documentation to match the actual >> behavior? Or (C) find some middle

Re: #14891, a.k.a. "related managers don't work how we claim they do"

Hi Ivan, On 04/18/2011 01:07 PM, Ivan Sagalaev wrote: >> even if "use_for_related_fields" is absent or explicitly set to >> False on your Manager subclass. > > … the default manager should not be used as a base class. Fixing just > this would be the best option because it retains current

Re: Filter via related_name in inherited model not working .. Bug?

Hi Alex, On 04/18/2011 02:44 AM, robim42 wrote: > thank you for your answer. I also thought that owner_partner should > work ... but when you try you get this: Sorry, not owner__partner - since partner is only a field on Buyer, not on Base, you'd need owner__buyer__partner. In any case, I don't

Re: Accidental logging disabling

Hi Ivan, On 04/17/2011 10:38 PM, Ivan Sagalaev wrote: > On 04/15/2011 02:20 AM, akaariai wrote: >> I have been using setup_environ in my projects, and the lazy >> initialization in can cause some weird problems, for example if you do >> manual timing using: >> start = datetime.now() >> access

Re: The model option's verbose_name_raw is not really that 'raw'

Hi Viktor, On 04/18/2011 09:14 AM, Viktor Kojouharov wrote: > I think I might have stumbled upon a small bug. According to its docs, > the 'verbose_name_raw' property is supposed to return an untranslated > version of the 'verbose_name' property. However, if LANGUAGE_CODE is > set, then

#14891, a.k.a. "related managers don't work how we claim they do"

Hi all, Our documentation on "automatic managers" [1] and related managers [2] is quite clear that automatically-created managers for related-objects access will be plain-vanilla Manager instances, unless you set "use_for_related_fields = True" on the custom Manager subclass that you use as a

Re: Accidental logging disabling

On 04/15/2011 04:20 AM, akaariai wrote: > I have been using setup_environ in my projects, and the lazy > initialization in can cause some weird problems, for example if you do > manual timing using: > start = datetime.now() > access settings > print 'Used %s' % (datetime.now() - start) > > You

Re: Filter via related_name in inherited model not working .. Bug?

Hi Alex, On 04/15/2011 07:51 AM, robim42 wrote: > --- models.py code --- snip --- > from django.db import models > > class Base(models.Model): > name = models.CharField(max_length=20) > > def __unicode__(self): > return self.name > > class Seller(Base): > childa =

Re: [GSoC] Composite fields

Hi Michal, On 04/01/2011 09:22 PM, Michal Petrucha wrote: > I propose to implement a CompositeField with the following properties: > > - will be represented as a namedtuple containing the values of the > actual fields it encapsulates > > - will support retrieval and assignment (assignment

Re: Revised form rendering

Hi Mikhail, On 04/01/2011 05:09 PM, Mikhail Korobov wrote: > Hi Carl and Gregor, > > On 2 апр, 01:17, Carl Meyer <c...@oddbird.net> wrote: >> >>> 3. The designers I worked with are often interested on adding custom css >>> class >>>o

Re: [GSoC] Revised form rendering

Hi Gregor, As you've probably seen in past threads, this is an area where I'm quite motivated to see some improvement. I think you've got quite a strong proposal here in general, and you've clearly done your homework, so my comments below dive directly into the details: On 04/01/2011 11:57 AM,

Re: GSOC : Django auth

On 03/30/2011 07:43 PM, Russell Keith-Magee wrote: > ... and this is the exact model that has been proposed, and rejected > in #3011 (albeit with a more complex dance around default values). It I just re-read #3011, and it is far from clear from reading through the ticket that that approach was

Re: Single Table Inheritance

On 03/29/2011 02:46 PM, Shawn Milochik wrote: > I'm not proposing a change to Django itself or suggesting that this > should be a standard practice. I do think that this is a fairly clean > solution for an individual to use to solve this problem if they have > it. > > They can create a custom

Re: Single Table Inheritance

Hi Shawn, On 03/29/2011 01:28 PM, Shawn Milochik wrote: > Hopefully someone on the core dev team can let me know if this is > possible in Django. If so, it will solve this problem. > I am not familiar with custom metaclass stuff done within models.Model. > > 1. Create a custom metaclass as

Re: Single Table Inheritance

On 03/29/2011 12:40 PM, Jeremy Dunck wrote: > What about keeping abstract inheritance in this case, but allowing > Document.objects.* to work by returning instances of the subclasses. > Filtering, etc. would only work based on the Document base class. > > It would mean doing some unions, but

Re: Proposal: switch to HTML5 for bundled templates

I think it would be helpful here to clearly distinguish three distinct varieties of "using HTML5," two of which are clear wins and one which I don't see any reason to do: 1. Switching to the HTML5 doctype in those few places where Django actually renders a full page with doctype (the admin,

Re: Complains about FileField not deleting files in 1.3.

Hi Alex, On 03/29/2011 01:36 AM, Alex Kamedov wrote: > I think, cron jobs is an overhead in many simple cases where old > behaviour was useful and more simpler. > Why you don't want include DeletingFileField[1] in django? > > [1] https://gist.github.com/889692 Because, as mentioned above, it is

Re: Proposal: switch to HTML5 for bundled templates

Hi Luke, On 03/28/2011 12:38 PM, Luke Plant wrote: > Overall, I think the advantages outweigh the disadvantages, that we have > to make the move sometime, and now is about the right time, or perhaps > slightly late. 100% agreed, for all the reasons you outlined. We've been using the HTML5

Re: Trac components cleanup

On 03/28/2011 02:33 AM, Russell Keith-Magee wrote: > As with the other thread on Trac changes -- I agree this is worth > doing, but would like to hear some other core dev voices before making > any changes. These changes look to me like a gain in sanity on every front. +1 Carl -- You

Re: Complains about FileField not deleting files in 1.3.

On 03/27/2011 06:42 AM, -RAX- wrote: > I am referring to this: > http://docs.djangoproject.com/en/dev/releases/1.3/#filefield-no-longer-deletes-files > Instead of preventing the data loss from happening a very usefull > feature has been removed. Well, it does also prevent the data loss from

Re: Wrong error message when user having is_staff=False tries to login to admin

On Mar 16, 12:11 am, Tai Lee wrote: > Assuming that any authenticated user might be an attacker who has > brute forced a password and presenting obscure error messages to > authenticated users is not helping anybody. I agree with this, and with the many people in this

Re: Proposal: template-based widget rendering

Hi Bruno, On 03/23/2011 08:56 AM, Bruno Renié wrote: > I'm not sure, however, how django's backwards-compatibility applies in > this case. The widgets API has never been publicly documented but the > official documentation encourages people to look at the code and > create their own widgets based

Re: secret key from file...

On 03/22/2011 07:05 PM, Ian Kelly wrote: > On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt > wrote: >> Why not just do an import for your custom settings? >> >> try: >>from site_settings import * >> except ImportError: >>pass > > No particularly

Re: Improving Class based views names

On 03/21/2011 09:14 AM, daonb wrote: > On Mar 20, 4:49 am, Carl Meyer <c...@oddbird.net> wrote: >> Those last five characters in "get_context_data" actually serve quite a >> useful purpose, IMO. They clarify that the return value is just the data >>

Re: Improving Class based views names

Hi Benny, On 03/19/2011 05:41 PM, daonb wrote: > Migration to the beta was quite smooth except for two names that broke > my code: `pk` & `get_context_data`. The first comes from `models` and > is now used instead of `object_id` in urls and views. It also broke > compatibility with

Re: Homogenization of User and UserProfile

On 03/18/2011 08:09 AM, Alexander Schepanovski wrote: > I think using subclass of User model for your fields has the same > flexibility as separate profile model (since you can have only one). You can have multiple subclasses of the User model (not that I recommend subclassing). > contrib.auth

Re: Default project layout / directory structure

On 03/17/2011 05:36 AM, Tom Evans wrote: > I strongly disagree here. Django shouldn't be doing magic with my > PYTHONPATH, if I want stuff in my PYTHONPATH, I'll darn well put it > there. Hear, hear! I'm only a weak +0 on the entire idea of documenting a "standard" project layout, as I think

Re: Django urls in JavaScript

Hi Marco, On 03/17/2011 10:44 AM, Marco Louro wrote: > I don't really know how to approach this issue the best way, so I'm > just going to be direct, I'd love to see Django provide support for > django.core.urlresolvers.reverse (at least) on the client (in > JavaScript). I think this is really

Re: Composite primary keys

On Mar 16, 11:43 am, Christophe Pettus wrote: > On Mar 16, 2011, at 2:24 AM, Johannes Dollinger wrote: > > > I would be nice if support for composite primary keys would be implemented > > as a special case of general composite fields. > > It's appealing, but the reality is

Re: QuerySet subclass based on namedtuple()

Hi Alexander, On 03/15/2011 03:30 AM, Alexander Schepanovski wrote: > It would be nice to have a QuerySet subclass based on namedtuple(). > namedtuples takes less memory than dicts (from ValuesQuerySet), much > more convenient and induce more readable code than tuples > (ValuesListQuerySet). >

Re: Proposal: template-based widget rendering

Hi Bruno, On 03/14/2011 06:33 PM, Bruno Renié wrote: > Although Django 1.3 is not released yet I'd like to take advantage of > the pycon sprints to discuss a proposal for 1.4: render form widgets > using Django templates instead of python code. > > This approach is implemented in

Re: Expensive queryset cloning

Hi Alex, On 03/14/2011 08:49 PM, Alexander Schepanovski wrote: > Personally, I would like all querysets mutate not clone by default. > And when one need a clone just make it explicitly. This is not an option. It will break quite a lot of existing code, and often in highly confusing ways. You'll

Re: type-field model inheritance

Hi Simon, On Mar 4, 3:27 am, Simon Meers wrote: > +1 for better polymorphic support in Django core; it is a very common > problem which could do with an efficient and elegant solution. > Regarding efficiency, if you can keep track of your subclasses > effectively (potentially

Re: type-field model inheritance

Hi Craig, On Mar 4, 1:03 am, Craig de Stigter wrote: > It looks like django_polymorphic does what I want. I'm not yet sure why it > says it takes one query per type of model in a queryset. Unless it is > talking about multi-table inheritance, in which each type would require

Re: Problem due to contenttype cache

On Mar 4, 5:55 am, Rahul wrote: > When i ran test cases of multiple_databases model of regressiontests > then "test_generic_key_deletion" test case gave Error at the point > where it was trying to create Review object using "other" db, > but when i ran

Re: Delete cascade up for Inherited models

Hi Rahul, On Feb 21, 12:56 am, Rahul wrote: > When i ran the test cases ( "modeltests/delete/ > test_inheritance_cascade_up" ) which were doing cascade up for > inherited models, it failed for DB2 cause of the fact that DB2 doesn't > support initial deferred

<    1   2   3   4   5   6   7   >