Hi Andreas,
I'm completely in agreement with you that *in theory* using tuples would
be a (very marginal) improvement. I also happen think that the idea that
tuples are semantically different from simply being immutable lists is a
nonsense - regardless of what a particular section of documentation may or
may not say, language features are defined solely in terms of their
behavior, they do not have dreams, hopes and grand philosophical outlooks
on how they should be used.
However, the simple case that tuples have a far poorer syntax in python
than lists, and are *very* easy for beginners to get wrong is a good enough
reason to prefer the usage of lists consistently.
("a string")
("a tuple",)
Beginners will not be following your "I notate every (globally available)
constant sequence in the pattern" advice, and no amount of documentation is
sufficient to prevent it being a very simple and easy error, that might be
difficult for a beginner to track down. I think that's a bigger and easier
trap than intentional assignment.
> accidental assignment to the settings object itself could be easily
prevented with a __setattr__ method on its class
I'd suggest treating that as a separate issue - perhaps if you or someone
else came up with a pull request that enforced immutability of the settings
object that'd be considered on it's own merits. (Note that you could
perfectly well also deal with making translating list and dict objects into
immutable objects at *that* point of API, even if they're not in the
settings module.) I haven't given that any great thought, so expect it
would have it's own set of obstacles to overcome, but I think it's a
different issue to the topic at hand here, which is really just about
settling on an acceptable and consistent style.
> maybe a compromise would be to explicitly note in the docs
I'd be against that as unnecessary fluff - doing one thing in the code and
recommending another in the docs just introduces noise and uncertainty.
The topic's been discussed more that it really deserves, but I understand
that it can be frustrating if it feels like your reasoned arguments are
being brickwalled. I wanted to at least contribute and note that I do agree
with you in theory, even if practically I'd say that lists throughout is
consistent, clear, and slightly less likely for developers to get wrong.
Cheers,
Tom
On Tuesday, 20 January 2015 17:52:51 UTC, Andreas Kahnert wrote:
>
> Just for completness: accidential assignment to the settings object itself
> could be easily prevented with a __setattr__ method on its class, since
> django yields on various other places about configuration problems it could
> not be wrong if the programmer gets noted about an illegal assignment. If
> everything works fine the method will only get called during startup, so
> there is no runtime overhead. Simplified example:
> def __setattr__(self, key, val):
> if self.configured:
> raise Exception('settings can not be changed after server startup')
> super(LazySettings, self).__setattr__(key, val)
>
> @Carl Meyer: At the first hand you're right, a thing all programmers
> should know about (if they call themself so), but he assumed there existed
> some kind of copy-on-read semantic for the settings, because you get
> something different when imported from django.conf instead directly and
> because it's a "magical" lazy object.
>
>
> But since you all seem to like lists that much, maybe a compromise would
> be to explicitly note in the docs that there is a danger in using lists
> which can be prevented by tuple usage.
>
--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/063919e0-8d5e-4bfc-b6dc-429885fcfbc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
