Re: DJANGO_SETTINGS_FILE

[James Pic]

I'm sorry you've seized the opportunity to use my effort to put a little
joy and humor in my message to push me on the slope, sorry that it's been
misinterpreted and that I just don't understand at all your technical
explanation. I guess there is always that risk.
Best
James

Le 7 avr. 2017 10:43 PM, "James Bennett"  a écrit :

> On Thu, Apr 6, 2017 at 5:22 PM, James Pic  wrote:
>
>> Do I need this to deploy my projects ? No of course, because I use the
>> prettiest way hhihihi ;) I'm more than happy to win a debate
>>
>
> Please don't do this. This does not make you look like someone who I could
> constructively engage with to try to figure out what problem is being
> reported and what a good solution would be.
>
>
>> And this is
>> how the drama begins, I can imagine them in front of Tobias.
>>
>
> Please also don't do this. You are perfectly well aware that people will
> give one type of explanation to a new user they're helping, and quite
> another to a mailing list of experienced developers discussing the merits
> of different approaches. And regardless of the context-insensitivity of
> what you're doing here, putting words in someone's mouth to try to make
> them look bad just makes you look bad.
>
> Meanwhile, Django has a way to avoid all the turmoil you've proposed in
> your reply -- run 'startproject', get package with settings file inside,
> run 'manage.py '. Several tools for deploying Django into
> production even make use of this, providing custom management commands
> which can be invoked to run/deploy/etc., and doing so requires no deep
> dives into Python imports, Python packages, or environment variables. Of
> course, a third-party package which develops its own independent
> configuration mechanism will need to teach all of its users how to make use
> of and deploy that configuration mechanism, but that's the responsibility a
> third-party project takes on when it invents its own method.
>
> --
> 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/CAL13Cg_JBcc6mYhH7un3LKgGFR22pZz%3D_
> kQyc0sB5dh4uq8g-g%40mail.gmail.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/CAC6Op18F%2B3TM-P2NHb-qv4tXC0X9s1YJ045q5iK50HA45VULZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO_SETTINGS_FILE

[James Pic]

Tobias, Adam, I have "imagined" you this dialogue where you're helping
people deploy an open source citizen lobbying tool in Django in an NGO was
not to make you look bad of course, the intention was rather the inverse of
that. This situation, and exact dialogue, I have actually had, see the
source code if you don't believe me: there is a module called
memopol_settings and I have actually been bitten by this. Obviously I
forgot humility when I thought you would have said the same to the users as
you told me on the list - because I actually have - but it's true that I
was biased when I thought you would have done the same mistake as me, so,
sorry for making you look like you would have yourself :)

Anyway, people from over the world have been **fighting** this situation
rather than **fixing it upstream** for **ages**, see the demand:

https://djangopackages.org/grids/g/configuration/
https://code.djangoproject.com/wiki/SplitSettings

On one hand, I ear about all the efforts our community is doing to be
inclusive, and not being just elitist trolls (like me unfortunately but
working on it!!), on the other hand, we don't even provide a native and
simple way for user to put their environment specific configuration in a
file, despite the obvious demand (see links above, any NGO's workshop),
just because we, linux experts, are experienced enough to deal with it as
is.

"You can't expect everybody to be a guru like you James" is what people
have telling me over and over again, and what I'm working on (because my
name is also James). And that's exactly why I'm trying to understand where
they struggle and what's the most efficient way to fix it **upstream**,
because that's my philosophy, don't fight the controls, fix them.

Now, you say I can invent my own settings file system, or reuse any of the
existing system. While that is perfectly true, the problem with this, is
that I don't need any myself: I'm happy with env vars and a settings
module, because I deploy containers and set environment varibales at
container creation. At the risk of looking like a broken record (in
addition to everything I already look like, "le ridicule ne tue pas" :D):
it's not about me, it's not about you, it's about different users.

I'm ending up with a different implementation (that i don't need) in every
project I contribute to, because everyone creates their own, when after all
the need is the same: they just want a configuration file outside the
project with their environment specific thing. This is how I ended up with
a project in my hands, that requires writing an undocumented JSON
configuration file or something as warry as that. Currently I have to learn
each and every environment-specific settings file app there is out there
just in case somebody adds it to their project because of the lack of
DJANGO_SETTINGS_FILE.

After all, isn't the framework about proposing design decisions ?

Doesn't it make sense for a framework to at least provide projects built on
it with a way to pass a config file by path ?

And really, if the django project **should** be a python module so that the
settings should **always** be importable, then shouldn't startproject
create a setup.py ?

As you said, using django project shouldn't even **require** configuring
DJANGO_SETTINGS_MODULE even at all because it's hard coded in wsgi.py and
manage.py from the moment you run django-admin startproject. However,
DJANGO_SETTINGS_MODULE was never designed for deployment: environment
specific configuration.

So really, all we need users to do, is to call
`DJANGO_SETTINGS_FILE=/etc/theirconfig.py
./manage.py` (or `DJANGO_SETTINGS_FILE=/etc/memopol/production.py memopol`)
to keep environment specific, non-defaults, where it belongs: outside the
**public project**. Keep that in swarm, a json blob in etcd (ie.
kubernetes) or in a repository with ansible playbooks, chef recipes,
saltstack roles, for example it's your choice, but environment specific
variables have nothing to do in the public repository anyway.

About my joke on deployment debates, I recon I am in a currently mad love
story that drives me a bit crazy (in a good way) with gitlab-ci and docker
swarm, because it lets me treat server as cattle put a django project under
continuous deployment with like ~100 SLOCs of YAML and ~5 commands on a
server in NGOs that have no money to buy services such as Divio cloud or
else. I love it so much, it makes me euphoric, guilty as charged, I don't
feel like writing about it in a boring way where we can't indicate a joke
with " hihihihihi ;)". Because if I were going to write on this in a
boring way, I'd say perhaps making Django more comfortable to deploy for
non-technical users would not be good for business. But then again, I'm not
talking about commercial projects at all, rather, citizen lobbying tools
and the like, software for people who strive to change the world, people
without technical knowledge for example, but who have already changed how
politics work at some 

Re: Proposal: make Model __unicode__() default to self.name

[is_null]

Usually people tell me that type(self) is better than self.__class__, so 
you might prepare to change that too.

But yeah, it seems like a very reasonable change to me, reading lists of 
indistinct  have always required extra steps to figure out 
what models they are.

Thanks for your effort,
Best
James

-- 
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/6c7cc560-8f68-497d-99f8-eb1396bcff0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make Model __unicode__() default to self.name

[Marco Silva]

I have no idea what is the best way, just say that comment. this is the 
original PR
https://github.com/django/django/commit/d2a26c1a90e83dabdf3d67ceec4d2a70fb86

I think you should submit the PR to change the __str__ method, and maybe 
open a new discussion regarding __repr__

sexta-feira, 7 de Abril de 2017 às 15:34:32 UTC+1, Kapil Garg escreveu:
>
> The opened ticket is about Model.__str__ method. Should i open a new 
> ticket for this change ?
> As i see in code, self.__class__ is used in a lot of places but will it 
> effect optimization if we change lookups from self.__class__ to self.cls
>
> Because the methods where class is being used frequently, already store it 
> in local variable and then make references to local variable. 
>
> So should it really be changed ?
>
> On Fri, Apr 7, 2017, 6:52 PM Marco Silva  > wrote:
>
>> I noticed this on the init
>>
>> def __init__(self, *args, **kwargs):
>>  # Alias some things as locals to avoid repeat global lookups
>>  cls = self.__class__
>>
>> maybe you should change it to self.cls??
>> Try to submit a PR to the open ticket.
>>
>> segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg escreveu:
>>>
>>> So does this patch seem fine ? 
>>>
>>> diff --git a/django/db/models/base.py b/django/db/models/base.py
>>> index 3c1cb9a..f58e12b 100644
>>> --- a/django/db/models/base.py
>>> +++ b/django/db/models/base.py
>>> @@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
>>>  return '<%s: %s>' % (self.__class__.__name__, u)
>>>  
>>>  def __str__(self):
>>> -return '%s object' % self.__class__.__name__
>>> +return '%s object pk=%s' % (self.__class__.__name__, 
>>> self._get_pk_val())
>>>  
>>>  def __eq__(self, other):
>>>  if not isinstance(other, Model):
>>>
>>>
>>>
>>>
>>> On Monday, 3 April 2017 23:07:56 UTC+5:30, Collin Anderson wrote:

 I'd recommend not saying "unsaved". "new" if anything. UUID pk's may 
 default to generating a pk before save, so it might just be best to show 
 the actual current pk value

 On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg  wrote:

> So what should the final __str__ show: Should it be 'ClassName object 
> pk=Something' and if pk is None then should it be 'ClassName object 
> (unsaved)' or 'ClassName object pk=None' ?
>
> On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:
>>
>> Makes sense to me. Maybe still keep the "Transaction object" part, 
>> and use None if no pk.
>>
>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  
>> wrote:
>>
>>> Ticket 27953  is 
>>> regarding this proposal and the suggestion is about adding "pk" in 
>>> Model 
>>> string representation if it exists. 
>>>
>>> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:

 Hi All,

 Have you ever quickly set up a model, ran syncdb, and added a few 
 sample objects in the admin to only see a bunch of "MyModel object"s 
 in the 
 changelist? I always forget to add a __unicode__()/__str__() method on 
 my 
 models.

 I ran "git grep -1 __unicode__" on some of my django projects and 
 noticed a lot of repeated code. In fact, it seems that in about a 
 _third_ 
 of all my cases, I'm just returning self.name, or returning 
 self.name would have been a good default. I looked at a few 3rd 
 party apps for comparison and found similar results, though not for 
 every 
 app.

 IMHO, returning self.name (if the field or property exists) is a 
 sensible default for __unicode__. We can still return "MyModel object" 
 if 
 there's no "name" attribute. You'll still end up adding your own 
 __unicode__ method much of the time, just like you always have.

 Yes, it's "magic", but we can document it.
 Yes, it's a little more confusing, but we don't have to explain it 
 during the tutorial.
 Yes, it's backwards incompatible, but only in rare cases should it 
 be a problem.
 Yes, it could look like any Model without a "name" field is 
 "wrong", but it's not.
 Yes, "title" is also very popular, but name is better. :)

 It has the effect of being a little more friendly in many cases, 
 and can result in more DRY code.

 What do your __unicode__/__str__ methods look like? Is this a bad 
 idea?

 Thanks,
 Collin

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

Re: Proposal: make Model __unicode__() default to self.name

[Marco Silva]

just saw that __repr__ is now under discusion here
https://groups.google.com/forum/#!topic/django-developers/UNKFMg6DO5s

sábado, 8 de Abril de 2017 às 17:06:05 UTC+1, Marco Silva escreveu:
>
> I have no idea what is the best way, just say that comment. this is the 
> original PR
>
> https://github.com/django/django/commit/d2a26c1a90e83dabdf3d67ceec4d2a70fb86
>
> I think you should submit the PR to change the __str__ method, and maybe 
> open a new discussion regarding __repr__
>
> sexta-feira, 7 de Abril de 2017 às 15:34:32 UTC+1, Kapil Garg escreveu:
>>
>> The opened ticket is about Model.__str__ method. Should i open a new 
>> ticket for this change ?
>> As i see in code, self.__class__ is used in a lot of places but will it 
>> effect optimization if we change lookups from self.__class__ to self.cls
>>
>> Because the methods where class is being used frequently, already store 
>> it in local variable and then make references to local variable. 
>>
>> So should it really be changed ?
>>
>> On Fri, Apr 7, 2017, 6:52 PM Marco Silva  wrote:
>>
>>> I noticed this on the init
>>>
>>> def __init__(self, *args, **kwargs):
>>>  # Alias some things as locals to avoid repeat global lookups
>>>  cls = self.__class__
>>>
>>> maybe you should change it to self.cls??
>>> Try to submit a PR to the open ticket.
>>>
>>> segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg escreveu:

 So does this patch seem fine ? 

 diff --git a/django/db/models/base.py b/django/db/models/base.py
 index 3c1cb9a..f58e12b 100644
 --- a/django/db/models/base.py
 +++ b/django/db/models/base.py
 @@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
  return '<%s: %s>' % (self.__class__.__name__, u)
  
  def __str__(self):
 -return '%s object' % self.__class__.__name__
 +return '%s object pk=%s' % (self.__class__.__name__, 
 self._get_pk_val())
  
  def __eq__(self, other):
  if not isinstance(other, Model):




 On Monday, 3 April 2017 23:07:56 UTC+5:30, Collin Anderson wrote:
>
> I'd recommend not saying "unsaved". "new" if anything. UUID pk's may 
> default to generating a pk before save, so it might just be best to show 
> the actual current pk value
>
> On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg  
> wrote:
>
>> So what should the final __str__ show: Should it be 'ClassName object 
>> pk=Something' and if pk is None then should it be 'ClassName object 
>> (unsaved)' or 'ClassName object pk=None' ?
>>
>> On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:
>>>
>>> Makes sense to me. Maybe still keep the "Transaction object" part, 
>>> and use None if no pk.
>>>
>>> On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg  
>>> wrote:
>>>
 Ticket 27953  is 
 regarding this proposal and the suggestion is about adding "pk" in 
 Model 
 string representation if it exists. 

 On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>
> Hi All,
>
> Have you ever quickly set up a model, ran syncdb, and added a few 
> sample objects in the admin to only see a bunch of "MyModel object"s 
> in the 
> changelist? I always forget to add a __unicode__()/__str__() method 
> on my 
> models.
>
> I ran "git grep -1 __unicode__" on some of my django projects and 
> noticed a lot of repeated code. In fact, it seems that in about a 
> _third_ 
> of all my cases, I'm just returning self.name, or returning 
> self.name would have been a good default. I looked at a few 3rd 
> party apps for comparison and found similar results, though not for 
> every 
> app.
>
> IMHO, returning self.name (if the field or property exists) is a 
> sensible default for __unicode__. We can still return "MyModel 
> object" if 
> there's no "name" attribute. You'll still end up adding your own 
> __unicode__ method much of the time, just like you always have.
>
> Yes, it's "magic", but we can document it.
> Yes, it's a little more confusing, but we don't have to explain it 
> during the tutorial.
> Yes, it's backwards incompatible, but only in rare cases should it 
> be a problem.
> Yes, it could look like any Model without a "name" field is 
> "wrong", but it's not.
> Yes, "title" is also very popular, but name is better. :)
>
> It has the effect of being a little more friendly in many cases, 
> and can result in more DRY code.
>
> What do your __unicode__/__str__ methods look like? Is this a bad 
> idea?
>
> Thanks,
> Collin

Re: Making __repr__ safe by default

[Marco Silva]

going in the python docs we find this

> If at all possible, this should look like a valid Python expression that 
> could be used to recreate an object with the same value (given an 
> appropriate environment).

so maybe something that returned ModelName(field1=value1, field2=value2 
...) where fields with references could return the id of the reference to 
avoid DB lookups 

sábado, 18 de Maio de 2013 às 17:04:48 UTC+1, Patryk Zawadzki escreveu:
>
> As suggested by Marc Tamlyn I am posting this here for discussion: 
>
> https://code.djangoproject.com/ticket/20448 
>
> tl;dr: 
>
> Currently __repr__() calls __unicode__() which can be a very bad 
> thing. You really don't want things like an exception being raised or 
> debugger being used to cause additional side effects (like executing a 
> database query inside __unicode__). 
>
> -- 
> Patryk Zawadzki 
> I solve problems. 
>

-- 
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/1c59d03d-49da-4bfa-836b-31c7d42b63d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DJANGO_SETTINGS_FILE

[James Pic]

tl;dr

I'm not debating deployment here: my automated deployments are fine
the way it is today: I love linux and env vars, shells and subshells
and so on.

I'm /reporting/ that users have been fighting the lack for
DJANGO_SETTINGS_FILE for as long as I can remember.

In many case, they loose the fight and make something that's unusable
for an actual linux or django guru like you.

Have I really been the only witness of all kinds of horrors in
settings.py just because they wanted to have their deployment settings
parsed in it from another file path ?

I suggest we show people who do not abide by 12factor that they are welcome too.

I recommend we show people who do not have the technical background to
deal with env vars that we can think of them too, and not just about
ourselves hackers.

So, next time I have a Django deployment workshop with newbies, they
won't tell me: "You can't expect everybody to be a guru James".

Thanks for reading
Best
James

-- 
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/CAC6Op1-F0Yn8QM9x5qQjDtcXT-FRC%3DvN7v--YfcT8m6K6W1qdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: make Model __unicode__() default to self.name

[Collin Anderson]

I just made a pull request.
https://github.com/django/django/pull/8336

(1) is my first choice, pk=1 is my second choice. I'd be fine with either.

On Sat, Apr 8, 2017 at 12:08 PM, Marco Silva 
wrote:

> just saw that __repr__ is now under discusion here
> https://groups.google.com/forum/#!topic/django-developers/UNKFMg6DO5s
>
>
> sábado, 8 de Abril de 2017 às 17:06:05 UTC+1, Marco Silva escreveu:
>>
>> I have no idea what is the best way, just say that comment. this is the
>> original PR
>> https://github.com/django/django/commit/d2a26c1a90e83dab
>> df3d67ceec4d2a70fb86
>>
>> I think you should submit the PR to change the __str__ method, and maybe
>> open a new discussion regarding __repr__
>>
>> sexta-feira, 7 de Abril de 2017 às 15:34:32 UTC+1, Kapil Garg escreveu:
>>>
>>> The opened ticket is about Model.__str__ method. Should i open a new
>>> ticket for this change ?
>>> As i see in code, self.__class__ is used in a lot of places but will it
>>> effect optimization if we change lookups from self.__class__ to self.cls
>>>
>>> Because the methods where class is being used frequently, already store
>>> it in local variable and then make references to local variable.
>>>
>>> So should it really be changed ?
>>>
>>> On Fri, Apr 7, 2017, 6:52 PM Marco Silva  wrote:
>>>
 I noticed this on the init

 def __init__(self, *args, **kwargs):
  # Alias some things as locals to avoid repeat global lookups
  cls = self.__class__

 maybe you should change it to self.cls??
 Try to submit a PR to the open ticket.

 segunda-feira, 3 de Abril de 2017 às 21:07:47 UTC+1, Kapil Garg
 escreveu:
>
> So does this patch seem fine ?
>
> diff --git a/django/db/models/base.py b/django/db/models/base.py
> index 3c1cb9a..f58e12b 100644
> --- a/django/db/models/base.py
> +++ b/django/db/models/base.py
> @@ -504,7 +504,7 @@ class Model(metaclass=ModelBase):
>  return '<%s: %s>' % (self.__class__.__name__, u)
>
>  def __str__(self):
> -return '%s object' % self.__class__.__name__
> +return '%s object pk=%s' % (self.__class__.__name__,
> self._get_pk_val())
>
>  def __eq__(self, other):
>  if not isinstance(other, Model):
>
>
>
>
> On Monday, 3 April 2017 23:07:56 UTC+5:30, Collin Anderson wrote:
>>
>> I'd recommend not saying "unsaved". "new" if anything. UUID pk's may
>> default to generating a pk before save, so it might just be best to show
>> the actual current pk value
>>
>> On Mon, Apr 3, 2017 at 1:06 PM, Kapil Garg 
>> wrote:
>>
>>> So what should the final __str__ show: Should it be 'ClassName
>>> object pk=Something' and if pk is None then should it be 'ClassName 
>>> object
>>> (unsaved)' or 'ClassName object pk=None' ?
>>>
>>> On Sunday, 2 April 2017 23:47:01 UTC+5:30, Collin Anderson wrote:

 Makes sense to me. Maybe still keep the "Transaction object" part,
 and use None if no pk.

 On Sun, Apr 2, 2017 at 11:09 AM, Kapil Garg 
 wrote:

> Ticket 27953  is
> regarding this proposal and the suggestion is about adding "pk" in 
> Model
> string representation if it exists.
>
> On Thursday, 11 July 2013 09:16:25 UTC+5:30, Collin Anderson wrote:
>>
>> Hi All,
>>
>> Have you ever quickly set up a model, ran syncdb, and added a few
>> sample objects in the admin to only see a bunch of "MyModel object"s 
>> in the
>> changelist? I always forget to add a __unicode__()/__str__() method 
>> on my
>> models.
>>
>> I ran "git grep -1 __unicode__" on some of my django projects and
>> noticed a lot of repeated code. In fact, it seems that in about a 
>> _third_
>> of all my cases, I'm just returning self.name, or returning
>> self.name would have been a good default. I looked at a few 3rd
>> party apps for comparison and found similar results, though not for 
>> every
>> app.
>>
>> IMHO, returning self.name (if the field or property exists) is a
>> sensible default for __unicode__. We can still return "MyModel 
>> object" if
>> there's no "name" attribute. You'll still end up adding your own
>> __unicode__ method much of the time, just like you always have.
>>
>> Yes, it's "magic", but we can document it.
>> Yes, it's a little more confusing, but we don't have to explain
>> it during the tutorial.
>> Yes, it's backwards incompatible, but only in rare cases should
>> it be a problem.
>> Yes, it could look like any Model without a "name" field is
>> "wrong", but it's not.
>> Yes, "title" is also very popular, 

Re: DJANGO_SETTINGS_FILE

[Daniele Procida]

On Sat, Apr 8, 2017, James Pic  wrote:

>I'm sorry you've seized the opportunity to use my effort to put a little
>joy and humor in my message to push me on the slope, sorry that it's been
>misinterpreted and that I just don't understand at all your technical
>explanation. I guess there is always that risk.

I think in these discussions the greatest risk isn't failure to understand 
something technical, but failure to understand the other person.

Given differences in timezones, language, cultural expectations etc with great 
opportunity for misunderstandings to escalate, it seems like a good idea, when 
there is any doubt, to assume that what another person is saying is friendlier 
than it appears, and that no-one is trying to win arguments by making others 
look bad.

Daniele

-- 
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/20170408204652.1129349886%40mail.gandi.net.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - April 8, 2017

[Tim Graham]

Triaged

---

https://code.djangoproject.com/ticket/28011 - Correct Field.hidden docs 
regarding what fields are hidden (created)

https://code.djangoproject.com/ticket/28027 - UTF-8 in help_text in 
models.ManyToManyField doesn't work anymore (invalid)

https://code.djangoproject.com/ticket/28031 - Documentation for uwsgi 
deployment mentions buggy uwsgi packages in some distros but not when they 
were fixed (fixed)

https://code.djangoproject.com/ticket/28037 - Incorrect return type in 
QueryDict.items()/values() docs examples (accepted)

https://code.djangoproject.com/ticket/28034 - Update the contributing 
tutorial to use a more recent patch (accepted)

https://code.djangoproject.com/ticket/28042 - mimetype Fallback for 
attachments passed to EmailMessage.__init__ removed (accepted)

https://code.djangoproject.com/ticket/28039 - 
BaseGeometryWidget.subwidgets() crashes with KeyError 'widget' (accepted)

Authored

--

https://github.com/django/django/commit/a1f948b468b6621083a03b0d53432341b7a4d753
 
- Fixed CVE-2017-7234 -- Fixed open redirect vulnerability in 
views.static.serve().

https://github.com/django/django/commit/5ea48a70afac5e5684b504f09286e7defdd1a81a
 
- Fixed #27912, CVE-2017-7233 -- Fixed is_safe_url() with numeric URLs. 

Reviewed/committed

--

https://github.com/django/django/pull/8286 - Fixed #11854 -- Added Azimuth 
GIS function.

https://github.com/django/django/pull/8278 - Fixed #27928 -- Avoided 
SET/DROP DEFAULT unless a field changes from null to non-null.

https://github.com/django/django/pull/8287 - Fixed #27573 -- Made Distance 
on geodetic coordinates return a raw value on MySQL.

https://github.com/django/django/pull/8272 - Refs #27834 -- Removed Value 
wrapping from StrIndex's substring param.

https://github.com/django/django/pull/8270 - Fixed #27974 -- Kept resolved 
templates constant during one rendering cycle.

https://github.com/django/djangoproject.com/pull/758 - Used correct sphinx 
builder for downloadable docs

https://github.com/django/django/pull/8294 - Fixed #28001 -- Updated 
comment and tested context popping in ForNode.render().

https://github.com/django/django/pull/8291 - .Fixed #28006 -- Allowed using 
D with lookups on Distance annotations.

https://github.com/django/django/pull/8328 - Fixed #28051 -- Made 
migrations respect Index's name argument.

https://github.com/django/django/pull/8116 - Fixed #25406 -- Removed 
exception hiding in PostgreSQL test database creation.

https://github.com/django/django/pull/8317 - Fixed #28038 -- Restored 
casting to text of builtin lookups on PostgreSQL.

https://github.com/django/django/pull/8323 - Fixed #28042 -- Fixed crash 
when using a two-tuple in EmailMessage's attachments arg.

https://github.com/django/django/pull/8260 - Fixed #27972 -- Made 
BaseSpatialField.geodetic() use SpatialReference.geographic.
https://github.com/django/django/pull/8325 - Refs #26605 -- Added 
migrations state test for a swappable model inheriting an abstract model 
inheriting concrete model.

-- 
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/e5699ac8-69b2-4e55-a743-e14bb475e33d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.