Hi all,
Here is this week's report. You can see a more readable version of
this report at
https://code.djangoproject.com/wiki/DjangoFellows/BerkerPeksag#Weekof2015-01-12
Code reviews
* https://github.com/django/django/pull/3908 -- Fixed #24145 --
Changed POST redirect error to be rais
On Friday, January 16, 2015 at 10:19:15 PM UTC+2, Tim Graham wrote:
>
> Here’s my final report for the 3 month fellowship pilot. I hope the DSF’s
> fundraising efforts will be successful and I’ll have an opportunity to "be
> back" soon. :-)
>
>From my point of view the fellowship pilot has been
Hi all,
I'm strongly against lists. Lists are mutable objects, their components can
be changed in place. The settings are initialized at server start and after
that changes on them arn't reflected. Therefore all settings should be
tuples from my point of view. Using a custom list/tuple class fo
On Monday, January 19, 2015 at 12:35:10 PM UTC+1, Andreas Kahnert wrote:
>
> I'm strongly against lists. Lists are mutable objects, their components
> can be changed in place. The settings are initialized at server start and
> after that changes on them arn't reflected. Therefore all settings s
I'm not talking about modifications inside the settings.py but in other
place. With lists, unexperienced devs might do things like: from
django.conf import settings; settings.TEMPLATE_DIRS[3] = '/my_tpls'; and
expect to work out good. (This doesn't violate the docs, since technicaly
settings.TE
I think Florian's point would be that you can still do:
from django.conf import settings
settings.TEMPLATE_DIRS += ('foo',)
if it is a tuple, so I don't really see how it being a tuple is making it
necessarily more safe than a list - is the above code really much different
to:
from django.conf i
Test Code:
old_var = settings.TEMPLATE_DIRS
settings.TEMPLATE_DIRS += ('foo',) if isinstance(settings.TEMPLATE_DIRS,
tuple) else ['foo']
old_var is settings.TEMPLATE_DIRS # will return True if it was a list;
will return False if it was a tuple, since a new tuple was assigned to
settings.TEMPLAT
Hi Andreas,
I agree that tuples do slightly help enforce that settings are supposed to
be immutable, and I agree that if someone were to try to modify the
settings the way you showed it would be very hard to debug. However, I
think it's a pretty rare case.
I think a much more common case is th
On Monday, January 19, 2015 at 3:45:18 PM UTC+1, Andreas Kahnert wrote:
>
> I'm not talking about modifications inside the settings.py but in other
> place. With lists, unexperienced devs might do things like: from
> django.conf import settings; settings.TEMPLATE_DIRS[3] = '/my_tpls'; and
> expe
Well, yep. You can't prevent programmers to do stupid things in python. But
I'm kind of a theroretician and it hurts me if I see that exactly that what
it should not be is proposed as the standard. And for the dicts: In my
private code-base I use a frozendict c-package I wrote.
@Collin: The not
PS: python should be able to access tuple members faster, because it can be
implemented as array instead of double-linked-structs which are necessary
mutable lists. But as far as I know it doesn't.
--
You received this message because you are subscribed to the Google Groups
"Django developers
Thanks, Anssi. By the way, we are compiling testimonials to help in the
fundraising efforts. Do you mind if we include those two sentences from
you? (feel free to add a couple more sentences if you like). If anyone else
would like to share one, please send them my way. I am especially
intereste
On 01/19/2015 10:21 AM, Tim Graham wrote:
> Thanks, Anssi. By the way, we are compiling testimonials to help in the
> fundraising efforts. Do you mind if we include those two sentences from
> you? (feel free to add a couple more sentences if you like). If anyone else
> would like to share one, p
Hi Andreas,
As Florian pointed out, you can't mutate a tuple, but you can mutate the
settings object, so using a tuple or a frozendict won't buy you much.
Regarding the theoretical perspective, tuples aren't meant to be immutable
lists. Tuples are for heterogenous collections of fixed size (e.g
Hi Loïc,
I agree that we should not discuss about the theoretical aspects too much
(while I disagree on your distinction, the API difference is just their
mutability, so unless you refer to python intern algorithms for sort-
/lookup- optimization (if so, excuse me) your distinction is just your
> On Jan 20, 2015, at 01:43, Andreas Kahnert wrote:
>
> Hi Loïc,
>
> I agree that we should not discuss about the theoretical aspects too much
> (while I disagree on your distinction, the API difference is just their
> mutability, so unless you refer to python intern algorithms for sort-
>
Interesting, ... so excuse me.
The next point also clearifys my PS from above, lists are over-allocated
dynamic sized arrays. (this explains why python is such an memory eater as
well as why I experienced performance loss when using the mutability of
lists extensivly)
Am Montag, 19. Januar 201
I advertise that strongly against lists, because we actually had that kind
of issue in our company.
One colleague created a list with phrases for some verbose logging in the
settings.py. In the view function he promoted this list together with the
actual data, also a list which is used for stori
The situation you described was definitely a learning experience for your
company. Your strong opinion in favor of tuples is also noted.
For the various reasons stated in this thread, I'm still +1 for lists.
Regards,
Michael Manfre
On Mon, Jan 19, 2015 at 3:13 PM, Andreas Kahnert wrote:
> I ad
On 01/19/2015 01:13 PM, Andreas Kahnert wrote:
> I advertise that strongly against lists, because we actually had that
> kind of issue in our company.
> One colleague created a list with phrases for some verbose logging in
> the settings.py. In the view function he promoted this list together
> wit
On 19 janv. 2015, at 21:13, Andreas Kahnert wrote:
> I advertise that strongly against lists, because we actually had that kind of
> issue in our company.
Hi Andreas,
This is probably obvious, but I thought I’d mention it just in case — you can
keep
using tuples in your projects. We’re just ta
>
> Perhaps we’ll bikeshed names at some point but let’s leave the “naming
> things” problem aside for now.
> “name” must be optional for loaders that don’t load templates from
> files.
> “loadname” must be optional too for templates instantiated from
> strings.
> Here option
You can of course include what I wrote.
A little known fact is that since DuTH I have committed two patches myself,
yet authored several patches my self. I have essentially stopped using my
commit bit. I did this mostly to test how a workflow where Django
contributors do not commit their patche
23 matches
Mail list logo
