Re: Goodbye, Malcolm

[Satinderpal Singh]

On Tue, Mar 19, 2013 at 10:31 PM, Jacob Kaplan-Moss  wrote:
> Hello fellow Djangonauts,
>
> We have difficult news: Malcolm Tredinnick has passed away.
>
> Malcolm was a long-time contributor to Django, a model community member,
> a brilliant mind, and a friend. His contributions to Django — and to
> many other open source projects — are nearly impossible to enumerate.
> Many on the core Django team had their first patches reviewed by him;
> his mentorship enriched us. His consideration, patience, and dedication
> will always be an inspiration to us.
>
> To say we'll miss him is an understatement.
>
> Our thoughts are with Malcolm's friends, colleagues, and family at this
> difficult time.
>
> This came as quite a shock, and we're still sorting out details. We'll
> update our blog,
> https://www.djangoproject.com/weblog/2013/mar/19/goodbye-malcolm/,
> once we know the details of how you can express your condolences to
> Malcolm's friends and family.

Rest in Peace

> — The Django Core Team
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 
Satinderpal Singh
http://devplace.in/~satinder/wordpress/
http://satindergoraya.blogspot.in/
http://satindergoraya91.blogspot.in/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Goodbye, Malcolm

[mugisha moses]

RIP Malcolm

On Tue, Mar 19, 2013 at 10:25 PM, Leon Matthews  wrote:

> On 20 March 2013 06:01, Jacob Kaplan-Moss  wrote:
> > We have difficult news: Malcolm Tredinnick has passed away.
>
> What a shock.  Malcolm was a great guy, and a huge asset to our
> community.  I had the pleasure of hearing him talk in Wellington.
>
> He will be missed...
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Ian Kelly]

On Tue, Mar 19, 2013 at 12:26 PM, Felipe Prenholato
 wrote:
> Hi Julian. My 2 cents.
>
> What you want is:
>
> urlpatterns = patterns('',
> url_fallthrought(r'^(?P[-\w]+)$',
> views=[(ProductView.as_view(),
>CategorView.as_view(),
>OccasionView.as_view())], name="my_super_url"),)

def view_chain(views):
def inner(*args, **kwargs):
for view in views:
try:
return view(*args, **kwargs)
except Http404:
pass
raise Http404
return inner

urlpatterns = patterns('',
(r'^(?P[-\w]+)$',
 view_chain([ProductView.as_view(),
 CategoryView.as_view(),
 OccasionView.as_view()]), name="my_super_url"),
)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Felipe Prenholato]

Hi Julian. My 2 cents.

What you want is:

urlpatterns = patterns('',
url_fallthrought(r'^(?P[-\w]+)$',
views=[(ProductView.as_view(),
   CategorView.as_view(),
   OccasionView.as_view())], name="my_super_url"),)

But you know that we don't have it. To make it works you will need to do
some loop on views and answer with first that not raises 404, and than
return it response. To be better you just run get_object() of view and
after return get() or post(). It should be done on object (wrapper view?)
that url_fallthrought returns. This will be very very similar to what you
will do if use a wrapper view... to not say same code.

This functionality will be used mostly by Django based CRMs, Blogs and
E-commerce solutions, lot of people of course, but in my opinion is so
simple to do that don't need to be in Django itself.

Att,

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2013/3/19 Adrian Holovaty 

> On Mon, Mar 18, 2013 at 10:23 AM, julianb  wrote:
> > Well, at the moment, as far as I am aware, you can't. The first URL will
> > match everything all the time, not giving the other views a chance to
> kick
> > in.
> >
> > So I propose some kind of URL fallthrough. The view could do
> >
> > raise UrlNotMatched
> >
> > and the dispatcher goes to the next possible matching view.
> >
> > Would that be good? Any thoughts?
>
> Hi Julian,
>
> I'd rather not add this to the framework, as it's already possible
> with a "wrapper" view (as others have suggested). And on a more
> theoretical level, it introduces more coupling between URL patterns
> and views.
>
> Adrian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: ModelForm API improvements

[Felipe Prenholato]

+1. (+10 if I can)

This kind of customization will help community to integrate many
css/js/html frameworks into Django with custom apps.

Felipe 'chronos' Prenholato.
Linux User nº 405489
Home page: http://devwithpassion.com | http://chronosbox.org/blog
GitHub: http://github.com/chronossc/ | Twitter: http://twitter.com/chronossc


2013/3/9 Aaron Merriam 

> +1
>
> This would be great.
>
>
> On Thursday, March 7, 2013 12:42:29 PM UTC-7, Bruno Renié wrote:
>>
>> Hello,
>>
>> There was some discussion on the current limitations of the ModelForm
>> API in the past couple of days on IRC, I'd like to make a proposal to
>> address some of them.
>>
>> I wrote django-floppyforms, a library that lets you render forms using
>> templates instead of python code. It behaves exactly like the Django
>> forms library, the only difference is the import path. Import
>> `floppyforms as forms` and when you render a form, the HTML code comes
>> from templates.
>>
>> There is still a limitation with ModelForms: since there is no way to
>> globally override the model field -> form field/widget mapping since
>> ModelForms fields come from the model definition. I documented this
>> here:
>>
>> http://django-floppyforms.**readthedocs.org/en/latest/**
>> differences.html#modelforms
>>
>> It is possible to override widgets using the Meta.widgets dict but not
>> in a way that would switch all the ModelForm's fields to
>> template-based widgets automatically. The idea is to have custom
>> ModelForm subclasses with specific strategy on the model field -> form
>> field mapping.
>>
>> This is currently possible using something called `formfield_callback`
>> as a ModelForm class attribute: it is simply a callback that takes a
>> db field and returns a form field. But this callback is a) private and
>> b) limited: it gets lost in the inheritance chain as described in
>> ticket #12915:
>>
>> https://code.djangoproject.**com/ticket/12915
>>
>> A discussion thread was started a couple of days ago for a design
>> decision about formfield_callback: should we consider its behaviour as
>> buggy or leave it as it is? In fact formfield_callback is only used by
>> the admin, which has custom widgets for pretty much every db field.
>> This customization is done using the following methods and attributes
>> (all in django/contrib/admin/options.**py):
>>
>> FORMFIELD_FOR_DBFIELD_DEFAULTS
>> ModelAdmin.formfield_overrides
>> ModelAdmin.formfield_for_**dbfield(db_field, **kwargs)
>> ModelAdmin.formfield_for_**choicefield(db_field, **kwargs)
>> ModelAdmin.formfield_for_**foreignkey(db_field, **kwargs)
>> ModelAdmin.formfield_for_**manytomany(db_field, **kwargs)
>>
>> In most cases those methods end up calling formfield() on the DB field
>> object, with some arguments for customizing the field class (wrongly
>> called `form_class`) and its constructor arguments (widget, label,
>> help_text, required, etc).
>>
>> The arguments to db_field.formfield() are passed via the
>> formfield_callback function I mentioned earlier.
>>
>> My proposal is to move that field customization API from the
>> ModelAdmin class back to ModelForm:
>>
>> * Move formfield_for_* to ModelForm and document them as public APIs
>> * Deprecate `formfield_callback`
>> * Write an AdminModelForm class that implements all the admin form
>> fields and widgets customization
>> * Modify ModelAdmin to make use of that base class
>> * (maybe?) deprecate ModelForm.Meta.widgets in favor of something
>> similar to the admin's formfield_overrides, which is more generic.
>>
>> I see the following advantages to this:
>>
>> * This would allow people to have "site-wide" fields/widgets
>> overrides, which is a feature that the admin is already proving
>> useful. Write a nice date picker once, register it for all your
>> DateFields globally.
>>
>> * Maintainers of form libraries can ship a base ModelForm class that
>> implements custom fields/widgets while keeping API compatibility with
>> Django.
>>
>> Backwards-compatibility shouldn't be an issue as this touches only a
>> couple of ModelAdmin methods. Regarding formfield_callback, despite it
>> being a private API I'm not sure it can be removed safely. There are
>> references to it on StackOverflow and on the Django bug tracker.
>>
>> I'm happy to work on a patch if core devs agree to accept this. Thoughts?
>>
>> Regards,
>> Bruno
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 

Re: Goodbye, Malcolm

[Carlos Aguilar]

+1

El martes, 19 de marzo de 2013, Jacob Kaplan-Moss escribió:

> Hello fellow Djangonauts,
>
> We have difficult news: Malcolm Tredinnick has passed away.
>
> Malcolm was a long-time contributor to Django, a model community member,
> a brilliant mind, and a friend. His contributions to Django — and to
> many other open source projects — are nearly impossible to enumerate.
> Many on the core Django team had their first patches reviewed by him;
> his mentorship enriched us. His consideration, patience, and dedication
> will always be an inspiration to us.
>
> To say we'll miss him is an understatement.
>
> Our thoughts are with Malcolm's friends, colleagues, and family at this
> difficult time.
>
> This came as quite a shock, and we're still sorting out details. We'll
> update our blog,
> https://www.djangoproject.com/weblog/2013/mar/19/goodbye-malcolm/,
> once we know the details of how you can express your condolences to
> Malcolm's friends and family.
>
> — The Django Core Team
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
Carlos Aguilar
Consultor Hardware y Software
DWD
http://www.dwdandsolutions.com
http://www.houseofsysadmin.com
Cel: +50378735118
USA: (301) 337-8541

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Goodbye, Malcolm

[Jacob Kaplan-Moss]

Hello fellow Djangonauts,

We have difficult news: Malcolm Tredinnick has passed away.

Malcolm was a long-time contributor to Django, a model community member,
a brilliant mind, and a friend. His contributions to Django — and to
many other open source projects — are nearly impossible to enumerate.
Many on the core Django team had their first patches reviewed by him;
his mentorship enriched us. His consideration, patience, and dedication
will always be an inspiration to us.

To say we'll miss him is an understatement.

Our thoughts are with Malcolm's friends, colleagues, and family at this
difficult time.

This came as quite a shock, and we're still sorting out details. We'll
update our blog,
https://www.djangoproject.com/weblog/2013/mar/19/goodbye-malcolm/,
once we know the details of how you can express your condolences to
Malcolm's friends and family.

— The Django Core Team

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Adrian Holovaty]

On Mon, Mar 18, 2013 at 10:23 AM, julianb  wrote:
> Well, at the moment, as far as I am aware, you can't. The first URL will
> match everything all the time, not giving the other views a chance to kick
> in.
>
> So I propose some kind of URL fallthrough. The view could do
>
> raise UrlNotMatched
>
> and the dispatcher goes to the next possible matching view.
>
> Would that be good? Any thoughts?

Hi Julian,

I'd rather not add this to the framework, as it's already possible
with a "wrapper" view (as others have suggested). And on a more
theoretical level, it introduces more coupling between URL patterns
and views.

Adrian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[Tom Evans]

On Mon, Mar 18, 2013 at 3:23 PM, julianb  wrote:
> Hi,
>
> imagine the following use case:
>
> You build an online store where you have sorted products into several
> categories and maybe associated an occasion. Now you want to build URLs. So
> the URL schema that all of the store's owners agree on is:
>
> //
> //
> //
>

Really straying into user talk now...

If you have a heterogeneous hierarchy of objects that have slugs, and
you wish to look up arbitrary objects by slug, perhaps just go the
whole hog, add a SluggedItem model with a generic foreign key, and a
view that fetches items from their slugs and dispatches to the
appropriate view.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Note of thanks to the release-managers

[Tim Chase]

I just read through the novel that is
docs/internals/howto-release-django.txt and I have a new level of
respect for just what happens when a release is made.  That's a LOT
of work.

So thanks to those that wade through the whole process!

-tkc


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: URL dispatcher fallthrough?

[julianb]

A single pattern with a catchall view is certainly a way to go. However, I 
really does not help to see what the views do. And if you have different 
views with different arguments, you cannot do your regex explicitly.
You are right that it is non-obvious when the view itself has to invoke the 
fallthrough. So I'm thinking it would be better in the urlpatterns itself. 
Then it is explicitly clear, rather than having some catchall magic do-all 
views and patterns. Right?

On Monday, March 18, 2013 4:44:19 PM UTC+1, Andrew Ingram wrote:
>
> The approach we take at work is to have a view that wraps around the 
> product, category and occasion views and takes care of the fallthrough 
> logic. I'm not a fan of this approach, because it means that you can't just 
> look at the urlconf and see which pattern maps to which view function. On 
> the other hand, I don't think your solution would solve this either, you'd 
> end up having 3 patterns that could all match, making it non-obvious what 
> the behaviour is.
>
> Obviously the ideal solution is to scope URLs correctly to avoid all this 
> in the first place, but I've found that in the real world this is easier 
> said than done. So it would be nice to have an idiomatic solution.
>
> An alternative might be a kwarg on the url function, such as 
> 'fallthrough_on_404'. But it all feels a bit hackish to me :/
>
> Regards,
> Andy
>
>
> On 18 March 2013 15:23, julianb  wrote:
>
>> Hi,
>>
>> imagine the following use case:
>>
>> You build an online store where you have sorted products into several 
>> categories and maybe associated an occasion. Now you want to build URLs. So 
>> the URL schema that all of the store's owners agree on is:
>>
>> //
>> //
>> //
>>
>> Look simple.
>>
>> Because product slugs should generally be different to category slugs and 
>> occasions, you expect no clashes here. And you don't want to bloat the URLs 
>> by putting product/ and category/ in there. And you also do not want to 
>> resort making it look cryptic by having just /p// and so on.
>> Then it comes to Django. How do you do that?
>>
>> Well, at the moment, as far as I am aware, you can't. The first URL will 
>> match everything all the time, not giving the other views a chance to kick 
>> in.
>>
>> So I propose some kind of URL fallthrough. The view could do
>>
>> raise UrlNotMatched
>>
>> and the dispatcher goes to the next possible matching view.
>>
>> Would that be good? Any thoughts?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, 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?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

[Florian Apolloner]

Hi,

On Tuesday, March 19, 2013 8:21:05 AM UTC+1, Shai Berger wrote:
>
> Is there any interest in fixing this, specifically?
>

Sure, I just don't have to knowledge to debug cx_Oracle, so if you are up 
to please. Although I think the endresult would most likely be a patch to 
cx_Oracle and not Django. 

Regards,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

[Shai Berger]

On Monday 18 March 2013, Shai Berger wrote:
> Hi,
> 
> Reviving an oldish thread:
> 
> On Tuesday 26 February 2013 00:35:10 Florian Apolloner wrote:
> > it would be of great help
> > if you could setup cx_Oracle on an Ubuntu 11.10 (I have to double check
> > that tomorrow, don't have my ssh keys with me currently) 64 bit system
> > with python 3.3 and see if you can get the tests running or if you also
> > get a segfault.
> 
Segfault after ~3850 tests (including several errors and failures, but that's 
minor).

Is there any interest in fixing this, specifically? My guess is that the 
intersection between Oracle users and Python3 users (within Django users) is 
pretty slim, and further, Ubuntu 11.10 (a non-current, non-LTS release) is  a 
prime target for neither Oracle (stable-liking) users nor Python3 (new-
preferring) users.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.