Re: How to get patches from 'Accepted' to 'Committed'
Jacob Kaplan-Moss wrote: > A polite nag on the mailing list -- like this email -- is a perfect > way to prod things along. > Cool, thanks for committing those. All the best, Steve. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Custom templatetag for latex users
Hi, I need to take a template ( written in latex ) and fill it with data, then send it through pdflatex to get the pdf output, and return it to the user. Django makes this easy, but not quite as smooth as an html template. I use render_to_string and output this to a file, then run pdflatex on that file - i know this is not ideal (should really be done in memory) so any advice on how to do this would be appreciated. However the point of this email is that characters in the data such as &, #, \, $ and some others are special latex characters and have to be escaped, so i wrote a templatetag called escapelatex (i saw someone has written escapejs, so i followed the naming convention) - my question is where should i post this tag so others can critique it, improve it, and possibly add it to contribs for all to use? -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Custom templatetag for latex users
On Wed, Aug 4, 2010 at 3:27 PM, mrkiwi wrote: > Hi, > > I need to take a template ( written in latex ) and fill it with data, > then send it through pdflatex to get the pdf output, and return it to > the user. Django makes this easy, but not quite as smooth as an html > template. > > I use render_to_string and output this to a file, then run pdflatex on > that file - i know this is not ideal (should really be done in memory) > so any advice on how to do this would be appreciated. > > However the point of this email is that characters in the data such as > &, #, \, $ and some others are special latex characters and have to be > escaped, so i wrote a templatetag called escapelatex (i saw someone > has written escapejs, so i followed the naming convention) - my > question is where should i post this tag so others can critique it, > improve it, and possibly add it to contribs for all to use? I'd suggest your best approach would be to publish it as a standalone reusable library on something like Github or Bitbucket. This allows you to publish the source, and allows others to easily use the source and contribute fixes. While I have great affection for LaTeX as a language (I wrote both my theses using LaTeX), I don't think it's appropriate for the core of Django. Ultimately, Django is a web framework, and HTML/JS are the focus of web work. Given that it's easy to distribute a template tag library as a third-party feature, your library doesn't need to be in the core, either. By maintaining a set of LaTeX tools as a third-party library, you are able to: * keep the development pace independent of Django's release cycle (particularly important during initial development) * help distribute the development load outside of the Django core team (since you aren't dependent on Django's core team to commit changes) * help keep the size of Django's core library under control (end-users are able to choose the extensions and languages they want to support) Best of luck with your LaTeX library. Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Make "required=True" on forms.fields.NullBooleanField do something useful?
Sorry this is quite late on this thread, but I hadn't noticed any answer for
it.
How about:
from django import forms
class MyNullBooleanField(forms.NullBooleanField):
def clean(self, value):
if value is None:
raise forms.ValidationError('Choose either Yes or No.')
return super(MyNullBooleanField, self).clean(value)
class YourForm(forms.Form):
whatever_field_name = MyNullBooleanField()
You could also subclass the django.db.models.fields.NullBooleanField and
overload the formfield method if you want this for free on a ModelForm, but
I suspect we're heading into django-users territory already.
Cheers,
Gary
On Thu, Jun 17, 2010 at 10:39 AM, Matt Hoskins wrote:
> My use case is that I want to have a BooleanField on the model and on
> the form want to have the choices of "Unknown", "Yes" and "No" in a
> select list and give a "this field is required" error if the user
> leaves it set to "Unknown" (i.e. require them to actively choose "Yes"
> or "No", rather than defaulting to either of them). I thought I'd just
> be able to use NullBooleanField with "required=True" set, but
> NullBooleanField just ignores the "required" argument. To my mind it
> would be a sensible use of "required" for NullBooleanField, but before
> raising a ticket I thought I'd ask if it was a deliberate oversight or
> if what I'm suggesting isn't sensible for some reason :).
>
> Looking at the code for forms.fields.BooleanField and
> forms.fields.NullBooleanField I guess the change would be in to_python
> in the latter to check in the case where it would return None if
> self.required is true and raise the validation error if that's the
> case (i.e. similar to what BooleanField.to_python does for values of
> False).
>
> Matt
>
> --
> 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
> 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 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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Enhanced URL Resolver Match
Hey Russ, Is there anything I should do to get http://code.djangoproject.com/ticket/13922 into RFC state? Let me know if you feel that the existing patch needs any work, or better docs. Thanks! Nowell On Jul 10, 4:35 am, Russell Keith-Magee wrote: > On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite wrote: > > When Django 1.1 was released URLs gained the ability to be nested with > > namespaces by adding "app_name" and "namespace" attributes to the > > include(...) functions within urls.py. The reverse(...) function was > > updated to allow you to specify namespace and current_app when > > resolving URLs, however, we never brought the resolve(...) function up > > to speed to include the relevant namespace and app_name data of the > > resolved URL. I have taken an initial stab with code and tests (minus > > documentation, until this feature is completed and agreed upon by the > > community). > > > In order to achieve this I have graduated the result of the > > resolve(...) method to be a ResolverMatch class as opposed to the old > > tuple(func, args, kwargs). I have also implemented this feature to > > provides backwards compatibility for the old "func, args, kwargs = > > resolve(...)" so this feature should hopefully be completely backwards > > compatible. The new ResolverMatch class provides access to all > > attributes of the resolved URL match such as (url_name, app_name, > > namespace, func, args, kwargs). > > > Please take a look and let me know what you think of the direction and > > implementation: > > >http://github.com/nowells/django/compare/master...resolver-match > > I'll need to do a detailed teardown before I commit, but on a first > inspection, this looks pretty good to me. > > If there isn't a ticket for this already, could you please open one > and include a reference to your github branch (and/or upload the > patch). Once there are some docs, I'm happy for this to be RFC for > 1.3. > > Yours, > Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
Updated the patch http://code.djangoproject.com/ticket/13795 On Jun 23, 11:12 am, Russell Keith-Magee wrote: > On Sun, Jun 20, 2010 at 6:16 AM, Byron wrote: > > Yes I agree. I never quite understood why the > > CACHE_MIDDLEWARE_KEY_PREFIX was implemented, but not at the lower > > level (did thecacheAPI become available after the middleware > > caching?). Of course a custom backend can be written, but then there > > would need to be a different one for each backend type. This is a very > > simple change to BaseCache that provides a means off prefixing. I also > > added a default for `key_prefix' in BaseCache (so current custom > > backends don't need to be rewritten and will work as normal). > > > BTW, the patch passes all previous tests at that revision (with the > > exception of a non-related markup test?) and I also subclassed all the > >cachetests and added a CACHE_KEY_PREFIX (renamed from > > PROJECT_KEY_PREFIX) for those tests -- they all pass as well. I also > > added a preliminary snippet of documentation that most likely will > > need to be expanded on. > > > I would appreciate any suggestions, criticisms, etc. > > Apologies for not weighing in sooner -- I think this is a reasonable > feature proposal; I've just marked the ticket as accepted. The patch > looks pretty good too, although I've got a couple of light polish > requests. I've attached comments on the ticket. > > Yours, > Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Enhanced URL Resolver Match
Hi Nowell, My apologies for the lack of action on this -- I've been really busy at work over the last month or so. I'm finally coming up for air, and this ticket is high on my list of things to look at. The patch itself looks like it's in pretty good shape; I just need to pick apart the logic to make sure nothing has been missed. Yours, Russ Magee %-) On Wed, Aug 4, 2010 at 8:37 PM, Nowell Strite wrote: > Hey Russ, > > Is there anything I should do to get > http://code.djangoproject.com/ticket/13922 > into RFC state? Let me know if you feel that the existing patch needs > any work, or better docs. > > Thanks! > Nowell > > On Jul 10, 4:35 am, Russell Keith-Magee > wrote: >> On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite wrote: >> > When Django 1.1 was released URLs gained the ability to be nested with >> > namespaces by adding "app_name" and "namespace" attributes to the >> > include(...) functions within urls.py. The reverse(...) function was >> > updated to allow you to specify namespace and current_app when >> > resolving URLs, however, we never brought the resolve(...) function up >> > to speed to include the relevant namespace and app_name data of the >> > resolved URL. I have taken an initial stab with code and tests (minus >> > documentation, until this feature is completed and agreed upon by the >> > community). >> >> > In order to achieve this I have graduated the result of the >> > resolve(...) method to be a ResolverMatch class as opposed to the old >> > tuple(func, args, kwargs). I have also implemented this feature to >> > provides backwards compatibility for the old "func, args, kwargs = >> > resolve(...)" so this feature should hopefully be completely backwards >> > compatible. The new ResolverMatch class provides access to all >> > attributes of the resolved URL match such as (url_name, app_name, >> > namespace, func, args, kwargs). >> >> > Please take a look and let me know what you think of the direction and >> > implementation: >> >> >http://github.com/nowells/django/compare/master...resolver-match >> >> I'll need to do a detailed teardown before I commit, but on a first >> inspection, this looks pretty good to me. >> >> If there isn't a ticket for this already, could you please open one >> and include a reference to your github branch (and/or upload the >> patch). Once there are some docs, I'm happy for this to be RFC for >> 1.3. >> >> Yours, >> Russ Magee %-) > > -- > 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 > 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 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote: > Updated the patch http://code.djangoproject.com/ticket/13795 Looks good. A couple of questions/comments: * Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't quite see the point of a separate setting, so unless you can think of a good reason to have both I'd suggest we deprecate CACHE_MIDDLEWARE_KEY_PREFIX in favor of CACHE_KEY_PREFIX globally. * In a few places you have functions defined like:: def get_cache(backend_uri, key_prefix=settings.CACHE_KEY_PREFIX): This is a bad idea: it forces the loading of settings at import time, meaning that if you've not defined DJANGO_SETTINGS_MODULE or called settings.configure() you can't even import the cache module. As a rule, you should avoid evaluating settings at import time, so in this case you'd do something like:: def get_cache(backend_uri, key_prefix=None): if key_prefix is None: key_prefix = settings.CACHE_KEY_PREFIX ... * Have you considered supporting "versioning" of keys to help with cache invalidation? Eric Florenzano has been doing some interesting experimenting along those lines in django-newcache (http://github.com/ericflo/django-newcache); you may want to look at the code and/or talk to him about working some of his ideas back into your key prefix proposal. At the very least, any changes we make to the caching backend should allow the sorts of things he's doing to keep working; ideally we should make those sorts of changes really easy to make. Thanks for your work - this looks good. Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
Thanks Jacob. I personally don't think the CACHE_MIDDLEWARE_KEY_PREFIX is necessary anymore. I suggest removing it, but I would imagine it would have to be deprecated for the next release then removed in 1.4? > As a rule, you should avoid evaluating settings at import time, so in > this case you'd do something like:: Ah, good point. I will make the changes. > Have you considered supporting "versioning" of keys to help with cache > invalidation? Thanks for the link to Eric's work, I will take a look and see how we can join forces. On Aug 4, 10:57 am, Jacob Kaplan-Moss wrote: > On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote: > > Updated the patchhttp://code.djangoproject.com/ticket/13795 > > Looks good. A couple of questions/comments: > > * Is there a reason to keep CACHE_MIDDLEWARE_KEY_PREFIX around? I don't > quite see the point of a separate setting, so unless you can think of a > good reason to have both I'd suggest we deprecate > CACHE_MIDDLEWARE_KEY_PREFIX in favor of CACHE_KEY_PREFIX globally. > > * In a few places you have functions defined like:: > > def get_cache(backend_uri, key_prefix=settings.CACHE_KEY_PREFIX): > > This is a bad idea: it forces the loading of settings at import time, > meaning that if you've not defined DJANGO_SETTINGS_MODULE or called > settings.configure() you can't even import the cache module. > > As a rule, you should avoid evaluating settings at import time, so in > this case you'd do something like:: > > def get_cache(backend_uri, key_prefix=None): > if key_prefix is None: > key_prefix = settings.CACHE_KEY_PREFIX > ... > > * Have you considered supporting "versioning" of keys to help with cache > invalidation? Eric Florenzano has been doing some interesting > experimenting along those lines in django-newcache > (http://github.com/ericflo/django-newcache);you may want to look at the > code and/or talk to him about working some of his ideas back into your > key prefix proposal. At the very least, any changes we make to the > caching backend should allow the sorts of things he's doing to keep > working; ideally we should make those sorts of changes really easy to > make. > > Thanks for your work - this looks good. > > Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote: On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote: Updated the patch http://code.djangoproject.com/ticket/13795 * Have you considered supporting "versioning" of keys to help with cache invalidation? Eric Florenzano has been doing some interesting experimenting along those lines in django-newcache (http://github.com/ericflo/django-newcache); you may want to look at the code and/or talk to him about working some of his ideas back into your key prefix proposal. At the very least, any changes we make to the caching backend should allow the sorts of things he's doing to keep working; ideally we should make those sorts of changes really easy to make. Couldn't versioning be handled by setting CACHE_KEY_PREFIX to include some varying data like the svn revision? We've got a cache key prefix hacked into our work environment, and I ensure my dev machine never gets stale cache data like this: import time CACHE_KEY_PREFIX = "dev-ned-%s" % time.time() This uses the start time of the dev server as part of the cache key so each invocation gets fresh data. In production, you'd use something different, but this illustrates the point. Or is there some more elaborate versioning being considered here? --Ned. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Model translation
Hi. As promised I hereby bump this old thread about model translation: http://groups.google.com/group/django-developers/browse_thread/thread/c6fdd3abea0c7f0e/8cd990e2e1f98e22?lnk=gst&q=hejsan#8cd990e2e1f98e22 I hope there is time to discuss this now even if it will not be targeted before the 2.0 release or later. Best, hejsan -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
The most flexible way is to be able to specify a callable that runs on each cache key before it is sent to the server. Then it's just up to Django to provide a sensible default callable, but people could override it to provide one which matches their own requirements. This is what I do in django-newcache, at least. Thanks, Eric Florenzano On Aug 4, 11:31 am, Ned Batchelder wrote: > On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote: > > > > > On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote: > > >> Updated the patchhttp://code.djangoproject.com/ticket/13795 > > > * Have you considered supporting "versioning" of keys to help with cache > > invalidation? Eric Florenzano has been doing some interesting > > experimenting along those lines in django-newcache > > (http://github.com/ericflo/django-newcache);you may want to look at the > > code and/or talk to him about working some of his ideas back into your > > key prefix proposal. At the very least, any changes we make to the > > caching backend should allow the sorts of things he's doing to keep > > working; ideally we should make those sorts of changes really easy to > > make. > > Couldn't versioning be handled by setting CACHE_KEY_PREFIX to include > some varying data like the svn revision? We've got a cache key prefix > hacked into our work environment, and I ensure my dev machine never gets > stale cache data like this: > > import time > CACHE_KEY_PREFIX = "dev-ned-%s" % time.time() > > This uses the start time of the dev server as part of the cache key so > each invocation gets fresh data. In production, you'd use something > different, but this illustrates the point. Or is there some more > elaborate versioning being considered here? > > --Ned. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model translation
Hi Hejsan -- Thanks for the reminder, and for your round-up of the solutions in the previous thread. Having used all three of the projects you looked at, and having spent a bunch of time thinking about the problem, I've come to the conclusion that nothing's really fully baked enough to consider as an addition to Django itself. So an obvious prereq is a candidate piece of software, and none of the existing tools feel all that ready. Further, I'm far from convinced that Django *needs* to ship a model translation library. I'm not convinced it's possible to do in a way that'll work for every -- or even most -- cases. I'd be a lot more interested in a patch or patches making the creating of tools like django-multilingual, -transmeta, and -modeltranslation easier, but I'd be fairly against including any one of them in Django. Jacob -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
Hi Eric - I took a look at django-newcache and I like the overall design. The whole thought behind my patch was a simple way to provide a global cache prefix since I had ran into key clashes among my projects (equivalent to your 'FLAVOR' setting). Your solution provides a much more flexible and extensible interface (especially with versioning). What are your thoughts on adding these implementations to core? Of course these additional hooks can be implemented for the other backends as well. On Aug 4, 3:11 pm, "flo...@gmail.com" wrote: > The most flexible way is to be able to specify a callable that runs on > each cache key before it is sent to the server. Then it's just up to > Django to provide a sensible default callable, but people could > override it to provide one which matches their own requirements. This > is what I do in django-newcache, at least. > > Thanks, > Eric Florenzano > > On Aug 4, 11:31 am, Ned Batchelder wrote: > > > > > On 8/4/2010 10:57 AM, Jacob Kaplan-Moss wrote: > > > > On Wed, Aug 4, 2010 at 8:06 AM, Byron wrote: > > > >> Updated the patchhttp://code.djangoproject.com/ticket/13795 > > > > * Have you considered supporting "versioning" of keys to help with cache > > > invalidation? Eric Florenzano has been doing some interesting > > > experimenting along those lines in django-newcache > > > (http://github.com/ericflo/django-newcache);youmay want to look at the > > > code and/or talk to him about working some of his ideas back into your > > > key prefix proposal. At the very least, any changes we make to the > > > caching backend should allow the sorts of things he's doing to keep > > > working; ideally we should make those sorts of changes really easy to > > > make. > > > Couldn't versioning be handled by setting CACHE_KEY_PREFIX to include > > some varying data like the svn revision? We've got a cache key prefix > > hacked into our work environment, and I ensure my dev machine never gets > > stale cache data like this: > > > import time > > CACHE_KEY_PREFIX = "dev-ned-%s" % time.time() > > > This uses the start time of the dev server as part of the cache key so > > each invocation gets fresh data. In production, you'd use something > > different, but this illustrates the point. Or is there some more > > elaborate versioning being considered here? > > > --Ned. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Project-wide cache prefix (low-level API)
On Aug 4, 1:33 pm, Byron wrote: > What are your thoughts on adding these implementations to core? I think that the callable key function would fit well in core, and debatably the flavor, version, and hashing stuff could fit well in core too. I don't really think that the thundering herd protection stuff is necessarily right for core, but that would be for others to decide. Thanks, Eric Florenzano -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
#12074 Fixed patch and added tests.
Hey, in the interest of easing myself into helping out I've picked an easy ticket to get done. http://code.djangoproject.com/ticket/12074 I've fixed the patch and added tests. Let me know if I've missed something, or done something wrong :) Cheers, David -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12074 Fixed patch and added tests.
On Wed, Aug 4, 2010 at 6:52 PM, David P. Novakovic wrote: > Hey, in the interest of easing myself into helping out I've picked an easy > ticket to get done. > http://code.djangoproject.com/ticket/12074 > I've fixed the patch and added tests. > Let me know if I've missed something, or done something wrong :) > Cheers, > David > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > Hey David, Thanks for contributing! The one reccomendation I'd make is to change the doctests into unittests. I realize a ton of the formsets tests are doctests, however in general we're trying to move away from them for a number of reasons (mostly that they're a pain in the ass to debug). If you could switch those to be unittests I'll mark it as RFC. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12074 Fixed patch and added tests.
Hey Alex, Thanks for the feedback. I actually had checked this with Russ earlier, but didn't have a response yet. I prefer TestCases and would be happy to oblige. I'll move the cases I'm testing to a TestCase in the same file and add the relevant import to regressiontests/forms/tests.py D On Thu, Aug 5, 2010 at 8:55 AM, Alex Gaynor wrote: > On Wed, Aug 4, 2010 at 6:52 PM, David P. Novakovic > wrote: > > Hey, in the interest of easing myself into helping out I've picked an > easy > > ticket to get done. > > http://code.djangoproject.com/ticket/12074 > > I've fixed the patch and added tests. > > Let me know if I've missed something, or done something wrong :) > > Cheers, > > David > > > > -- > > 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 > > django-developers+unsubscr...@googlegroups.com > . > > For more options, visit this group at > > http://groups.google.com/group/django-developers?hl=en. > > > > Hey David, > > Thanks for contributing! The one reccomendation I'd make is to change > the doctests into unittests. I realize a ton of the formsets tests > are doctests, however in general we're trying to move away from them > for a number of reasons (mostly that they're a pain in the ass to > debug). If you could switch those to be unittests I'll mark it as > RFC. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your > right to say it." -- Voltaire > "The people's good is the highest law." -- Cicero > "Code can always be simpler than you think, but never as simple as you > want" -- Me > > -- > 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 > 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 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #12074 Fixed patch and added tests.
New patch attached : *formset-as_p-as_ul-with-unittests.patch* * * At the moment it is checking the string literal, something I'm a little opposed to doing. But since it replicates the doctest and all the html seems to be html5 friendly, so it shouldn't be too much of an issue. Cheers On Thu, Aug 5, 2010 at 9:17 AM, David P. Novakovic wrote: > Hey Alex, > > Thanks for the feedback. I actually had checked this with Russ earlier, but > didn't have a response yet. I prefer TestCases and would be happy to oblige. > > I'll move the cases I'm testing to a TestCase in the same file and add the > relevant import to regressiontests/forms/tests.py > > D > > > On Thu, Aug 5, 2010 at 8:55 AM, Alex Gaynor wrote: > >> On Wed, Aug 4, 2010 at 6:52 PM, David P. Novakovic >> wrote: >> > Hey, in the interest of easing myself into helping out I've picked an >> easy >> > ticket to get done. >> > http://code.djangoproject.com/ticket/12074 >> > I've fixed the patch and added tests. >> > Let me know if I've missed something, or done something wrong :) >> > Cheers, >> > David >> > >> > -- >> > 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 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. >> > >> >> Hey David, >> >> Thanks for contributing! The one reccomendation I'd make is to change >> the doctests into unittests. I realize a ton of the formsets tests >> are doctests, however in general we're trying to move away from them >> for a number of reasons (mostly that they're a pain in the ass to >> debug). If you could switch those to be unittests I'll mark it as >> RFC. >> >> Alex >> >> -- >> "I disapprove of what you say, but I will defend to the death your >> right to say it." -- Voltaire >> "The people's good is the highest law." -- Cicero >> "Code can always be simpler than you think, but never as simple as you >> want" -- Me >> >> -- >> 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 >> 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 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
