Re: [GSoC 2013] How i can start in idea group of GSoC?

[Russell Keith-Magee]

On Tue, Apr 23, 2013 at 7:12 AM, Mário Idival  wrote:

> Hello Bro's,
> I dont know how i can enter in group of idea list, posted in GSoC... Today
> is day start for enter in this groups for development?
>
> Hi Mário,

A starting list of ideas for Django GSoC projects can be found on our wiki:

https://code.djangoproject.com/wiki/SummerOfCode2013

However, this is just a starting point - you'll need to flesh out these
ideas into a full project proposal.

Once you've got a project proposal, or if you're looking for feedback on an
idea that you have, mail the details to this list and we'll give you some
feedback.

Yours,
Russ Magee %-)

-- 
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.

[GSoC 2013] How i can start in idea group of GSoC?

[Mário Idival]

Hello Bro's,
I dont know how i can enter in group of idea list, posted in GSoC... Today 
is day start for enter in this groups for development?

-- 
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 for simplifying part of the GCBV API slightly.

[Andrew Ingram]

The original use case for pk_url_kwarg and slug_url_kwargs was something
like this:

/(?P[\w-]*)/ - DetailView
/(?P[\w-]*)/another-resource/ - Scoped ListView
/(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped
DetailView

In this case, the Scoped ListView and Scoped DetailView would both inherit
a mixin that overrides get_queryset(), and the Scope DetailView would just
set "slug_url_kwargs = 'another_slug'"

I've used some variant of this pattern on almost every project I've been
involved with that utilises class-based views, including some frameworks,
so I don't think this edge case is quite as edgy as it might seem at first.

However, I do agree that your simplification is an improvement. I've done a
lot with CBVs since I first suggested the URL kwarg overrides, and I think
it's better to have less configurable fields and focus instead on having
good entry points into customising the classes through method overrides.


Andy



On 22 April 2013 13:33, Tom Christie  wrote:

> Hi Calvin,
>
> I can think of a few reasons.
>> - you've changed models or fields internally through migrations, but need
>> to continue supporting old URLs.
>> - you don't like the internal name to be exposed
>> - you have different models but want to expose a consistent URL pattern.
>
>
> Those attributes control the URL kwargs that are used in the regex, we're
> not talking about URL query parameters or anything else that's visible to
> the end-user.  Internal names aren't being exposed anywhere, and there'd be
> no issue with updating field names and continuing to support the URLs that
> reference them.
>
> Having said that, you're probably correct that I've overstated point (1) -
> There might be some circumstances where the developer would prefer to use
> 'slug' as the regex kwarg, but look up against a differently named model
> field.  I'd still think that there's a very strong argument to be made that
> we could consider that a corner case that requires overriding `get_object`,
> in exchange for having a simpler API for the standard case.
>
> There would of course be other alternatives such as using both
> `lookup_field` and `lookup_kwarg` with the later defaulting to the same as
> the former if unset, but I'm not wild about something like that given that
> the intention of this proposal is to try to slightly slim down an aspect of
> the API.
>
>
> On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote:
>>
>>
>> On Apr 22, 2013 7:15 AM, "Tom Christie"  wrote:
>> >
>> > I'd be interested to know what you folks think of this proposal.
>> >
>> > SingleObjectMixin currently exposes these three attributes and one
>> method all dealing with queryset filter arguments...
>> >
>> > * pk_url_kwarg = 'pk'
>> > * slug_field = 'slug'
>> > * slug_url_kwarg = 'slug'
>> > * get_slug_field()
>> >
>> > I was wondering if it would be worth considering simplifying the API
>> somewhat, by moving those three attributes, and that method, into a
>> PendingDeprecation state, and replacing their usage with a single attribute
>> instead, that is used both as the URL kwarg, and as the queryset filter.
>> >
>> > * lookup_field = 'pk'
>> >
>> > That'd (eventually) lead to a simpler get_object implementation
>> internally, and (immediately) present a slightly nicer, simpler API.
>> >
>> > It'd be marginally different in that slug based lookups would require
>> an explicit `lookup_field = 'slug'` to be added to the view,
>> > and also in that it wouldn't handle the case of `slug_field` being set
>> to a different value from `slug_url_kwarg`.
>> >
>> > Personally I don't see the later being an issue as:
>> >
>> > 1. It's not clear to me why you'd ever *need* to use a URL kwarg that's
>> not the same as the filter arg.
>>
>> I can think of a few reasons.
>> - you've changed models or fields internally through migrations, but need
>> to continue supporting old URLs.
>> - you don't like the internal name to be exposed
>> - you have different models but want to expose a consistent URL pattern.
>>
>> > 2. If it's really something you need to do, then overriding get_object
>> is still really simple, as well as being nice and explicit...
>> >
>> > get_object(self, queryset):
>> > if queryset is None:
>> > queryset = self.get_queryset()
>> > return get_object_or_404(queryset, ...) # whatever custom
>> lookup behavior you need.
>> >
>> > To me, the main trade-off seems to be - Is the resulting API enough of
>> an improvement to be worth the change?
>> >
>> > Any opinions?
>> >
>> >   Tom
>> >
>> > As an aside, is the discussion group considered the correct place for
>> API-changing proposals like this, or should I just raise them straight to
>> the ticket tracker?
>> >
>> > --
>> > 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 

Re: Proposal for simplifying part of the GCBV API slightly.

[Tom Christie]

Hi Calvin,

I can think of a few reasons.
> - you've changed models or fields internally through migrations, but need 
> to continue supporting old URLs.
> - you don't like the internal name to be exposed
> - you have different models but want to expose a consistent URL pattern.


Those attributes control the URL kwargs that are used in the regex, we're 
not talking about URL query parameters or anything else that's visible to 
the end-user.  Internal names aren't being exposed anywhere, and there'd be 
no issue with updating field names and continuing to support the URLs that 
reference them.

Having said that, you're probably correct that I've overstated point (1) - 
There might be some circumstances where the developer would prefer to use 
'slug' as the regex kwarg, but look up against a differently named model 
field.  I'd still think that there's a very strong argument to be made that 
we could consider that a corner case that requires overriding `get_object`, 
in exchange for having a simpler API for the standard case.

There would of course be other alternatives such as using both 
`lookup_field` and `lookup_kwarg` with the later defaulting to the same as 
the former if unset, but I'm not wild about something like that given that 
the intention of this proposal is to try to slightly slim down an aspect of 
the API.


On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote:
>
>
> On Apr 22, 2013 7:15 AM, "Tom Christie"  
> wrote:
> >
> > I'd be interested to know what you folks think of this proposal.
> >
> > SingleObjectMixin currently exposes these three attributes and one 
> method all dealing with queryset filter arguments...
> >
> > * pk_url_kwarg = 'pk'
> > * slug_field = 'slug'
> > * slug_url_kwarg = 'slug'
> > * get_slug_field()
> >
> > I was wondering if it would be worth considering simplifying the API 
> somewhat, by moving those three attributes, and that method, into a 
> PendingDeprecation state, and replacing their usage with a single attribute 
> instead, that is used both as the URL kwarg, and as the queryset filter.
> >
> > * lookup_field = 'pk'
> >
> > That'd (eventually) lead to a simpler get_object implementation 
> internally, and (immediately) present a slightly nicer, simpler API.
> >
> > It'd be marginally different in that slug based lookups would require an 
> explicit `lookup_field = 'slug'` to be added to the view,
> > and also in that it wouldn't handle the case of `slug_field` being set 
> to a different value from `slug_url_kwarg`.
> >
> > Personally I don't see the later being an issue as:
> >
> > 1. It's not clear to me why you'd ever *need* to use a URL kwarg that's 
> not the same as the filter arg.
>
> I can think of a few reasons.
> - you've changed models or fields internally through migrations, but need 
> to continue supporting old URLs.
> - you don't like the internal name to be exposed
> - you have different models but want to expose a consistent URL pattern. 
>
> > 2. If it's really something you need to do, then overriding get_object 
> is still really simple, as well as being nice and explicit...
> >
> > get_object(self, queryset):
> > if queryset is None:
> > queryset = self.get_queryset()
> > return get_object_or_404(queryset, ...) # whatever custom lookup 
> behavior you need.
> >
> > To me, the main trade-off seems to be - Is the resulting API enough of 
> an improvement to be worth the change?
> >
> > Any opinions?
> >
> >   Tom
> >
> > As an aside, is the discussion group considered the correct place for 
> API-changing proposals like this, or should I just raise them straight to 
> the ticket tracker?
> >
> > -- 
> > 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: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[LittleQ@NCCU, Taiwan]

On Sunday, April 21, 2013 6:54:22 PM UTC+8, Florian Apolloner wrote:
>
> Hi,
>
> aside from what Russell already pointed out, I would like to add a few 
> points:
>
> * You list "Refactor for Expandability" as last on your schedule. I think 
> it should be at the start, eg compare different solutions like GAE, heroku, 
> Gondor, find a common subset and then write the backends accordingly. I 
> fear that if you do this the other way around you will have to throw away 
> most of the code for heroku/GAE and rewrite it.
>

thanks for the advise, I will try it :D
 

>
> * Regarding storage stuff, you say "I chose Google Cloud Storage according 
> to the networking speed and authorization flow will be easier than using 
> other storage service such as S3.". Personally I don't think it's wise to 
> choose the easier storage (network speed should be no concern here 
> anyways), your API should be able to allow to hook in the more complex 
> authorization flow too, what would be a better way to test your API than 
> using S3 :)
>

okay, I think I can do that, could you provide some storage providers 
besides S3 and Google Storage? I don't know what are popular now, but if 
there's recommendations, I will try to make it.
 

>
> All in all this proposal imo tries to address way to much and focuses to 
> much on Google. It would be more useful to lay the groundwork for an API 
> instead. That said, did you get in contact with the project authors about 
> mentorship (eg are they interested and do have the time for it), I am 
> pretty sure none of the core devs uses django-deployer, so mentoring it 
> would be a bit suboptimal.


I'm so sorry about that, LOL, they are the services which I'm most familiar 
with, but I will consider other solutions or workaround, any recommendation 
please feel free to provide me, I will appreciate for that.

And about the mentoring, I contacted the owner of django-deployer and he 
said he would like to help and already sent the application for begin a 
mentor of django, is that working?

thanks for the advise, now I'm going to modify my proposal first, and try 
to make it more generic and detailed : )

have a nice day,
- Colin 
 

>
> 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: Proposal for simplifying part of the GCBV API slightly.

[Calvin Spealman]

On Apr 22, 2013 7:15 AM, "Tom Christie"  wrote:
>
> I'd be interested to know what you folks think of this proposal.
>
> SingleObjectMixin currently exposes these three attributes and one method
all dealing with queryset filter arguments...
>
> * pk_url_kwarg = 'pk'
> * slug_field = 'slug'
> * slug_url_kwarg = 'slug'
> * get_slug_field()
>
> I was wondering if it would be worth considering simplifying the API
somewhat, by moving those three attributes, and that method, into a
PendingDeprecation state, and replacing their usage with a single attribute
instead, that is used both as the URL kwarg, and as the queryset filter.
>
> * lookup_field = 'pk'
>
> That'd (eventually) lead to a simpler get_object implementation
internally, and (immediately) present a slightly nicer, simpler API.
>
> It'd be marginally different in that slug based lookups would require an
explicit `lookup_field = 'slug'` to be added to the view,
> and also in that it wouldn't handle the case of `slug_field` being set to
a different value from `slug_url_kwarg`.
>
> Personally I don't see the later being an issue as:
>
> 1. It's not clear to me why you'd ever *need* to use a URL kwarg that's
not the same as the filter arg.

I can think of a few reasons.
- you've changed models or fields internally through migrations, but need
to continue supporting old URLs.
- you don't like the internal name to be exposed
- you have different models but want to expose a consistent URL pattern.

> 2. If it's really something you need to do, then overriding get_object is
still really simple, as well as being nice and explicit...
>
> get_object(self, queryset):
> if queryset is None:
> queryset = self.get_queryset()
> return get_object_or_404(queryset, ...) # whatever custom lookup
behavior you need.
>
> To me, the main trade-off seems to be - Is the resulting API enough of an
improvement to be worth the change?
>
> Any opinions?
>
>   Tom
>
> As an aside, is the discussion group considered the correct place for
API-changing proposals like this, or should I just raise them straight to
the ticket tracker?
>
> --
> 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.

Proposal for simplifying part of the GCBV API slightly.

[Tom Christie]

I'd be interested to know what you folks think of this proposal.

SingleObjectMixin currently exposes these three attributes and one method 
all dealing with queryset filter arguments...

* pk_url_kwarg = 'pk'
* slug_field = 'slug'
* slug_url_kwarg = 'slug'
* get_slug_field()

I was wondering if it would be worth considering simplifying the API 
somewhat, by moving those three attributes, and that method, into a 
PendingDeprecation state, and replacing their usage with a single attribute 
instead, that is used both as the URL kwarg, and as the queryset filter.

* lookup_field = 'pk'

That'd (eventually) lead to a simpler get_object implementation internally, 
and (immediately) present a slightly nicer, simpler API.

It'd be marginally different in that slug based lookups would require an 
explicit `lookup_field = 'slug'` to be added to the view,
and also in that it wouldn't handle the case of `slug_field` being set to a 
different value from `slug_url_kwarg`.

Personally I don't see the later being an issue as:

1. It's not clear to me why you'd ever *need* to use a URL kwarg that's not 
the same as the filter arg.
2. If it's really something you need to do, then overriding get_object is 
still really simple, as well as being nice and explicit...

get_object(self, queryset):
if queryset is None:
queryset = self.get_queryset()
return get_object_or_404(queryset, ...) # whatever custom lookup 
behavior you need.

To me, the main trade-off seems to be - Is the resulting API enough of an 
improvement to be worth the change?

Any opinions?

  Tom

As an aside, is the discussion group considered the correct place for 
API-changing proposals like this, or should I just raise them straight to 
the ticket tracker?

-- 
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: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[LittleQ@NCCU, Taiwan]

On Sunday, April 21, 2013 12:26:30 PM UTC+8, Russell Keith-Magee wrote:
>
> Hi Colin,
>
> I've taken a look at your proposal, and I've got some concerns.
>
> Firstly, I'm not familiar with Django-deploy; but from a quick inspection 
> of the project page it doesn't appear that anyone in the Django core team 
> is on the committee list. In order for you to have this proposal accepted 
> as part of the GSoC, you'll need to secure agreement from the project 
> maintainers of Django-deploy that they want the help your offering, that 
> your project proposal is sound, and that they're willing to commit to 
> applying any patches you produce.
>

I've contacted the owner of this project, and he said he would like to 
mentor this project, I sent him my proposal as well and haven't got the 
response. I think for this part it's no problem. and actually I finished 
some prototypes of some ideas in my proposal, it's my bad not yet writing 
it in my proposal. I'm not good at writing proposals (I'm not English 
native, so it takes me more time to write it), but I will keep improving my 
proposal, so plz feel free to give me some input. 
 

>
> Secondly, you haven't provided any timelines for your proposal. My 
> immediate reaction is that you're proposing a lot of work for a student to 
> complete in 12 weeks. For example, writing a fully tested and documented 
> database backend strikes me as a 12 week project in itself - yet this is 
> apparently just one line item in one part of your project proposal.
>

I'm still calculating how much time will I spend on each part of work, 
sorry about that, I know it's too much for doing it in 12 week, so I have 
already started it, in the project github repo you could find there's 
already some commit by me. 

>
> Lastly, your project proposal is very light on details. You're proposing a 
> lot of ideas, but you haven't really specified anything beyond "I'm going 
> to do it". Are there APIs that need to be specified? If, in the case of 
> something like a database backend, the APi is already specified, are there 
> going to be any complications in satisfying the API? We need a lot more 
> detail before we will be able to judge if you understand the project your 
> proposing, or if you are just proposing a bunch of ideas but haven't given 
> those ideas any more thought than "this sounds interesting"
>

Sorry about this part, I will filled it out ASAP, I posted this to mailing 
list beforehand because I would like to know am I correct on the idea, and 
willing to get feedback on the mailing, then refine my proposal after 
discussion of my idea. I will keep working on the proposal detail until 
it's good enough for GSoC and everybody's understanding.

I will conclude the others' comments and keep modifying the proposal.

thanks you very much : )

- Colin 
 

>
> Yours,
> Russ Magee %-)
>
> On Sunday, April 21, 2013, LittleQ@NCCU, Taiwan wrote:
>
>> to django-developers:
>>
>> Sorry, I use Google Drive for proposing, and I original tend to 
>> copy it to here but found it will get in a mess.
>>
>> so I put my proposal here: 
>> http://goo.gl/xJyJ9
>>
>> My idea is to contribute to django-deployer and make some significant 
>> improvements for it.
>> This proposal is still editing, but I pre-post it to prevent I'm thinking 
>> it in the wrong way.
>>
>> any questions or any advise are welcome, thank you, I'm really a big 
>> Django fan, and I hope I can make it better.
>>
>> cuz seems like there's no #django-dev, so feel free to add my XMPP 
>> directly: littleq0...@gmail.com
>>
>> it's open for messaging anytime :D
>>
>>
>> - Colin Su
>>
>>
>>
>>  -- 
>> 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.