On 8 kesä, 19:42, Carl Meyer wrote:
> Yuck. I am not at all convinced that this cure isn't worth than the
> disease. In every case where Django has introduced flattened
> pseudo-namespaces in place of Python's existing namespace system, I think
> it's come back to bite us later.
>
> How bad is it
On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote:
>
> This isn't particularly robust. The SQL string generated by a
> particular backend isn't considered part of any API, and might change
> formatting or semantics on minor updates. Some SQL is quite
> complicated and dubiously rela
Hi Andrew,
On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote:
>
> - Requiring that all fields expose a method which says how to
> reconstruct them.
>
> Essentially, it returns the positional and keyword arguments you would
> have to pass into the constructor to make the field ag
On Fri, Jun 8, 2012 at 8:45 AM, Jacob Kaplan-Moss wrote:
> Can't this be done by auto-discovering subclasses of Field
> (Field.__subclasses__)?
Unfortunately, __subclasses__() doesn't work down through the whole
hierarchy, just one level deep. So unless we plan to walk the tree to find
them all,
Hi Andrew --
Generally I'm +1, and I think I see the point pretty clearly. Just a
couple of questions:
On Thu, Jun 7, 2012 at 7:17 PM, Andrew Godwin wrote:
> - Requiring that all fields expose a method which says how to
> reconstruct them.
>
> Essentially, it returns the positional and keyword
n 8 kesä, 00:20, Andrew Godwin wrote:
> On 07/06/12 21:56, Anssi K ri inen wrote:
>
> > Is the reason for this to be able to track changes to field by
> > checking if its init arguments have changed? Why is it not possible to
> > track changes by checking the SQL output the field will generate
> >
On 8 kesä, 17:28, Luke Plant wrote:
> First, thanks so much to Aymeric and Anssi and others for the
> contribution guidelines, they're very helpful.
>
> I've got some questions that are due to my ignorance of git (I have
> managed to avoid it as something I need in daily use, I still think it's
>
First, thanks so much to Aymeric and Anssi and others for the
contribution guidelines, they're very helpful.
I've got some questions that are due to my ignorance of git (I have
managed to avoid it as something I need in daily use, I still think it's
got a brain-damaged UI...)
In this section:
ht
On 8 kesä, 13:43, Russell Keith-Magee wrote:
> That's certainly an interesting use case. However, I can think of at
> least 2 ways it could be mitigated.
>
> One way would be to treat this as part of the contract of a pluggble
> app. We've always said that an app should do one thing, and one thing
On Fri, Jun 8, 2012 at 8:53 AM, Anssi Kääriäinen
wrote:
> On 8 kesä, 02:43, Russell Keith-Magee wrote:
>> > - For documentation: It should be suggested that the example MyUser
>> > should define class Meta: swappable = 'AUTH_USER_MODEL'. Otherwise it
>> > will be synced to the database even if i
Hi Simon,
On Fri, 6 Apr 2012, Simon Meers wrote:
On 6 April 2012 07:26, Beres Botond wrote:
Isn't it this what you are trying to do?
class DocumentForm(ModelForm):
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
self.fie
On 07.06.2012, at 17:32, Luke Plant wrote:
> On 01/05/12 22:58, Ramiro Morales wrote:
>> On Tue, May 1, 2012 at 11:04 AM, Sam Simmons wrote:
>>> For app/project templates I found the docs a little misleading when they say
>>> 'Any option passed to the startapp command' will be added to the conte
12 matches
Mail list logo
