On Fri, Jan 30, 2009 at 5:08 PM, Ludvig Ericson
wrote:
>
> On Jan 30, 2009, at 22:19, Todd O'Bryan wrote:
>>
>> I'm not sure I understand this. If you try to call a file-like method
>> or access a file-like attribute on an UploadedFile, it would either do
>&g
On Fri, Jan 30, 2009 at 3:10 PM, Ludvig Ericson
wrote:
>
> On Jan 30, 2009, at 17:28, Todd O'Bryan wrote:
>> OK, after I did this, I was lying in bed and had the following
>> revelation. Would there be anything terribly wrong with just using
>> __getattr__ i
On Thu, Jan 29, 2009 at 11:14 PM, Todd O'Bryan wrote:
> On Thu, Jan 29, 2009 at 9:28 PM, Malcolm Tredinnick
> wrote:
>>
>> On Thu, 2009-01-29 at 15:40 -0500, Todd O'Bryan wrote:
>>> I'm trying to validate an uploaded csv file, so I want to read the
I thought I'd mention Kodos as a help for people with regex troubles:
http://kodos.sourceforge.net/
When I've wondered why things just weren't working in my URLs, and I've
wasted time banging on stuff, copying the pattern into Kodos and typing in
the URL I wanted to match it has usually pointed o
there's a way to get around the problem that you can't
always control order things are listed in classes seems to imply that
it's impossible.
Todd
On Dec 28, 2007 4:13 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 28, 2007 3:04 PM, Todd O'Bryan <[
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 declaration. I went on IRC and someone told me about overriding
self.fields.keyOrder
Use __file__ to get the path to the test code and then access the file
using a relative path.
Todd
On Dec 11, 2007 1:09 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I've gone ahead and created these tests: http://dpaste.com/27680/ I'm
> not sure whether this will work though, since if yo
I just found a bug in some code I submitted earlier that's already
been committed. It turns out that the default options to
django-admin.py would only get read if they were the first options,
but if another option intervened, they'd get lost. In other words,
django-admin.py command --settings=pat
ut not the other.
Todd
On Nov 16, 2007 4:30 PM, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Just replied directly to Russ, but I'll mention this here for posterity.
>
> I found the problem--I'd missed an ImportError in an except clause.
> Unfortunately, now all the
Done. Except that I should have used a pre-formatted block for the
test output, so it looks really awful. Sorry about that.
On Nov 18, 2007 11:18 PM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
>
> On Sun, 2007-11-18 at 22:54 -0500, Todd O'Bryan wrote:
> > I&#x
UP,
which both Deryck and I think it should. :-) I've modified the ticket
to reflect the real state of affairs.
On Nov 14, 2007 10:17 AM, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> Hi, Todd. So this is two issues, then.
>
> On Nov 14, 2007 9:04 AM, Todd O'Bryan <
I've been playing with the Django tests a bit and noticed something
odd. Here's what the docs say:
Yes, the unit tests need a settings module, but only for database
connection info, with the DATABASE_ENGINE setting. You will also need
a ROOT_URLCONF setting (its value is ignored; it just needs to
n app that's in INSTALLED_APPS wouldn't be available,
feel free to share.
Todd
On Nov 15, 2007 6:24 AM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 11/15/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > Patch provided in
> >
> > http://
Patch provided in
http://code.djangoproject.com/ticket/5943
On Nov 14, 2007 4:36 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
>
> On 11/14/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > Hey Russ,
> >
> > It looks like you made it i
Hey Russ,
It looks like you made it impossible to call user-supplied commands
using django-admin.py, even if the user specifies a --settings option
which would give the apps and thus provide the commands. My patch for
http://code.djangoproject.com/ticket/5516
specifically handles the --settings
2007 8:17 AM, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> On Nov 14, 2007 4:02 AM, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > I submitted a patch as http://code.djangoproject.com/ticket/5936
> >
> > Should be an easy change, I hope.
> >
> >
&
I submitted a patch as http://code.djangoproject.com/ticket/5936
Should be an easy change, I hope.
On Nov 13, 2007 6:24 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> Deryck Hodge said the following:
> > It's the variable that says whether or not the option --plain was
> > used. It determines
I finally decided I wanted to get a history working in the Python
shell, which I managed by using Collin Grady's script here:
http://collingrady.com/2006/11/17/tab-complete-and-a-persistent-history-in-python/
Unfortunately, it wouldn't work in Django's shell launched by ./manage.py.
I started
On Sat, 2007-09-22 at 20:12 +0800, Russell Keith-Magee wrote:
> So my question becomes 'how do we accomodate the 1% case'. I would
> suggest the best approach here would be to check for name clashes when
> a new command is registered. If a clash is identified, we can either:
> 1) Raise an error,
On Sat, 2007-09-22 at 11:52 +0800, Russell Keith-Magee wrote:
> On 9/22/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > I have a couple of reservations about the version of app commands that
> > got committed and just wanted to bring them up here.
> ...
I have a couple of reservations about the version of app commands that
got committed and just wanted to bring them up here.
In my original patch you had to use the following form for app-supplied
commands:
$ django-admin.py app_name.command
I also separated out the help contents by app so that
On Wed, 2007-09-19 at 00:29 +, Johann C. Rocholl wrote:
> On Sep 17, 10:17 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> > I personally would also like a favicon for the django sites. I took the
> > liberty of creating one using django's colors and fonts (stole the d from
> > the logo).
> >
On Tue, 2007-09-18 at 15:51 -0500, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> OK, I figured out what went wrong, but unfortunately in the process
> wiped away the ones uploaded in the last couple hours.
>
> Sigh.
>
> I'm gonna consider that "good enough" and stop fucking around until
> I've got
On Mon, 2007-09-17 at 00:23 +0200, Christopher Lenz wrote:
> So yeah, I want to be able to show previews of data that may at that
> point not be valid. Imagine there's a form with 12 required fields,
> and I want to enable users to see what their entry would look like
> even before they've c
http://code.djangoproject.com/ticket/5516
I just uploaded a patch that seems to allow apps to register their own
commands for django-admin.py. However, smarter people than I have tried
the same thing previously, so I'd appreciate it if some of those people
would take a look and try to break it.
I noticed a small problem in a change to some admin docs for a patch I
submitted that was accepted. Should I reopen the closed ticket and
attach the patch to it or should I create a new ticket and reference the
first one?
Todd
--~--~-~--~~~---~--~~
You received t
I guess I should know what a 403 error is, shouldn't I? :-)
Thanks a million, Collin. That was exactly what I was looking for.
On Wed, 2007-09-12 at 12:28 -0700, Collin Grady wrote:
> Todd O'Bryan said the following:
> > Does anyone else wish that there were a setting for
Does anyone else wish that there were a setting for a PERMISSION_DENIED
page that the permission_required decorator could send users who are
already logged in to, rather than sending them to the login page?
I'd still like users who aren't logged in to be sent to the login page.
Todd
--~--~--
The code you removed was trying to catch an error created by using
illegal options or arguments in one of the commands. Apparently optparse
still prints the usage message, but you also see the Python error.
It looks like sys.exit(3) is raising an exception that no one has ever
noticed before. Not
On Sun, 2007-09-09 at 23:25 -0500, Adrian Holovaty wrote:
> On 9/9/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > I see the problem. The reloader uses sys.argv and grabs the last command
> > line directly. By the time it gets to runserver.Command.handle, the
> >
On Sun, 2007-09-09 at 21:55 -0500, Adrian Holovaty wrote:
> On 9/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> > I'm seeing breakage too: I haven't tested it that extensively, but I'm
> > getting the following pair of tracebacks consistently on Windows on
> > the first reload of the serve
On Sun, 2007-09-09 at 23:41 +, SmileyChris wrote:
> On Sep 10, 10:16 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> > On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> >
> > > I think my refactoring of django.core.management to
On Sun, 2007-09-09 at 17:16 -0500, Adrian Holovaty wrote:
> On 9/8/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > I think my refactoring of django.core.management to let each command
> > register its own options is complete.
>
> Great stuff, Todd. I've
I think my refactoring of django.core.management to let each command
register its own options is complete. (Can anybody think of a good way
to test everything, other than running stuff by hand, which I've been
doing?)
I did hit a couple of issues:
1. The args for loaddata had 'fixture, fixture,
Currently,
$ django-admin.py --help
returns a usage guide for every command available. It's long and lists
all command options at the bottom, even though some are only appropriate
for some commands. Because of this, each command has to list which
options it allows separately and these appear in
Currently, both of the following work:
$ django-admin.py --opt value command_name [1]
$ django-admin.py command_name --opt value [2]
because django-admin.py is the actual command and the command_name is
just an arg.
If we create a parser that only admits options that are valid for the
given co
On Tue, 2007-08-28 at 10:55 -0500, Adrian Holovaty wrote:
> On 8/28/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Here's a suggestion to pull the options out of
> > django.core.management.ManagementUtility: What if we just read the
> > command after manage.p
The testserver command doesn't currently allow you to set the port for
the server to run on. I teach high school in a Linux thin client lab, so
all of my students are running on the same server and each needs his/her
own port, unfortunately. (Interestingly, having 10-15 Django dev servers
running
On Mon, 2007-08-13 at 16:31 -0500, Adrian Holovaty wrote:
> I'm proposing a "--with-fixture" flag to django-admin.py, so that you
> could do something like this:
>
> django-admin.py runserver --with-fixture=mydata.json
>
> With this command, Django would:
>
> * Delete the test database when
On Wed, 2007-08-08 at 10:35 +1000, Malcolm Tredinnick wrote:
> Since contributed applications are just Python packages, they do not
> need to be part of Django at all. A nice consequence is that we
> encourage people to first build something as a separate application that
> simply lives somewhere
On Thu, 2007-08-02 at 18:14 -0500, James Bennett wrote:
> Please read the entire thread above -- autoescaping will not work at
> the level of blocks; it will only work at the level of autoescaping or
> not autoescaping the **entire** output of the template, meaning all
> includes, all tag output a
On Fri, 2007-07-13 at 14:43 +1000, Malcolm Tredinnick wrote:
> I'm -1 one on this for pretty much the same reasons as Adrian. It's just
> not that big a deal even for people who want to work the way you do.
I should have re-subjected my second post, since I'm willing to accept
the loss of a poss
On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote:
> On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Is there a good reason not to do something like the following in
> > django.db.models.Model?
> >
> > def form(self):
> > return
Is there a good reason not to do something like the following in
django.db.models.Model?
def form(self):
return form_for_instance(self)
@classmethod
def form(cls):
return form_for_model(cls)
As I was writing this, I realized that you can't do this in Python
because you can't overload fu
On Tue, 2007-07-10 at 02:54 +, [EMAIL PROTECTED] wrote:
> On further reflection, there is a huge internationalization issue
> here. The hyphenation rules and data driven exceptions are English
> specific. Some will work (minimally) for other languages, but are not
> good enough. Proper integra
On Mon, 2007-07-09 at 08:09 -0400, Kevin Menard wrote:
> I'm not sure that makes a large amount of sense, so please correct me
> if I'm wrong. But, if n users want to be able to use email addresses
> as usernames but m developers are indifferent to it, where n is likely
> to be magnitudes larger
Yep. I just saw it...
On Fri, 2007-07-06 at 18:06 +0100, Matt Riggott wrote:
> Yesterday evening I upgraded my site to the latest Subversion trunk so
> I could take a look at all the Unicode loveliness. It seemed to work
> with one minor problem.
>
> If I pass a method as the first argument to
On Wed, 2007-06-13 at 01:10 +, SmileyChris wrote:
> http://code.djangoproject.com/ticket/4551 raises the issue that the
> docs say that PhoneNumberField is a subclass of CharField when really
> it's an IntegerField.
>
> Now that's an easy fix, but looking at the code a bit deeper it seems
> t
On Tue, 2007-04-10 at 10:25 -0700, Gulopine wrote:
> On 4/10/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Given that logic (which, as I said, may or may not be a correct
> > recollection), I vote for Jacob's solution. In fact, it might be cleaner
&g
On Tue, 2007-04-10 at 13:51 +0800, Russell Keith-Magee wrote:
> However, I haven't been able to find the original discussion leading
> to this decision in the archives (other than a reference in the early
> discussions about model validation [1]), so I haven't been able to
> establish the source
On Thu, 2007-03-29 at 13:02 +, Jonas Maurus wrote:
> > I think there are lots of situations where you need to normalize the
> > labels with some string. Why not just make it an optional parameter to
> > the Form class with a default value.. maybe ":"?
> >
> > Rune
>
> so that would make
>
>
On Wed, 2007-03-28 at 03:57 -0700, Simon G. wrote:
> Ok, my reading of the general consensus here is that everyone thinks a
> BinaryField is a good idea, so I've kept #2417 as accepted, with the
> patch needing a few improvements.
>
Is this BinaryField the BLOB variety or the BINARY/VARBINARY var
On Mon, 2007-03-26 at 10:03 -0500, Jacob Kaplan-Moss wrote:
> -1 on allowing File/ImageField to be stored in the database. That's
> bad design 99% of the time, and will needlessly complicate file upload
> code.
>
If people want to do it themselves, it's pretty easy to create a DBFile
model with n
And almost immediately marked as a duplicate. :-)
Guess I should read through all of my mail before acting on any of it.
On Sat, 2007-03-03 at 08:52 -0500, Todd O'Bryan wrote:
> Done. #3645
>
> On Fri, 2007-03-02 at 16:38 -0800, Simon G. wrote:
> > Hi Todd,
>
Done. #3645
On Fri, 2007-03-02 at 16:38 -0800, Simon G. wrote:
> Hi Todd,
>
> Can you drop by code.djangoproject.com and create a ticket for this,
> so we don't lose trac (sorry) of it.
>
> Thanks :)
> Simon G.
>
>
> >
--~--~-~--~~~---~--~~
You received this
I think I've found a bug in the admin's Change Password form. Here's the
call to render the template from the user_change_password function in
django.contrib.admin.views.auth:
return render_to_response('admin/auth/user/change_password.html', {
'title': _('Change password: %s') % esca
On Feb 17, 2007, at 4:58 PM, Honza Král wrote:
> On 2/17/07, oggie rob <[EMAIL PROTECTED]> wrote:
>>
>>> I find it useful to have the {% for %} tag syntax extended so
>>> that one can write:
>>> {% for a,b in L %} meaning the obvious thing
>
> +1
>
>>
>> You can do this. a,b return type is imp
The decimal module is part of Python from 2.4 onward, so it uses the
Python license.
On Sun, 2007-01-28 at 11:22 -0600, Jacob Kaplan-Moss wrote:
> On 1/28/07 8:18 AM, Andrew Durdin wrote:
> > * The 'decimal' module from 2.4 is included under django.utils, to
> > ensure Python 2.3 compatibility
I must say, I **hate** drop-downs for the state postal abbreviation. The
vast majority of the time, when people are filling in a form where they
need a postal abbreviation, they are either:
a. putting their own address and know the abbreviation
b. filling in an address they've been given, which h
I've actually been thinking about this, recently. How would people feel
about a Field type that took a regex to validate input against.
Or, to be even more wacky, how about providing callables that would
validate the input and normalize it? Something like
def __init__(self, validator=lambda x: t
On Aug 6, 2006, at 4:04 PM, Ivan Sagalaev wrote:
> Todd O'Bryan wrote:
>> But aren't backslashes legal characters in unix-like OSes, so that
>> the filename will get truncated if it has a backslash in it?
>
> You're right. But it's better to have nice
Near the bottom of the parse_file_upload function, there's:
# IE submits the full path, so trim everything but the basename.
# (We can't use os.path.basename because it expects Linux paths.)
filename = name_dict['filename'][name_dict['filename'].rfind("\\")+1:]
But aren't backslashes legal chara
Am I looking in vain for file tests in the test suite? My guess is
that I am, which makes sense, because I'm not sure how exactly one
would go about providing tests for file uploads.
Any suggestions?
Todd
--~--~-~--~~~---~--~~
You received this message becaus
On Aug 5, 2006, at 10:32 PM, Malcolm Tredinnick wrote:
> On Sun, 2006-08-06 at 07:05 +0800, limodou wrote:
>> If I write my own scripts which will use models and deal with them,
>> but I also need to set PYTHONPATH and DJANGO_SETTING_MODULE evn
>> variables. I know manage.py can do this thing, an
On Aug 5, 2006, at 8:12 PM, Malcolm Tredinnick wrote:
>> Yes, this will be slower than having Apache serve the file directly,
>> but it has the huge advantage that the file is served as the result
>> of a view. That means you can do all kinds of interesting permission
>> checking, url mapping, an
On Aug 5, 2006, at 5:25 PM, Ivan Sagalaev wrote:
>
> Todd O'Bryan wrote:
>> Would it be better to expose the file-like object that comes with a
>> file upload, rather than reading the file's whole content into memory
>> (or into the server's file system,
gt;
> You can use Apache's LimitRequestBody directive to restrict the size
> of accepted uploads.
>
> http://groups.google.com/group/django-users/browse_thread/thread/
> ca95963aaa33ce1e
>
>
>
> On 8/5/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>> Th
It seems that requests for some way to store binary data in the
database is a perennial request. I've seen comments (I think Adrian
said it "opens a can of mutated worms."), but never a real
discussion of what the problems would be.
There's a recent ticket, #2417, that adds support for "sm
The way Django ships, isn't it possible for a user to hijack the
server by uploading HUUUGE files? Because the files are stored in
memory, this seems like it could be a very bad thing.
There's a ticket, #2070, with a patch that buffers files in small
chunks, so that no more than about 64k i
On Jul 29, 2006, at 8:18 PM, Malcolm Tredinnick wrote:
>> 1. Allow people to set a prefix for each app in the settings.py file.
>> This would basically tell the app what URLs that are mapped to it
>> start with, and views and templates inside the app could use this
>> when they want to create int
As our application is growing larger, we're noticing some issues with
coupling and the modularity of apps.
In particular, how plugable are apps supposed to be? It's clear that
at the top level, a project should be able to access all of its
parts, but it seems like it should be the case that
I must say I really like Luke's (I think it was Luke) idea of
different tags for escaping vs. auto-escaping.
What if we deprecated {{ }} and replaced it with an escape tag and a
raw tag? It would keep backward compatibility, but would encourage
people to use escaped strings unless they have
On Jul 27, 2006, at 3:49 PM, [EMAIL PROTECTED] wrote:
> Tom Tobin wrote:
>> On 7/27/06, Joe <[EMAIL PROTECTED]> wrote:
>
>> In line with other sentiments I've expressed here in the past: IMHO,
>> this means your *project manager* is addled, not Django's release
>> process. If you can understand
On Jul 27, 2006, at 1:05 PM, Joe wrote:
> Malcolm Tredinnick wrote:
>> Release management is a little more faceted than that. You do
>> understand
>> that any Open Source project has multiple releases, right? Putting
>> out
>> periodic releases to act as checkpoints, regardless of whether it
On Jul 22, 2006, at 7:18 PM, James Bennett wrote:
>
> On 7/22/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>> What is the current wisdom on OneToOne? Will it be finalized soon?
>> Ever?
>
> As I understand it from a conversation I had the other day, not
On Jul 22, 2006, at 2:59 AM, Ivan Sagalaev wrote:
>
> Again, having the solution with OneToOne relation scares newbies away
> because it's become a kind of common wisdom that OneToOne will be
> changed very drastically very soon and "all your code would burn".
What is the current wisdom on OneToO
Is xml_escaped just too verbose? Seems very descriptive and unambiguous.
Todd
On Jul 19, 2006, at 4:56 PM, SmileyChris wrote:
>
>> 'escape' and 'safe' have a different meaning for fireworkers, too ;-)
> Or bank robbers :-P
>
> Back on topic, I like finalization too (even though I cringe having
On Jul 16, 2006, at 5:53 PM, Martina Oefelein wrote:
>
>> (3) Auto-escaping inherits down through template inclusions. That
>> is, if
>> you extend a template that has auto-escaping enabled, you get
>> auto-escaping enabled (obviously the autoescape template tag can
>> control
>> this). Anybody h
On Jul 6, 2006, at 4:14 AM, Simon Willison wrote:
> I just got back from EuroPython, and one of the hot topics there was
> templating systems. One thing that caught me by surprise when
> discussing this issue is how Django is actually the exception rather
> than the norm in terms of the escaping
On Jun 21, 2006, at 6:41 PM, Jacob Kaplan-Moss wrote:
> There's
> no right and wrong here, there's just what "fits" with the rest of
> the framework, and encapsulating a distrust of the developer into
> this framework doesn't feel right.
Does there seem to be consensus out there among web framew
Hey. We came up with this independently. It must be a good idea. :-)
Todd
On Jun 20, 2006, at 5:50 AM, adurdin wrote:
> Simon Willison wrote:
>> I've written up a proposal for how we can implement auto escaping
>> while hopefully keeping most people happy:
>>
>> http://code.djangoproject.com/wi
Couldn't we do something less invasive/complicated?
How about
{{ var }}
by default escapes the contents (in other words, the very first
filter called on a variable is escape, by default) and
{{ var|raw }}
skips the call to escape?
It breaks backwards compatibility, but maybe there's a way
D'oh. Thanks!
(And that doesn't come up at all if you google the words "arbitrary"
"precision" "Python", strangely.)
Todd
On May 29, 2006, at 6:21 PM, Nicola Larosa (tekNico) wrote:
>
>> Sorry for the OT post, but what do people use for arbitrary
>> precision decimals in Python?
>>
>> I woul
Sorry for the OT post, but what do people use for arbitrary precision
decimals in Python?
I would think it's in the standard libraries somewhere, but I must be
googling the wrong terms.
Todd
--~--~-~--~~~---~--~~
You received this message because you are subs
On May 29, 2006, at 11:09 AM, Derek Anderson wrote:
> schema evolution was an idea suggested and specifically granted for
> the
> SoC project. i don't know who here was involved with ranking the
> proposals, but for better or worse mine was accepted.
And I for one am very excited.
Do you hav
On Apr 13, 2006, at 10:34 PM, James Bennett wrote:
> Which is a problem, because really the whole idea behind a URL slug is
> to provide some useful information about the page which lives at that
> URL.
And if your users aren't speakers of languages that are normally
represented in ASCII text,
86 matches
Mail list logo
