eness sake.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscr
Sigh! I guess I sent this out a little prematurely.
On Wed, Aug 12, 2009 at 3:50 PM, Waylan Limberg wrote:
[snip]
>
> 2. Implement ticket #11625 -- Add admin actions to the comments admin.
>
[snip]
>
> 3. Using a proxy model and custom manager, create a second admin
> instanc
om/en/dev/ref/contrib/comments/custom/#django.contrib.comments.get_model
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
and this reference to relative urls. Relative to what? The site
root? The app root? The currently viewed page? "get_relative_url" is
probably not what you actually want. "get_url_path" is.
Of course, this all really a bikeshed issu
f/models/fields/#django.db.models.DateField
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroup
out
and our wrapper seems to work ok now. Yes - ok - I get the sense it
could be better.
Ever since then, any mention of logging leaves a bad taste in my
mouth. Perhaps if I was working only in 2.6 or such, this wouldn't be
an issue, but we have promised support back to 2.3.
Of course, it is po
t could cause some other test to fail that previously
passed. So I'm going to run the whole test suite anyway - or at least
all the tests for that module, etc.
Alex suggestion of --failfast seems like a much more useful way to
shorten test runs.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
of the command line option, or if they should
> still take effect.
Well, a logger can have multiple handlers. I would think we would want
to leave the handlers defined in settings.py in tact and add the
manage.py handler (most likely output to stderr - but could be
dif
orting, just create your own
custom filter that does just that. You could even copy the built-in
filter to your own project/app and use it with a one or two line
change.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message
GS_MODULE is required) of the docs linked above. As
Russell mentioned settings is lazy so you don't get an import error
but you will get a RuntimeError if settings have not been configured
properly when you actually try to use your templates.
--
--
On Thu, Oct 29, 2009 at 11:07 AM, Waylan Limberg wrote:
> On Thu, Oct 29, 2009 at 10:37 AM, Johan wrote:
>>
>> I am
>> wanting to use the template engine outside the context of a django
>> project so I would not have a settings file anywhere on my path.
>
>
our
> attention second. I don't think the current color scheme does that in an
> effective way.
> Tobias
>
Actually, they current colors look an awful lot like diffs as they are
displayed by on various sites (green lines added, red lines removed).
In fact, at first gla
rapped in a check that request.user
exists like the new add_message function does?
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googl
On Thu, Dec 3, 2009 at 10:23 AM, Luke Plant wrote:
> On Thursday 03 December 2009 14:18:10 Waylan Limberg wrote:
>
>> Looking though this patch I couldn't help but notice the new
>> get_messages function. What if a project has neither the
>> MessageMiddleware nor
t wouldn't that really come under a future proposal for a
better/replacement site app? Or should the current proposal be set
aside until that is solved first?
Personally, I'd prefer this proposal to land now and hope for a better
solution to the limitations of the site app later. That way t
.
[1]: http://code.djangoproject.com/wiki/LoggingProposal
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To un
ta:
> # Defaults to False
> validate_model = True
Well, what if one view uses that ModelForm one way and another view
uses the same ModelForm the other way? What about
``form.is_valid(validate_model=True)``?
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
djan
group, send email to
>> > > django-developers+unsubscr...@googlegroups.com
>> > > .
>> > > For more options, visit this group at
>> > >http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are s
pers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" gro
On 10/11/06, Le Roux Bodenstein <[EMAIL PROTECTED]> wrote:
>
> I wrote some filters
On 10/12/06, Tim <[EMAIL PROTECTED]> wrote:
>
> Here are some simple math functions that we found useful for templates
> as well:
>
Both of you should post those in the cookbook [1] on the wiki so they
don't get
be able to see the full path of the URL somehow under
> mod_python? (Maybe there is a better way than I'm trying).
>
> I'm not sure what's right so I thought I'd post a question here before
> submitting a ticket.
>
> Thanks,
> -Dave
My guess is the problem
d when entered.
And with the current filters, as you point out, that proper
capitalization won't be altered. Hey, if someone types in their name
wrong, we shouldn't be expected to fix it, or even know how. 'Garbage
in, garbage out' (tm).
>
> >
>
--
Waylan Li
re to post the fixes to the ticket (and perhaps a
link to this thread) so is doesn't get lost.
>
> Now how do I write a regression test? Any docs available?
>
> --
> James
>
>
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~-
Brantley Harris wrote:
> Maybe good practice, but not practical. I'd love to not have to use
> tables. But practical CSS just isn't there yet. Yes, tables aren't
> good for general layout, but they still have their uses, and forms are
> a prime example.
>
A table's uses generally consist of
introduced in python2.4.
[1]: http://www.python.org/doc/current/lib/typesseq-strings.html
[2]: http://docs.python.org/lib/node40.html
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
idation? Wouldn't storing the
data in sessions avoid that?
That said, hidden fields certainly have their place and are probably
"good enough" for generic usage. Just a thought.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You r
de available? Perhaps file a ticket and upload a patch?
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
ress
> both trees.
>
But only for the short time before newforms are moved to forms. This
way those who are still using oldforms can get everything adjusted to
working with oldforms while not breaking any calls to forms as
described here:
http://www.djangoproject.com/documentation/newforms/#
ing like this:
user = User.objects.get(pk=user_id, default=None)
Of course, I think that would probably be significantly more work than
your little wrapper function.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because
Nice job Honza. I was about to suggest just about the same, but
hesitated because of the *args and **kwargs. I just wasn't sure why
that made me hesitate.
On 12/18/06, SmileyChris <[EMAIL PROTECTED]> wrote:
>
> On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECT
27;, \
'default_redirect_to': '/'}),
Worthwhile?
I think so.
In the meantime, I can set up a redirect from /accounts/profile/ to /,
but this seems hackish to me.
Cheers!
Rob
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~-
make more
sense. Either way, I don't see the value in 1 as in either 2 or 3, the
default can still be set to None.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups &
tribute to lack of documentation more than anything else. But maybe
I'm missing something.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers&q
On 1/5/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
Prior to `initial` being available, I created a static (although is
could be a dynamically populated) dict, and passed that in when
initializing a blank form. Being I never validated the form, no errors
appeared. So that is another
set 4284 [1], the behavior of clean_data was altered. It
looks like the tests in tests/modeltests/model_forms/models.py were
not updated to reflect that change. Specifically, I see no calls to
is_valid() which would explain the above error.
[1]: http://code.djangoproject.com/changeset/4284
--
Wayla
On 1/8/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
As of changeset 4284 [1], the behavior of clean_data was altered. It
looks like the tests in tests/modeltests/model_forms/models.py were
not updated to reflect that change. Specifically, I see no calls to
is_valid() which would expla
tation explaining how to use it. In both cases they should
be submitted as diffs, just like the code. You can attach each as a
different file, or include everything all in one diff file.
[1]: http://www.djangoproject.com/documentation/contributing/#patch-style
--
----
Waylan Limberg
d. However, if there was a way to pass final_attrs for each
field in a form to the template (perhaps as an optional behavior),
that would give template authors complete control over the layout of
their forms. Perhaps something like:
http://code.djangoproject.com/browser/django/trunk/django/newfor
On 1/11/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> However, if there was a way to pass final_attrs for each
> field in a form to the template (perhaps as an optional behavior),
> that would give template authors complete control over the layout of
> their forms.
I thing
owser/django/trunk/tests/regressiontests/markup/tests.py
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to dj
se.
My understanding is that Django's templating system was built on the
idea that as little logic should go into the template as possible.
Asking for more logic will likely fall on deaf ears. Just pick your
alternate of choice and go to work. That's the beauty of Django.
--
Way
On 2/5/07, Henry <[EMAIL PROTECTED]> wrote:
>
> You're preaching to the converted :)
Sorry Henry, that comment wasn't met for you, but the original poster.
I was just building off of your comment. Perhaps I didn't make that
clear.
>
> On Feb 5, 11:19 pm, &
rather than "a different class" it should add an **additional** class. We
don't want to remove any classes that already exist.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
pplied data and simply call save() -- on
> maliciously crafted data -- you may end up overwriting existing data!
>
> Without availability of INSERT, the only way you can save yourself is
> by doing get_or_create() (or something similar) -- which is twice as
> slow. Why imitat
s:
{% with some.complex.variable as var %}
{% with some.another.variable as other %}
{{ var }}
{{ other }}
{% endwith %}
{% endwith %}
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are s
it.
>
> http://code.djangoproject.com/ticket/4024
>
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [
ww.djangoproject.com/documentation/contributing/#submitting-patches
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group
On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote:
>
> I think what you're overlooking is that in some cases the issue of
> whether its the "best solution" is irrelevant. If the database is
> already in production or the policies are already set or controlled by
> an external entity, th
. Although I might suggest wrapping the
entire model def in a single if statement rather than individual
fields.
That way, we get the immediate needs (longer email, etc) addressed
with an interim solution but have only one path (Apps re-factor) to
the broad solution down the road.
--
\X/ /-\ `
t to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
--
\X/ /
rest as is.
I do not recommend the approach of the current patch. It leaves a bad
taste in my mouth. Also note that I do not recommend supporting
Markdown's "safe_mode" in any form. Of course, the Django team will
need to make whatever decision will better serve the community - not
m
ludes my take (as the maintainer of the markdown lib) of the
current markdown implementation in contrib.markup.
Someone else in this discussion mentioned that the markdown implementation
is not safe. I believe that it the case with all "true" markdown
implementations.
--
----
\X/ /-\ `/ |_
list and you'll find various
discussions about this - mostly proposals to update the tutorials to
not use the "project" concept. Unfortunately, no one has stepped up to
do the work.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to
oups.google.com/groups/opt_out.
>
>
If I'm not mistaken, the only part of the download url that changes
with each release is the version number -- which is referenced only a
few lines up. Why isn't the url dynamically created using version?
That's what I do for my projects and the
t don't bother trying later if it didn't work the first
time.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroup
nals/contributing/#ticket-triage
But that hardly makes clear exactly what "accepted" actually means.
The text in that section is helpful to understanding the basic
process, but if someone changes the status of my ticket, there's no
definitive place to go and see exactly what that stat
e situation is. Will the community redux change
this?
[1]: http://code.djangoproject.com/wiki/WikiStart?action=diff&version=259
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To p
arning in the docs that create() and get_or_create() do
not run validation before writing to the db may be appropriate.
[1]: http://docs.djangoproject.com/en/dev/ref/models/querysets/#create
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed t
m home page. A range of other queries have always
> been there, but there wasn't a simple "needs review" query.
>
> [1] http://code.djangoproject.com/wiki/Reports
>
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subsc
ions should be added to the
"bugs-and-features" section? Just a thought.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
s for years, and will have
> long since worked out the kinks.
> --
> Vernon
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.co
here in his project. At the same time, we don't want to waste
resources on every request when it's not needed. A templatetag makes
the most sense to me. It could easily be loaded into any template and
used from any app. Additionally, while its a nice-to-have feature, I
don't see it as
ommand [2].
[1]:
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion#head-15564b76f3172721218d34c912aa0c31e156a94b
[2]: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You rec
n" and "Settings" links up in
the top right corner.
If that doesn't work - then perhaps a dancing animation across the
newticket page. Ok, maybe not. :-D
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this messag
#x27;t recommend it. For one, that could result
in some long urls (perhaps even longer than the limit). A multi-part
form could add up to a lot pretty quick. Second, those would be some
ugly urls. And third, as mentioned above, it's not really the proper
use of GET anyway.
So, unless a strong use-
On Tue, Jul 1, 2008 at 8:28 PM, Arien <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Jul 1, 2008 at 5:59 PM, David Durham, Jr.
>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
like to get in line with the thought processes on Django
> development. Could someone here please elaborate on why ticket 7591 is a
> bad idea? Or better yet why its a worse idea than other approaches?
>
>
> Thanks,
> --
> - Paul
>
> >
>
--
Waylan Limberg
[EMAIL PR
;>> ''.join(a for a in ['1','2','3'])
File "", line 1
''.join(a for a in ['1','2','3'])
^
SyntaxError: invalid syntax
>>> ''.join([a for a in ['1','
in formats and
> then tries to render_to_response("%s.%s" % (template, format,
> returned_dict, RequestContext(request))
>
> As I said above, the mechanism (in my case, a decorator) should
> probably try to investigate what the request looks like, rathe
h it if I get a chance.
> It's also heavily documented - *everything* has a docstring. I hope
> you enjoy,
I'll say. What, less that 50 lines of code in a 500+ line document? Wow.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
Yo
that would be added to a users app, which can then be used
in place of the one that ships with Django.
If your interested in more specifics as to why Django has chosen
silent failure, search the list archives. Seems there was a recent
discussion about it.
--
Waylan Limberg
[EMAIL PROTECTED]
I've found an old-style `class Admin` your
> request declaration in an example in "Django at a glance" and I'm not
> sure if such bugs are known.
>
There's already a ticket for this: #8150. Although the patch might
need to
% var better than var + '/'? I can think
> of some reasons: 1) consistency with other code, 2) certainty of
> string concatenation. But is the second expression not much faster?
> (This is an honest question, no criticism or any
On Thu, Aug 21, 2008 at 12:22 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
>
> On Thu, Aug 21, 2008 at 10:00 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>> I had thought that I read from that same source that formatting is
>> faster than concatenation (and tha
the other way anywhere - and would find that confusing.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
...
)
Not sure how that would work for over-riding the default
get_connection method though. We'd probably still be referring to a
callable by 'dotted.path.to.a.function' syntax. And it would apply to
all models in an app, not just some.
Just a thought.
--
Waylan Lim
le Django is with CPython
> 2.6. I know that it should work fine anyway, but I thought it a good
> idea just to check. Has anyone looked into this?
>
> Regards,
> Zack
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You
whoever asked didn't really want this, but
something else. Therefore, I don't believe anyone has provided a valid
use case for such a signal. I'd suggest searching the archives.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You r
inheriting
> GeoModelAdmin to one of them. How can I contribute the modified
> templates and subclass to the Django project, that is if there is any
> interest in adding this to django ?
>
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--
caught while
testing not in an egg first, but it is a real possibility. Perhaps we
shouldn't care about that one though.
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Grou
[1]: http://code.djangoproject.com/wiki/InstalledAppsRevision
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, se
.
Although, I do see that the documentation specific to the
login_required view does not specifically mention the behavior.
Perhaps a note there would be beneficial.
[1]: http://docs.djangoproject.com/en/dev/topics/auth/#api-reference
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~---
use on my production
sites. I'd say the developers time is better spent elsewhere.
Especially considering there are already working solutions out there.
I seem to recall at least one management command someone put together
that runs a multithreaded cherrypy server. Why reinvent the wheel?
Lets focus
ject itself. That's bad.
You see, anyone can use Django any way they want and don't have to use
any of the "shortcut" helper functions. However, everyone has to use
the request and response objects, so the code needs to make as few
re
Hi Dmitri,
Welcome to Django. However, this list for the development of Django
itself, not development with Django. Please ask your question on the
django-users list. <http://groups.google.com/group/django-users>
--
Waylan Limberg
way...@gmail.com
On Thu, Dec 25, 2008 at 10
t; this sort of scenario in a cleaner way. Or perhaps there's a more
> django-y way of doing it?
>
> Any info/pointers/tips would be appreciated.
>
> //Ed
>
> >
>
--
Waylan Limberg
way...@gmail.com
--~--~-~--~~~---~--~~
Y
?
> Can i try dev this new models class or classes!?
>
> sorry about my english...
>
> att,
>
> Marcello Bontempo Salgueiro.
>
> >
>
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message b
ct.com/settings
[3]: http://code.djangoproject.com/wiki/ServerArrangements
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
t in on declaring the
field without creating my own subclass etc.
[1]: http://www.freewisdom.org/projects/python-markdown/Available_Extensions
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
ld get ugly, but I thought I'd throw it out there.
2. ForeignKey dependent default or not.
Again, the obvious way would be with different fields.
But what about checking to see if the string passed in matches an
existing foreignkey on
markup.py
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from
t will work is to accept
kwargs. So, using the above example:
>>> e.body.save_markup(formatter='markdown.markdown',
kwargs={'safe_mode': True})
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this me
hile setting it to False
would leave the message in the db, set "is_public" to False, but also
recognize that it has already been moderated (I believe
`comment.is_removed = True` does that).
[1]: http://code.google.com/p/django-spambayes/
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
orked before, that was a bug. Now it's fixed.
You'll have to edit your tag to coerce the string to an integer. Not
to hard to do, but a good idea even if it's not necessary.
[1]:
http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#templat
On Tue, Mar 24, 2009 at 3:14 PM, eXt wrote:
>
> On 24 Mar, 15:26, Waylan Limberg wrote:
>> Well, you are using the `stringfilter` decorator, which, according to
>> the docs [1], "will convert an object to its string value before
>> being passed to your function.&
e and
only call it the first time. Not fun, but it's got to be better than
dealing with DJANGO_SETTINGS_MODULE and settings.py.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
torical reasons.
See other reasons discussed elsewhere [1]. Particularly the last
section of that post.
[1]: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You receiv
Support in Django"
Mentor: Russell Keith-Magee
In any event, congrats to all.
--
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To p
7;m not a core dev, so I could be
wrong, but my recollection of previous similar requests would seem to
indicate otherwise.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
1 - 100 of 134 matches
Mail list logo
