On Dec 4, 2007 11:46 AM, Marc Garcia <[EMAIL PROTECTED]> wrote:
> I agree on not commiting patches to a module that will be rewrite
> soon. I hope that you find the way to allow that feature on new
> version.
I guarantee you it'll be possible. I just hate how ugly it'll look,
unless I find a way
On Dec 4, 2007 2:21 PM, Travis Terry <[EMAIL PROTECTED]> wrote:
> exception escape, then everywhere I call get_or_create() will have to
> implement a very non-DRY piece of identical code to handle the situation.
I won't get into the issue of whether this should or shouldn't be in
core, but you mo
On Dec 5, 2007 12:55 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> http://code.djangoproject.com/ticket/3591 has been following this
> problem (and the other, related ones). The patches there look
> relatively good and the tests appear to pass, but I'm concerned about
> the level of boat-rock
On Dec 5, 2007 2:48 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Great to hear this is gaining some momentum. I'm not a fan of the
> patch on 3591, as it goes only halfway (by adding the app() function),
> stopping short of a full, elegant solution. The approach I've been
> wanting to take is
On Dec 5, 2007 4:00 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> It's *extremely* useful to be able to inspect settings files *without*
> triggering imports of all INSTALLED_APPS -- I've got at least a dozen
> utilities that operate on multiple sites by introspecting various
> settings modul
On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> this be allowed/disallowed/checked for? As for standard template
> loading, there's no reason that the standard template loading
> (app_loader) code could not be modified to work with App instances,
> using whatever logic to use the
On 12/7/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> > FWIW, I'm interested in this approach.
>
> Same here. I'm planning to look at this on Monday, but am very much
> interested.
I haven't given any thought to how caching should work internally, but
this approach seems on par with how the
On 12/7/07, Marc Garcia <[EMAIL PROTECTED]> wrote:
> Hi guys (specially Marty Alchin I think)!
You remembered me!
> I've realized about a little issue with FileField in admin. Issues are
> invalid html code in widget (unclosed tag and invalid target
> attribute), and
On Dec 13, 2007 1:16 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> ...Perhaps IRC or chat would be good here?
Just make sure you post the results of said chat so the rest of us can see. :)
-Gul
--~--~-~--~~~---~--~~
You received this message because you are subsc
Gang,
I've updated the patch on #5361, so that it now includes a variety of
tweaks and updates that I've been working on since before the sprint.
Jacob's help during the sprint was great, but I've run across a
variety of other issues[1] since then, and I did my best to make
decisions that I felt
On 12/19/07, simonbun <[EMAIL PROTECTED]> wrote:
> The only thing I was wondering is how #2070 is affected by all this?
> I'm not sure if this has come up before; a search in the archives
> didn't produce anything useful.
There's obviously a slight relation since #2070 would need to commit
files
On Dec 28, 2007 5:19 AM, Marinho Brandao <[EMAIL PROTECTED]> wrote:
> when I said "a place to put in applications", I did not saying a hard
> place to put the applications, but a more flexible way to import them
> from. The solution could be a registration (i.e like template tags) by
> an kind of
On Dec 28, 2007 3:04 PM, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> I have a use case where a Form superclass includes fields at the top
> and bottom of the form, with the subclasses providing the fields in
> the middle. Obviously, there's no easy way to fix the ordering using
> simple declaratio
On 12/29/07, fietske <[EMAIL PROTECTED]> wrote:
> this post is a response to ticket 6095.
I'm not championing #6095, but I do have opinions on this, so I'll
voice them here for the archives.
> In relational modeling theory ALL tables (or better: relations)
> are first class citizens. What's call
On 1/4/08, Brian Harring <[EMAIL PROTECTED]> wrote:
> One additional optimization point for signals is deciding whether
> connect(Any, f1)
> connect(Any, f2)
>
> Must execute f1, f2 in that explicit order- internally, dispatcher
> uses some nasty linear lookups that could be gutted if f1/f2 orderi
A slight amendment. I like your idea of moving registration and
triggering into methods of the signal object itself, though that does
then require that signals support a particular API, which currently
isn't a requirement. Providing a base "Signal" class would, of course,
help with this, but I lik
On Jan 7, 2008 12:45 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> FYI, there will be a Jython sprint at PyCon, with a specific emphasis
> on getting applications running, including Django.
Hrmph. Django sprint, possible Satchmo sprint, and now a Jython
sprint. I expect I'll only work on Django p
Hey all,
I finally got around to creating a ticket[1] for an S3 file storage
backend. Yay! Of course, it's very, very broken at the moment. I
haven't touched it since the last sprint, where I was trying to switch
from Amazon's own library to boto.
I don't use S3 though, so even if I did finish i
On Jan 16, 2008 12:35 PM, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi Marty,
> What's your feeling about how much work is involved? I might be in a
> position to help out and his is something that I'd love to see!
> Ben
Feel free to take a look at the code as it sta
On Jan 29, 2008 3:13 PM, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Thoughts?
I haven't run into any problems with this as of yet, but I'd like to
wholeheartedly support this move. I was sincerely amazed when I
noticed that models could be instantiated either way, and I couldn't
think of a re
In the worst case, generating a kwargs dictionary from an args tuple
isn't really all that difficult.
kwargs = dict([(cls._meta.fields[i].attname, v) for (i, v) in enumerate(args)])
Seems like any code which explicitly needs to handle tuple
instantiation (likely the minority) can supply a helper
On Feb 1, 2008 1:47 PM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> That said, I'd like to propose that the majority of the contents of
> django.template.__init__ be preemptively moved to
> django.template.main, and imported back into __init__ as necessary.
> Furthermore, I'd like to see all use of __i
While I understand the intent, and I agree that people need to realize
that trunk is quite stable, I don't think this is a good way to go
about it. It seems to me that it will only raise questions about the
Django release schedule: "Wait, if there have been 2297 commits since
0.96, why hasn't ther
On 2/24/08, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> A few things I'm working on now end up requiring additions to this list
> and every time I open up the file I want to reorganise it to makes
> things easier to maintain. The main point is that almost all of these
> validation checks a
On Fri, Mar 28, 2008 at 9:05 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> Have you seen the dbsettings [1] app? If I'm understanding you
> correctly, it does everything you want.
>
> [1]: http://code.google.com/p/django-values/
Well, not exactly everything, since dbsettings doesn't export t
On Mon, Mar 31, 2008 at 5:27 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> If you want to be able to specify a different default manager for some
> particular use of an existing model, you're sort of after a third type
> of model subclassing that I've thought about but haven't implemented
I won't bother responding to anybody in particular, because I'm in
agreement with so many on this thread so far. I'm glad to see this
refactoring happen, because a doc improvement can only make things
better for everybody.
I know you're not getting into details yet, but once you do get down
to it
On Wed, Apr 2, 2008 at 12:22 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> I most sincerely hope not; unless you're like me and write short-form
> novels in your docstrings, they tend to be an absolutely horrible
> source of end-user documentation.
def get_object_from_cache(self, ...):
""
On Wed, Apr 2, 2008 at 7:05 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> One thing that struck me while looking over this list is that it might
> be a good idea to add a section on best practices for writing reusable
> apps. James Bennett's presentation at PyCon hit on some really good
>
On Fri, Apr 4, 2008 at 2:04 PM, Mike Axiak <[EMAIL PROTECTED]> wrote:
> However, the instant they pass the file to some remote location
> (think: S3UploadHandler) or alter the content (think:
> GZipUploadHandler) they will need their own way of defining what is
> content and how it should be "
breakdown.
I'll read over the patch and the docs and see if I can get a better
handle on how it works, so I can be of more use there. Also, Mike and
I put our heads together in IRC sometimes, so we should be able to get
it sorted out soon.
> FYI, I plan to merge 2070 first (sorry, Marty!)
On Tue, Apr 8, 2008 at 11:30 AM, konryd <[EMAIL PROTECTED]> wrote:
> A question I'd like to ask experienced developers:
That's not what django-developers is for. It's for the development of
Django itself. There are plenty of experienced developers reading
django-users too.
> Is it possible to
On Thu, Apr 10, 2008 at 1:05 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> mymodel.filedfield.save_file()
For what it's worth, ticket #5361 does exactly this.
http://code.djangoproject.com/ticket/5361
> - Clutters the model namespace
Agreed
> - [Assumption] Performance gain by removing the
On Thu, Apr 10, 2008 at 1:08 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I think with field subclassing, descriptors are a good way to add this
> sort of thing, but it needn't be backwards imcompatible, because any
> get_XXX_display could just translate to model.XXX.display, etc.
Unfortunate
On Thu, Apr 10, 2008 at 1:30 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Unfortunately, there are still a number of situations where existing
> code (and most likely will) break. Some of these situations are easily
> solvable, others *could* be solved easily by doing a bit of
On Fri, Apr 11, 2008 at 12:02 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
> Why not use the opposite test and check for instances of dict?
Because then you have to pass something that subclasses dict instead
of something that implements the interface of dict. We could go on and
on about this
On Sun, Apr 13, 2008 at 7:05 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> I was wondering about the reason that middleware classes were used instead
> of decorators to implement middleware functionality. One of the use cases
> that lead me into thinking about it is that I was looking for a way t
On Thu, Apr 24, 2008 at 8:19 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> * Marty's file backend work needs to land, because that drastically
> improves both the ease of file handling in general and the ability
> to use popular storage solutions like Amazon S3.
I know you said your list is
On Fri, Apr 25, 2008 at 3:26 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
> Purely in terms of OO design, because it's cleaner. Object
> composition is usually a more appropriate paradigm than class
> inheritance. To take the example from the post that started this
> thread, the relationship bet
I had mentioned this a while back, in passing, but I'd like to bring
it up again now that the filestorage patch is getting close to making
it into trunk.
In particular, I thought I had remembered some discussion a while back
about how expensive different test packages were, since each package
req
On Sun, Apr 27, 2008 at 1:37 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> - The database reset is only used by django.test.TestCase. If you are
> using raw unittest.TestCase or doctests, the database isn't flushed,
> and so they can run quite quickly.
This addresses the root of my ques
On Sun, Apr 27, 2008 at 8:00 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> So use both. Put the example file field usage in model tests and the
> other stuff in regression tests.
Yeah, that was the plan, I just wanted to make sure it wasn't the
"wrong" thing to do. Thanks.
-Gul
--~--~--
I'm a bit on the other side of the situation here. To me, save() seems
adequately ambiguous, either inserting or updating depending on the
situation. As an alternative, I'd think having separate methods, like
create() and update() would make things clearer still.
In addition to avoiding the whole
On Sun, Apr 27, 2008 at 10:17 PM, Grégoire Cachet
<[EMAIL PROTECTED]> wrote:
> Why could you not include a parameter in the Meta class, like
> no_update = True ?
> By default, this parameter would be False.
The problem is, in Malcolm's example of an employee database, you
might well sometimes
On Mon, Apr 28, 2008 at 4:03 PM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
> I've just hit a wall with a behavior that I find a bit strange. When a
> model is instantiated from a queryset result it's not created with it's
> own constructor but instead uses Model.from_sequence that does creates
>
On Tue, Apr 29, 2008 at 2:02 PM, James Bennett <[EMAIL PROTECTED]> wrote:
> > 3) This is a pretty major change to Django, and there's nothing on the
> > page that says "HEY WE JUST CHANGED THE ENTIRE DBAPI ALL YOUR HACKS
> > WILL BREAK" (I didn't even know QSRF was released until someone
>
On Thu, May 1, 2008 at 10:49 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
> On Thu, May 1, 2008 at 10:31 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> > I'm still not quite sure why we need any additional methods, or flags, or
> anything. Can someone explain to me where the underlying API is havi
On Wed, May 14, 2008 at 10:07 AM, Simon Willison
<[EMAIL PROTECTED]> wrote:
>> I suspect that a lot of people actually rely on this behavior, and it
>> would be devastating to them.
>
> Thinking about it some more you're right - I'm sure there are lots of
> cases where people are relying on things
301 - 348 of 348 matches
Mail list logo
