All,
We've merged the magic-removal branch to trunk. All Django development
will focus primarily on the branch formerly known as magic-removal,
and all documentation on djangoproject.com will focus on the
development version.
Previous versions of the documentation are here:
On Wed, 2006-03-01 at 17:55 -0800, Kevin wrote:
> I had this same problem. I checked through the source code and my
> guess is that the new magic-removal branch requires all models to be in
> a module named .models
>
> Now my existing code was split up between functions and the
I had this same problem. I checked through the source code and my
guess is that the new magic-removal branch requires all models to be in
a module named .models
Now my existing code was split up between functions and then I just
used the __all__ variable to add them together.
__init__.py
Hi
I am using manage.py from /manage.py
Can you send me an examlpe model file ? I would just like to make sure
it nothing do with my typing.
Thanks,
S
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django de
On Wednesday 15 February 2006 20:59, ChaosKCW wrote:
> Hi
>
> I hope this is the correct place.
>
> I just took downloaded the magic removal branch, and entered some
> models in the new way.
>
> manage.py sql* functions dont seem to work.
>
> if i run the manage.py
Hi
I hope this is the correct place.
I just took downloaded the magic removal branch, and entered some
models in the new way.
manage.py sql* functions dont seem to work.
if i run the manage.py shell, and import manually it appears to work,
but manage.py sql or sqlall or install, just error
On 1/17/06, Matthew Marshall <[EMAIL PROTECTED]> wrote:
> Minor nitpick, but could we use 'class_' instead of 'klass'?
Sorry for the slow response on this. It's all set:
http://code.djangoproject.com/changeset/2193
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
>AFAIR unicodefication must be done before Django 1.0. This not big API
>change, but some code must be changed too after it.
>(Ex. str->repr or str->unicode)
Before doing it, there still is the analysis of what needs exactly to
be done - for now it's just a list of keywords on the wiki page, I
de
Adrian Holovaty пишет:
On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
Is there any reason subtyping and field descriptors need to happen on
magic-removal? Could we just test/merge magic-removal and create a new
branch for those tasks? Is there anything else but those two tasks
left?
On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Is there any reason subtyping and field descriptors need to happen on
> magic-removal? Could we just test/merge magic-removal and create a new
> branch for those tasks? Is there anything else but those two tasks
> left? It doesn't sound li
On 1/22/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> >
> > I'd like to start moving my stuff over to the magic removal branch and
> > was wondering if the API is stable enough to start doing
On 1/23/06, Jason Davies <[EMAIL PROTECTED]> wrote:
> I'm keen to get the "semantics of subtyping" stuff done. If you have
> any implementation hints to help me along that would be really helpful,
> thanks.
Same here. I'd love to see a working subtyping implementation for
magic removal, the soon
Robert Wittams wrote:
> I personally am not going to be able to work on it any time soon. Sorry.
> Anyone else should feel free to give it a stab.
I'm keen to get the "semantics of subtyping" stuff done. If you have
any implementation hints to help me along that would be really helpful,
thanks.
Russell Keith-Magee wrote:
> On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
>>
>>I'd like to start moving my stuff over to the magic removal branch and
>>was wondering if the API is stable enough to start doing so.
>>
>>
>
> I would sa
>Up until today I could even run both branches of
>code against the same database, but that changed tonight because we've
>changed the way database-table names are calculated.
Ok, now I know why it was a bad idea to switch the logger to
magic-removal ;-)
(just kidding, it's a really simple proje
On 1/22/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> I'd like to start moving my stuff over to the magic removal branch and
> was wondering if the API is stable enough to start doing so.
>
> I'm not after something bugfree, just something where the ground is
> s
On 1/23/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
I'd like to start moving my stuff over to the magic removal branch andwas wondering if the API is stable enough to start doing so.I would say probably not. There is still one big change to come - the use of descriptors on database ob
Hi.
I'd like to start moving my stuff over to the magic removal branch and
was wondering if the API is stable enough to start doing so.
I'm not after something bugfree, just something where the ground is
stable enough so I don't have to rewrite huge portions of my code
every wee
hugo wrote:
>>+1. Gets around the reserved word problem entirely, and removes a
>>little bit more magic from model definitions.
>
>
> Problem with that discussion was, IIRC, that neither Adrian nor Jacob
> where very fond of allways having to explicitely provide the manager.
> So the result of t
>+1. Gets around the reserved word problem entirely, and removes a
>little bit more magic from model definitions.
Problem with that discussion was, IIRC, that neither Adrian nor Jacob
where very fond of allways having to explicitely provide the manager.
So the result of the discussion was what we
On 1/18/06, hugo <[EMAIL PROTECTED]> wrote:
>
> One thing I would agree to is, the default 'objects' is magic that
> should be removed. Actually that was my position in the discussion, to
> make the manager assignment _allways_ explicit, so people allways will
> choose the name of the manager obje
>Personally I find the idea of "every model class has an objects
>property for manipulation in bulk, except when it doesn't" pretty
>horrifying, especially from a code maintenance point of view. I guess
>if people really want to make their lives more difficult we should
>let them but I certainly w
On 16 Jan 2006, at 08:49, hugo wrote:
Uhm - in what way is nowadays defining classes and using them
"clumsy"?
Thought that's what OO is all about. The beast is named "removing the
magic" for a good reason, so why throw in another "magic" (one that
turns a scoped class definition into a - dif
Minor nitpick, but could we use 'class_' instead of 'klass'?
>From the 'Pythonic guidelines' in PEP 8:
- If your public attribute name collides with a reserved keyword,
append a single trailing underscore to your attribute name. This is
preferable to an abbreviation or corrupted spelling.
> Sorry, but I am -1 on this change. Several reasons:
One more point I would like to add:
- Flat is better than nested
Ok, so Tim Peters isn't infallible, but I think this is pretty good
advice.
my 2 cents
MWM
[current sample with defined classes and used objects]
>The above feels a little clumsy to me. Here's my proposed alternative:
[sample with inner class]
Uhm - in what way is nowadays defining classes and using them "clumsy"?
Thought that's what OO is all about. The beast is named "removing the
On 1/14/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Basically, you define your own inner class called "Manager" if you want
> to add custom methods to Person.objects (or modify the behaviour of
> existing methods). If you don't define this inner class the default
> Manager will be used.
I can
> I suppose the greater problem is the ability to easily construct (and
use) a filter on queries (e.g. construct a 'tall_people_only' filter,
make it a member of Person, so you can write
Person.get_list(tall_people_only, name__exact='Fred'). You should be
able to do this using arg-level query obje
On 1/15/06, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> The current system in magic-removal enables multiple managers (you can
> assign as many as you like to different properties). I don't see the
> advantage in allowing this - why not just add wrapper methods to your
> custom Manager inner cla
I've been thinking a bit about how we add custom table-level methods to
models in the magic-removal branch. Here's how it works at the moment:
class PersonManager(models.Manager):
def get_list(self, **kwargs):
# Changes get_list() to hard-code a limit=10.
kwargs[&#x
Sure. There may not be a need for a "project" dir when you have only
one project running. It is cleaner to simply have /admin/blog/entry/add
or even /admin/entry/add. Also, you may want your model to technically
describe the object accurately, but present it to the user in a more
readable way, or
oggie rob wrote:
> Would it be possible to override the url location within the
> modules/classes? My only concern is that sometimes the project, module
> and/or class name are not an appropriate part of a URL, and would be
> nice to easily override. (This of course assumes that URLs are part of
>
Would it be possible to override the url location within the
modules/classes? My only concern is that sometimes the project, module
and/or class name are not an appropriate part of a URL, and would be
nice to easily override. (This of course assumes that URLs are part of
the UI, which I feel is tr
On 12/14/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
+1
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message
news:[EMAIL PROTECTED]
>Or substitute slashes for dots:
>
> /admin/myproject/blog/models/entry/add/
I like this better. Slashes are better than dots.
Thanks,
Eugene
I think Cherry is more instance-y, Quixote was more package-based but
with v.2 is now more explicit with "Directory" classes that define
traversals. I think. I don't use either in real life.
Just thought I'd mention them as references that might be applicable --
even if they're too much for this
ToddG wrote:
> I don't know if there's a mathematical formula for this, but it's
> looking like all ideas are approaching an object traversal/resolution
> scenario like in: Zope, Quixote, CherryPy, etc. Perhaps one of those
> can offer some direction.
>
>
I think most of those work on an instan
I don't know if there's a mathematical formula for this, but it's
looking like all ideas are approaching an object traversal/resolution
scenario like in: Zope, Quixote, CherryPy, etc. Perhaps one of those
can offer some direction.
On Dec 14, 2005, at 9:15 PM, Adrian Holovaty wrote:
Or maybe get rid of the "models" cruft:
/admin/myproject/blog/entry/add/
This one's my favorite.
Double points if /admin/myproject/ shows a list of models under
myproject (and /myproject/blog/ shows all the ones under
myproject.blo
Adrian Holovaty wrote:
> In the magic-removal branch (see
> http://code.djangoproject.com/wiki/RemovingTheMagic), we're removing
> the magic model modules, which means the concept of "module_name" goes
> away. This creates a bunch of interesting new issues, because
On 12/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
+1 for being the most readable and less cumbersome.
--
Jeroen Ruigrok van der Werven
On 15 Dec 2005, at 3:59, Adrian Holovaty wrote:
Clearly we would want to avoid that. Before importing, it could check
that the module is in INSTALLED_APPS.
By going with /admin/project/app/model/add/ stick with more normal
looking urls, you can do the checking at quite a fine-grained level
On 12/14/05, Ian Holsman <[EMAIL PROTECTED]> wrote:
> my other concern with putting the python path into the URL is would it
> allow nasty thing
> like
> admin/init.me.and.i.format.your.hard_disk/
> ?
> and other weird easter eggs which a unsuspecting admin doesn't realize
> is on his machine?
Cl
On 12/15/05, Afternoon <[EMAIL PROTECTED]> wrote:
>
>
> On 15 Dec 2005, at 3:15, Adrian Holovaty wrote:
>
> > /admin/myproject/blog/entry/add/
>
> +1, most readable, most compact, most guessable.
>
> > The problem with "/admin/myproject.blog.models.entry/", though, is I'm
> > not sure it's pos
ion I would like to see
/admin///add
where application is the 'short' version.. ie 'forum' would be short
for zilbo.apps.forum
and that shorthand could live in the content-type table perhaps?
On 12/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> In
On 15 Dec 2005, at 3:15, Adrian Holovaty wrote:
/admin/myproject/blog/entry/add/
+1, most readable, most compact, most guessable.
The problem with "/admin/myproject.blog.models.entry/", though, is I'm
not sure it's possible to get the Python path *to* an object. For
example, given a mo
In the magic-removal branch (see
http://code.djangoproject.com/wiki/RemovingTheMagic), we're removing
the magic model modules, which means the concept of "module_name" goes
away. This creates a bunch of interesting new issues, because some
parts in Django use module_name -- namely,
47 matches
Mail list logo
