a data loss bug (the specific example in the policy), but I'd argue that
the gradual nature of the async rollout and its importance in moving Django
forward mitigates for an exception to the backport policy.
Cheers,
Kevin
On Friday, December 30, 2022 at 5:24:51 PM UTC-5 timog...@gmail.com wrot
aluated]>"
QuerySet.__repr__ = __repr__
```
If folks are willing to reconsider their positions on this issue, I am more
than willing to do what is necessary to contribute this change upstream, so
that others are not impacted by this in the future.
Thank you,
Kevin
On Tuesday, March
`staff_member_required` is a nice convenience method, quite useful outside
of the admin if your authorization needs are sufficiently served by
User.is_staff (which isn't always the case of course, but often *is* on a
small project).
Yes, it can be reduced to a `user_passes_test` call, but that'
ain disadvantage—and a real one—is that it's more work for Django.
Cheers,
Kevin
On Friday, October 9, 2020 at 8:06:49 AM UTC-7 Paul Ganssle wrote:
> Before looking at alternatives, I wonder if we can just change the shims
> package to make it fully backwards compatible? Right now the
#x27;t it actually attempt to adjust the
time the way pytz does? Perhaps by wrapping pytz itself, and calling its
normalize() from the corresponding pytz timezone; or by simply replicating
its time-changing logic? Apologies if that's a naive question.
Cheers,
Kevin
On Thursday, October
igh that. (Just one perspective, of course...)
Cheers,
Kevin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dja
fo) way. I don't have strong
feelings about how that should happen (e.g. a feature flag), or when it
should happen.
Cheers,
Kevin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
d to throw this out to the community and
see if there were any strong feelings one way or another before moving
forward with a PR.
Cheers,
Kevin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
You are totally right, my mistake. Sorry about that, noob here.
On Tuesday, November 12, 2019 at 12:16:12 PM UTC-6, Adam Johnson wrote:
>
> Hi Kevin,
>
> I feel like this is a support question more than a question around
> developing Django, so I've pasted my canned response
Hi, I'm new to Django so excuse me if it's a noob question.
I have a Django app, let's call it "project", that uses a Django reusable
app, let's call it "app", version controlled on github, and tagged.
1. I create a first version of the app with its initial 0001_initial.py
migration file, tag i
ther trivial, and I'm not presently able
to volunteer to do it, so I'm working on the assumption that
dj-database-url retains more or less its present scope.
Kevin
On Thursday, July 18, 2019 at 12:46:13 PM UTC-4, Jacob Kaplan-Moss wrote:
>
> Hi folks -
>
> I’d like to ga
can look to
in terms of a template?
Thanks,
Kevin
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-develop
itely agree that it would nice to
have a Windows-native solution that Just Works, so +1 from this occasional
Windows user.
Cheers,
Kevin
[1] https://bugs.python.org/issue22343
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions
I agree with requiring pytz if you have timezone support enabled in Django,
as that cuts out a set of edge cases and likely simplifies the code base a
bit in the long run. And I even agree with forcing it to be installed with
Django if we want to encourage people to use Django with timezone supp
inction would
make a difference in your native language?
For what it's worth, I'm in favor of both proposed changes.
Cheers,
Kevin
On Saturday, June 25, 2016 at 9:29:15 PM UTC-4, Tim Graham wrote:
>
> Reinout, I agree that the imperative mood seems awkward, especially when
&g
Hello,
With all the talk of DEPs flying around I thought I'd finally take a look
at one in detail.
I wanted to make a suggestion about it and realized that there wasn't
really a good place to do so. The issue was too minor for a mailing list
discussion, and there was no open pull request to co
Thomas, did you ever find a solution to your problem? I'm having similar
thoughts and am looking for an answer.
On Friday, February 6, 2015 at 4:18:53 AM UTC-8, guettli wrote:
>
>
>
> Am 04.02.2015 um 14:04 schrieb Anssi Kääriäinen:
> > I'd really like to be able to define middlewares that actu
Validation that doesn't rely on browser behavior *is* useful, if only for
the (admittedly shrinking, but still non-zero) population of folks using
older browsers. Also API clients and so forth.
Very much agreed that it should match the HTML5 spec, though - fewer edge
cases and more predictable
I have found a good alternative to the old initial data feature. It's
called django-update-initial-data.
https://github.com/ambitioninc/django-dynamic-initial-data
MySQL compatible version:
https://github.com/minervaproject/django-dynamic-initial-data/tree/mysql
It's actually better than the o
Later than expected, but here we go folks:
https://github.com/archen/django-tests
There are some barebones instructions for contributing and direction. Feel
free to reach out to me directly for any assistance or questions so I can
better document the process for anyone else interested in helpin
est
> to not duplicate efforts. Let me know how I can pitch in.
> On Wednesday, April 22, 2015 at 10:25:17 PM UTC+5:30, Kevin Glavin wrote:
>>
>> Thank you everyone for your interest. I spoke with Tim last night to start
>> piecing together the strategy. The gameplan on my end
Thank you everyone for your interest. I spoke with Tim last night to start
piecing together the strategy. The gameplan on my end is to start a repo that
we can all work from and (in)formally define the high level strategy. I'll
enter any work items as issues on the github repo and share the link
Hi Tim,
I have been using Docker, Vagrant, and Jenkins for a while now independently.
Would love to help out with this effort.
Feel free to reach out to me privately if you'd like to continue the discussion.
--
You received this message because you are subscribed to the Google Groups
"Django
This issue was the subject of https://code.djangoproject.com/ticket/24082.
There, the accepted (but not implemented) solution is the same as suggested
here: allowing the user to opt out of the creation of the additional index
with `db_index=False`.
On Wednesday, April 15, 2015 at 2:11:25 PM UTC
ul for the average django developer.
Links:
Fun Project - https://github.com/kburts/drf-music
Website / blog - http://kevinburton.ca/
Github - https://github.com/kburts
Thanks for reading & your feedback,
Kevin
--
You received this message because you are subscribed to the Google Groups
On Wednesday, September 10, 2014 10:39:51 AM UTC-4, Josh Smeaton wrote:
>
> Kevin,
>
> > It simply says, in deliberately vague language, that if a member of the
> Django community is treated abusively by another member of the Django
> community _outside_ a Django fo
at I don't expect is for you to submit a
pull request offering the affirmative, positive reworking of the CoC that
you have proposed, so you have an opportunity to surprise me there.
Regardless, your criticism has provided me with the opportunity to more
thoroughly think through and ex
e group does decide to create the ASBO, could
> it be called the Anti-Social Django Act?
>
> On Tue, Sep 9, 2014 at 7:33 AM, Benjamin Scherrey > wrote:
>
>> Hi Kevin,
>>
>>And thanx for responding to my question about the need for such a
>> policy with Dj
vs wisely and quickly made the right choice.
On Monday, September 8, 2014 9:37:16 PM UTC-4, Russell Keith-Magee wrote:
>
> Hi Kevin,
>
> Thanks for these suggestions.
>
> By way of settings expectations - a patch of this nature has a little more
> procedural overhead than a norma
oject.com/pull/86>, to make
explicit the currently implicit policy that someone's abusive behavior
outside the django community *may* have an adverse effect on their
ability to participate within the django community.
I welcome your feedback.
Thanks,
Kevin Daum
--
You rece
My name is Kevin Sebastian and I have been working with django for quite
some time and I would like to contribute to any of its projects.I will be
grateful if someone can offer any suggestion for the same.I am also
proficient in python and its various libraries and I have worked on python
>
> What kind of support do you except for third-party template tags? Suppose,
> that
> `cycle` tag is not builtin. Would it be acceptable to write sth like that:
>
> dtl cycle '1' '2' as rows
>
> It could be quite easily implemented as a Jinja2 extensions. Of course, I
> guess
> that you'd
ing requests, please solve
that problem. :-) And if you're forced to prioritize, I think that would be
more useful than being able to inherit from DTL templates.
Cheers,
Kevin
>
> - It would be nice to use the same loaders for both django.dtl and
> jinja2. This
>requires to
Russell makes the very good point that Jinja2 isn't just a faster version
of the Django template engine - it's philosophically at odds with the
original design and intent of the Django template engine.
Personally, I prefer Jinja2's approach and would love to see it become the
standard. (The ben
+1 for "is_installed"
I don't find the grammar objectionable here, just think of it as "is_(each
one of these apps)_installed"
On Sunday, January 5, 2014 3:50:45 PM UTC-6, Aymeric Augustin wrote:
>
> On 5 janv. 2014, at 22:38, Raffaele Salmaso
> >
> wrote:
>
> > Should it takes a list of app
ew users who may not know anything
about transaction management (and who are probably also the least likely to
need the faster tests). Are we leading them into a premature optimization?
Cheers,
Kevin
[1] https://code.djangoproject.com/ticket/21540
--
You received this message because you are subscr
s. I think
this is Marc and Florian's suggestion. The problem here is that the
grouping of with statements depends on both logical and lexical
considerations, which seems somewhat less readable to me.
4) Revert the commit and stick with one with statement per line.
Personally, I prefer 4 or
>
>
> We probably cannot move checks of `primary_key` and `unique` living in
> `FileField.__init__`. We test if one of these two parameters was passed; we
> don't check their values. Consider that an user passes unique=False. This
> is
> the default value, but nevertheless, this should result in
gt;
> I don't think it would break South installations as custom app commands
> will always override builtins. Could you open a ticket for that? The
> inconsistency is problematic. Obviously it would be backwards incompatible,
> but we need to gauge the size of the impact.
>
>
changed so that management commands were consistent with the other
cases, but that would create serious backwards compatibility issues. Like,
breaking everyone's South installation. :-O
Cheers,
Kevin
On Wednesday, August 14, 2013 5:26:47 AM UTC-4, Stefano Crosta wrote:
>
> Done! https://co
Not sure where to report this, but the docs.djangoproject.com is going very
slow today, and I received a "504 Gateway Time-out" from the nginx server.
Any ideas?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this gr
ocess like CRUD
and how to make it extendable. it uses docstrings, which provide
additional info on the classes and methods themselves.
On Wednesday, 3 April 2013 22:26:06 UTC-5, Jacob Kaplan-Moss wrote:
>
> On Wed, Apr 3, 2013 at 10:19 PM, Kevin Veroneau
> >
> wrote:
> > Is
is to document the entire Django
project using Epydoc to see how that would look. Seeing these UML graphs
is memorizing and very educational for when working with Django.
Is this Epydoc error related to Epydoc or something that Django shouldn't
have done in it's source code?
Best
h during this ordeal.
Link to retained InstantDjango(for example purposes):
http://www.pythondiary.com/blog/Apr.10,2012/instant-django-release-information.html
I plan on updating this InstantDjango with Django 1.5, and using distribute
over setuptools. Current Download count: 1461
Best Regar
Scratch this, I just noticed that the dev docs explain a lot more than the
1.3/1.4 docs do. Perhaps having this documentation in 1.3/1.4 as well, or
at least mentioning there that the dev docs contain much more information.
On Sunday, 11 November 2012 11:31:41 UTC-6, Kevin Veroneau wrote
example of what I would love to see in
a future version of class-based views.
Best Regards,
Kevin Veroneau
Python Diary
http://www.pythondiary.com/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion
bscribed to the Google Groups
> "Django developers" group.
> To post 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
&
Has the repository been
deleted? https://github.com/mitsuhiko/django-template-compilation is giving
me a 404.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django
esn't __unicode_cast function need to call *unicode* on
*self.__func(...)* like what __str_cast does,call *str* function?
Any help is appreciated.
Kevin Xiao
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
e best way to do this would be, but I should have plenty
of time this week to look into it.
Cheers,
Kevin
--
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.
Whoops, url should be https://bitbucket.org/bolhoed/django_disqus_comments.
On Nov 28, 7:29 pm, Kevin Renskers wrote:
> The existing apps use the JavaScript interface offered by Disqus. This
> does not integrate with apps that expect Django's comments app.
>
> I've ma
cket: http://bitbucket.org/bolhoed/django-disqus-comments/.
I think that from this code the problem of the current situation is
clear.
I'd be more then happy to work on a new comments API for Django by the
way!
Kevin
On Nov 28, 5:19 pm, "subs...@gmail.com" wrote:
> Heh, a
es in the admin interface. Django-blog-zinnia does this.
I am looking forward to any comments and ideas. Is something like this
even possible without completely breaking backwards compatibility?
Kind regard,
Kevin Renskers
--
You received this message because you are subscribed to the Google Groups
r modifications, so I'm still intending to commit
>> early next week, barring major objections.
>>
>
> As per my answer to Kevin - I think a NullHandler addition to the
> 'django' logger needs to happen internally (not under a site
> developer's control)
f handlers... ie:
logger = logging.getLogger('adsf')
if not logger.handlers:
dictConfig(settings.LOGGING)
I feel like that check is unnecessary anyhow... but I guess that's how
you'd do it if it is necessary.
-k
On Fri, Oct 1, 2010 at 8:54 AM, Vinay Sajip wrote:
> On Oct 1,
I feel like something like this would be better suited to be in an
external application... since it will fail without a cache-backend.
Also, the implementation will have to change as Russell is about to
commit a logging patch with ticket #12012.
This would be best suited though for a custom handl
re: verbose logging configuration.
This bothered me as well initially, though after starting to use
logging extensively I realized that there isn't really a more concise
way to provide all of the features that the logging config brings to
the table.
We can however, create a very concise default s
ervers for
debugging. Though this is more of a poor excuse for me to work with
websockets and rabbitmq, I think it could be useful. Thoughts?
Anyhow... here's the current project... If anyone has feature
requests... feedback.. criticism ... i'm always game.
http://github.com/kevin/djang
Could be good to include some text about using the python loggers on
that WSGI debug page, rather than relying on the apache logging
mechanisms.
In django land ... there's django-devserver, django-debugtoolbar, and
django-lumberjack.
All of them more or less share the same profilers and such. Th
> For a very high traffic project backed by 20+ DB servers
Slightly OT, but MySQL performance related...
If you are write heavy, there's another issue that I imagine would
bring significant gains on a MyISAM setup of that proportion... and
possibly other databases to a lesser degree (the locking m
"I agree, and while we're at it also change the settings.py template to
just point to urls instead of project_name.urls"
Indeed, always the first thing I change when I start a project...
Having the project_name there means you are including the directory
above your project in the python path in yo
This abstract base class likely is a bit less performant than having
in-db support for cascades in pgsql... though it should give you the
behavior you are seeking.
It should set to default, or null if allowed.
Enjoy.
-k
class ClearOnDelete(models.Model):
def delete(self):
related_obje
This was not a "hey you guys are lazy", actually came across it ...
after I had fixed the same issue.
I just posted a patch for you generated off trunk... and left a
hopefully somewhat entertaining explanation of the details surrounding
the issues.
-k
--
You received this message because you ar
http://code.djangoproject.com/ticket/10758
Can we fix this? It's a pretty easy fix.
thanks,
-k
--
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
I added a AdminEmailHandler to my branch and pulled the upstream
changes.
http://github.com/kevin/django-experimental/
It now behaves very close to how django-trunk does on exception ... by
default there is a streamhandler pushing to stderr and the admin email
handler pushing emails to admins
p in log/messages if that's what you assumed ...
it should be caught by the default apache loggers at minimum, or be
sent to your vhost log if you have logging setup per virtual host.
-k
On May 28, 8:30 pm, Vinay Sajip wrote:
> On May 28, 10:27 pm, Kevin howerton wrote:
>
> > Indeed,
ler by default spits everything out to stderr which is in
turn picked up by apache's logging.
btw...
My implementation of logging is here:
http://github.com/kevin/django-experimental
and a flushed out demo of what a third party app that utilizes python
logging is here (basically just django-
I see the utility of being able to have additional ways to setup the
logging, though as it is I think the biggest issue people have with
the logging stuff is that the dictconfig is already fairly
intimidating looking. If someone really wants to disable the default
setup of logging, it should be as
On Wed, May 5, 2010 at 3:48 PM, Jacob Kaplan-Moss wrote:
> On Wed, May 5, 2010 at 1:53 PM, Kevin Howerton
> wrote:
>> Where django pulls a 500 it should call these two lines, which will
>> dump the exception raised to stderr.
>>
>> type, value, traceback
in production.
-k
On Wed, May 5, 2010 at 1:51 PM, Karen Tracey wrote:
> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton
> wrote:
>>
>> What I was suggesting in my post though, was that we alter the default
>> CRITICAL error handling behavior ... as it stands (by default
I did.
On Wed, May 5, 2010 at 12:56 PM, Jacob Kaplan-Moss wrote:
> On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
> wrote:
>> ps. I don't want to get into a flamewar
>
> Then next time leave out the rambling, ad hominems, and sweeping
> generalizations. Focu
#x27;s very reductionist. Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.
On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip wrote:
>
> On May 5, 4:47 am, Kevin Howerton wrote:
>
> I think the plan was t
#x27;s very reductionist. Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.
On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip wrote:
>
> On May 5, 4:47 am, Kevin Howerton wrote:
>
> I think the plan was t
#x27;s very reductionist. Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.
On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip wrote:
>
> On May 5, 4:47 am, Kevin Howerton wrote:
>
> I think the plan was t
Realized today that by default django more or less suppresses errors
sent to stderr when debug is off. Well I guess it uses email sent to
admins by default. Though, I distinctly remember stderr being sent
into my apache logs for some reason. Maybe this was when I was using
mod_python rather than
>Nothing I've seen so far solves, or even addresses the original need for
>_not_ sourcing the same script numerous times (thanks to widgets with
>their own media)
The widget and admin media system needs to be re-evaluated IMO
none of these solutions are going to address the flaws you are
refer
The django-compress looks a bit better as it has the option to do the
versioning (based on a file hash), compression, and concatenization
with a management command.
Django_compressor does this all on page load, which is not production
worthy IMO.
Generating an MD5 hash on page load is un-needed ov
>From the github:
"* Commits should be atomic: they should each encompass a single logical
change that works on its own. You can use "git rebase --interactive" to
collapse multiple commits into a single commit before pushing your code
up for contribution."
I think the idea is to basi
"I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening this
can of worms would mean having to incorporate some kind of a pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've brie
Thanks for the support Russ...
I think Cujo (the name at least) has been abandoned and I have joined my
efforts with some other developers also interested in contributing to an
experimental branch.
http://github.com/tomxtobin/django-experimental
http://groups.google.com/group/django-experimental?
Cujo... for starters it's Amon Tobin's first moniker (he remixes jazz
into some delightful tunes, if you don't know of him I strongly
recommend you go to your local record store and pick up a copy of
"Adventures in Foam").
Also, I felt it was somewhat apt due to the rabid nature of the
discussions
"That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc."
1.1 and 1.2 are by definition not point releases. Point releases
don't introduce new features.
On Thu, Apr 15, 2010 at 3:32 PM, Jacob Kaplan-Moss wrote:
> On Thu, Apr 15, 2010 at 1:57 PM, Kevin
Why not just use the backend feature that already exists?
I have an S3 backend that does this...
It checks if it's on S3, if not it serves it locally. If it's on S3
it throws the url into memcache, and bob is your uncle.
On Wed, Apr 14, 2010 at 9:27 AM, Russell Keith-Magee
wrote:
> On Wed, Apr
"You seem to be suggesting that a fork will somehow magically fix the
speed of Django development. I ask you: who is going to work on this
fork?"
I think a hostile fork is almost a certain outcome if development
continues as it has. Not only is the resistance to make backwards
incompatible change
c wit henceforth, as it clearly doesn't translate
well on the internet.
sorry again.
-k
On Tue, Apr 6, 2010 at 12:14 AM, Jacob Kaplan-Moss wrote:
> On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton
> wrote:
>> ps. I didn't really murder a hooker in vegas
>
> This s
cket/7539
>
> But I like your imagination, or is there more truth behind your story
> than you'd admit?
>
> Cheers,
> Florian Apolloner
>
> On Apr 5, 8:06 pm, Kevin howerton wrote:
>> Hi.
>>
>> So I came across a use-case for wanting to delete conte
Hi.
So I came across a use-case for wanting to delete content (which
django doesn't really handle exactly to my liking). I just got back
from a vacation in vegas and noticed in a drunken stupor I had posted
some pictures on my blog that should I really shouldn't have (
http://i.imgur.com/5oj15.jp
On Dec 12, 5:09 pm, Jacob Kaplan-Moss wrote:
>
> I prefer to think of it like this:
>
> Django 1.2 ships. Users read the release notes, and notice that
> psycopg1 is now deprecated and will be removed. It's still there, and
> still supported, so they can upgrade quickly and not have to be stuck
On Oct 26, 7:23 pm, Tobias McNulty wrote:
>
> IMHO the project namespace is a useful one to keep around. If you lose the
> project name space, then you risk polluting your python path with a lot of
> generic 'urls' modules, among other things.
>
> If your directory structure on your server incl
It's Python which doesn't allow dots in the name of a package,
although it's Django which is putting the name of your project name on
sys.path. This was intentional, see the django.core.management
package:
# Import the project module. We add the parent directory to
PYTHONPATH to
# avoid s
On Oct 21, 3:43 am, maxky wrote:
>
> I know, that this is not the right place for that discussion. Can
> anyone redirect me
> to the adequate bb or usenet group?
Python's Web-SIG list is the best place for asking questions that will
be read by a variety of different Python framework developers
On Oct 6, 1:43 am, Simon Willison wrote:
>
> Option 6 would be welcome if anyone has any ideas.
>
Do what Grok does:
$ grokproject newapp
$ cd newapp
$ ./bin/test
Running tests at level 1
Total: 0 tests, 0 failures, 0 errors in 0.000 seconds.
That is, if it's a fresh project, and no code has
> If the objective is to seperate the two systems why is having the URL
> system know about Models more acceptable than having the Model system
> know about URLs? This is most certainly a bike shed IMO.
>
> Alex
Because it's the URL system which is making those models available on
the web, not
> > Thanks, the accompanying discussion is very interesting and on point.
> > But as someone there points out, why stop at widgets?
>
> Because customizing widgets is a common request, unlike other attributes.
But customizing fields is quite common, no? I agree that it's rare
that you will want t
> Please file a ticket for the documentation fix it would be greatly
> appreciated. :-)
Will do.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
e, but I'm not sure of a better solution.
Cheers,
Kevin
--~--~-~--~~~---~--~~
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 unsu
s would be implemented, I
just wanted to throw the idea out there. But unless there's a
groundswell of support for my position, I guess I'll just file a
documentation ticket.
Cheers,
Kevin
--~--~-~--~~~---~--~~
You received this message because you are
Take a simple Model and ModelForm like this:
class Author(models.Model):
name = models.CharField(max_length=80, blank=True, default="Joe",
help_text="A name")
class AuthorForm(forms.ModelForm):
class Meta:
model = Author
The resulting form will reflect the desired help text, de
ekend, but will have access to e-mail, and will
be checking when possible. Hopefully the end of next week will be the end of
most documentation/testing efforts, and I can give people the go-ahead to
start trying to mess around with everything!
--
Kevin Kubasik
htt
ests of
> django.test.TestCase (not tests that use django.test.TestCase, but a
> test that verifies the TestCase class itself is working properly), and
> haven't been able to locate them. Any pointers on where I can find
> these? Or do they not exist?
>
> Much thanks!
>
&g
1 - 100 of 168 matches
Mail list logo
