On Fri, Jun 8, 2012 at 8:45 AM, Jacob Kaplan-Moss wrote:
> Can't this be done by auto-discovering subclasses of Field
> (Field.__subclasses__)?
Unfortunately, __subclasses__() doesn't work down through the whole
hierarchy, just one level deep. So unless we plan to walk the tree to find
them all,
On Fri, May 6, 2011 at 12:25 PM, Christophe Pettus wrote:
> Steal from the best! :) One additional feature that they added was a dynamic
> way of doing {{ extends }}. Rather than specifying the tag in the template
> source, the inheritance path can be specified directly in the
> render-equiva
On Tue, Jan 4, 2011 at 3:10 PM, Yo-Yo Ma wrote:
> Simple question (A or B): Would you rather A) have a
> SomeDjangoException come up where you don't expect it and a visitor
> see a 500 page, or B) have your data ruined by a developer mistake?
Developer mistakes can ruin your data. Full stop.
Tha
On Thu, Jan 14, 2010 at 2:32 PM, Karen Tracey wrote:
> Martin's approach was single codebase where the 3.x version for execution is
> generated by 2to3, not single source for execution across 2.x and 3.x. Thus
> I'm wondering if this difference is accounted for by 2to3? If yes, then it
> is not
2010/1/14 Łukasz Rekucki :
> It is possible to write 3.x code that is backwards-compatible with
> python 2.6+. There are some rough edges like, names of stdlib modules,
> instance checks for strings and some introspection details. In my
> opinion, it's pretty much the same as supporting old 2.x pyt
On Mon, Dec 21, 2009 at 10:46 AM, Simon Willison
wrote:
> On Dec 21, 2:22 pm, Marty Alchin wrote:
>> Looking over Simon's patch for signed cookies, I noticed that yet
>> another feature needs to write its own "load a backend from a setting"
>> function.
>
Looking over Simon's patch for signed cookies, I noticed that yet
another feature needs to write its own "load a backend from a setting"
function. A quick search of the codebase shows at least four other
instances of this behavior (shown below), and it seems it's only going
to get more common going
On Mon, Dec 21, 2009 at 8:00 AM, Luke Plant wrote:
> Rather than use 'settings.SECRET_KEY' as the default HMAC key,
> shouldn't we add a prefix so that any usage of SECRET_KEY can't be
> (potentially) used to attack other usages? We discussed this a while
> back. The new messages system uses:
>
On Mon, Oct 12, 2009 at 12:09 PM, Jeremy Dunck wrote:
> Also, I bet Marty knows this area well from his book work.
Actually, I didn't research much on the initialization process as a
whole, if there indeed is such a beast. I started with what happens
when Python actually encounters a model defin
On Fri, Sep 25, 2009 at 10:42 AM, Simon Willison
wrote:
> On Sep 25, 3:39 pm, Simon Willison wrote:
>> While that makes sense for caching, I couldn't say if it makes sense
>> for signatures or not - when we sign something, will we always know
>> the point at which we want that signature to expir
On Fri, Sep 25, 2009 at 9:26 AM, Simon Willison wrote:
> The API would look something like this:
>
s = signed.sign('value', timestamp=True)
v = signed.unsign(s, expire_after=24 * 60 * 60)
>
> A SignatureExpired exception would be raised if the signature was
> older than the expire_after
On Fri, Sep 25, 2009 at 7:02 AM, Luke Plant wrote:
> Suppose one part of an app signs an e-mail address for the purpose of
> an account confirmation link sent in an e-mail. The user won't be
> able to forge the link unless they know HMAC(SECRET_KEY, email).
>
> However, suppose another part of t
On Thu, Sep 24, 2009 at 3:22 PM, Benjamin Slavin
wrote:
>> response.set_cookie('key', 'value', sign=True)
>> - results in a Set-Cookie: key__Xsigned=value header
>
> Unfortunately, this approach won't work.
>
> A malicious client can just send "key" rather than "key__Xsigned" and
> you'll never k
> Also, does the name of a cookie factor into the cookie length limits?
> My reading of RFC 2109 says yes, but it'd be worth verifying, since it
> would cut down on the usable value space. With your compressed base64
> stuff, that's not as big of a problem, but still something to look
> into.
Als
On Thu, Sep 24, 2009 at 2:54 PM, Simon Willison wrote:
> Hmm... I hadn't considered that. I was thinking that the unsigning
> could be transparent, so by the time you access request.COOKIES['key']
> the value had already been unsigned (and if the signature failed the
> cookie key just wouldn't be
I'm obviously going to weigh in here, having authored the signed
cookies app you mentioned below, but be aware I'm not a cryptographer,
nor do I have any personal use for signed cookies at all. I can
appreciate their value, but I'm not even using my own app in anything,
so if there are problems wi
Alexey wrote:
> I wonder, why is there no folder creation functions in Storage and
> FileStorage classes?
Because none of Django's features really required it.
> I ask this not because I don't know how to create it mysef. I'm just
> curios, why there are only one function for working with folder
I won't speak to most of this, since Russ and Jacob have said it all,
but I do want to respond to one point.
On Thu, Aug 6, 2009 at 3:55 AM, Russell
Keith-Magee wrote:
>> By simply checking that the template has a ``render`` method in
>> ``get_template``, we get the added benefit of allowing user
On Tue, May 26, 2009 at 2:16 PM, Jerome Leclanche wrote:
> Right now, removing months and years is a matter of removing two lines
> from the patch. I didn't want to write a patch just to get told "it's
> lacking months/years!"; I'm also in favour of dropping it and
> following Python's style; but
Okay, I'm finally back around looking into this situation, and I have
to say I'm not thrilled with the direction it's currently headed. I've
never liked the "1h 30m 10s" syntax in any situation I've ever
encountered it, and I highly doubt that it will be meaningful to much
of anyone. That's person
On Mon, May 11, 2009 at 8:45 AM, Armin Ronacher
wrote:
> All bugs are fixed now except for #10788. Now the problem with
> closing that one is that this one requires a design descision. I
> updated the ticket accordingly for jacob or anyone else to decide on
> it. My personal opinion is that I
On Fri, May 8, 2009 at 7:05 AM, Jacob Kaplan-Moss
wrote:
> """
> Discussion group for Django developers. This group is used for
> discussion of developing Django itself, not user questions; Please use
> django-users for issues regarding using the framework, questions for
> the Django user communi
On Thu, May 7, 2009 at 3:43 PM, Armin Ronacher
wrote:
> On May 7, 5:37 pm, Karen Tracey wrote:
>> #10249: can't create consistent MRO (method resolution order) when assigning
>> a File to a FileField.
> This is fixed.
I was reading over the patch Alex mentioned in IRC (yay for
DjangoBot's logge
On Thu, May 7, 2009 at 12:05 PM, Armin Ronacher
wrote:
> I'm working with Alex on that right now here in Prague. We have some
> branches on github related to that. Basically the idea is to start
> with getting rid of some of the over engineering in the abstract base
> classes and make sure the
On Thu, May 7, 2009 at 11:37 AM, Karen Tracey wrote:
> I noticed the question of what to do about the r9766-related issues came up
> in the 1.1 thread so figured, in case it's helpful, I'll lay out my
> understanding of what/where these are.
You've been doing some great working tracking these is
On Thu, May 7, 2009 at 8:34 AM, Jacob Kaplan-Moss
wrote:
> Ugh, I really hate not being able to just assign files to fields. It
> just feels hacky and wrong to call instance.file_field.save(). It'll
> also break a bunch of code folks have written over the last few
> months. I know, no backwards-c
On Thu, May 7, 2009 at 6:43 AM, Jacob Kaplan-Moss wrote:
> Once this is done we'll be down to blockers for 1.1; many of us at the
> sprint are focusing on these. More help will be appreciated!
I just wanted to add a note here that may have some impact on which
tickets get punted vs. fixed in 1.1
On Mon, Apr 6, 2009 at 1:16 PM, Karen Tracey wrote:
> We cannot know for sure what the file name is until it is saved to disk, as
> the save operation may tack on underscores when handling race conditions.
> Thus we cannot delay file save to a field pre_save routine and report the
> guaranteed co
On Thu, Apr 2, 2009 at 11:45 AM, Karen Tracey wrote:
> I think it's a bug, and I'm pretty sure it was introduced by r9766. The
> setting of the actual file name that will be used (which pulls in the
> upload_to path and possibly tacks on some underscores if the uploaded name
> conflicts with al
On Mon, Mar 30, 2009 at 1:25 PM, Kurt Grandis wrote:
> cull_interval or cull_period would absolutely be the most accurate
> description in terms of the algorithm's operation. My contention is that
> parameter name would be confusing to all but those who have seen the actual
> underlying culling a
On Sat, Feb 28, 2009 at 11:27 PM, NewSpire wrote:
> First, this restriction is not there in the database. Auto-increment
> fields do not have to be primary keys. Imposing this restriction
> could cause a problem when trying to use legacy tables in a Django
> environment. Is there a compelling
I haven't looked too much at the patch, so I can't comment much on the
implementation yet, but reading your description and the ticket, I'd
to offer some thoughts, based on some of my own thoughts I've had on
this in the past.
First, I don't think you actually addressed the question mentioned in
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, storage and uploads. If there are methods
missing, I'm almost certainly the
I haven't been following everything, but I do have a couple comments
to make here.
On Fri, Jan 23, 2009 at 8:04 AM, mrts wrote:
> works both for forms and models with the proposed approach (all_values
> is model_instance.__dict__.copy() in model field validation case).
One thing to consider is
On Thu, Jan 15, 2009 at 10:33 AM, Marty Alchin wrote:
> While working again with files for model validation, I realized (and
> confirmed with Russ, Honza and Alex in IRC) that the tests put in as a
> fix for #6009[1] don't actually prove all the behavior that ticket
> refers to
While working again with files for model validation, I realized (and
confirmed with Russ, Honza and Alex in IRC) that the tests put in as a
fix for #6009[1] don't actually prove all the behavior that ticket
refers to. They prove that Unicode filenames come through fine from
uploads, but that test
In light of the upcoming feature completion deadline for Django 1.1,
I'd like to take a few minutes to mention where the signed cookies
application stands right now and some of my thoughts about its
inclusion in django.contrib. The code itself is done. I made a few
minor updates to it last week to
On Tue, Dec 16, 2008 at 2:02 PM, David Cramer wrote:
> Could we just use a lazy proxy for the value value? When it's executed, it
> could then just call the get_value_from_db method (or whatever).
I expect that the lazy approach is what most people would really want,
so I'd be fine with that. I
On Tue, Dec 16, 2008 at 1:03 PM, Jacob Kaplan-Moss
wrote:
> This seems like a good idea to me, and an easy one to implement; I'm
> all for it. Are there any backwards-compatibility concerns here? It
> doesn't look like it -- we're just talking about adding a new hook to
> SubFieldBase, right?
My
Thanks, guys. All that just to delete a question mark from my name
after signed cookies. :)
-Gul
On Tue, Nov 25, 2008 at 12:04 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Nov 25, 2008 at 11:02 AM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Ok, the page is now editable.
>
]> wrote:
> On Tue, Nov 25, 2008 at 10:34 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>>
>> The biggest issue is that we can't edit anything. There's no "Edit
>> Page" button, and when I manually add "?action=edit" to the URL, it
>
The biggest issue is that we can't edit anything. There's no "Edit
Page" button, and when I manually add "?action=edit" to the URL, it
gives me an editor form, but upon submission, I see the culprit: 403
Forbidden (WIKI_ADMIN privileges are required to perform this
operation). Any hope of getting
On Tue, Oct 14, 2008 at 12:34 PM, Jesse Young <[EMAIL PROTECTED]> wrote:
> A LazyTextField that manages a dynamic model behind the scenes sounds
> like a neat idea. That would certainly make the Django side of this
> easier to manage. (But of course I have a slight bias towards code
> that exists
I won't pretend to know the whole story here, but I will take issue
with some of your points. I'll leave others to people who have history
on the subject.
On Tue, Oct 14, 2008 at 3:14 AM, Jesse Young <[EMAIL PROTECTED]> wrote:
> * If you split them out, you have to manually create one model every
On Fri, Oct 3, 2008 at 10:39 PM, Eduardo O. Padoan
<[EMAIL PROTECTED]> wrote:
> IIRC, the file-ABCs are in the new `io` library.
Ah, indeed. I was looking for something called "File" or similar, not IOBase. :)
-Gul
--~--~-~--~~~---~--~~
You received this message
On Fri, Oct 3, 2008 at 9:48 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> Think "interfaces". Given that you wrote the file storage stuff and are
> no doubt aware that we still have lots of fuzzy issues where something
> may or may not be able to be used where a Python file object is used,
>
On Fri, Oct 3, 2008 at 7:34 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> Trendy might be superficially appealing, but I personally felt 2.6 would
> have been just as useful without the ABC backport.
Actually, I don't find it particularly appealing myself. The PEP
specifically states that it isn'
Looking over the new things in Python 2.6, I wonder if there are plans
to inherit from any of the new abstract base classes in Django. It
looks (to me) like it could be backwards-compatible, using an import
like so:
try:
from collections import Sequence
except ImportError:
# Fallback for
On Tue, Sep 23, 2008 at 8:44 AM, Steve Holden <[EMAIL PROTECTED]> wrote:
> This appears to be a proposal to re-implement triggers inside Django.
I suppose it is. But then, perhaps triggers were a re-implementation
of application-based denormalization. ... The chicken? The egg? The
world may never
On Mon, Sep 22, 2008 at 4:03 PM, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> So, I'd love people's opinions about where I should take this - to a
> dark corner and hide it, to a separate app like django-extensions (which
> involves keeping the horrid hacks in there), into a separate app but
> with
On Thu, Jul 24, 2008 at 9:54 AM, zvoase <[EMAIL PROTECTED]> wrote:
> Developers,
> I've just looked at the latest revision (r8068) for Django and there
> are a couple of things I'd like to suggest.
I've already replied to part of this email, but I'd like to take a
minute to also reply to the othe
On Mon, Jul 21, 2008 at 11:37 AM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Gah, I really haven't had time to do the
> move-code-out-of-__init__-modules dance. I'm fairly certain that
> it'll be completely backwards compatible (via re-importing back into
> __init__), though, so I'm not too worried;
On Tue, Jul 15, 2008 at 7:49 PM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> I was using HttpResponse.set_cookie for the first time and annoyed
> that expires has to be a properly-formatted string.
>
> Why not take a datetime and do the formatting in the function?
>
> Obviously this is a breaking ch
On Fri, Jul 11, 2008 at 4:14 AM, Julien Phalip <[EMAIL PROTECTED]> wrote:
> Not sure if we're talking about the same thing here. What I ask is if
> it'd be a good idea to have a generic method for UploadedFile which
> lets copy/move the file to where ever you want. These method would
> have to be
On Thu, Jul 10, 2008 at 3:23 PM, Jeff Anderson <[EMAIL PROTECTED]> wrote:
> So I'm a linux user, but I have a MBP. I was playing with the django test
> suite a while back, and some test failed on my mac but would succeed on any
> of my linux machines. After discovering the django buildbot, I thoug
On Thu, Jul 10, 2008 at 2:52 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Sorry for the late reply. I meant to look at this awhile ago but it
> slipped off my plate for a bit. Looking at the latest patch
> (filestorage.16.diff) it does look like a similar approach the main
> differences comi
On Thu, Jul 10, 2008 at 12:35 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> It'll be a badge of honor/experience. "I used Django back when forms
> was called newforms!"
Yeah, and everybody at DjangoCon can have a little icon on their name
badges that indicates how many backwards-incompatible c
On Thu, Jul 10, 2008 at 4:46 AM, Ivan Sagalaev
<[EMAIL PROTECTED]> wrote:
> I've seen already two people highly confused with this thing. After
> successful validation of a form with file upload
> form.cleaned_data['fieldname'] contains an instance of a wrapper --
> newforms.fields.UploadedFile. P
On Thu, Jul 3, 2008 at 12:22 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I just talked about this with Mike on IRC; I think chunk() is
> non-obvious and we're gonna change it to chunks(). Hopefully nobody's
> written so much code in the last week to be pissed.
>
> Also, we're going to chang
On Wed, Jul 2, 2008 at 2:56 PM, George Vilches <[EMAIL PROTECTED]> wrote:
> On Jul 2, 2008, at 1:24 PM, Paul Kenjora wrote:
>
>> I understand the resistance but you've got demand, you've got a
>> willing developer, and you've got a clean fix that significantly
>> improves the adaptability of the f
On Wed, Jul 2, 2008 at 1:24 PM, Paul Kenjora <[EMAIL PROTECTED]> wrote:
> Reasons why an alternate backend or view is not good:
> 3. Maintaining my own back end, means others are doing the same, again poor
> re-use.
Not if you:
1. Write it well
2. Distribute it freely
3. Make its presence known
On Wed, Jul 2, 2008 at 12:55 AM, Kenneth Gonsalves
<[EMAIL PROTECTED]> wrote:
> actually this debate belongs on django-users (which is why I put in
> my 2 paise) - I think if taken there we can get a real measure of the
> pros of his help against the cons of his curtness at times (I
> wouldn't cal
On Fri, Jun 27, 2008 at 8:31 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
> I've got code for this lying round which I'd be happy to donate if
> people agree this is the right approach.
I personally much prefer this approach. I've worked in a couple
communities where personal attacks were quite
On Thu, Jun 26, 2008 at 3:14 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> Hi folks --
>
> As far as I'm concerned, #2070, adding large streaming uploads, is
> done. I'd like to get some public kicking-of-the-tires before I push
> the change to trunk (which won't happen before Tuesday: I'm
Hey all,
First, I apologize for posting this on django-dev, since I know it's
not development *of* Django, but I didn't want to add to the noise on
django-users, and most of the people I'm hoping to reach are frequent
readers of this list. No need to flame, I got it.
As most of you are no doubt
On Mon, Jun 16, 2008 at 2:17 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Mon, Jun 16, 2008 at 12:43 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>> * Leave them as they are, and just tell whoever commits #5361 to
>> reference them in the commit message.
On Mon, Jun 16, 2008 at 11:15 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> As requested, I've also added milestones for 1.0 alpha, beta, and
> final (as well as a "post-1.0" catch-all). Triagers, feel free to use
> these milestones thusly:
>
> * Any *feature* tickets related to the maybe lis
On Fri, Jun 13, 2008 at 1:38 PM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Hey, it helps me segment my incoming mail. ;)
It's always about *you* isn't it? ;)
> Google Groups makes new mailing lists trivial. Although this may all
> be moot if that djangosearch site pans out as useful.
Well, I'd s
On Fri, Jun 13, 2008 at 1:23 PM, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Ugh, time. I have a bad habit of assuming I have more of that
> resource available than I ultimately do. :) I'd definitely like to
> help, but I don't think I could assume a driving role at this point.
> (Chicago Djangonaut
On Fri, Jun 13, 2008 at 1:23 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> There is existing multi-lingual aggregator http://djangosearch.com/
I didn't realize djangosearch broke articles down by language,
complete with individual feeds! Looks like that's one problem down.
Combine that with Jaco
This whole thing reminds me of something I've had rattling around in
my head for a while, and maybe now's the time to bring it to the
group. In addition to the language of blog posts, I've often had a
hard time tracking down information from past conversations that have
happened in the community.
On Fri, Jun 13, 2008 at 8:48 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> I've been implementing a flexible file storage system for Django for
> my own use (hacked in on top of the existing file field) and would be
> happy to make this code available if you have any interest in it. I
> hones
On Thu, Jun 12, 2008 at 7:06 AM, Forest Bond <[EMAIL PROTECTED]> wrote:
> I think that this is a must-have:
>
> #285 -- WSGI SCRIPT_NAME and PATH_INFO stuff
Then you'll be glad to know that it's #3 the list of "Must-have
features" in Jacob's email, just a bit below the portion you quoted.
-Gul
I like it, but mainly that's because I'm not the "maybe" list, and I'm
sure I can get it done in time. I do have one suggestion, though.
On Wed, Jun 11, 2008 at 10:03 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> * "Maybe" features: things that *should* be in 1.0 and should be worked on
> i
Hey all,
I've been fairly quiet on the file storage front for a while, since
it's basically done now, and is just waiting on the streaming upload
ticket to hit trunk first. Since I got to that point, however, I've
had two different people, working on two different storage backends,
both approach
On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote:
> Unfortunately, I don't think your ticketing system likes me. I'm
> getting: 500 Internal Server Error (Submission rejected as potential
> spam).
Right on the new ticket screen, under the big heading labeled "Read
this first"
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
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 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 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 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
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 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
--~--~--
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
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 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
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 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 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 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 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: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 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 Fri, Apr 4, 2008 at 3:43 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> Yeah, one thing we'll need to figure out PDQ is what's appropriate for
> an upload handler, and what's appropriate for a storage backend.
> Hopefully the two of you can work out the breakdown.
I'll read over the pat
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 "
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 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, ...):
""
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 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
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
1 - 100 of 338 matches
Mail list logo
