Missing release notes for point releases (#15330)

Hi Russell et al, I don't agree with the wontfix resolution of #15330. I think the OP there is right - we should be consistent in providing release notes for all releases, even if they would be as short as "No significant changes" (and I don't actually think that's true even for 1.2.1 or 1.2.3 --

Re: Bound formset.empty_form after posting formset

Hi Hidde-Jan, On Feb 18, 10:20 am, Hidde-Jan Jongsma wrote: > Lately, I've been working a lot with Django's modelformsets in > combination with javascript. The BaseFormSet implements a handy method > _get_empty_form, accessible through the empty_form property. This > method

Re: Pluggable encryption for django auth (design proposal)

Hi Paul, On Feb 14, 1:37 am, poswald wrote: > * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is > python 2.5 compatible (due to hashlib being added in python 2.5) and > PBKDF2 is short enough that it could be included into the project. > This satisfies

Re: Feature request: Abstract ManyToManyField

Hi Mike, On Feb 3, 4:36 pm, Mike Lindsey wrote: > I'm doing something with bidirectional ManyToManyFields, in a project > I'm working on, that is resulting in duplicate attempts to create the > intermediate tables.  I'm perfectly open to suggestions of "You're > doing it

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Feb 4, 3:41 am, Rahul wrote: > When i set this flag in DatabaseFeatures  then for full test suit also > both test cases of "contenttypes" app works fine. > > But i am not able to figure out why this test case was failing when we > were not sets

Re: r15401 and removing star imports

Only reason I didn't add it to the import is that it's not used in any of the commented sample lines. But the better solution is to import it and demonstrate using it. Done in http://code.djangoproject.com/changeset/15415 Thanks for the suggestion. Carl -- You received this message because

Re: Ticket #8809 - "Better error message when can't import url callback".

Hi Vivek, On Feb 3, 1:03 am, Vivek Narayanan wrote: > I am new to the Django community and I would like to implement a patch > for the ticket #8809 - "Better error message when can't import url > callback". Welcome, and thanks for contributing! > I was looking into the

Re: Question on ForeignKey (on_delete=DO_NOTHING)

Hi Rahul, On Feb 2, 4:03 am, Rahul wrote: > When i run the entire inbuilt test suit of django, first test case it > hits is of contenttypes app of contrib apps and first test > case(intest_lookup_cache)  works fine. But when it hits the 2nd test > case

Re: One Django instance, hundreds of websites

On Jan 31, 1:49 am, Xavier Ordoquy wrote: > The thread is pretty long because there are also 2 threads in one: >  - one for simply changing the site_id per request >  - one for changing the all setting per request Exactly! For the record, as far as I'm concerned #15089 is

Re: Question on ForeignKey (on_delete=DO_NOTHING)

On Jan 24, 3:51 am, Rahul wrote: > Can you let me know how i can specify that this test case should not > be run, when i run the inbuilt unit test-cases. Currently i just run > them like this 'python runtests.py --setting=settings' You should not avoid running

Re: Ticket #15124: BooleanField should not use False as default (unless provided)

This seems right to me. Does anyone with more history on BooleanField know of any reason why the "wontfix" resolution on #2855 was incorrect and the current default-to-False behavior is correct? Carl -- You received this message because you are subscribed to the Google Groups "Django

Re: contrib.sites and multitenancy

Thanks legutierr for all your work on this ticket and patch, and everyone for the comments. I just took some time to review the patch on #15089 and had a long conversation on IRC with legutierr, and here's what I'm thinking: It does appear that there is some code (CurrentSiteManager, for

Re: ForeignKey with null=True

On Dec 17, 9:21 am, Carl Meyer <carl.j.me...@gmail.com> wrote: > Instance._state.adding is new in 1.2 (in 1.2 it was instance._adding > and only ever monkeypatched onto a model instance by ModelForm; I > changed it to instance._state.adding and encapsulated it inside the > OR

Re: ForeignKey with null=True

Hi Luke, On Dec 16, 9:47 am, Luke Plant wrote: > For the latter, I think we should use instance._state.adding to reliably > detect whether a PK has been set or not. This could cause some [snip] > While I was there,  I fixed _get_next_or_previous_by_FIELD to use >

Re: Models.py not loaded at server startup ?????

Hi, On Dec 12, 4:40 pm, Pakal wrote: > Why, then, isn't it specified that all models.py files should be > loaded by each starting worker ? That would solve the whole problem > and hidden errors around startup code like signals and startup checks. This is a real issue

contrib.sites and multitenancy

Hi all, I've recently been exploring simple multitenancy options in Django using contrib.sites, and have some thoughts on how core could make it easier. First, let me make a quick distinction between static and dynamic multitenancy. In the static case, you have a limited set of sites running on

Deprecating ADMIN_MEDIA_PREFIX

Hi all, The special-cased handling of contrib.admin static assets in Django core is a long-time wart. Fortunately, the new static assets standard introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT settings finally allows us to begin a migration path to remove this wart.

Re: RFC: Add a "needinfo" state to triaging

On Nov 17, 9:16 am, Tai Lee wrote: > I believe that only the reporter, owner, and CCs are notified when an > update is made, not anyone who added a comment. I am quite sure this hasn't been my experience. I often receive email notifications from Trac about changes to

Re: Call for review and comment: #7539 (ForeignKey on_delete)

This is committed as r14507: http://code.djangoproject.com/changeset/14507 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-develop...@googlegroups.com. To unsubscribe from this group, send

Re: Call for review and comment: #7539 (ForeignKey on_delete)

Last call for any concerns with the patch; planning to land it in the next 24 hours. 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-develop...@googlegroups.com. To unsubscribe from this

Re: No default comment_notification_email.txt, no docs

Hi Peter, On Nov 7, 9:41 pm, Peter Herndon wrote: > I just ran into a minor issue and thought I'd bring it to light.  In adding > django.contrib.comments to a site I'm building, I found that when using > moderation and setting email_notification to True, that there is no

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 6:51 pm, Gabriel Hurley wrote: > 1. Add the versionadded directive to "docs/topics/db/queries.txt", and > "docs/ref/contrib/contenttypes.txt". For reference, you can make it > very clear what was changed/added by using the following syntax (note > the *single* line

Re: Call for review and comment: #7539 (ForeignKey on_delete)

On Nov 5, 11:17 am, Russell Keith-Magee wrote: > Giving credit where it's due, I think Michael Glassford also deserves > a shoutout here. He was the original driving force behind this ticket, > as was actively involved during the 1.2 development cycle. Indeed! My

Call for review and comment: #7539 (ForeignKey on_delete)

Hi all, The patch for #7539 [1] (support for on_delete behaviors other than cascading deletes) has reached a state where I consider it a candidate for committing; I invite review and comments. The current patch is available as a github branch; the compare view [2] presents it nicely as a diff

Re: Git-using core devs: preference for merge vs. rebase?

Hi Tom, On Nov 2, 12:58 pm, "Tom X. Tobin" wrote: > Do the Git-using core developers have a preference for merge vs. > rebase for updating an upstream-tracking branch?  I prefer to rebase > to keep the changes in question at the branch HEAD, especially if the > branch

Re: Gentle Proposal: add 'render' shortcut in 1.3

On Oct 29, 2:04 pm, Ivan Sagalaev wrote: > Aha, I see the point now. On a second thought I think we can avoid this > problem altogether by not passing actual response object into > middleware. Instead we could pass just those bits that a middleware > should care about:

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 29, 3:05 am, Waldemar Kornewald wrote: > Just to clarify: We are in fact talking about two questions here: > 1. Do we need a standard for URL handling? > > This is the most important question and my answer is "yes" (I'll > explain this in the rest of

Re: contrib.staticfiles and runserver

On Oct 28, 9:45 pm, SmileyChris wrote: > My suggestion is that StaticFilesHandler only does its magic if > 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that > sound acceptable? That seems like a very reasonable opt-in approach that solves the

Re: contrib.staticfiles app concerns

Hi Waldemar, Thanks for putting so much thought into this issue, and outlining these options in detail. However, I am not convinced that this something Django core should be concerned with. I think we need to maintain a clearer conceptual separation between the various layers of functionality

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 20, 4:04 pm, Waldemar Kornewald wrote: > In what way does staticfiles make writing reusable apps easier? It > merely collects apps' "static" folders. The same thing could be > achieved by defining a simple standard: > "Put media files in the 'media'

Re: contrib.staticfiles app concerns

Hi Waldemar, On Oct 20, 1:40 pm, Waldemar Kornewald wrote: [snip] > However, what staticfiles does has almost nothing to do with "bigger > project" asset management. Just look at the features grid on > djangopackages (disclaimer: I'm the author of django-mediagenerator >

Re: #6735 -- Class based generic views: call for comment

On Oct 2, 4:34 am, Russell Keith-Magee wrote: > I can't argue with the fact that setting variables in __init__() is a > common idiom in Python generally, and this is certainly a weakness of > copy on call that will fail in non-thread safe ways. > > My counterclaim is

Re: #6735 -- Class based generic views: call for comment

On Oct 1, 10:00 pm, Russell Keith-Magee wrote: > Now, I'm sure the counterargument is going to be that copy() will be > just as error prone and FAQ inducing. My argument to this is: Yes. >   * when it fails, it will fail during development, not just in production > >  

Re: proposal for lazy foreignkeys

On Sep 25, 1:50 pm, Alex Gaynor wrote: > ISTM this would solve the "auth.User" issue, but doesn't help reusable > apps at large: one can trivially imagine a project that wants voting > (or tagging ;), or commenting, or ...) on more than one model. Of course! This isn't a

proposal for lazy foreignkeys

Hi all, I've seen some level of interest in the idea of a lazy foreign key (one whose target table is determined by project configuration in some way, not hardcoded by the app/model in which it lives). The idea was most recently brought up again in Eric Florenzano's keynote at DjangoCon. I have

Re: Proposal: Add signals test_setup and test_teardown to Django test suite runner

Hi Jim, On Sep 19, 1:19 am, "Jim D." wrote: > I found some time this evening to work this out, and have included a > revised patch for this proposal at the end of this message. Thanks for your work on this! The usual Django workflow doesn't include patches to the mailing

Re: Django 1.2.3 released

On Sep 11, 2:25 pm, Dana Spiegel wrote: > When will the releases be available as tags in subversion? > Specifically, both 1.2.2 and 1.2.3 have not been tagged in > thehttp://code.djangoproject.com/svn/django/tags/releases/SVN directory. I believe this has now been

Re: memcached-based-cache - timeout=0 does not work as intended by memcached

On Jul 26, 10:02 am, Tobias McNulty wrote: > If such reusable code needs to cache things forever, which sounds perfectly > reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all > cases.  Each backend that supports caching with no timeout could easily

Re: memcached-based-cache - timeout=0 does not work as intended by memcached

On Jul 23, 12:45 pm, Jacob Kaplan-Moss wrote: > On Fri, Jul 23, 2010 at 8:17 AM, Tobias McNulty > wrote: > > The only concern in that ticket seems to be that 0 means different things > > for different cache backends. > > There may have been some

Re: Proposal: Revised form rendering

On Jul 14, 4:15 pm, SmileyChris wrote: > We also need d) Media hooks for a single widget - whether this can be > done in only the template layer is a tricky problem... > > I'm still struggling with how you'd be able to render all the media at > the top of your template for

Re: Proposal: Revised form rendering

Hi Tai, On Jul 13, 8:42 pm, Tai Lee wrote: > I wouldn't like to see widget libraries being packaged up with > templates including conditional templates based on doctype. This seems > messy, not friendly to override in your own templates, and effectively > combining what

Re: Proposal: Revised form rendering

Hi Russ, On Jul 13, 12:11 pm, Russell Keith-Magee wrote: > I have exactly 0 mad skillz as a front end guy, but I know that rich, > pretty ajax widgets et al are necessary for a good user experience. My > goal, as a backend guy with limited frontend skills, was to find a

Re: Proposal: Revised form rendering

Hi Russ, First of all, thanks very much for this proposal! Form rendering has been a major pain point for us (thus the existence of django-form-utils), and improving it is tops on my 1.3 wishlist. I will also be at DjangoCon and eager to sprint in this area. Django has a really good template

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

Hi Russ, On Jul 10, 8:24 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer <carl.j.me...@gmail.com> wrote: > > Wouldn't it be most sensible to treat the URL mount point similarly to > > hostname, since they

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

On Jul 7, 7:11 pm, Graham Dumpleton wrote: [snip] > web application, to be a well behaved WSGI citizen, should honour > SCRIPT_NAME setting as supplied by the server, and ensure that ways > are provided such that everything in the users code, including > configuration,

Re: Proposal: Improvements for django.forms

On Jun 3, 5:48 pm, "petr.marhoun" wrote: > - It seems that it is not possible to say if form has fieldsets > (fieldsets method even construct fieldsets if meta attribute is not > set) - I think it is useful to know it in templates. I spoke too quickly here: this is a

Re: Proposal: Improvements for django.forms

Hi Petr, On Jun 3, 5:48 pm, "petr.marhoun" wrote: > I have some notes to forms-utils: > - The code says: "if legend is None: legend = name". I dislike it - I > want to have possibility not to set legend. I think that if legend is > not set it should be "None" in fieldset.

Re: Proposal: Improvements for django.forms

On Jun 3, 8:57 am, Russell Keith-Magee wrote: > 5. Parameters "template" and "attrs" for forms, formsets, fieldsets, > forms, (bound) fields and widgets > 6. Support for (X)HTML5 and legacy HTML > > I strongly suspect that these two may be covered by something I >

Re: Proposal: Improvements for django.forms

Hey Petr, On Jun 3, 11:32 am, "petr.marhoun" wrote: > OK, more details: If fieldsets would be defined, fields would be > concatenation of fields from individual fieldsets. So methods > as_table, as_ul and as_li and "for field in form" would work as now. > But if you want

Re: Class based generic views in 1.3?

On Jun 2, 6:20 pm, Ben Firshman wrote: > Yeah, this idea came up at the sprints, but it's a little too magic for my > tastes. I dunno... is __new__ really more magic than having a __call__ method that magically copies the instance you call it on? That certainly breaks my

Re: Long-running tests

On Apr 17, 2:58 am, Paul McMillan wrote: > For the particular test case in modeltests/fixtures/models.py, we > might be able to improve test time by tearing the fixtures down after > verifying them, rather than doing a full flush. This will be easier to > do after converting

Re: dbsettings, and user configurable app settings

On Mar 1, 9:40 am, stuff4ash wrote: > I am not necesary advocating magic. But the need for a more robust (or > lets say, any) configuration management exists for many. "Configuration management" is a fuzzy phrase that can mean many things to many people. I think it'd be more

Re: dbsettings, and user configurable app settings

On Feb 27, 1:53 pm, stuff4ash wrote: > b) easy way to register, override, configurations for apps. > a settings.py in an app folder that is "magically" loaded the same way > other things are would suffice, but there has to be a way to: I've never understood the desire for

Re: Deleting related objects in the admin: patch for #6191

On Jan 26, 7:24 pm, Russell Keith-Magee wrote: > I'll put it on my list. It will probably still be a 'post 1.2-beta' > activity, but I'll try to look at it at the start of the bugfixing > phase. Great, thanks. Looking forward your feedback. Carl -- You received this

Deleting related objects in the admin: patch for #6191

Hey all, During the Chicago sprint a few weeks ago I put together a patch for #6191: the admin's "the following related objects will be deleted" list in some cases omits items that actually are deleted (oops!). The admin has its own routine for collecting related objects for notification,

Re: Revisiting #8245: admin.py errors under runserver cause app to disappear

Anyone have thoughts on this? It would be really nice to get this fixed so admin.py errors don't break the runserver, and I think the updated patch on #11957 accomplishes this without any breakage. Carl On Sep 28, 4:56 pm, Carl Meyer <carl.j.me...@gmail.com> wrote: > Today I filed

Revisiting #8245: admin.py errors under runserver cause app to disappear

Hi all, Today I filed #11957 [1], and because it is questioning an earlier bugfix, I was asked to bring up the issue for discussion here. Under the dev server, if an error occurs while importing an app's admin.py, the error will show up on the first request, and then disappear. On all

Re: An issue with ticket system

On Sep 18, 6:48 pm, Alex Gaynor wrote: > If you press the original format button you will see that the patch is > still there, trac just can't display all diffs (it's a very special > piece of software). Specifically, if you're obsessive about avoiding minor breakages,

Re: On returning appropriate subclass instances when querying a model with subclasses

On Aug 23, 9:14 pm, Andrea Zilio wrote: > So the answer to the question "Can I get the right instances with one > single and only DB query" seems to be: > "No, you cannot do so without touching the Django orm code". > > Am I right? Actually, I think the ORM's extensibility

Re: GSoC Intro, Update, and Proposal -- HTTP & WSGI Support Improvements

Hi Chris, On Apr 24, 7:47 pm, ccahoon wrote: > Tickets #6527, #7581, and #2504 deal with issues in HttpResponse. They > all have code but decisions need to be made about how to keep > middleware from interfering with or breaking HttpResponses in certain > instances, and

Re: Can Trac email CC list when bug is fixed?

On Apr 11, 1:15 pm, Marc Fargas wrote: > That's a but in TRAC's svn-commit-hook script, there's a ticket about it in > TRAC's TRAC with workarounds and so onhttp://trac.edgewall.org/ticket/3508. Thanks. Actually reading through that ticket, it appears there is no bug

Re: Session-based messages (Contrib-05, #4604)

On Jan 6, 11:20 am, "Jacob Kaplan-Moss" wrote: > I'd like to see this moved into an external app so that we can > de-couple it from the 1.1 release. If it proves to be popular and > stable, we could then consider it for 1.2. I extracted 4604 into an external app[1]

Re: BitmaskField

@Andrew: Thanks! That's precisely the missing piece from my code; if I get some time to put it all together, I think it'll be a full solution. My approach uses sets of arbitrary flag values rather than creating constants for flags, and it's implemented as a normal model field, which seems a

Re: BitmaskField

I've written and am using a BitFlagsField, but hadn't yet shared it since I haven't been able to get the ORM lookup stuff working the way I want it. I've pasted my code-in-progress at dpaste: http://dpaste.com/hold/96435/ The current code includes a model BitFlagsField, a form

ticket 9163

Hi devs, Anyone have a moment to give an opinion on the best direction for a fix to #9163 [1]? I know there's been some discussion of alternate ways to do CSRF-protection, but for the time being CSRFMiddleware is what we've got, and it would be nice if it didn't break ETags. I can put together

Re: Proposal: Do not use global settings.py when running unit tests

On Nov 3, 3:24 am, Siddhi <[EMAIL PROTECTED]> wrote: > What is needed is a way for a test to specify its environment so that > it is run in the same environment irrespective of the project > environment specified in settings.py. This doesn't fix the third-party/contrib apps problem, but "a way

Re: Proposal: Decouple messages from contrib.auth

> I think that auth messages are the wrong way to do it most of the time > they are used (including django core code) anyway. They are usually > used to inform that an action worked (or didn't) -- this should be > done as session messages, not user messages. +1 to this, and also to decoupling

<    2   3   4   5   6   7