On 29/10/2007, Justin Driscoll <[EMAIL PROTECTED]> wrote:
>
> To me having the two mutually-exclusive arguments sounds too much like
> trying to fake static typing in a dynamic language. I don't see the
> advantage of separate names for basically the same information provided in
> different ways. I
To me having the two mutually-exclusive arguments sounds too much like
trying to fake static typing in a dynamic language. I don't see the
advantage of separate names for basically the same information provided in
different ways. If it walks like a duck...
if callable(upload_to):
self.upload_t
Am Freitag, 26. Oktober 2007 15:39 schrieb Marty Alchin:
> Okay, just a quick update. I don't have a new patch ready yet, because
> I wanted to outline a couple things and ask another question. I've
> implemented the callable method for determining filenames, including
> the ability to include a s
On 10/28/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> How about introducing new argument, and allowing to use only one or another?
>
> so, variant 1 (backward-compatible one):
> my_file = models.FileField(upload_to="%Y/%m/%d")
>
> variant 2 (works only in new revisions):
> my_file = models.FileFi
On 10/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Aren't you still left with one option for upload_to and one for
> specifying the full details of the filename in this version? Two options
> is at least twice as many as we need.We have to live with (which means
> maintain, document and
How about introducing new argument, and allowing to use only one or another?
so, variant 1 (backward-compatible one):
my_file = models.FileField(upload_to="%Y/%m/%d")
variant 2 (works only in new revisions):
my_file = models.FileField(upload_to=get_file_path)
def get_file_path(obj):
return
On Sun, 2007-10-28 at 20:21 -0500, Marty Alchin wrote:
> On 10/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > I haven't been concentrating too much, since I'm pretty overloaded with
> > other things (both Django and real life) at the moment. But my general
> > impression is in line with
On 10/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I haven't been concentrating too much, since I'm pretty overloaded with
> other things (both Django and real life) at the moment. But my general
> impression is in line with yours, Marty: having two attributes and a
> complex system of "
On Sun, 2007-10-28 at 18:31 -0500, Marty Alchin wrote:
> On 10/28/07, Justin Driscoll <[EMAIL PROTECTED]> wrote:
> > I may be missing something but lets say when you pass a string to
> > "upload_to" it functions basically as it does now, however, if you pass a
> > callable it takes the return valu
On 10/28/07, Justin Driscoll <[EMAIL PROTECTED]> wrote:
> I may be missing something but lets say when you pass a string to
> "upload_to" it functions basically as it does now, however, if you pass a
> callable it takes the return value (the full relative path of the file,
> including the filename
I may be missing something but lets say when you pass a string to
"upload_to" it functions basically as it does now, however, if you pass a
callable it takes the return value (the full relative path of the file,
including the filename, in relation to MEDIA_ROOT) and splits it into the
path and file
On 10/27/07, Justin Driscoll <[EMAIL PROTECTED]> wrote:
> Any reason not to have upload_to accept a string OR a callable and function
> accordingly?
Hrm, to be honest, I hadn't really considered that. To me, upload_to
makes the most sense as a directory path only, rather than including a
filename
Any reason not to have upload_to accept a string OR a callable and function
accordingly?
Justin
On 10/27/07, Robert Coup <[EMAIL PROTECTED]> wrote:
>
>
> Presumably filename is optional, so only people who actually care will
> use it... with that in mind, personally I'd save the back-compat
> hass
Presumably filename is optional, so only people who actually care will
use it... with that in mind, personally I'd save the back-compat
hassle and support upload_to (as it works now) as well as the
callable. And make it clear in the docs that all it does is
os.path.join() the two. It also might be
Okay, just a quick update. I don't have a new patch ready yet, because
I wanted to outline a couple things and ask another question. I've
implemented the callable method for determining filenames, including
the ability to include a subdirectory in the filename. Also, ignore my
comment about reusin
On 10/24/07, Thomas Guettler <[EMAIL PROTECTED]> wrote:
> I am one of the people who asked for this. I only want to use the
> primary key for a directory name. I think a filename is not enough:
> I don't want to store the files under MEDIA_ROOT. Otherwise you can't
> use access control, since the
Am Dienstag, 23. Oktober 2007 14:49 schrieb Marty Alchin:
> In response to some recent questions regarding FileField usage, I
> thought about including a way to format the filename based on details
> from the model instance itself. It's looking like it' be best to add
> an argument to FileField, c
On 23/10/2007, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> In response to some recent questions regarding FileField usage, I
> thought about including a way to format the filename based on details
> from the model instance itself. It's looking like it' be best to add
> an argument to FileField, ca
On 10/23/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Currently, get_filename uses os.path.basename, and after filestorage
> > goes in, get_available_filename will do the same. This means that any
> > directory information is lost, unless it's preserved separately. It's
> > possible, but
On Tue, 2007-10-23 at 08:49 -0400, Marty Alchin wrote:
> In response to some recent questions regarding FileField usage, I
> thought about including a way to format the filename based on details
> from the model instance itself. It's looking like it' be best to add
> an argument to FileField, call
In response to some recent questions regarding FileField usage, I
thought about including a way to format the filename based on details
from the model instance itself. It's looking like it' be best to add
an argument to FileField, called 'filename' perhaps, which takes a
format string, like so (pa
21 matches
Mail list logo
