command, if not always the
full docs (g info gr). So I'd suggest considering implementing
something to generate a man page from whatever you wish the "canonical"
source of the information to be.
Cheers,
Nick
--
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These sta
use, and who therefore never use the runserver at all...
Cheers,
Nick
--
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago
--
You received this message because you are subscribed to the Google Groups
"Django
e value, by the way. "Looking
for a positive outcome".
Well, perhaps face value plus a head of frustration that he's hiding
fairly well.
Thanks again to all of you who are making it happen.
Cheers,
Nick
--
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These state
On Tue, 2013-02-19 at 15:46 -0700, Carl Meyer wrote:
> Hi Nick,
>
> On 02/19/2013 03:32 PM, Nick Phillips wrote:
> > I don't recall looking at the ALLOWED_HOSTS setting before. Now that I
> > do, it seems rather problematic. In particular, that host verification
> > is
t all times and allow us to ensure we get the right
hosts in the right environments?
What am I missing?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are
stead of
> floats.
>
Not if you have a "legacy" database which uses NUMBER, I'm guessing...
I'd have thought the inability to work with any particular common field
type should be a bug, as it could effectively prevent working with
non-managed models altogether.
Cheers,
Nic
the arguments really have to be within the single tag?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are subscribed to the Google Groups
"Django de
a forced logout with disabling of account and email to
admin, could be all sorts of things, depending on the site.
The question should probably be "how can we allow the developer to
specify the desired behaviour when the user attempts to access a URL to
which they have no access?" - subject
eral people who, on finding that they can't do what they
want with raw(), would naturally progress to writing a postgres function
to do the dirty work (on the grounds that that can then be called using
"select").
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# t
starting another one?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
self) where any
of these processes are automated across multiple DBs at the moment?
FWIW I *always* forget that I have to explicitly call syncdb for each
database, and expect the one call with no db specified to have done the
lot.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otag
e sake of that
> ideal.
Makes sense. What you're doing is clearly an improvement, and one with
no cost to the user involved in making the change, so...
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of
tually allow the keys to be refreshed
without invalidating existing otherwise-valid HMACs?
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You received this message because you are subscribed
ir issue is buried within the framework and can't easily be
overridden, I think their ubiquity does justify the the lower priority.
However, as Alex pointed out, this is essentially bikeshedding. So,
since you're the one doing the work, at this point I'll shut up and wish
you well with it :-)
Cheer
ditions
LOG_ERRerror conditions
LOG_WARNINGwarning conditions
LOG_NOTICE normal, but significant, condition
LOG_INFO informational message
LOG_DEBUG debug-level message
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.
e that all munging of
data took place in one method which could then be used for the purpose
described above - which worked just fine.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these statements are my own, not those of the University of Otago
--
You re
if I did want to, I wouldn't expect to get
anywhere with your current tactic.
This thread is distracting energy that could be better spent, so I'm
going to leave it at that, and would suggest that others do too.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# thes
/foo, /foo/ and /foo/index.html
usually being equivalent )
was correct. I think you're probably just looking at it from a different
angle.
As someone else pointed out, it's very likely moot at this point anyway.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
# these st
an index in one of two
different ways), there are absolutely no security implications involved
in the decision (or lack of decision ;-) ) that is currently being
discussed.
FWIW, I personally dislike extraneous slashes. Django views seem to me
to be analogous to files, not directories, so I don't l
for everything so far; it looks like this could be quite
enjoyable :-)
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED]
# these statements are my own, not those of the University of Otago
--~--~-~--~~~---~--~~
You received this m
I don't know whether I'd use magic-removal --
damned if I do, damned if I don't.
So yes, you're absolutely right. And my timing is, as usual, awful.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED]
# these statements are my own, not those of the University of Otago
--~-
21 matches
Mail list logo
