In case anyone else gave up on the above link,
http://docs.djangoproject.com brought me successfully to
http://docs.djangoproject.com/en/dev/
Can't wait to check out the new docs!
Thanks,
Wayne
On Aug 22, 12:21 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> I've tried several
I've tried several times yesterday and today to go to the new docs
link above, but unfortunately 404'ed every time.
Thanks,
Wayne
On Aug 19, 6:01 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Hi folks --
>
> The docs refactor work is pretty much done; now I need a bunch more
> eyes to look
Hi!
It's usually best to provide code examples at dpaste.com, and not to
drop long code sections into the post.
I also prefer the decorator syntax for Model method attributes. The
following paste contains the decorators the I use for this purpose.
http://dpaste.com/67425/
These decorators are
hmmm... next time, coffee first, post second. Appologies...
On Jun 23, 1:55 pm, Collin Grady <[EMAIL PROTECTED]> wrote:
> AmanKow said the following:
>
> > Actually, 'required' is an argument to the *Model* field constructor,
> > and models are *not* always
Probably not the place for this discussion, but...
On Jun 22, 3:08 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote:
> ambiguous in this context. Two perceptions exist:
> - required=True means the field has to be set. Following HTML form
> logics, it always is.
> - required=True means the require
e you suggesting that on fixture loading that parents should *not* be
> saved?
>
> Would this possibly allow you to load fixtures that don't fit in your model?
> E.g. children without parents?
>
>
>
> On Sat, May 10, 2008 at 10:24 AM, AmanKow <[EMAIL PROTECTED]> wrote:
Above, I said:
> I notice that child instances have an undocumented save_base method,
> which I assume is called from the child's save. I wonder if it might
> not be useful to have some way (r.save(exclude_parent=True) or some
> such thing) in order to save the child record only.
But I didn't ex
I've been hooking up child instances with existing parent instances
without problem, which seems entirely similar:
class Place(models.Model):
name = models.CharField(max_length=50)
address = models.CharField(max_length=80)
class Restaurant(Place):
serves_hot_dogs = models.BooleanFiel
Hmmm... I read the subclassing post. As a non-abstract child is
essentially a one to one with some syntactical sweetness, I'm still
not sure how using a one to one field is better suited than
inheritance for extending user.
Rajeev J Sebastion wrote:
> Because every app has its own concept/method
> Well, I personally have been saying for over a year that inheritance
> has never been and never will be the right way to do that, so I think
> y'all know what my answer is...
Could you elaborate or point to elaboration on why non-abstract
inheritance is a bad fit for extending user?
Thanks!
--~
On Apr 8, 12:20 pm, Trevor Caira <[EMAIL PROTECTED]> wrote:
> You don't need anything more than python string formatting for that.
> e.g.
>
> slug_re = r'(?[-\w]+)'
> year_re = r'(?\d{4})'
> # snip
> url(r'/article/%s/' % slug_re, views.article_detail),
> url(r'/category/%s/' % slug_re, vi
I don't know about sticking that in core, but that sure is a neat idea
that I think I might use in some personal stuff. Particularly useful
when urls have a complex 'bases' that I wish to use to parse the same
info out of groups of urls each time that are distinguished with
additional fiddly bits
On Apr 4, 11:06 am, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> (docstrings occupy memory too, so if you're *only* writing for folks
> reading the source, use comments.)
And of course, a production environment can always optimize the doc
strings out.
--~--~-~--~~~---~
On Apr 2, 12:26 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> def get_object_from_cache(self, ...):
> """
> Get an object from the cache and return it.
>
> ...
hmm... the doc string equivalent of the infamous c inanity:
i++ // increment i
I have seen a bit of that in the c
s/additions are
noted when the signature docs lives near the code.
Not advocating code as prose! I do indeed understand that code is
poetry!
Wayne
On Apr 2, 12:40 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Wed, Apr 2, 2008 at 10:47 AM, AmanKow <[EMAIL PROTECT
Will the api and internals references be generated (at least in part)
via doc string extraction? That's a big plus to me.
On Mar 31, 2:45 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> I'm embarking on a mission to refactor Django's documentation; this is where
> you give me feedback about
On Feb 7, 2:14 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> I've reopenedhttp://code.djangoproject.com/ticket/5124.
> 'contains_nontext' must be an instance attribute, not a class
> attribute in 'NodeList'. There is a patch attached.
Arrggh... my humble apolo
On Feb 7, 2:26 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> BTW, do I understand this correctly...
> {# comment #} is alright, but {% comment %} ... {% endcomment %} is
> not? I don't see anything in the code that would allow block
> comments. Would be nice if it did...
Th
BTW, do I understand this correctly...
{# comment #} is alright, but {% comment %} ... {% endcomment %} is
not? I don't see anything in the code that would allow block
comments. Would be nice if it did...
Wayne
--~--~-~--~~~---~--~~
You received this message be
I've reopened http://code.djangoproject.com/ticket/5124.
'contains_nontext' must be an instance attribute, not a class
attribute in 'NodeList'. There is a patch attached.
Wayne
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
to 0 the default behavior wouldn't change.
As far as I can tell, there is no way to change this behavior without
a recompile of the mysql code.
On Dec 20, 4:12 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> Ok, I'm stymied... it's a session variable only, not global and
> there
Ok, I'm stymied... it's a session variable only, not global and
therefore I cannot change the default value in the options file.
Also, it is not dynamic, which means that it requires a server restart
to be effective, but then it uses the default behavior, oh, my head
hurts.
Ok, I take it back...
Yikes!... it's a session variable only... makes it hard to change the
default behavior...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
I don't think mysql adding a setting to turn off/on behavior that
allows integration with some odbc applications as evidence of
hallucinogen use . It is an unfortunate choice to have the
non-standard behavior as the default, however.
Other than the above test, I find it hard to imagine someone f
24 matches
Mail list logo
