Re: Django Admin New Look

['Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)]

On Sun, Aug 16, 2015, at 16:00, elky wrote:
> Hi guys,
>
> I made double work for vector icons - now we have Font and SVG icons.
> Let's choose what to use.
>
> *Quoting my comment[1] from SVG discussion here:*
>
>> Well, only week ago I was 100% happy with font icons. But after
>> Collin's comment I vote for SVG ( with svg as a source). Below I
>> listed advantages/disadvantages for both options.
>
>> *Font*
>* Customizing. Changing icon color with CSS
>* Additional 100KB (font file + css)
>* Lots of changes in CSS, HTML and JS
>* To support IE8: just add *.ttf file (+ 70KB)
>* Code Diff:
>  
> https://github.com/django/django/compare/master...elky:font-icons?diff=unified&name=font-icons
>>
>> *SVG*
>* Much less changes
>* Code is elegant - I actually *just replaced* gifs with svg in
>  CSS. No pseudo-elements. No alignment tweaks
>* 25 additional files (requests) but just 19KB in total
>* To support IE8: add fallback in CSS (since we already have gif
>  icons in the repo, my suggestion is to show them in IE8)
>* Code Diff:
>  
> https://github.com/django/django/compare/master...elky:svg-icons?diff=unified&name=svg-icons
>> And the final and main argument to choose SVG is that some apps use a
>> bit overridden Django CSS classes so font approach may cause visual
>> issues (I checked it with few CMS apps). So font approach is an extra
>> headache for app developers.

I see not mention of this later on this thread so I have to ask: Do we
have an equivalent of an `alt` if using fonts? If not, how would this be
usable by, for example, blind users?

Currently, django-flat-theme.git@flat-icons does not seem to deal
with this.

--
Hugo Osvaldo Barrera
 


Links:

  1. https://code.djangoproject.com/ticket/20597#comment:16

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1440150209.1064260.362101817.51CCCE33%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[elky]

Does 'title' attribute help in terms of accessibility? 


On Friday, 21 August 2015 14:44:02 UTC+5, Hugo Osvaldo Barrera wrote:
>
>  
>
I see not mention of this later on this thread so I have to ask:
> Do we have an equivalent of an `alt` if using fonts? If not, how would 
> this be usable by, for example, blind users?
>  
> Currently, django-flat-theme.git@flat-icons does not seem to deal with 
> this.
>  
> --
> Hugo Osvaldo Barrera
>  
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eb2b9500-f253-4845-873a-b7f7d74ccd2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The hypothetical models.MultiField: is there a rationale to avoid it ? Or could it make it into future releases ?

[Anssi Kääriäinen]

I've been thinking how we could move forward with composite fields without 
requiring too much changes in one go (large changes tend to never happen).

It seems the first step forward would be to introduce a composite field 
with the following properties:

class Foo(models.Model):
x = models.IntegerField()
y = models.IntegerField()
point = models.CompositeField((x, y))

foo.point would always return a named tuplet. You could customize the 
return value to a full fledged object by implementing a custom subclass of 
CompositeField, but Django will not have any opinion on what should happen 
when you do:
foo.x = 1
foo.y = 2
foo.point.x = 2
foo.point.x == foo.x ???

this was one of the main concerns in the DEP.

In addition, on query side you should be able to use 
.filter(point__x__lte=...), and you should be able to select 
.values('point'). We also need migrations support, and likely changes in a 
lot of other places in Django.

The draft DEPs for this feature shouldn't be used as definite resource when 
implementing this feature.

 - Anssi

On Thursday, August 20, 2015 at 6:49:11 PM UTC+3, Aron Podrigal wrote:
>
> Have a look at [1] it is a composite field implementation.
>
> [1] 
> https://groups.google.com/forum/m/#!msg/django-developers/MZUcOE6-7GY/sZkBaHvC8wgJ
> [2] 
> https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
> [3] 
> https://github.com/django/deps/blob/master/draft/0192-standalone-composite-fields.rst
> On Aug 20, 2015 10:31 AM, > wrote:
>
>>
>>
>> Le mardi 18 août 2015 01:36:28 UTC+2, Tim Graham a écrit :
>>>
>>> I think the general idea is captured in ticket #5929 -- Allow Fields to 
>>> use multiple db columns (complex datatypes). Is that the gist of your 
>>> proposal?
>>>
>>
>> Thank you for this link! It seems to discuss the same end result as what 
>> I tried to present in my first message: the ability to have a single 
>> models.Field managing an arbitrary number of DB columns under the hood.
>>
>> The proposed approach is perhaps a bit different: if I understood the 
>> ticked correctly, it proposes to change the base Field class to make it 
>> possible, when deriving from it, to manage one or several DB columns. My 
>> first idea was more to mimic the composite pattern implementation already 
>> in use with forms.MultiValueField:
>> * The models.Field *leaf* classes would still manage a single DB column.
>> * Introduce a models.MultiField class, which is a container of 
>> models.Field classes (be it leaf classes or other MultiField classes). This 
>> container would address the multiple columns indirectly, through the 
>> interface of the composing fields. And, to the eyes of the rest of the 
>> code, it would behave as a normal field, notably offering the to_python() 
>> feature, hiding the composition in its implementation details.
>>
>> I did not take time yet to try and assemble a prototype of this idea; In 
>> fact, I first wanted to confirm if such approach has not already been 
>> rejected in the past, before investing work in it ;) 
>>
>> Does it sound like a feasible/interesting idea ? Or is there a good 
>> reason not to do it / too many obvious technical complications that I did 
>> not foresee ?
>>
>> Thank you for reading,
>>   Ad
>>
>>
>>> https://code.djangoproject.com/ticket/5929
>>>
>>> On Monday, August 17, 2015 at 5:11:01 AM UTC-4, boito...@gmail.com 
>>> wrote:

 Hi,

   While implementing  our collection management system based on Django, 
 we are always excited by the extensibility of the framework.
   Most recently, we were exposed to the *forms.MultiValueField* and* 
 widgets.MultiWidget*, that seem to offer composition capacities to 
 users of the *form* and *widget* layers. Yet, we did not find any 
 equivalent in the *model* layer, which seemed a bit surprising knowing 
 that those 3 layers can work hand-in-hand very easily

   Is there a rationale to prevent implementation of such a 
 models.MultiField class ? It could be a wrapper around the composite 
 pattern in the *model* layer, allowing users to easily define custom 
 models.Field that would leverage existing *models.Field* classes, by 
 assembling them for specific purposes (while maximizing reuse).

 

 This question was also raised in Stack Overflow here: 
 http://stackoverflow.com/q/32014748/1027706. Below is a summary of the 
 question's example motivating such feature request:

 Imagine we want to store partial date in the DB (i.e., a date that is 
 either complete , or just month+year, or just year). We could model it in 
 the models layer using a *models.DateField* + a *models.CharField* 
 (this last field storing whether the date is complete, or month+year, or 
 just year).

 Now, if we move to the forms layer, let's say we want a custom 
 validation step that when a date is partial, the "unused" part of the 
>>

Re: Django Admin New Look

['Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)]

On Fri, Aug 21, 2015, at 08:06, elky wrote:
> Does 'title' attribute help in terms of accessibility?

`title` adds a tooltip, so no, not really.

--
Hugo Osvaldo Barrera
 

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1440156363.1085860.362172385.34BE66F2%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: future of QuerySet.extra()?

[Adam Johnson]

Actually I spoke too soon, I excitedly misunderstood what *RawSQL* does/doesn't 
do. Unfortunately it requires access to a column, which is not what I need. 
I'm inserting WHERE conditions like */*specialcomment*/1* - the special 
comment is translated into query rewriting, leaving *1* in the *WHERE* 
condition 
as a no-op. Unfortunately I can't see a way of injecting the raw SQL into 
the *QuerySet* using *filter* without referring to a column (required to 
make the ORM extension work without affecting queries too badly) - so 
*extra* remains the only solution here, unless I'm missing something... any 
suggestions welcome 
( https://github.com/adamchainz/django-mysql/pull/144/files ).

On Thursday, August 6, 2015 at 10:06:38 PM UTC+1, Adam Johnson wrote:
>
> I've seen *extra()* misused in cases where developers came from a 
> background of writing raw SQL and then used it rather than figuring out the 
> (often relatively simple) ORM way of doing it. This is then a big 
> maintenance burden, and the harsher warning against its use is a good idea.
>
> Also thanks for documenting *RawSQL*, didn't realize it was usable until 
> now so I've been able to get rid of some *extra()* usage in django-mysql.
>
> On Wednesday, August 5, 2015 at 1:09:30 AM UTC+1, Josh Smeaton wrote:
>>
>> You're right about that. You can aggregate over custom expressions. For 
>> aggregating over enums you should be able to use case expressions
>>
>> On Wed, 5 Aug 2015 at 05:05 Anssi Kääriäinen  wrote:
>>
>>> On Tuesday, August 4, 2015, Shai Berger  wrote:

 The classic database aggregation examples involve aggregation over 
 time: Sum
 of sales per quarter (which is, itself, a function over date); average
 temparature per month; etc. All these require group-by clauses which 
 name
 (expressions over) columns which are not FKs.


>>> The following should work:
>>>
>>>
>>>  
>>> qs.annotate(quarter=Quarter('sold_date')).values('quarter').annotate(sum=Sum('amount'))
>>>
>>> I recall some changes to how the group by expression is generated for 
>>> expressions. If I recall correctly the group by should have the expression 
>>> itself now, not the base columns of the expression.
>>>
>>> There are many similar examples involving "enum columns" -- columns with 
 a
 limited set of choices, where the choices are not instances of another 
 model.
>>>
>>>
>>> I'm not sure of this one.
>>>
>>>  - Anssi
>>>
>>> -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/django-developers/FojuU0syO8Y/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to 
>>> django-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/CALMtK1FqTkdmnXNYvjZ8U_QF9%2BWzrMCb1DDFQU5WB4SiKPX06g%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3521e31f-48a9-4576-86aa-b13227a7c29c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding Optional Better Unicode Handling for `slugify`

[Carlton]

Hi. 

This came up on Crispy Forms 
:

In [*1*]: from django.utils.text import slugify


In [*2*]: s = u'επιτέλους'


In [*3*]: slugify(s)

Out[*3*]: u''


It isn't great. 

It's been discussed before and closed as Won't Fix 
.

> The drawbacks of implementing something more complicated outweigh the 
advantages at this stage.

I'm happy with the reasoning there but was pondering how to allow users an 
easy route to implement one of the external options. 

My thought was to allow a setting to provide a callable that could be used 
instead of the default implementation. I was thinking to add this to Crispy 
Forms but it would be better at the Django level. 

The idea would be that if you provide the callable In[1] above would import 
that rather than the current Django provided implementation. 

I'm happy to take this on but, given the history, wanted to ask if it would 
be likely to be accepted?

Thanks. Carlton



-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6becd4d-63b9-499c-92a0-66e4b49cdfee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding Optional Better Unicode Handling for `slugify`

[Tim Graham]

Does 
https://github.com/django/django/commit/f8cc464452f495fce2a3d6f7494396c8f798a1e6#diff-f614fc7a7dbb2882be1692a448abd21fR413
 
work for you? :-)

On Friday, August 21, 2015 at 10:29:03 AM UTC-4, Carlton wrote:
>
> Hi. 
>
> This came up on Crispy Forms 
> :
>
> In [*1*]: from django.utils.text import slugify
>
>
> In [*2*]: s = u'επιτέλους'
>
>
> In [*3*]: slugify(s)
>
> Out[*3*]: u''
>
>
> It isn't great. 
>
> It's been discussed before and closed as Won't Fix 
> .
>
> > The drawbacks of implementing something more complicated outweigh the 
> advantages at this stage.
>
> I'm happy with the reasoning there but was pondering how to allow users an 
> easy route to implement one of the external options. 
>
> My thought was to allow a setting to provide a callable that could be used 
> instead of the default implementation. I was thinking to add this to Crispy 
> Forms but it would be better at the Django level. 
>
> The idea would be that if you provide the callable In[1] above would 
> import that rather than the current Django provided implementation. 
>
> I'm happy to take this on but, given the history, wanted to ask if it 
> would be likely to be accepted?
>
> Thanks. Carlton
>
>
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a5854628-d4e5-4d3d-aaca-23ca56fec78c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow custom "BoundFields" on forms and make BoundField public API

[Tim Graham]

While reviewing the proposed documentation for BoundField, I noticed the 
methods BoundField.as_textarea() and as_text() [1] introduced at the start 
of new forms [2]. According to the comment, their purpose is as "shortcuts 
for changing the output widget type". These methods aren't documented, and 
I don't think they should be preferred over specifying the widget on the 
form. Any objection to deprecating them? Same applies to as_hidden(), 
except that it's used by BoundField elsewhere, so we can't remove it. We 
could add an underscore prefix to show that it's "private", but I don't see 
much advantage to this.

[1] 
https://github.com/django/django/blob/d3bc86ec11bb22f06b5e30fac891ef3e43f82a6d/django/forms/forms.py#L587-L601
[2] 
https://github.com/django/django/commit/4d596a1f6443eaf5d18d70a18aaac25030c7fc81#diff-de8d446d202490f4ac045923ad6fcfb7R98

On Thursday, August 13, 2015 at 6:36:34 PM UTC-4, Preston Timmons wrote:
>
> Yes I know that you can access the Field instance but it wouldn't be 
>> possible to do {{ field.field.city }} since a Field is not supposed to 
>> have any data stored with it. 
>>
>
> This makes sense to me. Feel free to make a ticket and attach your PR once 
> it's ready for review.
>
> Preston
>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67f69d17-fb9a-472d-8d5b-fb5ba8f11c8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Allow custom "BoundFields" on forms and make BoundField public API

['Moritz Sichert' via Django developers (Contributions to Django itself)]

I replied to your comment on pr 5123 on github [1] but it seems to be
buried under "Show outdated diff" so here it is again:

I agree that as_text() and as_textarea() are not needed so I will remove
them from the docs.

There is a use case for as_widget() though. In one of my projects I have
a template filter that is called add_class and I use it like this:

{{ my_form.my_field|add_class:'class-added-to-input-field' }}

It uses the attrs argument to as_widget() to easily add the class
attribute. That wouldn't be possible like that if the code was just
private inside __str__().
Although this use case may be invalidated by the upcoming template based
widget rendering.

I'm not sure about as_hidden(). I personally never used it, since you
can easily emulate it with html_name but I'm sure there are a few people
using it.


[1] https://github.com/django/django/pull/5123#discussion_r37645967


Am 21.08.2015 um 17:34 schrieb Tim Graham:
> While reviewing the proposed documentation for BoundField, I noticed the
> methods BoundField.as_textarea() and as_text() [1] introduced at the
> start of new forms [2]. According to the comment, their purpose is as
> "shortcuts for changing the output widget type". These methods aren't
> documented, and I don't think they should be preferred over specifying
> the widget on the form. Any objection to deprecating them? Same applies
> to as_hidden(), except that it's used by BoundField elsewhere, so we
> can't remove it. We could add an underscore prefix to show that it's
> "private", but I don't see much advantage to this.
> 
> [1]
> https://github.com/django/django/blob/d3bc86ec11bb22f06b5e30fac891ef3e43f82a6d/django/forms/forms.py#L587-L601
> [2]
> https://github.com/django/django/commit/4d596a1f6443eaf5d18d70a18aaac25030c7fc81#diff-de8d446d202490f4ac045923ad6fcfb7R98
> 
> On Thursday, August 13, 2015 at 6:36:34 PM UTC-4, Preston Timmons wrote:
> 
> Yes I know that you can access the Field instance but it
> wouldn't be
> possible to do {{ field.field.city }} since a Field is not
> supposed to
> have any data stored with it.
> 
> 
> This makes sense to me. Feel free to make a ticket and attach your
> PR once it's ready for review.
> 
> Preston
> 
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/-Bbi8vg5c9s/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com
> .
> To post to this group, send email to django-developers@googlegroups.com
> .
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/67f69d17-fb9a-472d-8d5b-fb5ba8f11c8d%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55D74670.1070704%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Improving MSSQL and Azure SQL support on Django

[Meet Bhagdev]

Hi Django Committers,

 

My name is Meet Bhagdev, I work in the Database Systems engineering team at 
Microsoft in Seattle, WA. My focus is the APIs used to connect to and 
use Azure SQL Database and SQL Server (MSSQL). Example APIs are ODBC, JDBC, 
ADO.NET, etc.

 

We’d love for Django users to have a solid option to use MSSQL and Azure 
SQL if they wish, and it would be great to make this option a reality. Our 
goal is to partner with committers like yourself to bring first-class 
support for MSSQL to Django. We want to bring the benefits of Django to 
millions of existing MSSQL and Azure SQL customers as well as folks that 
would like to evaluate us as a database option for Django.

 

I have been in touch with Tim Graham and Russell Keith-Magee related to us 
building such support. We are prepared to 
make the engineering investment required on our end and to work with the 
Django community to make this happen, the right way. We are willing to do 
all the heavy lifting, but we do need your help and guidance.

 

At Microsoft we have an existing program for bringing partners and 
eco-system developers to Seattle, WA, all expenses paid, and we’d like to 
extend this to the Django committers. This would be a great way to get 
started. We would love to get a group of you here during our October 
workshop. The idea is to get developers from both sides to meet and learn 
from each other—Django and Microsoft.

 

Please reach out me at me...@microsoft.com or give me a call on +1 425 722 
5342 if you would like to attend. Would love to get you more details.

 

Sincerely,

Meet Bhagdev | Linkedin 
 | Github 


 

P.S. This is not a sales pitch; we are excited about bringing the benefits 
of Django to our customers.:)

 

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7edd97f0-dcd9-4178-8398-b29429a52e78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding Optional Better Unicode Handling for `slugify`

[Carlton]

Why sir, I think it might. :-)

Thanks. 

On Friday, 21 August 2015 16:37:02 UTC+2, Tim Graham wrote:
>
> Does 
> https://github.com/django/django/commit/f8cc464452f495fce2a3d6f7494396c8f798a1e6#diff-f614fc7a7dbb2882be1692a448abd21fR413
>  
> work for you? :-)
>
> On Friday, August 21, 2015 at 10:29:03 AM UTC-4, Carlton wrote:
>>
>> Hi. 
>>
>> This came up on Crispy Forms 
>> :
>>
>> In [*1*]: from django.utils.text import slugify
>>
>>
>> In [*2*]: s = u'επιτέλους'
>>
>>
>> In [*3*]: slugify(s)
>>
>> Out[*3*]: u''
>>
>>
>> It isn't great. 
>>
>> It's been discussed before and closed as Won't Fix 
>> .
>>
>> > The drawbacks of implementing something more complicated outweigh the 
>> advantages at this stage.
>>
>> I'm happy with the reasoning there but was pondering how to allow users 
>> an easy route to implement one of the external options. 
>>
>> My thought was to allow a setting to provide a callable that could be 
>> used instead of the default implementation. I was thinking to add this to 
>> Crispy Forms but it would be better at the Django level. 
>>
>> The idea would be that if you provide the callable In[1] above would 
>> import that rather than the current Django provided implementation. 
>>
>> I'm happy to take this on but, given the history, wanted to ask if it 
>> would be likely to be accepted?
>>
>> Thanks. Carlton
>>
>>
>>
>>

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d2217561-67b8-42aa-98c6-f2d4ef602b3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.