Re: Composite key development

2017 at 7:08:35 AM UTC+2, Asif Saifuddin wrote: >> >> Hi Julien, >> >> I will publish it very soon. >> >> Thanks >> >> On Wednesday, March 1, 2017 at 5:58:50 AM UTC+6, Julien Phalip wrote: >>> >>> Hi Asif, >>> >>> That soun

Re: Composite key development

n, as I haven't had the time > and energy to look into it too much, but I can try to clarify some > aspects of what I did years ago. > > On Mon, Feb 27, 2017 at 11:10:55AM -0800, Julien Phalip wrote: > > Composite primary keys (GSoC) > > > > = &g

Re: Composite key development

Hi Asif, That sounds good. On first look I did have some reservations about some of the design details in the current DEP, especially around the observer pattern for data binding. But I’m going to have to dig deeper into the implementation to get a clearer idea. It’d be great if you could

Re: Composite key development

On Tuesday, November 29, 2016 at 4:10:38 AM UTC-8, Craig Kerstiens wrote: > > My company (Citus Data) is interested in sponsoring some Django work. In > particular work on support for composite primary keys. From what I > understand this wouldn't be the first time the work has been explored and

Re: Deprecate admindocs?

On Jul 25, 2013, at 5:29 AM, Aymeric Augustin wrote: > Hello, > > I'd like to deprecate admindocs. Here are my reasons: > > 1) It's called the "documentation generator", but it only operates on > docstrings. This promotes the idea that docstrings are

Re: #20739 - Making LiveServerTestCase not depend on staticfiles?

Hi, On Jul 15, 2013, at 9:22 AM, Carl Meyer wrote: > On 07/14/2013 07:16 AM, Jannis Leidel wrote: >> Yeah, I can relate to that, it does to me, too. I think decoupling >> the file serving slightly from how the files got to the place they >> are served from, is a good first

Re: Ticket 19445

Hi Luke, On May 1, 2013, at 3:31 PM, Luke Plant wrote: > Hi all, > > Can I get some feedback on what to do about ticket 19445? > > https://code.djangoproject.com/ticket/19445 > > I have re-opened this ticket because I don't think it was addressed > satisfactorily. I

Re: broken pipe issue with runserver #4444

On Dec 18, 2012, at 5:18 AM, Emil Stenström wrote: > On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote: > I'd rather see this be leaved as-is, since I haven't seen a single > report on these broken pipe 'issues'. > > Here's a report: > > I'm using PhantomJS (headless

Re: django.contrib.redirects customisation

On Nov 15, 2012, at 12:22 PM, Лебедев Илья wrote: > Recently I needed functionality just like in django.contrib.redirects - > redirects table, that can be edited in admin. I was sad to find out that its > strongly not configurable. For example, I dont need status 301, but

Re: Admin UI improvement - actions displayed as buttons rather than drop-down list

Hi Marijonas, I've left a comment in your ticket. The conversation can continue there. Thanks, Julien On Nov 4, 2012, at 8:15 AM, Marijonas Petrauskas wrote: > Yes, it's created by me. Sorry for not referencing it. > > > On Sun, Nov 4, 2012 at 2:06 PM, Łukasz Rekucki

Re: Yak shaving the test framework on the way to pluggable user models (#3011)

On Aug 25, 2012, at 1:15 AM, Russell Keith-Magee wrote: > Hi all, > > So, I've been working on a Django branch [1] to implement the approach > to pluggable user models that was decided upon earlier this year [2] > > [1] https://github.com/freakboy3742/django/tree/t3011 > [2]

Re: RFC: More class based views, take two

Hi Andy and Iván, On May 28, 2012, at 12:38 PM, Iván Raskovsky wrote: > Hi Andy, > > On Mon, May 28, 2012 at 7:30 AM, Andrew Ingram wrote: >> Hi Iván, >> >> I'd temporarily given up on getting extra_views into Django because of >> a blocking issue with pagination and

Re: Redesign of djangoproject.com?

Hi everyone, It's really exciting to see the community offering to help in this endeavor. I myself spent quite a bit of time last year driving a redesign effort for djangoproject.com, so I thought I'd share my work with you now while the momentum is picking up again. So, using some initial

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

On Apr 11, 2012, at 11:44 AM, 3point2 wrote: > Julien, I'm not describing an edge case. Django will return an HTTP > 500 for ANY field lookup on a related model that is not in the > list_filter option. > > To test, simply create a model that has a ForeignKey to another model > and hook it up

Re: Admin site: Appropriateness of HTTP 500 when using non-allowed query strings

On Apr 10, 2012, at 4:34 AM, 3point2 wrote: > The admin site allows the use of certain query strings to filter > change list pages. The syntax follows queryset field lookups, for > example http://mysite.com/admin/myapp/mymodel/?field__exact=test. > Lookups that are not specified on the

Re: Feature request: read-only admin view

Hi, This feature has been discussed in the past on this mailing list (e.g., http://goo.gl/ezMpc and more recently: http://goo.gl/j1CPv). There has also been talks about merging the databrowse contrib app into the admin (see this ticket: https://code.djangoproject.com/ticket/8936 or the GSoC

Re: Message Formatting in AdminMailHandler

Hi, On 27 October 2011 22:47, momo2k wrote: > Hello, > > I posted this question some time ago on django-users, but since nobody > answered and I think about this as a serious problem, I'll post here: > > Is there a reason why AdminMailHandler does not use >

Re: Proposal for a new templatetag definition syntax

On 13 October 2011 15:30, LeeS wrote: > Not sure if this is still an ongoing discussion, but I prefer to write > all new tags with a simple syntax that matches Python. There's no > real advantage in defining a unique, custom syntax for a template > tag. > > All HTML authors

Re: Splitting out admin functionality

On 11 October 2011 14:04, tWoolie wrote: > > Yep. Could you outline your plan of attack for this? > > 1) create "newadmin" project to be a dropin replacement for admin. >(Clone current admin and slowly replace features/trim dead code) > > 2) Split out

Re: Splitting out admin functionality

On 11 October 2011 12:22, tWoolie wrote: > > If someone is willing to take this on then I'd be happy to provide some > > support by reviewing patches, giving feedback etc. > > Cheers. Would you be willing to review code that swaps out entire > swathes of

Re: Splitting out admin functionality

Hi, On 10 October 2011 15:20, tWoolie wrote: > I'd like to propose a project to split out the table/list > functionality and the filtering functionality in the django admin into > a seperate contrib app. This is really core functionality which is >

jQuery.noConflict() vs. jQuery.noConflict(true)

Hi, During the recent DjangoCon sprints there have been some discussions between Jannis, Rob Hudson and I around a change which occurred in trunk a few months ago in r16415 [1]. This change specifically made the admin use jQuery.noConflict() instead of jQuery.noConflict(true) while namespacing

Re: confusing things in Trac UI (was: Design decision for #1625...)

On 20 September 2011 14:16, Carl Meyer wrote: > On Tuesday, September 20, 2011 1:26:22 PM UTC-6, jdunck wrote: > > Well, I meant to mark accepted as endorsement of the patch, but that > > made me owner. > > Yeah, this is confusing in our Trac UI. The "accept" radio button at

Re: filter_horizontal back button issue under webkit

Hi John, On 9 September 2011 11:28, John wrote: > Hi All, > > This is in regards to ticket #13614 (Back button breaks many to many > widget). I'm hoping that bringing this up might bring some attention > to it. This is a rather nasty bug affecting the filter horizontal

Re: Browser Support

On 30 August 2011 19:08, Julien Phalip <jpha...@yahoo.fr> wrote: > ... perhaps the FAQ? > That is, assuming we'd consider this a potentially frequently-asked question :) -- You received this message because you are subscribed to the Google Groups "Django developer

Re: Browser Support

On 30 August 2011 17:33, Idan Gazit wrote: > So, a while back, I announced that Django is dropping support for IE6 in > the admin. What I _didn't_ specify is what browsers are supported. > > I'm currently composing a bit for the 1.4 release notes about admin browser > support, and

Re: What is Django?

On 26 August 2011 07:55, Amirouche Boubekki wrote: > 2011/8/25 Mikhail Korobov > > >> There are many big and well-known sites built with django and I think >> mentioning these sites and providing testimonials from people working on >> these

Re: MultipleObjectMixin and Pagination

Hi Andrew, On Jul 1, 9:12 am, Andrew Ingram wrote: > Hi All, > > I've been working with Django's class-based views a fair bit recently, > specifically to create some additional ones (dealing with formsets > mostly). I've been trying to inherit as much of the existing >

Re: Additional example for reverse_lazy documentation

Hi Alasdair, On Jun 30, 7:49 am, Alasdair Nicol wrote: > Hi, > > I like the upcoming reverse_lazy in Django 1.4 (commit 16121). I suggest > the examples should include using reverse_lazy in urlpatterns. > > I just helped a user out in stackoverflow [1] who was struggling

Re: Javascript Testing

Hi Sean, On Jun 18, 4:24 am, Sean Bleier wrote: > Hello everyone, > > A couple months ago I started work on a django branch [1] (with the help of > @jezdez) that introduces a framework for writing javascript unit tests using > QUnit[2].  I started with QUnit because Django

Re: 5-for-1?

On Jun 18, 11:38 am, Stephen Burrows wrote: > I would love it if someone could look at 13956 [1] RFC'd, thanks ;) Julien -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to

Re: Logging configuration and handle_uncaught_exception

On Jun 17, 10:48 pm, Matt Bennett wrote: > > This is a case for a custom Filter object [1]. The filter object > > implementation would only be a few lines, to reject logging when DEBUG > > is True, and can be attached to the admin email handler in the default > > logging

Re: FYI: added a proper "easy" field to Trac

On Jun 16, 10:32 am, Julien Phalip <jpha...@gmail.com> wrote: > On Jun 16, 3:08 am, Alex Kamedov <kame...@gmail.com> wrote: > > > Django documentation page Contributing to Django [1] has the same problem > > too > > [1]https://docs.djangoproject.com/en/1.3/in

Re: FYI: added a proper "easy" field to Trac

On Jun 16, 3:08 am, Alex Kamedov wrote: > Django documentation page Contributing to Django [1] has the same problem > too > [1]https://docs.djangoproject.com/en/1.3/internals/contributing/ I've fixed the link in the wiki page. The doc is already fixed in trunk. Thanks,

Re: Sorting UX question

On Jun 9, 9:45 am, Luke Plant wrote: > In the new admin sorting UI, which now supports sorting on multiple > fields, the behaviour can be described by the following two rules: > > 1. If you click on a header, it is made the primary sort field >    (with others moved down

Re: Proposal: Adding UI and UX fields to Trac

On Jun 8, 12:25 am, Luke Plant wrote: > On 07/06/11 11:32, Idan Gazit wrote: > > I'd like to propose adding two flags to Trac, "UI" and "UX". > So would it be better to have just "UI/UX"? I totally agree that Trac needs something specific for this, as it's a shame we have

Re: Preventing the leaking of sensitive information in error logs

Many thanks to all for the feedback. I've just posted a new patch, welcoming any further feedback: https://code.djangoproject.com/attachment/ticket/14614/14614.exception-reporter-filter.diff Regards, Julien -- You received this message because you are subscribed to the Google Groups "Django

Re: Preventing the leaking of sensitive information in error logs

On Jun 1, 7:53 pm, Luke Plant wrote: > Would it possible to make the sensitive decorator add some kind of > strategy object to the request, which itself is responsible for the > filtering, rather than a simple boolean flag? The GET/POST parameters appearing in the error

Preventing the leaking of sensitive information in error logs

Hi, Recently I've been a bit embarrassed to receive a 500-error email report containing a client of mine's password displayed in clear because the admin login view had encountered an unhandled exception. This is probably OK in a debug environment but in production this can potentially have

Re: Reshaping the "Contributing to Django" documentation

On May 21, 2:15 am, "Jonas H." wrote: > > "[...] try and duplicate it. If you can duplicate it [...]" > > I'd stick with "reproduce" here because "duplicate" may be confused with > "duplicate tickets". Yes that's a good point. I fixed that in the latest patch. Thanks! -- You

Re: Reshaping the "Contributing to Django" documentation

On May 21, 1:33 am, Waylan Limberg wrote: > One nitpick thought. I expect that people reporting bugs will go to > the "bugs-and-features" page, which is fine. However, as is often the > case, when their ticket is marked "accepted" (or some other triage > stage) they often get

Reshaping the "Contributing to Django" documentation

Hi there, I've been working on reshaping the documentation about contributing to Django, in particular the rather dense historical page [1] and the excellent recently added how-to guide [2]. This documentation has sort of grown organically over the years and has become a bit difficult to read, so

Re: model fields options

On May 7, 2:21 am, Alex Gaynor wrote: > Sounds like a bad idea to me.  unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields.  All the other options belond to specific fields. I agree in

Re: PatchHammer 40,000

On May 6, 8:25 am, Luke Plant wrote: > I do think this could be useful though. If someone submits a patch that > *immediately* doesn't apply to trunk, then it will be useful to know > that, and hooking this in to Trac at the point the patch is uploaded > would be useful.

Re: Make redirection customizable in ModelAdmin view

On May 4, 4:13 pm, Yishai Beeri wrote: > +1 on breaking backwards compatibility, defaulting the arg to None. Just a note. Defaulting to None in itself does not break compatibility. Defaulting to None allows to do the url reversal from inside response_add. But then the

Re: Make redirection customizable in ModelAdmin view

On May 4, 10:59 am, Dario Ocles wrote: > Hello everybody. > > Ramiro Morales and me were working on this ticket #15294 [0] and > Julien linked this one #8001 [1]. We had a little discussion about two > possible solution for #8001 and Julien suggested that we should hear >

Re: NoSQL support

On Apr 28, 4:59 pm, Russell Keith-Magee wrote: > I haven't used the django-nonrel branch, and I'm not aware of anyone that > I know and trust that has. For what it's worth, I am currently using django-nonrel and its companions djangoappengine, djangotoolbox, and

A coupla patch reviews

Hi there, I've just posted a patch for #14262 to add a new assignment_tag helper function. Is anyone keen to review it? Also, it would be great if someone could review the latest patch for #15805. If that one gets checked in then we'll also be able to fix #14608 and then I'll start work on

Re: Request for comments: custom admin filters

On Apr 14, 8:46 am, Julien Phalip <jpha...@gmail.com> wrote: > Thanks a lot for your feedback. I agree with all your points and have > made the corresponding amendments in a new > patch:http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filt... Sorry, just in case

Re: Request for comments: custom admin filters

On Apr 14, 3:11 am, Jacob Kaplan-Moss wrote: > Hi Julien -- > > Thanks for your work on this! I'm working my way through the patch, > and it's looking good. I'm pretty happy with the internals, though I > do have some questions about the public API: > > * I'm rather unhappy

Re: Request for comments: custom admin filters

Hi Mikhail, On Apr 14, 4:56 am, Mikhail Korobov wrote: > Will your patch simplify creating filters not based on choices? E.g. > min/max filters where exact minimun and maximum values can be entered > (using form with method=GET and input fields for values)? I want a >

Request for comments: custom admin filters

Hello there, I've just posted a patch with a suggested implementation of custom admin filters: http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filterspecs.3.diff I've written some pretty comprehensive tests and have also had a stab at writing some documentation. You should find

Re: Something wrong about AssertRaisesRegexp and assertFieldOutput

On Apr 12, 2:00 pm, Karen Tracey wrote: > Adding re.escape in that function does break some tests, from a quick look > it seems mostly ones that are raising multiple errors but only one has been > listed by the caller of that utility function. It isn't clear to me from the >

Something wrong about AssertRaisesRegexp and assertFieldOutput

Hi, I've found two similar (and potentially linked) weird problems in the test framework while trying to understand why the perfectly looking tests in #14608 were failing. Before I open some tickets I'd like to hear if anybody has any clue about what's going on or if I'm missing anything. 1)

Re: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

On Apr 6, 12:09 am, Matt Hoskins wrote: > My apologies for reposting this - I originally posted this at the end > of January and as soon as I posted it I realised that with the push > for bug squashing for the 1.3 release going on I probably wouldn't get > any attention

Re: Proposal: switch to HTML5 for bundled templates

FYI, I've just stumbled on ticket #7452 and this thread: http://groups.google.com/group/django-developers/browse_thread/thread/f346813ab89d4155/ One interesting idea that was suggested is to introduce a setting for controlling the type of HTML. -- You received this message because you are

Re: Suggestion: a new "nature" field in Trac

On Apr 1, 10:36 am, Russell Keith-Magee wrote: > On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee > > wrote: > > Barring objection, I'll try to find some time this afternoon to > > introduce the new flags. > > A little later than originally

Re: Suggestion: a new "nature" field in Trac

On Apr 1, 10:36 am, Russell Keith-Magee wrote: > On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee > > wrote: > > Barring objection, I'll try to find some time this afternoon to > > introduce the new flags. > > A little later than originally

Re: Suggestion: a new "nature" field in Trac

On 29 March 2011 22:42, Luke Plant wrote: > As for the gardening, there are about 1700 open tickets that need the > type setting. Those needing the severity field changing to 'Blocker' can > be found more easily here: > > >

Re: Trac components cleanup

On Mar 29, 4:47 pm, Gabriel Hurley wrote: > The component re-organization is done now, as per Julien's (and Jannis') > suggestions above. I even re-categorized the 84 tickets that were in > "Contrib apps" into their new separate contrib.foo components (thank god for > Trac bulk

Re: Proposal: switch to HTML5 for bundled templates

On Mar 29, 4:01 pm, Stephen Burrows wrote: > 3. There is a simple workaround going back to ie6 for handling the css > problems related to unrecognized tags. [3] ...snip... > [3]http://diveintohtml5.org/semantics.html#unknown-elements The workaround works if

Re: Trac components cleanup

On Mar 29, 8:58 am, Gabriel Hurley wrote: > I can work on it late tonight (about 6-8 hours from now) if no one else gets > to it. > > All the best, > >     - Gabriel Excellent, thank you Gabriel! There's no rush -- whenever it suits you. Let me know if I can help in any way.

Re: Trac components cleanup

On Mar 29, 2:01 am, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip <jpha...@gmail.com> wrote: > > Now that 1.3 has been released (yay!), I'm reviving this thread to see > > if we can make Trac a little more efficient on o

Re: Suggestion: a new "nature" field in Trac

On Mar 28, 10:49 pm, Karen Tracey wrote: > +1 on having a distinction between bug, feature, and optimization. > > I don't think both "Uncategorized" and "Other" are necessary. My reasoning for "Other" was that there might be things that are neither a bug, a feature or an

Re: Suggestion: a new "nature" field in Trac

On 28 March 2011 17:28, Russell Keith-Magee wrote: > > * Uncategorized (default) > > * Feature request: for adding something new. > > * Bug report: for when an existing thing is broken or not behaving as > > expected. > > * Optimisation: for when an existing thing is not

Re: Suggestion: a new "nature" field in Trac

Hello, I'm not sure if the consensus so far is either "Meh" or "Let's give it a try", or if there's even a consensus. I'm still keen on the idea but I don't want to insist too much if it doesn't gather enough support, so I'll re-submit it here one last time. The latest proposal is to introduce a

Re: Trac components cleanup

Hi all, Now that 1.3 has been released (yay!), I'm reviving this thread to see if we can make Trac a little more efficient on our way to 1.4. I'll try to summarise what's been suggested so far in regard to improving and clarifying the "Component" field: * The "Contrib apps" component would be

Re: Trac components cleanup

On Feb 28, 10:58 am, Paul McMillan wrote: > I think the django-admin.py categories could be consolidated into a single > one. > > In the interest of readability, we might rename django.contrib.foo to > simply contrib.foo. > > As long as we're clarifying, "Django Web Site" might

Re: Suggestion: a new "nature" field in Trac

> On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip <jpha...@gmail.com> wrote: > > Hello, > > > I was wondering if others would find it useful to introduce a new > > field in Trac to characterise the nature of a ticket, allowing to > > choose from at l

Trac components cleanup

Hi, Tweaking Trac seems to be in the air, so I had some more ideas to suggest :) The "component" field in Trac is very useful when people look for tickets in their areas of familiarity/expertise. I think there are a few things that should be cleaned up to make the system a bit more useful and

Re: "needsinfo": resolution vs. triage stage

On Feb 24, 7:17 pm, Gabriel Hurley wrote: > In regards to #14702 , which so > far has been a universally favored idea, there's one lingering issue: > > Do we want to implement it as a resolution (i.e. you close a ticket as >

Re: Suggestion: a new "nature" field in Trac

On Feb 22, 3:22 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip <jpha...@gmail.com> wrote: > > I know there already is a "Has patch" flag, but I actually find that > > one a bit useless since there'

Re: Suggestion: a new "nature" field in Trac

On Feb 21, 4:35 pm, Gabriel Hurley wrote: > I'm still in favor of adding the "needsinfo" resolution and would love to > see that happen... I guess technically I could even do that one myself via > Trac's web admin if we're all agreed on it. I agree this is a good idea. By the

Suggestion: a new "nature" field in Trac

Hello, I was wondering if others would find it useful to introduce a new field in Trac to characterise the nature of a ticket, allowing to choose from at least: "bug report", "feature request", or "optimisation". I think this would help bring the right focus during alpha and beta stages, and also

Re: Enabling context access in simple_tag

On Dec 15, 10:52 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Wed, Dec 15, 2010 at 6:41 PM, Julien Phalip <jpha...@gmail.com> wrote: > > On Dec 14, 7:34 pm, Christian Hammond <chip...@gmail.com> wrote: > >> On Dec 14, 12:02 am, Jul

Re: Enabling context access in simple_tag

On Dec 14, 7:34 pm, Christian Hammond <chip...@gmail.com> wrote: > On Dec 14, 12:02 am, Julien Phalip <jpha...@gmail.com> wrote: > > > > On Dec 13, 10:16 am, Tai Lee <real.hu...@mrmachine.net> wrote: > > > -snip- > > > > One sug

Re: Enabling context access in simple_tag

On Dec 13, 10:16 am, Tai Lee wrote: -snip- > One suggestion from #1105 was to split out this functionality into > individual decorators, @takes_context, @takes_block. I'm not sure how > easy this would be technically to implement, but I think it would > solve the

Enabling context access in simple_tag

Hello, I'd like to bring up an itch that I've been desperate to scratch since my very early days with Django: the inability to access the context from a simple_tag. There are especially two use cases which I encounter on a near weekly- basis: (a) Generate a simple string or some very concise

Re: Tests for generic views' pagination

On Jul 6, 5:54 pm, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Tue, Jul 6, 2010 at 1:43 PM, Julien Phalip <jpha...@gmail.com> wrote: > > Hi, > > > I'm starting to work on ticket #2367 ("Pagination for date based > > generic views" -http

Tests for generic views' pagination

Hi, I'm starting to work on ticket #2367 ("Pagination for date based generic views" - http://code.djangoproject.com/ticket/2367) and I'm looking into the object_list generic view as a reference. For the life of me I cannot find any tests for object_list's pagination. Am I missing something or

Introducing a CACHE_MIDDLEWARE_KEY_PREFIX-like setting for all cacheing operations (#12831)

Hi, Several people have expressed interest in ticket #12831, which has also been marked as DDN. So I thought the next step would be to bring it up on this list - let me know if that's not the right thing to do. Basically, I think that it would make sense and that it would be very useful if a new

Re: admin reuse

On Aug 15, 9:14 pm, Russell Keith-Magee wrote: > On Sat, Aug 15, 2009 at 3:52 PM, Haroldo > > Stenger wrote: > >  I've seen the admin evolve to very sophisticated user interaction. > > Nonetheless, the param to  HttpResponse() when a model object

Re: Unified access to response.context in test client (follow-up)

On Mar 12, 11:10 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Thu, Mar 12, 2009 at 8:31 PM, Julien Phalip <jpha...@gmail.com> wrote: > > > On Mar 12, 9:30 pm, Russell Keith-Magee <freakboy3...@gmail.com> > > wrote: > >> On Thu,

Re: Unified access to response.context in test client (follow-up)

On Mar 12, 9:30 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip <jpha...@gmail.com> wrote: > > > Hi, > > > A few months ago James raised the issue on this list: > >http://groups.google.com/group

Unified access to response.context in test client (follow-up)

Hi, A few months ago James raised the issue on this list: http://groups.google.com/group/django-developers/browse_thread/thread/1b10084ea969141e Basically, the type for the test client's response context is inconsistent. Sometimes it's a dictionary and other times it's a list of dictionaries,

Re: reason for missing readline() in uploaded files?

On Feb 4, 3:12 am, Marty Alchin wrote: > I suppose I should probably weigh in over here. For those who don't > know, I worked on much of Django's file handling, refactoring > FileField, adding storage options and standardizing the File interface > across models, forms,

Re: #9344 and policy for small bug reports

On Jan 23, 6:42 pm, Karen Tracey <kmtra...@gmail.com> wrote: > On Fri, Jan 23, 2009 at 12:38 AM, Julien Phalip <jpha...@gmail.com> wrote: > > > Hi, > > > I just wanted to draw your attention to what appears to be a bug in > > Django: the 'tell()' pro

Re: #9344 and policy for small bug reports

On Jan 23, 5:14 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Fri, Jan 23, 2009 at 2:38 PM, Julien Phalip <jpha...@gmail.com> wrote: > > > Now, I know that this is sort of an edge case, and I also know that > > there are more important and more

#9344 and policy for small bug reports

Hi, I just wanted to draw your attention to what appears to be a bug in Django: the 'tell()' proxy is missing from the Windows-specific implementation of TemporaryFile. This causes Django to crash when manipulating the uploaded file with PIL, for example. Ticket #9344 contains a patch to fix

Re: logout() method for custom authentication backends

On Dec 1, 11:07 pm, David Reynolds <[EMAIL PROTECTED]> wrote: > On 1 Dec 2008, at 11:49, David Reynolds wrote: > > I have a custom authentication backend that requires a method to be > > run to log out of the system.  It would be quite useful if there was a > > way > > to hook into the

Re: Dropping Python 2.3 compatibility for Django 1.1

On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss > > <[EMAIL PROTECTED]> wrote: > > > Hi folks -- > > > I'd like to officially drop Python 2.3 support in Django 1.1. Discuss. > > I'm going to be the stick in the mud and say

Re: 1.1 feature: unify access to response.context in test client

On Nov 9, 7:56 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > The Djangotestclient exposes theContextused to render the returned > response, so that unit tests can inspect thatContextand verify that > it contained what it was expected to contain. This is all well and > good, except that there

Upgrading Trac?

I know that this is likely to be a tricky/boring task and that it is probably low-priority since we're on the way to 1.1, but I thought at least I'd ask: Is there any plan in the short/mid term to upgrade Trac? My personal itch is that the current version (0.10.4) doesn't allow email

Re: Declarative syntax for widgets in ModelForm

On Sep 29, 11:40 pm, Julien Phalip <[EMAIL PROTECTED]> wrote: > On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote: > > > Why not do something like this: > > > class MyForm(forms.ModelForm): > > class Meta: > > fields = { &

Re: Declarative syntax for widgets in ModelForm

On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote: > Why not do something like this: > > class MyForm(forms.ModelForm): > class Meta: > fields = { > 'text': forms.CharField(widget=forms.Textarea(), ...), > 'other_field': None, > } This syntax would

Re: Letting Library.simple_tag access context (code ready)

On Sep 28, 4:20 am, Leaf <[EMAIL PROTECTED]> wrote: > Out of necessity, I've made a modification to my Django trunk. It > gives a parameter to the Library.simple_tag() function named > takes_context. You might want to take a look at ticket #1105. I addresses the issue you're raising here, and

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote: > On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > > > Serving is totally orthogonal -- everyone is already serving up > > MEDIA_ROOT in their projects somehow anyway, and this just copies > > files to MEDIA_ROOT. > > Sorry, I

Re: Proposal: installmedia command - A story for distributing media with apps

On Sep 17, 7:09 am, "Don Spaulding" <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote: > > > $ python manage.py installmedia appname [appname ...] > > > The command is "dumb.".. > > Could it be a little smarter, and in the absence of specific

Re: I want a pony: Django Cheeseshop

On Sep 14, 8:35 am, Martin Diers <[EMAIL PROTECTED]> wrote: > The answer to the current package chaos is not a centralized   > repository. I do not like that idea one bit. It's too storm- > trooperish. Who is going to decide whether a package is repository- > worthy? I would take the example of

Model examples missing in refactored doc

Hi, First, apologies if this is already being looked after. Since the refactoring of the docs and the old docs being shut down, the model examples have gone. Also, some links are now outdated (4 occurrences in [1]). I just see it's been reported again in #9007, and I think this will be a trap

  1   2   >