Hi Russ,
Thanks for the suggestions once again, I've thought of changing the
model for handling nested fields.
Each model can have a no of serializers, and they can be plugged in to
other serializers
and in this way nested models can be handled instead of cycling
through a tree of arbitrary depth
Hello, Jonathan
> How exactly do you want to solve dynamic inheritance? It seems that
> some people are still interested in dynamic inheritance, by using
{%
> extends variable %}. (Which is still dirty in my opinion, but
anyway.)
> Block information has to be kept somehow.
For supporting dynam
Hi,
I have a potential job opportunity for you with one of my direct clients in
San Jose, CA.
Please find the job description below.
*Job Title: Python Developer*
*Job Location: San Jose, CA*
*Duration: 9 months
Position Type: Contract*
*Job Description*
- Experience with Python
-
On Mar 21, 2011, at 12:20 PM, Jacob Kaplan-Moss wrote:
> I think we're talking slightly different concerns here: I'm mostly
> interested in the Python-side API, and to my eyes a composite field
> matches more closely what's happening on the Python side of things.
I agree 100%! I think I'm just
On Thu, Mar 31, 2011 at 09:54:49AM -0700, Christophe Pettus wrote:
> What concerns me about composite fields is that they seem to be a
> lot of Python machinery just to accomplish the goal of allowing this
> annotation. If they were super-useful in their own right, that
> would be one thing, but I
Hi group,
Currently Django has its own concept of namespacing (apps) and mostly
ignores Python modules. I'd like to propose using Python paths
wherever we can instead of apps. This would solve a lot of problems
with conflicting submodule names that plague maintainers of reusable
apps and framework
On Wed, Mar 30, 2011 at 10:55 AM, George Karpenkov
wrote:
> Oh thanks Russel!
>
> Turns out django-tagging was creating those objects via the post-save
> signal hook.
>
> http://code.djangoproject.com/ticket/8399 <- here is the ticket which
> proposes an option to disable the signal handling durin
Hi i m new to dejano?
where can i find what it is?
thanks
--
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-devel
On Thu, Mar 31, 2011 at 1:47 PM, Rajendra Pondel wrote:
> Hi i m new to dejano?
>
> where can i find what it is?
Please direct questions like this to django-us...@googlegroups.com.
You can find documentation here: http://docs.djangoproject.com/en/1.3/
--
You received this message because you a
lol
On Thu, Mar 31, 2011 at 6:47 PM, Rajendra Pondel wrote:
> Hi i m new to dejano?
>
> where can i find what it is?
>
> thanks
>
> --
> 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@
Hi,
I just started updating my custom TestSuiteRunner to Django 1.3 and it
seems that reorder_suite() is broken. At least I think it is, because
I wasn't able to deduce what it should do.
In Django 1.2, the main effect that function was flattening the
TestSuite so it only consists of TestCase ins
On Thu, Mar 31, 2011 at 2:02 PM, Patryk Zawadzki wrote:
...
> Rather simple fix to the signal handler:
>
> def on_something_saved(sender, instance, created, **kwargs):
> if not kwargs.get('raw', False):
> do_stuff()
Concur, if the handler shouldn't run on loaddata, checking raw is the
r
Hi Andrey
I haven't yet looked through all of your code, but already a little
feedback.
Remember that every dot operator requires a dictionary lookup or
getattr call. Also the [ ]-operator is another level of redirection. I
think using 'self' inside a for-loop is not a good idea. If you're
going
Another one:
Instead of:
def has_key(self,key):
for level in xrange(0,len(self._levels)) :
if self._levels[level].has_key(key) :
return True
return False
do:
def has_key(self,key):
return any((key in l) for l in self._levels)
Ony one "s
On 31/03/11 19:35, Patryk Zawadzki wrote:
> I propose the following:
> * make the internal model handling operate on full paths to the
> classes, rather than just the app names and class names
> * make the DB table names use full python paths instead of just the
> app name and the class name
>
2011/3/31 Łukasz Rekucki
> I just started updating my custom TestSuiteRunner to Django 1.3 and it
> seems that reorder_suite() is broken. At least I think it is, because
> I wasn't able to deduce what it should do.
>
> In Django 1.2, the main effect that function was flattening the
> TestSuite so
On Fri, Apr 1, 2011 at 12:01 AM, Luke Plant wrote:
> On 31/03/11 19:35, Patryk Zawadzki wrote:
>> * for 1.4 provide a number of fallback settings that can be used to
>> enable legacy behavior in each of the first three points
> but this is where it falls down, because the devil is in the details
On Wed, Mar 30, 2011 at 7:42 AM, Russell Keith-Magee
wrote:
> Barring objection, I'll try to find some time this afternoon to
> introduce the new flags.
A little later than originally intended... but I've just made these changes.
Ladies and Gentlemen start your triage!
Russ %-)
--
You rec
On 1 April 2011 00:58, Karen Tracey wrote:
> 2011/3/31 Łukasz Rekucki
>>
>> I just started updating my custom TestSuiteRunner to Django 1.3 and it
>> seems that reorder_suite() is broken. At least I think it is, because
>> I wasn't able to deduce what it should do.
>>
>> In Django 1.2, the main e
On Fri, Apr 1, 2011 at 12:35 AM, Patryk Zawadzki wrote:
> Hi group,
>
> Currently Django has its own concept of namespacing (apps) and mostly
> ignores Python modules. I'd like to propose using Python paths
> wherever we can instead of apps. This would solve a lot of problems
> with conflicting su
20 matches
Mail list logo
