On 8/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > In implementing the "manage.py testserver" command, I've been struck
> > by how large django/core/management.py has gotten. It's 1730 lines
> > long -- and messy.
> >
> > I'd like
On 8/16/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> > Sounds like a really good idea to me -- looking forward to it!
>
> Cool -- I'm on it.
>
> > I'd like to suggest a (somewhat controversial) extension:
> >
> > Let any (installed)
On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> In implementing the "manage.py testserver" command, I've been struck
> by how large django/core/management.py has gotten. It's 1730 lines
> long -- and messy.
>
> I'd like to split this into several files, turning
> django.core.management in
On Thu, 2007-08-16 at 13:49 +1000, Malcolm Tredinnick wrote:
> I'm not sure if any of the Oracle devs are watching django-users (no
> need you should be, btw). In case you aren't you might be able to help
> out on this thread
>
> http://groups.google.com/group/django-users/browse_frm/thread/fbaea
Marty Alchin wrote:
> On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>> This would let projects like S-E -- there's a reason I used it for the
>> example -- provide custom management actions; installing said app
>> would make those actions "appear" in manage.py. This would go a long
>> w
On Wed, 2007-08-15 at 21:51 -0700, Collin Grady wrote:
> Malcolm Tredinnick said the following:
> > The current latest patch fails in a dangerous way, which is why I'm
> > against it. Fail safely (so that my data always gets saved when I call
> > save()) and it's up for consideration.
>
> Is the
Malcolm Tredinnick said the following:
> The current latest patch fails in a dangerous way, which is why I'm
> against it. Fail safely (so that my data always gets saved when I call
> save()) and it's up for consideration.
Is the failure you mention just the __setattr__ issue, or is there
another
On Wed, 2007-08-15 at 21:09 -0700, Collin Grady wrote:
> Malcolm Tredinnick said the following:
> > See earlier threads for why transparent behaviour is not a very safe
> > idea. If you override save(), for example, it's going to be very easy to
> > end up with things not being saved. This is not
Malcolm Tredinnick said the following:
> See earlier threads for why transparent behaviour is not a very safe
> idea. If you override save(), for example, it's going to be very easy to
> end up with things not being saved. This is not common behaviour, so
> asking somebody to at least pass in an e
I'm not sure if any of the Oracle devs are watching django-users (no
need you should be, btw). In case you aren't you might be able to help
out on this thread
http://groups.google.com/group/django-users/browse_frm/thread/fbaeab8eef802e94
It's a little beyond my skillset with Oracle, but it looks
On Wed, 2007-08-15 at 22:27 -0600, Norman Harman wrote:
> Malcolm Tredinnick wrote:
> > One obvious test would have been to create a test directory that didn't
> > contain a models file but did contain a tests.py file.
> I would be wary of writing unittests that created stuff on people's
> filesy
Malcolm Tredinnick wrote:
> One obvious test would have been to create a test directory that didn't
> contain a models file but did contain a tests.py file.
I would be wary of writing unittests that created stuff on people's filesystem.
> I think one reason the patch hasn't been applied is that i
On Wed, 2007-08-15 at 21:04 -0600, Norman Harman wrote:
> ticket 3310 http://code.djangoproject.com/ticket/3310
> manage.py test does not work if there is not a model.py in the application
>
> The 6mo patch doesn't apply anymore. Is there a reason it was never applied?
> Apps
> without models
On Wed, 2007-08-15 at 18:59 -0600, Norman Harman wrote:
> SmileyChris wrote:
> > Collin has put a lot of effort in to this ticket [1] which is still
> > waiting as a design decision. The latest patch is (apart from lack of
> > docs) ready for check-in in my opinion. Could we have a decision on
> >
On 8/16/07, Norman Harman <[EMAIL PROTECTED]> wrote:
>
> I'd like this to be fixed. I'd like to update the patch incorporating any
> concerns the
> list might have. I wouldn't like there to be someone else posting a similar
> email as this
> one in 6mo wondering why my patch was never applied.
I think the url tag if can work like below maybe more useful .
Example
mytags.py:
.
@register.inclusion_tag('xxx.html')
def page_link(url_name):
return {"url_name":url_name}
__
xxx.html:
1
ticket 3310 http://code.djangoproject.com/ticket/3310
manage.py test does not work if there is not a model.py in the application
The 6mo patch doesn't apply anymore. Is there a reason it was never applied?
Apps
without models seem valid to me. I have a couple django apps that don't use db
a
On 15 Aug., 19:51, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I'd like to split this into several files, turning
> django.core.management into a package. The purest way of splitting the
> functionality would be to give each manage.py action ("runserver",
> "syncdb", etc.) its own Python module
On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I think it would merely delay the bikeshed discussions. If we don't
> have a required file layout, people will spend long mailing-list
> threads five months from now talking about how *they* do things, and
> how there should be an establishe
On 8/16/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > I'd like to split this into several files, turning
> > django.core.management into a package. The purest way of splitting the
> > functionality would be to give each manage.py ac
Norman Harman said the following:
> Nobody knows me, so my opinion isn't worth much. But, this would be good.
> Better would
> be if it were transparent(properties or some other mechanism to notice when
> fields are set
> and therefore dirty/need updating). I'm fairly surprised something li
On 8/15/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> That's just my opinion, but it seems like it could avoid a lot of
> bikeshed discussions where people debate the best file structure to
> use.
I think it would merely delay the bikeshed discussions. If we don't
have a required file layout, peo
SmileyChris wrote:
> Collin has put a lot of effort in to this ticket [1] which is still
> waiting as a design decision. The latest patch is (apart from lack of
> docs) ready for check-in in my opinion. Could we have a decision on
> whether this is worthy?
Nobody knows me, so my opinion isn't wor
On 8/16/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Would it be worthwhile to add a way to purge unused content types via
> manage.py? It could look at INSTALLED_APPS and anything not installed
> it removes?
+1 to the idea - as noted elsewhere in the thread, this would be
handled best as an im
On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I'd like to suggest a (somewhat controversial) extension:
>
> Let any (installed) app provide its own manage.py actions in a similar
> way -- something like::
>
> schema_evolution/
> management/
> __init__.py
>
SmileyChris said the following:
> The solution is that clean_* methods should just be passed the field's
> value as an argument.
> Even being backwards incompatible, I think it needs to be done.
+1, passing them the value makes much more sense, IMO.
--
Collin Grady
I wouldn't marry her with a
On Aug 15, 3:34 pm, sime <[EMAIL PROTECTED]> wrote:
> >clean_field1 = generic_clean
> >clean_field2 = generic_clean
>
> The problem here is generic_clean doesn't know which field it is, and
> I can't pass arguments that way? Don't think we have field.name or
> similar eithe
On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Let any (installed) app provide its own manage.py actions in a similar
> way -- something like:
+1. As I was reading Adrian's post, I was thinking the very same thing.
--~--~-~--~~~---~--~~
You received t
On Aug 16, 5:51 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> This would be the extent of my refactoring for now. Any strong
> thoughts either way before I go ahead and implement it?
Sounds great! One other thing that would be nice is if the sql
generation methods were refactored too so they
On 8/15/07, George Vilches <[EMAIL PROTECTED]> wrote:
> There aren't enough +1s in the world for me to vote as strongly as I
> would like on both Adrian's initial proposal and this extension.
That's just because I've been hoarding them. Once the bottom drops out
of the subprime market I think the
> I'd like to suggest a (somewhat controversial) extension:
>
> Let any (installed) app provide its own manage.py actions in a similar
> way -- something like::
>
> schema_evolution/
> management/
> __init__.py
> commands/
> __init__.py
>
> If your verification logic wants to know what field is verifying now,
> you can use closure.
> It is simple, Pythonic and doesn't change core :-)
Closures; fantastic. The more I learn about Python the shorter and
shorter my code gets. :-)
Thanks very much for posting this, Vsevolod. I was abl
> Is this a common problem for people or just me? I don't run into it
> with every app, but I do refactor my models often times and run into
> this, and think it would be nice if there were a more automated way to
> clean up those tables.
I've bumped into this same problem several times. It woul
On 8/15/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Sounds like a really good idea to me -- looking forward to it!
Cool -- I'm on it.
> I'd like to suggest a (somewhat controversial) extension:
>
> Let any (installed) app provide its own manage.py actions in a similar
> way -- something l
On 8/15/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> Why not, rather than adding another option in django.core.management,
> have the contenttypes app do this? The existing post_syncdb hook
> could be extended to clear unused content types as well as create new
> ones.
>
> You would have to reme
On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'd like to split this into several files, turning
> django.core.management into a package. The purest way of splitting the
> functionality would be to give each manage.py action ("runserver",
> "syncdb", etc.) its own Python module, like th
On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> Shouldn't really be an issue with his scenario though, since he said
> this was during initial dev on the data model, so he wouldn't even have
> much (if any) data yet :)
Right, but when it comes time for the next app I create in that
project,
On 8/15/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> > Wouldn't reset do that?
> >
> > ./manage.py reset auth contenttypes
>
> I haven't tried that but that looks like it would clear those tables
> completely vs. purging only the unused tables
David Danier said the following:
> Even if it did the id's might have changed and any generic relations be
> broken.
Shouldn't really be an issue with his scenario though, since he said
this was during initial dev on the data model, so he wouldn't even have
much (if any) data yet :)
--
Collin G
> Would following that with a syncdb then restore the content types for
> the installed apps? I'll have to test that later.
Even if it did the id's might have changed and any generic relations be
broken.
Greetings, David Danier
--~--~-~--~~~---~--~~
You received
On 8/15/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> Wouldn't reset do that?
>
> ./manage.py reset auth contenttypes
I haven't tried that but that looks like it would clear those tables
completely vs. purging only the unused tables.
Would following that with a syncdb then restore the content ty
Rob Hudson said the following:
> Would it be worthwhile to add a way to purge unused content types via
> manage.py? It could look at INSTALLED_APPS and anything not installed
> it removes?
Wouldn't reset do that?
./manage.py reset auth contenttypes
--
Collin Grady
"Die? I should say not, de
On 8/15/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > I'd like to split this into several files, turning
> > django.core.management into a package. The purest way of splitting the
> > functionality would be to give each manage.py action ("
On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'd like to split this into several files, turning
> django.core.management into a package. The purest way of splitting the
> functionality would be to give each manage.py action ("runserver",
> "syncdb", etc.) its own Python module, like th
On 8/15/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> backends/
> __init__.py
> runserver.py
> sqlall.py
> syncdb.py
I wrote "backends" there, but I meant "commands", which would be a
more meaningfu
In implementing the "manage.py testserver" command, I've been struck
by how large django/core/management.py has gotten. It's 1730 lines
long -- and messy.
I'd like to split this into several files, turning
django.core.management into a package. The purest way of splitting the
functionality would
PS: I should add before Malcolm tells me, "We accept patches" that I'm
willing to code this up for submissions if the idea is generally well
received. :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
One of the things I typically do when starting a new project/app is to
spend some time adjusting and tweaking the data model. One thing I
run into sometimes when I change my model name is leftover content
types in the database and also in the permissions. It's a bit of a
pain removing these manu
Am 15.08.2007 um 16:52 schrieb Michael Radziej:
> currently, django/conf/__init__.py still sets __builtins__['_'] =
> gettext.
>
> This causes a UnicodeDecodeError in code like the following line
> when the
> the translated message contains non-ASCII characters:
>
> _('some message: %s').someM
Hey Michael,
On Wed, 2007-08-15 at 16:52 +0200, Michael Radziej wrote:
> Hi,
>
> currently, django/conf/__init__.py still sets __builtins__['_'] = gettext.
>
> This causes a UnicodeDecodeError in code like the following line when the
> the translated message contains non-ASCII characters:
>
>
Hi,
currently, django/conf/__init__.py still sets __builtins__['_'] = gettext.
This causes a UnicodeDecodeError in code like the following line when the
the translated message contains non-ASCII characters:
_('some message: %s').someModel.name
Shouldn't _ better evaluate to ugettext?
Michael
On Wed, 2007-08-15 at 04:15 +, SmileyChris wrote:
> Recent checkin http://code.djangoproject.com/changeset/5887 broke
> running an individual test:
I've tried to fix the same problem (as intended by [5887]) in a
different way in [5892] and [5893].
Regards,
Malcolm
--
No one is listening un
On Aug 14, 11:19 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 8/14/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> > I would suggest that rather than trying to make the --with-fixture
> > flag handle all this, it would be better to do this as a top level
> > command, i.e.:
>
> > dj
> It is simple, Pythonic and doesn't change core :-)
Pythonic sure, but not even close to what I would consider simple.
Surely we can find better, simpler, cleaner solutions to these common
problems. I'll gather some code so we can all see what a mess these
few trivial omissions are making.
--~
54 matches
Mail list logo
