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 mechanisms are suffi

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, you can try to avoid the "

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 subsequent

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 wrote: > Today I filed #11957 [1], and becau

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, separate

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 message because you are sub

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 more magical behavior

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 helpful to focus on s

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 from a doctest to a un

Re: Delete order of generic relation models

Hi Ryan, Moving discussion here off the Trac ticket. On Apr 25, 5:44 pm, Ryan wrote: > A decent workaround is for my post_delete hook to pass > force_update=True and catch DatabaseError when saving the article, in > case it has already been deleted.  But I think it would be nice if > django just

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 expectations. Django do

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 to really use fieldsets,

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 > discussed with Jacob at DjangoCon

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. Yes, this is one of the

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 relevant API question. In for

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, urls or settings files, can

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

Hi Russ, On Jul 10, 8:24 am, Russell Keith-Magee wrote: > On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer wrote: > > Wouldn't it be most sensible to treat the URL mount point similarly to > > hostname, since they are really just two pieces of the same data: the > >

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 syst

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 way > to get the people wh

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 should be multiple separat

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 the form. I guess you'd

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 effort towards making them all behave the same w

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 > offer a class attribut

Re: Model-level validation

On Thu, Sep 29, 2022 at 6:19 PM Curtis Maloney wrote: > On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote: > > Why doesn't Django validate Models on save()? > > > The short answer is: backwards compatibility. > > Model level validation hasn't always been a thing, with Django initially > depending

Re: load template tag library

On Nov 16, 12:40 pm, ptone wrote: > On Nov 16, 1:12 am, Roald wrote: > > Can anybody explain why template tag libraries are loaded from > > *inside* a template? The more I work with them, the more I get the > > feeling that specifying which template tags are available in a > > template should be

Re: load template tag library

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2011 02:51 PM, Luke Plant wrote: > It's pretty easy to produce a DOS attack using only builtin template > tags and filters, and a completely empty context e.g.: > > {% for a in "xxx"|make_list %} > {% for a in "xxx"|

Re: New feature: Defining fieldsets in form class (Ticket #17301)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mikołaj, Thanks for your work on contributing to Django! I am a bit skeptical about defining form fieldsets in Python code, as they have no effect on server-side interpretation or validation of form data, they are purely an HTML/presentational iss

Re: Allowing models to influence QuerySet.update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2011 02:58 PM, Kääriäinen Anssi wrote: > """ > H, that is not ideal behavior. You mean QuerySet.delete() calls > the signal for each deleted object, rather than doing a delete at the > database level? > """ These two things aren't mutuall

Re: Allowing models to influence QuerySet.update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2011 11:32 PM, Anssi Kääriäinen wrote: > I should not have said that this would be a good optimization, and > used the possible optimizations wording. I haven't got any performance > problems when using delete in 1.3. So from my point > of vie

Re: PUT and post data

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Thibault, Thanks for checking in on this ticket. It's helpful to get a clear resolution rather than leaving things hanging in an unclear state. On 12/01/2011 11:14 AM, Thibault Jouannic wrote: > I'm looking for some news about the ticket #12635. >

Re: Deprecate change pk + save behavior for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Anssi, On 12/02/2011 06:54 PM, Kääriäinen Anssi wrote: > I think I will pursuit the immutable PK approach, and see how it > works (back to square one). BTW are there -1 calls on this approach, > or the pk change tracking in general? I haven't been

Re: Deprecate change pk + save behavior for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2011 07:29 PM, Kääriäinen Anssi wrote: > At this point this is not the idea. The idea is to just disallow this > (assuming > multicolumn PK firstname, lastname): > > user = User(firstname = 'Jack', lastname = 'Smith') > user.save() > user.fi

Re: Deprecate change pk + save behavior for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2011 10:18 AM, Carl Meyer wrote: > So what about admin users who are currently relying on this behavior as > a way to clone objects with natural PKs (given that the > save-and-add-another button is useless with natural PKs unles

Re: Deprecate change pk + save behavior for 1.4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2011 02:13 AM, Anssi Kääriäinen wrote: > Admin should be fixed [#2259]. Making PK fields non-editable in > ModelForms would be good, too. Is it OK to consider the current > ModelForm behavior a bug, or will it need a deprecation cycle? I thin

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Vinay, On 12/05/2011 04:41 AM, Vinay Sajip wrote: [snip] > containing " IN ()", which the backend rejects as a syntax error]. I'm > running the full suite now, but I don't expect it to finish before the > end of the day :-( That sounds orders of m

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 08:10 AM, Vinay Sajip wrote: > Not too bad for a first complete pass. Over two and a half hours to > run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and > with fsync = off. All else set to default values. Time to investi

Re: Feature proposal: models.CALL_DELETE or effective equivalent

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 08:31 AM, Yo-Yo Ma wrote: > While I agree that signals allow for neat decoupling, they aren't as > DRY or quick as a simple field kwarg. Imagine you have 8 models that > have custom delete methods. Which is easier: A) avstracting the > fu

Re: Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2011 11:56 AM, Jeremy Dunck wrote: > Carl, to be clear, if py3 pg is slower, but py2 pg is still in line w/ > baseline, would that block merge to trunk? It's quite possible the > problem lies in psycopg, but I think merging (with caveat empto

Re: PUT and post data

Fwiw, for the last number of months we've been telling people that pull requests are fine in lieu of uploaded patch, but the pull request still needs to be linked from a Trac ticket (so Trac remains the single source of truth). Carl -- Sent from my Android phone with K-9 Mail. Please excuse my

Re: PUT and post data

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2011 07:25 AM, Thibault Jouannic wrote: > https://github.com/django/django/pull/87 > > Hope I did everything right. > > I've read the submitting patches doc, but is a git pull request > accepted? Otherwise, Should I upload a patch in the clo

Re: Django-nonrel patches

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mmm, this reads to me like a bit of a mis-understanding. Hinges on what Jonas means by "before the patch gets accepted." The phrase is slightly confusing because we have an Accepted state in Trac, but that applies to tickets, in concept, not to specifi

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/10/2011 03:35 PM, Joe & Anne Tennies wrote: > So, with the current plan to add 3.x support to 1.5 and the plan to > remove 2.5.x support in 1.5. Should all the exception handling blocks be > converted to "except MyExceptionClass as e:" style nota

notice: change in Trac emails behavior

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't believe this has ever been announced here, and it should be: As of the last week of November 2011, the "always_notify_updater" Trac setting on code.djangoproject.com was switched to False (as a result of user complaints; see https://code.django

Re: RFC: Query Methods

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Zachary, On 01/02/2012 10:55 PM, Zachary Voase wrote: > At the moment it's very easy to add methods to individual models, just > by putting a method on the model class itself which accepts 'self'. > However, defining business logic on collections o

Re: RFC: Query Methods

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2012 10:42 AM, Alex Gaynor wrote: > I haven't analyzed your suggestion in detail Carl, but there is a good > reason for managers to exist: > querysets cache internally on iteration, managers are not directly > evaluable, but were they you cou

Re: Proposal: Logout user when they change their password.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/08/2012 03:57 PM, Arnoud van Heuvelen wrote: [snip] > 2) Build a relation table that links the sessions to the users. (Or > use a CSV in the user object.) This could be done completely in the > auth package. Downside is that we have to create a n

Re: Proposal: Logout user when they change their password.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2012 09:01 AM, Carl Meyer wrote: > This is not an option because the database session backend is only one > of many session backends. Oh, never mind - I misunderstood the proposal. This wouldn't be dependent on using the datab

Re: RFC: Query Methods

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Anssi, On 01/10/2012 04:14 AM, Anssi Kääriäinen wrote: > However, I would like it if you could mix methods from different > managers. Maybe add qs.set_manager(manager_name), and so you could do: > SomeModel.objects.order_by('id').some_manager_metho

Re: Caching back-refernces on one-to-one fields

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/19/2012 11:02 AM, Jeremy Dunck wrote: > On Thu, Jan 19, 2012 at 5:14 PM, Adrian Holovaty wrote: >> john = Author.objects.get(name='john') >> books = list(john.book_set.all()) >> >> # Does a database query, but should be smart enough to simply re

Re: Why recommend to include project name in settings?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chris, On 02/10/2012 05:36 AM, Chris Wilson wrote: >> But "mysite" is a package, and Django wants us to be able to import >> "mysite.settings" and "mysite.urls" (in fact, the latter is the >> default ROOT_URLCONF setting). In order to make that pos

Re: Why recommend to include project name in settings?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2012 08:25 AM, Chris Wilson wrote: > On Fri, 10 Feb 2012, Carl Meyer wrote: >>> Is there any reason not to drop the project name part of >>> DJANGO_SETTINGS_MODULE and ROOT_URLCONF, to reduce the risk of >>>

Re: Why recommend to include project name in settings?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/10/2012 08:47 AM, Adam "Cezar" Jenkins wrote: > On Fri, Feb 10, 2012 at 9:50 AM, Carl Meyer <mailto:c...@oddbird.net>> wrote: > > "import .module" > > > Not arguing one way or another,

Re: Discussion on Ticket #16304

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 02/11/2012 10:13 AM, j4nu5 wrote: > I have written a patch for ticket #16304 (https:// > code.djangoproject.com/ticket/16304). Thanks for the patch. > The ticket adds support for the HTML5 input placeholder attribute > (WHAT Working Group pla

Re: Django 1.4 beta 1 released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Reinout, On 02/16/2012 03:35 PM, Reinout van Rees wrote: > Partially related question: several tickets have a pull request on > github instead of an svn patch. Is that enough? I assume a real svn > patch is better? A link on the ticket to a github

Re: Class-based view decorators

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Tobia, Thanks for taking the time to propose these additions. Comments below: On 02/17/2012 11:04 AM, Tobia Conforto wrote: > The first is an updated version of method_decorator, made to accept > additional arguments and pass them to the origin

Re: Django 1.4: call for release blockers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Anssi, On 02/18/2012 05:37 AM, Anssi Kääriäinen wrote: > The second one is about .iterator() and .prefetch_related() > interoperability. They are mutually exclusive (you need to fetch all > the objects before you can do prefetch. However, .iterator

Re: Django 1.4: call for release blockers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2012 09:40 AM, Carl Meyer wrote: > On 02/18/2012 05:37 AM, Anssi Kääriäinen wrote: >> The second one is about .iterator() and .prefetch_related() >> interoperability. They are mutually exclusive (you need to fetch all >&g

Re: Revisiting multiline tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2012 11:04 PM, Glenn Washburn wrote: > I'd like to reopen discussion on the multiline tag issue (see: > https://code.djangoproject.com/ticket/8652) which was closed 3 three > years ago as "won't fix". The last comment notes that this won't >

Re: Revisiting multiline tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2012 10:20 AM, Torsten Bronger wrote: > I've made the same observations as in the parallel posting: I18n > becomes awkward with single-line tags. We have dozens of lines like > > {% blocktrans with originator=entry.originator|get_really_full

Re: Revisiting multiline tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Glenn, On 02/19/2012 07:06 PM, Glenn Washburn wrote: > Very brief I might add. He only alludes to one technical reason > saying: "error trapping can occur much earlier". I'm trying to > understand what is meant by this as well. I don't see how m

Re: Should the settings.py template include USE_TZ = True?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2012 01:59 PM, Aymeric Augustin wrote: > The main reason for enabling time zone support by default in new > projects (through the settings.py template) was to store UTC in the > database (on SQLite, MySQL and Oracle; PostgreSQL always does tha

Re: Re-posting of previous thread: ``QuerySet.update`` not updating ``auto_now=True`` fields

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2012 05:11 PM, Yo-Yo Ma wrote: > I understand that ``QuerySet.update`` issues an UPDATE SQL statement, > but Django's code could be modified to include each ``auto_now=True`` > field on a model in the UPDATE statement, setting the value to > `

Re: django-admin.py startproject creating duplicate settings.py files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2012 08:31 PM, Yo-Yo Ma wrote: > I have trunk installed from last night, and this is actual terminal > output (except for the stuff omitted on the left of the $): > > (my_venv) myusername$ django-admin.py startproject foobarz > (my_venv) myus

Re: django-admin.py startproject creating duplicate settings.py files

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2012 09:19 PM, Yo-Yo Ma wrote: > (myvenv)My-Names-MacBook-Pro:dev myusername$ mkdir test_startproject > (myvenv)My-Names-MacBook-Pro:dev myusername$ cd test_startproject/ > (myvenv)My-Names-MacBook-Pro:test_startproject myusername$ ls -a > .

Re: ModelFormSet validation fails when initial queryset contains objects not in the default manager's queryset

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tom, On 02/20/2012 10:58 PM, Tom wrote: > I have a ModelForm and a ModelFormSet. I initialize my ModelFormSet with > a queryset containing objects from a custom manager that is not the > model's default manager. My formset does not validate, becaus

Re: ModelFormSet validation fails when initial queryset contains objects not in the default manager's queryset

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ramiro, On 02/21/2012 08:05 AM, Ramiro Morales wrote: > On Tue, Feb 21, 2012 at 2:58 AM, Tom wrote: >> Hi everyone, > > Please start threads like this to the django-users mailing list > as this list is dedicated exclusively to discussions about >

Re: Discrepancy involving choices with ModelForm and Form

Hi Stuart, On 02/21/2012 05:29 PM, Stuart Laughlin wrote: > It seems to me there is a discrepancy between ModelForm and Form when > it comes to fields with choices. When I create a ModelForm from a > model having a CharField with choices set, the resultant form contains > a select with a blank cho

Re: HttpRequest.read(), HttpRequest.body, HttpRequest.raw_post_data

Hi Tom, On 02/23/2012 06:07 AM, Tom Christie wrote: > I see that as of 1.4 `HttpRequest.raw_post_data` is being marked as > "pending deprecation", and `HttpRequest.body` has been introduced. > This still leaves us with two ways to get at the request body - `.body` > and `.read()` > > If we're goi

Re: Improving docs for User.is_authenticated()

Hi Tom, On 02/23/2012 08:41 AM, Tom Evans wrote: > I don't like this function that much. It doesn't actually check > whether users are authenticated - which is to say, they have presented > credentials which we have accepted and authorized them to use to the > site. Instead it always returns true.

Re: Improving docs for User.is_authenticated()

On 02/23/2012 09:42 AM, Luke Granger-Brown wrote: > It does prove that they've authenticated, in that request.user will > contain an AnonymousUser if they're not logged in, which overrides this > method to always return False. If they are, then they'll get their > actual user, which will return Tru

Re: HttpRequest.read(), HttpRequest.body, HttpRequest.raw_post_data

On 02/23/2012 09:40 AM, Tom Christie wrote: >> a design decision was made long ago that HttpRequest objects should > provide a file-like interface (thus also .readline(), .readlines(), and > .xreadlines()) > > Wouldn't having .read() .readline(), .readlines(), and .xreadlines() all > on `request.b

Re: Revisiting multiline tags

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2012 11:29 PM, Russell Keith-Magee wrote: > This thread contains 6 people expressing support for this change, and > 2 against (a BDFL, a core developer) -- and you can add me to the -0 FWIW, I'd forgotten how painful the single-line restricti

Re: django 1.4b + mysql + boolean fields

Hello Tomasz, On 02/24/2012 03:00 AM, Tomasz Kloc wrote: > I've changed my database from postgresql to mysql. I have never used > mysql in django projects before, so it was surprising to me when i saw > 0/1 values instead of True/False in boolean fields. It wasn't an issue > until i upgraded djang

Re: call_command; add *.pyc and *.pyo files to commands list

On 02/29/2012 09:07 PM, bhuztez wrote: > IMHO, no extra support for them is required. Simply add support for > PEP 302 importers, Django will find management commands in pyc/pyo > files. > > I improved patch for #14087 weeks ago, which add support for PEP 302 > importers. I am just wondering why t

Re: Pretty Django model instaces updating

Hi Kee, On 03/01/2012 11:24 AM, Kee wrote: > This helper could be used as an instance method in > django.core.models.Model class: > https://gist.github.com/1951748 Thanks for the suggestion. I agree that that's a useful pattern and one I frequently use myself. The problem is that the model insta

Re: Newline stripping in templates: the dnl way

On 03/01/2012 01:28 PM, Leon Matthews wrote: > It looks like a lot of work looks went into this patch, why did it stall? Same reason any ticket stalls - it seems that nobody felt strongly enough about it to put the time into reviewing and thoroughly testing the patch and marking it Ready for Check

Re: Pretty Django model instaces updating

On 03/01/2012 09:46 PM, Tai Lee wrote: > This is easy to achieve in your own code. Create your own BaseModel > class that all your models subclass. Instead of using > `.filter().update()`, do this: > > def update(self, **kwargs): > """ > Updates the fields specified in `kwargs` and the

Re: New feature: Templated email messages

Hello Artem, On 03/02/2012 03:04 PM, Артем Рыжов wrote: > I'm working as a web developer for many years. One of the most frequent tasks > is sending email messages. And template system is very usefull for this task > as for web pages. It's strange, but I have not found builtin support for > ema

Re: Django participation in Google Summer of Code 2012

On 03/08/2012 08:19 AM, Łukasz Rekucki wrote: > On 8 March 2012 16:43, Aymeric Augustin > wrote: >> PEP 414 was accepted a few days ago. It's designed to make it easier to >> support 2.6, 2.7, 3.3+ on the same codebase. >> >> I hope we'll take advantage of this new feature in Django; however, that

Re: [1.4] Pass "obj" parameter to get_inline_instances

Hi Yohan. On 03/08/2012 07:04 AM, Yohan Boniface wrote: > Some great changes have been made on the admin for this release. One of > them is the add of the "get_inline_instances" [1], that gives the > possibility to change the inlines list at runtime. > > I've a little suggestion on this. It could

Re: Django participation in Google Summer of Code 2012

Hi Ian, On 03/08/2012 08:40 AM, Ian Clelland wrote: > On Thursday, March 8, 2012, Aymeric Augustin > > wrote: >> PEP 414 was accepted a few days ago. It's designed to make it easier > to support 2.6, 2.7, 3.3+ on the same codebase. > > (finishes reading

Re: Making sure Web APIs built with Django don't have CSRF vulnerabilities.

Hi Tom, Thanks for raising this. On 03/14/2012 11:20 AM, Tom Christie wrote: [snip] > One idea to mitigating this in Django core that I've considered would be > introducing a '@csrf_defered' decorator, that would act like > '@csrf_exempt', but wrap request.session in a lazily evaluated > '@csrf_p

Re: authentication by email

Hi Daniel, On 03/15/2012 09:24 AM, Daniel Sokolowski wrote: > Why can we not just increase the length limit on the username field?, > Why can't we just throw a validation error if data entered is to long > and the schema has not been updated? I think the answer yes we can and > easily. I don't me

Re: authentication by email

On 03/15/2012 09:41 AM, Daniel Sokolowski wrote: > Yes it clearly would, however I see two possible solutions to make it > more friendly: > > 1. We provide MySQL, Sqlite3, PostgreSQL instructions on how to do it - > I mean the actual commands to execute. > 2. Catch the DB error and throw a form va

Re: [1.4] SECRET_KEY deprecation is confusing...

On 03/15/2012 07:52 AM, Nick Pope wrote: > There is a problem in 1.4rc2 where a missing SECRET_KEY causes Django to > refuse to start. > > According to the current version of the release notes on the > website: *In Django 1.4, starting Django with an empty SECRET_KEY will > raise a DeprecationWarn

Re: authentication by email

Hi Daniel, On 03/15/2012 11:48 AM, Daniel Sokolowski wrote: > The issue here is that django auth is limited, and restrictive and needs > hacks to make it use emails as usernames, we can agree on that yes? Certainly. > We > can also agree that contrib.auth2 with LFK is a complex undertaking far

Re: Looking for some insight into a tiny piece of the django codebase

Hi Tim, On 03/19/2012 05:17 PM, Tim Diggins wrote: > I'm wondering what the lines at the end of django/db/models/ > deletion.py do: > > for model, instances in self.data.iteritems(): > for instance in instances: > setattr(instance, model._meta.pk.attname, None)

Re: Contrib backwards-compatibility question

Hi Alex, On 03/22/2012 11:26 AM, Alex Ogier wrote: > Is it considered a backwards incompatibility to import > django.conf.settings at the top level in a contrib models.py file > (specifically, contrib.admin)? I know it's possible to do so, for > example contrib.comments.models imports it, but it c

Re: Django 1.4 default database required?

On 04/02/2012 09:35 AM, Optimus Paul wrote: > I've been running Django for quite a while without a "database", we > use MongoDB, and it has worked well for us. We upgraded to 1.4 and > found that suddenly a default database is required. Is there a reason > for this? Or is this a bug? Preston ha

Re: auth.user refactor: the profile aproach

On 04/02/2012 06:35 PM, Jacob Kaplan-Moss wrote: > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. +1 from me. One minorish nit: I think that "in the face of ambiguity, refuse the temptation to guess" should apply equally to r

Re: auth.user refactor: the profile aproach

On 04/03/2012 08:28 AM, Alex Ogier wrote: > I have written up a little bit about the alternate proposal that I made > a while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements > > In addition to other arguments, there is a point-by-point breakdown of > what I feel

Re: auth.user refactor: the profile aproach

On 04/03/2012 02:34 PM, Daniel Sokolowski wrote: > Correct me if I’m wrong but both LFK or a swappable user model approach > like your fail to address issue of extensibility. If today my project is > authorizing with username and password and tomorrow I wish to add > OpenAuth then my User model is

#18094: signals, model inheritance, and proxy models

Hi all, There's a discussion ongoing on ticket #18094 (https://code.djangoproject.com/ticket/18094) that has enough potential back-compat implications that it seems worth getting feedback here. Currently, when you delete a concrete-inheritance child model instance, pre_delete and post_delete sign

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 10:52 AM, Jeremy Dunck wrote: > On Thu, Apr 12, 2012 at 9:31 AM, Carl Meyer wrote: >> There's a discussion ongoing on ticket #18094 >> (https://code.djangoproject.com/ticket/18094) that has enough potential >> back-compat implications that it seems w

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote: > in my mental model, there are three types of inheritance: > > concrete: two tables, deletion should fire two signals, one for the > child record and one for the parent record. > > abstract: there's no parent table, deletion should fire one s

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 11:02 AM, Javier Guerra Giraldez wrote: > IOW, i think the existing signals are database-related and should be > fired only for the concrete part(s). if the abstract part wants to, > it can send custom signals. Also, it isn't really true that the model signals are strictly tied to d

Re: extra files in startproject (was: Django is not a serious framework, really)

Hi Jason, On 04/11/2012 06:10 AM, Jason Ma wrote: > Hi, > I download and tried to use the Django 1.4 yesterday. I am a dummy > and I just follow the official document, but When I just start a > project. > I found that it is what I see from my computer: > > jason@jason-pc:~/workspace/hunqing$

Re: #18094: signals, model inheritance, and proxy models

On 04/12/2012 12:43 PM, Anssi Kääriäinen wrote: > It is important that pre/post init signals will not get more expensive > than they currently are. Even now they can give around 100% overhead > to model.__init__(). And this is in a case where the currently > initialized model has no signals attache

Re: extra files in startproject

Hi Alex, On 04/12/2012 01:07 PM, Alex Ogier wrote: > Maybe it would be worth experimenting with various combinations of > django 1.x django-admin.py executables with django 1.4 libraries? Maybe > if django-admin.py is a symlink into a 1.3 tree but django 1.4 is on the > search path this stuff coul

Re: extra files in startproject

On 04/12/2012 03:16 PM, Aymeric Augustin wrote: > This problem occurs at least when you run "setup.py install" before > and after the commit that introduced the new project layout. > > Some people who had the habit of running "setup.py install" from a > git clone to keep up-to-date with the develo

  1   2   3   4   5   6   7   8   >