Re: confusion about contributions (login using github account)

[gilberto dos santos alves]

2016-03-02 23:19 GMT-03:00 Russell Keith-Magee :

> Hi Becka,
>
> On Thu, Mar 3, 2016 at 8:55 AM, Becka  wrote:
>
>> Hi,
>>
>> I've been spending some time looking over the docs, and I'm really
>> interested in making them more approachable to relative n00bs like myself,
>> particularly when it comes to contributing to Django and the docs.
>>
>
> Fantastic! This sort of contribution is most appreciated! Thanks for
> offering to help out.
>
>
>> It seems like there's some conflicting information around where to look
>> for issues.
>>
>> * There's one address  where
>> you need to log in, but I can't see where to sign up
>>
>> * There's another url
>> where there
>> are some "easy pickings" tickets
>>
>> Where can tickets be filed?  Where should someone starting out look for
>> tickets, and can they (we) open issues? I'd like to clarify what the docs
>> ssay about this point.
>>
>
> We’re using a system called Trac as an issue tracker; when you hit
> code.djangoproject.com, that’s our Trac instance.
>
> Trac has a number of features, including an issue tracker, a wiki, and a
> few other bits and bobs. The homepage of the Trac instance is a wiki page
> that tells you where to go next (or, at least, tries to!) The first two
> links under “getting started” on that page are links into the ticket
> tracker; If you’re looking for somewhere to make your first contribution
> “easy pickings” is a list of tickets that has been pre-filtered to only
> contain issues that might be easy for a newcomer to tackle. Easy pickings
> is a good place to start if you want to make your first contribution.
>
> The other link (“tickets”) is a link to a wiki page that contains a couple
> of other pre-canned queries that can be helpful. All of those pre-canned
> queries will ultimately end up at
> https://code.djangoproject.com/query, which is the searchable index of
> all tickets. From there, you can add and remove filters to find the exact
> ticket you want.
>
> If you want to report a new issue, the first link you provide (/newticket)
> is where you should go (unless it’s a security issue, in which case a whole
> other procedure is required). The login is required as a spam measure - if
> you don’t lock down Trac, random bots drop by and open tickets for !!Fr33
> STUFF!!.
>
​if someone do not have a login for github.com ​please go to
https://github.com/ and create one login using signup button.
After that login is active, use your github login on djangoproject.com




>
> I hope that helps - if there’s anything else we can do to explain the
> process we have, let us know!
>
> Yours
> Russ Magee %-)
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJxq848NRqQO6WpqOX4ZAs%2Bm%2B_JZqRievPq8Cmiw82UdaF28jA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
gilberto dos santos alves
+55(11)9-8646-5049
sao paulo - sp - brasil

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAP9G-NJFuYb1VnWbX6Y_ugG7po-F-D%3D1Eo4Us64XtLzQfxr61w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: confusion about contributions

[Russell Keith-Magee]

Hi Becka,

On Thu, Mar 3, 2016 at 8:55 AM, Becka  wrote:

> Hi,
>
> I've been spending some time looking over the docs, and I'm really
> interested in making them more approachable to relative n00bs like myself,
> particularly when it comes to contributing to Django and the docs.
>

Fantastic! This sort of contribution is most appreciated! Thanks for
offering to help out.


> It seems like there's some conflicting information around where to look
> for issues.
>
> * There's one address  where
> you need to log in, but I can't see where to sign up
>
> * There's another url
> where there
> are some "easy pickings" tickets
>
> Where can tickets be filed?  Where should someone starting out look for
> tickets, and can they (we) open issues? I'd like to clarify what the docs
> ssay about this point.
>

We’re using a system called Trac as an issue tracker; when you hit
code.djangoproject.com, that’s our Trac instance.

Trac has a number of features, including an issue tracker, a wiki, and a
few other bits and bobs. The homepage of the Trac instance is a wiki page
that tells you where to go next (or, at least, tries to!) The first two
links under “getting started” on that page are links into the ticket
tracker; If you’re looking for somewhere to make your first contribution
“easy pickings” is a list of tickets that has been pre-filtered to only
contain issues that might be easy for a newcomer to tackle. Easy pickings
is a good place to start if you want to make your first contribution.

The other link (“tickets”) is a link to a wiki page that contains a couple
of other pre-canned queries that can be helpful. All of those pre-canned
queries will ultimately end up at
https://code.djangoproject.com/query, which is the searchable index of all
tickets. From there, you can add and remove filters to find the exact
ticket you want.

If you want to report a new issue, the first link you provide (/newticket)
is where you should go (unless it’s a security issue, in which case a whole
other procedure is required). The login is required as a spam measure - if
you don’t lock down Trac, random bots drop by and open tickets for !!Fr33
STUFF!!.

I hope that helps - if there’s anything else we can do to explain the
process we have, let us know!

Yours
Russ Magee %-)

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJxq848NRqQO6WpqOX4ZAs%2Bm%2B_JZqRievPq8Cmiw82UdaF28jA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

confusion about contributions

[Becka]

Hi,

I've been spending some time looking over the docs, and I'm really
interested in making them more approachable to relative n00bs like myself,
particularly when it comes to contributing to Django and the docs.

It seems like there's some conflicting information around where to look for
issues.

* There's one address  where you
need to log in, but I can't see where to sign up

* There's another url
where there are
some "easy pickings" tickets

Where can tickets be filed?  Where should someone starting out look for
tickets, and can they (we) open issues? I'd like to clarify what the docs
ssay about this point.

Thanks,

Becka

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANOxe%2B2-Fz88GBq5OWhwcs7Fyk-fA4Bf-PRaNhmsRSNecm2J%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2016

[Tim Graham]

The best thing you can do to improve your chances to be accepted as a 
Django GSoC student is to start contributing now. Read up on ​Django’s 
contribution documentation 
 and make 
yourself known to the core team by your contributions (ideally, related to 
the area of your proposal). That way, when it comes time to evaluate 
student applications, you’ll be a known individual and more likely to be 
able to get the attention you need to develop a proposal. 

On Wednesday, March 2, 2016 at 4:27:45 PM UTC-5, Matheus Fernandes wrote:
>
> Hello!
>
> I'm brazilian software engineering student and am interested in contribute 
> to django in GSoC. I would to contribute with
>
> https://code.djangoproject.com/wiki/SummerOfCode2016#Improvingthelesspopulardatabasebackends
>
> How can I get started to contribute?
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9dd1c07f-6ca9-4a97-8f17-bc94de931bd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GSoC 2016

[Matheus Fernandes]

Hello!

I'm brazilian software engineering student and am interested in contribute 
to django in GSoC. I would to contribute with
https://code.djangoproject.com/wiki/SummerOfCode2016#Improvingthelesspopulardatabasebackends

How can I get started to contribute?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fa24d60-9f04-43ab-a378-24c6ed5bff1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Index expressions

[Asif Saifuddin]

Hi Josh,

I'm willing to work on django orm improvment for gsoc and considering 
custom index as a project idea. I have gone through the available resources 
like dep, POC on class based index, unification of transform API etc. What 
others stuff do you suggest me to look into to have some concrete ideas to 
complete a very good proposal.

Thanks
Asif

On Sunday, February 7, 2016 at 5:11:59 PM UTC+6, Curtis Maloney wrote:
>
>
> So, in #django recently there was a discussion about adding an index on 
> a date field for just the year. 
>
> I know the idea was raised some time ago, and several ideas on the 
> syntax were expressed.  But most of that focused on different types of 
> indices - not on indexing expressions. 
>
> It occurred to me that with the recent advances in expression syntax, it 
> should be fairly easy to add an indexes list to Meta to define complex 
> expressions. 
>
> Input? 
>
> -- 
> C 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/39ccca4c-735e-4add-9124-2752002c13c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Asking for some beginner friendly tasks

[Tim Graham]

Hi, have you read 
https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ 
and taken a look at the "Easy" tickets linked from there?

On Wednesday, March 2, 2016 at 9:18:08 AM UTC-5, anshul singhal wrote:
>
> Hi everyone,
>
> I am Anshul Singhal second year undergraduate student at IIIT Hyderabad, 
> India. I have been using Django web Framework since long time. I have very 
> good experience with using django. Now, I want to contribute to django.
> So, I would like to know some beginner friendly tasks to start with. 
>
> Thank You,
>
> Regards,
> Anshul Singhal
> UG-2, IIIT Hyderabad
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9510207a-9bf8-4814-b011-a16367570132%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Asking for some beginner friendly tasks

[anshul singhal]

Hi everyone,

I am Anshul Singhal second year undergraduate student at IIIT Hyderabad, 
India. I have been using Django web Framework since long time. I have very 
good experience with using django. Now, I want to contribute to django.
So, I would like to know some beginner friendly tasks to start with. 

Thank You,

Regards,
Anshul Singhal
UG-2, IIIT Hyderabad

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10c64bc5-5f49-4cd8-a466-3e574521b982%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Annotate date intervals or ranges

[Sam Peka]

It would be great if there was a way within the standard Queryset api to 
annotate ranges of dates. The use case is that it would remove the need to 
resort to RawSQL when grouping things by date ranges, such as the day of 
the month. I know the postgres extras package has a DateRangeField, but 
it's surprisingly difficult to do this dynamically.

So I'd propose something like this:

queryset.annotate(day_created=DateRange('day', 'created_date'))

Which for Postgres would equate to:

SELECT date_trunc('day', "created_date") as day_created from ...

Is there a technical reason why this hasn't already been done? Or has there 
not been much of a need for it?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fe7dcfc9-cbb5-439b-bf08-f45e854a99c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy-from-base inheritance

[Aymeric Augustin]

Now I understand — you want to inherit from a concrete model but to use a 
separate table.

I’m not sure how widely applicable this would be. I find it counter-intuitive 
that Parent.objects.all() isn’t a superset of Child.objects.all() anymore. This 
is a surprising way to implement inheritance.

The usual ways to implement inheritance in an ORM are single-table inheritance 
(STI) and multi-table inheritance (MTI). Django supports MTI. It also supports 
inheriting Python classes without affecting the database, with abstract or 
proxy models, depending on whether the database table(s) are tied to the 
children or the parent.



In your use case, the only reason why you can’t make the parent model abstract 
is that it’s provided by a third-party app. Perhaps the general problem is to 
customize models provided by third-party apps? At this time, Django doesn’t 
provide a mechanism for doing that. The two solutions I know of are:

1) Swappable models: this is only officially supported for the auth.User model 
via the AUTH_USER_MODEL setting but it’s technically possible to achieve a 
similar effect with other models.
2) App-registry hacks: for example, that’s what django-oscar does; I’m not sure 
they would have ended up with the solution if they had started after Django 
1.7, though.

So, in the current state of things, the path of least resistance is to 
encourage authors of reusable apps to provide an abstract version of 
inheritable models in addition to the concrete version, like Django does with 
AbstractUser and User, and perhaps discuss making swappable models a supported 
API.


If we leave aside the current implementation of abstract models for a moment, 
for your use case, I can see the logic in having the child model declare what 
kind of inheritance it uses rather than the parent. In the end, it’s the 
child’s database table that has either a FK to the parent of a copy of all the 
parent’s columns (with your patch). `copy_from_base` is a poor name for 
declaring the whether you’re using MTI or not, though.

If we ever implement single table inheritance (STI), either having the parent 
declaring that it collects database columns from all its children or the 
children declare that they add database columns to their parent will be 
awkward. When inheriting across applications, that will interact very poorly 
with the migrations framework. So it’s unclear that one solution is better than 
the other here.

That said, we need to keep `abstract = True` on the parent to prevent the 
creation of a related database table, which could be accidentally used even if 
the model was intended to be abstract.

So I don’t think we can draw a general conclusion on whether inheritance 
behavior should be declared on parents or children.


To sum up, Django currently provides limited but safe options for model 
inheritance:

- MTI — it's the default when inheriting from a regular model; the main 
usability drawback is that there’s no good way to specialize a queryset of 
parents into children
- abstract models (declared on the parent) — the parent cannot interact with 
the database, each child has its own table, which avoids interactions between 
the ORM and inheritance
- proxy models (declared on the child) — the child only specializes Python 
behavior, only the parent has a table, which also avoids interactions between 
the ORM and inheritance

There has been some talk about introducing STI but I don’t remember seeing a 
concrete proposal. (Also STI looks suspiciously similar to GFK which aren’t 
very popular among the core team.)

Looking at where your proposal would fit in this landscape, it’s unclear to me 
that the benefits outweigh the bizarre result of making both 
Parent.objects.all() and Child.objects.all() work, but not have the latter be a 
subset of the former.

I would be more comfortable with providing guidelines for reusable apps whose 
models may be inherited.


I suppose I just spent two pages rebuilding the reasoning behind the design of 
abstract models… I hope this helps anyway!

-- 
Aymeric.


> On 02 Mar 2016, at 11:02, Joakim Saario  wrote:
> 
> Yes it is true the patch do include some code for overriding parent fields, 
> but that is not the main feature.
> 
> In any way this thread is a double post (I thought the first one got lost). 
> Look at: 
> https://groups.google.com/forum/?hl=sv#!topic/django-developers/koRZDDCQREc 
> instead.
> 
> Den onsdag 2 mars 2016 kl. 10:52:07 UTC+1 skrev Aymeric Augustin:
> In that case, I believe this is the ticket you’re looking for: 
> https://code.djangoproject.com/ticket/24305 
> 
> 
> There seems to be some activity on the related PR: 
> https://github.com/django/django/pull/5122 
> 
> 
> You may want to review these discussions and see how you can help. Thanks!
> 
> -- 
> Aymeric.
> 
>> On 02 Mar 2016, at 10:25, Joakim Saario 

Re: Copy-from-base inheritance

[Joakim Saario]

Yes it is true the p*atch* do include some code for overriding 

*parent fields, but that is not the main feature.In any way this thread is 
a double post (I thought the first one go*t lost). Look at: 
https://groups.google.com/forum/?hl=sv#!topic/django-developers/koRZDDCQREc 
instead.

Den onsdag 2 mars 2016 kl. 10:52:07 UTC+1 skrev Aymeric Augustin:
>
> In that case, I believe this is the ticket you’re looking for: 
> https://code.djangoproject.com/ticket/24305
>
> There seems to be some activity on the related PR: 
> https://github.com/django/django/pull/5122
>
> You may want to review these discussions and see how you can help. Thanks!
>
> -- 
> Aymeric.
>
> On 02 Mar 2016, at 10:25, Joakim Saario  
> wrote:
>
> I'm sorry, this is a typo, local fields overrides parent fields of course. 
> Look at the patch.
>
> Den onsdag 2 mars 2016 kl. 08:19:23 UTC+1 skrev Aymeric Augustin:
>>
>> Hello,
>>
>> The “locally declared field gets overriden by parent definition” behavior 
>> shown in your example looks counter-intuitive to me.
>>
>> Inheritance means that children inherit and possibly specialize their 
>> parent’s behavior, not that the parent overrides the child.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>> On 02 Mar 2016, at 01:57, Joakim Saario  wrote:
>>
>> Hello!
>>
>> I'd like to propose another inheritance strategy for django's models.
>>
>> Think of it sort of like reversed abstract models
>>
>> For example:
>>
>> class NormalModel(models.Model):
>> foo = models.CharField(max_length=10)
>> bar = models.CharField(max_length=10)
>>
>> class CopiedBaseModel(NormalModel):
>> bar = models.CharField(max_length=2)
>> buzz = models.CharField(max_length=10)
>>
>> class Meta:
>> copy_from_base = True
>>
>> Would be equivalent to:
>>
>> class NormalModel(models.Model):
>> foo = models.CharField(max_length=10)
>> bar = models.CharField(max_length=10)
>>
>> class CopiedBaseModel(NormalModel):
>> foo = models.CharField(max_length=10)
>> bar = models.CharField(max_length=10)
>> buzz = models.CharField(max_length=10)
>>
>> My initial use case for this was with django-cms which didn't play well 
>> with
>> multi-table inheritance when i needed to extend a built in plugin of 
>> theirs. So
>> I ended copying the whole model instead, which didn't make me too happy.
>> So I started writing some code for the behaviour I was after. Which was,
>> ironicly a standard python inheritance. Django only offers part of this 
>> behaviour
>> through the proxy and abstract models. But neither of them worked for me.
>>
>> This is quite easy to implement with some of the current abstract model
>> logic (see the patch).
>>
>> -- 
>> 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-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/d4872520-eeb1-49a7-a8f3-aefc23a98346%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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d95ca003-a45a-4030-b36f-b7b2ffddd9fb%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/aec59b40-b2cf-4408-952e-4f5ad3619e9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy-from-base inheritance

[Aymeric Augustin]

In that case, I believe this is the ticket you’re looking for: 
https://code.djangoproject.com/ticket/24305

There seems to be some activity on the related PR: 
https://github.com/django/django/pull/5122

You may want to review these discussions and see how you can help. Thanks!

-- 
Aymeric.

> On 02 Mar 2016, at 10:25, Joakim Saario  wrote:
> 
> I'm sorry, this is a typo, local fields overrides parent fields of course. 
> Look at the patch.
> 
> Den onsdag 2 mars 2016 kl. 08:19:23 UTC+1 skrev Aymeric Augustin:
> Hello,
> 
> The “locally declared field gets overriden by parent definition” behavior 
> shown in your example looks counter-intuitive to me.
> 
> Inheritance means that children inherit and possibly specialize their 
> parent’s behavior, not that the parent overrides the child.
> 
> Best regards,
> 
> -- 
> Aymeric.
> 
>> On 02 Mar 2016, at 01:57, Joakim Saario  
>> wrote:
>> 
>> Hello!
>> 
>> I'd like to propose another inheritance strategy for django's models.
>> 
>> Think of it sort of like reversed abstract models
>> 
>> For example:
>> 
>> class NormalModel(models.Model):
>> foo = models.CharField(max_length=10)
>> bar = models.CharField(max_length=10)
>> 
>> class CopiedBaseModel(NormalModel):
>> bar = models.CharField(max_length=2)
>> buzz = models.CharField(max_length=10)
>> 
>> class Meta:
>> copy_from_base = True
>> 
>> Would be equivalent to:
>> 
>> class NormalModel(models.Model):
>> foo = models.CharField(max_length=10)
>> bar = models.CharField(max_length=10)
>> 
>> class CopiedBaseModel(NormalModel):
>> foo = models.CharField(max_length=10)
>> bar = models.CharField(max_length=10)
>> buzz = models.CharField(max_length=10)
>> 
>> My initial use case for this was with django-cms which didn't play well with
>> multi-table inheritance when i needed to extend a built in plugin of theirs. 
>> So
>> I ended copying the whole model instead, which didn't make me too happy.
>> So I started writing some code for the behaviour I was after. Which was,
>> ironicly a standard python inheritance. Django only offers part of this 
>> behaviour
>> through the proxy and abstract models. But neither of them worked for me.
>> 
>> This is quite easy to implement with some of the current abstract model
>> logic (see the patch).
>> 
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-developers 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/d4872520-eeb1-49a7-a8f3-aefc23a98346%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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d95ca003-a45a-4030-b36f-b7b2ffddd9fb%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/534E93F1-9D56-442F-A4E0-04510008849A%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Django admin and messages

[Claude Paroz]

Le mercredi 2 mars 2016 02:42:05 UTC+1, Cristiano Coelho a écrit :
>
> Another approach for gender languages like spanish would be to use "el 
> objeto %(obj)" rather than "el/la %(obj)".
>

That's exactly what we are doing for French.

Claude 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91991e61-07c3-4be5-8cf0-4fcbc871341a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy-from-base inheritance

[Joakim Saario]

I'm sorry, this is a typo, local fields overrides parent fields of course. 
Look at the patch.

Den onsdag 2 mars 2016 kl. 08:19:23 UTC+1 skrev Aymeric Augustin:
>
> Hello,
>
> The “locally declared field gets overriden by parent definition” behavior 
> shown in your example looks counter-intuitive to me.
>
> Inheritance means that children inherit and possibly specialize their 
> parent’s behavior, not that the parent overrides the child.
>
> Best regards,
>
> -- 
> Aymeric.
>
> On 02 Mar 2016, at 01:57, Joakim Saario  
> wrote:
>
> Hello!
>
> I'd like to propose another inheritance strategy for django's models.
>
> Think of it sort of like reversed abstract models
>
> For example:
>
> class NormalModel(models.Model):
> foo = models.CharField(max_length=10)
> bar = models.CharField(max_length=10)
>
> class CopiedBaseModel(NormalModel):
> bar = models.CharField(max_length=2)
> buzz = models.CharField(max_length=10)
>
> class Meta:
> copy_from_base = True
>
> Would be equivalent to:
>
> class NormalModel(models.Model):
> foo = models.CharField(max_length=10)
> bar = models.CharField(max_length=10)
>
> class CopiedBaseModel(NormalModel):
> foo = models.CharField(max_length=10)
> bar = models.CharField(max_length=10)
> buzz = models.CharField(max_length=10)
>
> My initial use case for this was with django-cms which didn't play well 
> with
> multi-table inheritance when i needed to extend a built in plugin of 
> theirs. So
> I ended copying the whole model instead, which didn't make me too happy.
> So I started writing some code for the behaviour I was after. Which was,
> ironicly a standard python inheritance. Django only offers part of this 
> behaviour
> through the proxy and abstract models. But neither of them worked for me.
>
> This is quite easy to implement with some of the current abstract model
> logic (see the patch).
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/d4872520-eeb1-49a7-a8f3-aefc23a98346%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d95ca003-a45a-4030-b36f-b7b2ffddd9fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.