from:"Carl Meyer"

Re: Model-level validation

2022-09-29 Thread Carl Meyer

On Thu, Sep 29, 2022 at 6:19 PM Curtis Maloney  wrote:

> On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote:
>
> Why doesn't Django validate Models on save()?
>
>
> The short answer is: backwards compatibility.
>
> Model level validation hasn't always been a thing, with Django initially
> depending primarily on Form validation.
>
> Since it hadn't _always_ been there, it wasn't possible to introduce it,
> enforce it, and not break most apps out there.
>
> There was so much code written that generally assumed it could call
> `save()` and not have to catch validation errors.
>
> For what it's worth, I'm all in favor of making it run on `save()` ...
> updating the documentation and preparing the community is going to be a
> mammoth task, however. A safe course through this will take some very
> careful planning.
>

Another factor that should be considered is that the Django ORM gives you
plenty of ways to update your database (eg bulk updates on a queryset) that
clearly cannot materialize and validate every object in the queryset. So is
it better to consistently say “the ORM doesn’t validate, forms do,” or
better to say “the ORM will validate on Model.save() but not in various
other cases, so you still can’t really rely on the ORM to enforce model
validation invariants consistently.”

Carl

>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGLapGA7NCkNrBNe7LQmTOzbj%2Bpa3xm7_tEPnBa7eZbUsq1xGg%40mail.gmail.com.

Re: Simplify middlewares (again) and get rid of process_view

2018-05-30 Thread Carl Meyer

On 5/16/18 10:49 AM, Florian Apolloner wrote:
> Hi Carl,
> 
> On Wednesday, May 16, 2018 at 5:58:02 AM UTC+2, Carl Meyer wrote:
> 
> I'm not sure this part is feasible. It's an intentional part of
> middleware design AFAIK (and useful) that middleware can modify
> request.path and have this modification respected in view resolution.
> 
> 
> my proposed urlresolver_factory takes the request as argument and should
> therefore allow for anything that the middleware would allow too -- are
> there any specific usecases you have in mind that would require a
> middleware?

Composing two different middleware that both alter request.path for
different purposes? This will require the site owner to manually compose
in their urlconf_factory.

I think your core proposal that the main middleware call layering should
run after view resolution instead of before it is probably a better
design for middleware in principle, but it needs work in a couple areas:

1. Motivating the change in a way that clarifies how it will benefit
typical Django users, sufficiently to justify the churn. What new
possibilities are unlocked by the change, and has there been demand for
those possibilities?
2. Fleshing out how a reasonable transition path for existing middleware
(including third-party middleware) would look.

It's too bad we didn't think about this possibility during the original
DEP5, to avoid multiple middleware changes within a few Django versions.

Carl

-- 
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/679c0352-d374-a979-90e3-732ea619ac63%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Simplify middlewares (again) and get rid of process_view

2018-05-15 Thread Carl Meyer

Hi Florian,

On 5/12/18 10:22 AM, Florian Apolloner wrote:

> After refactoring the middlewares to new-style middlewares as we have them 
> now, I am left with two pain points:
> 
>  * atomic requests are still special cased and not in a middleware
>  * process_view is as useless as always (it can neither alter nor convert 
> args/kwargs or the view)
> 
> To change this I am proposing the following changes:
> 
>  * Deprecate request.urlconf and provide a way to set the urlconf __before__ 
> the middleware chain is entered
>  * Resolve view before the middleware chain is entered

I'm not sure this part is feasible. It's an intentional part of
middleware design AFAIK (and useful) that middleware can modify
request.path and have this modification respected in view resolution.

Carl

-- 
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/0c8e1164-931e-72a9-438c-c099fd7447ad%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: About migrations

2017-07-07 Thread Carl Meyer

On 07/07/2017 05:09 AM, Patryk Zawadzki wrote:
> Right, and one reason for generating those "no-op" migrations is that
> they aren't actually no-ops, if you value being able to write data
> migrations in Python using the ORM. They keep the historical Python
> models accurate.
> 
> I would argue that this is a fairly optimistic view of the current state :)
> 
> They are technically "historically accurate" but the point in history
> they represent is not necessary the one you had in mind unless you only
> have a single application and linear migrations (ie. no merge
> migrations). Our current dependency system only allows you to express
> "no sooner than X" but the graph solver can execute an arbitrary number
> of later migrations between the one you depend on and the one you wrote.
> 
> Imagine you have app A and migration M1 adds field F. You then create a
> migration M2 in another application B that needs to access F so you have
> it depend on (A, M1). Two months later field F is removed or renamed in
> migration M3. Django has two ways to linearize the graph: (A, M1), (B,
> M2), (A, M3) or (A, M1), (A, M3), (B, M2). Both are valid but the latter
> will result in a crash when migrating from an empty DB state. In
> practice we often have to add arbitrary dependencies to later migrations
> to force a Python migration to execute in the correct order.

Yeah, that's an issue I've certainly run into. It's not _that_
unreasonable or arbitrary to solve this by adding a dependency of (A,
M3) on (B, M2), but it would be better if we could express this as a
"must-run-before" dependency on the B side (since the dependency of app
B on app A may be one-way, and we shouldn't have to introduce knowledge
of B into A's migrations -- and A may even be third-party). IMO this
would be a reasonable feature addition.

Carl

-- 
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/042cd6a3-1e7c-b5a5-7909-2ef90f91c284%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: About migrations

2017-07-04 Thread Carl Meyer

On 07/04/2017 07:04 AM, Patryk Zawadzki wrote:
> Have DB backends understand certain field types expressed as strings
> ("varchar", "text", "blob", "decimal" and so on).
> 
> Possibly some backends could implement a wider set than the others
> ("json", "xml", "rasterimage" etc.).
> 
> Have each Field class deconstruct to a field name and params, eg:
> "decimal", {"digits": 12, "decimals": 2}.
> 
> Then a model becomes essentially a list of tuples:
> 
> [
> ("title", "varchar", {"length": 100}),
> ("price", "decimal", {"digits": 12, "decimals": 2}),
> ...
> ]
> 
> This is not far from what "render model states" does currently except
> that it compares much richer model descriptions that leads to no-op
> migrations being generated each time you change a label or a
> user-visible part of choices.

Right, and one reason for generating those "no-op" migrations is that
they aren't actually no-ops, if you value being able to write data
migrations in Python using the ORM. They keep the historical Python
models accurate.

Of course, we do pay a cost in complexity for the "historical ORM"
feature, and it's reasonable to prefer a tradeoff that doesn't pay that
cost and requires all data migrations to be written in SQL. As Andrew
mentioned, there's nothing to prevent anyone from writing an alternative
migrations frontend that takes this approach. It should be able to reuse
the schema editor backend, which does the heavy lifting of cross-db
schema alteration.

It's worth remembering, though, that five or six years ago we _had_ a
range of different migrations solutions that chose different tradeoffs,
and South was the clear winner in user uptake. It's not due to arbitrary
whim that the Django migrations system is based on South and preserves
its popular features, like the historical ORM.

Carl

-- 
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/43abcfed-edaa-6f05-04cc-f30a9b0e59e6%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

Re: Exceptions in model._meta._property_names with some 3rd-pty libraries

2017-06-02 Thread Carl Meyer

Hi Zack,

On 06/02/2017 02:02 PM, Zack Voase wrote:
> Hi all,
> 
> I'm encountering exceptions in a number of popular third-party Django
> libraries when upgrading from 1.8 to 1.11. The code path is typically
> `MyModel.objects.get_or_create(...)`, which causes
> `model._meta._property_names` to be checked (to make sure we're not
> querying/setting a property). The problem is, `_property_names` is
> implemented as follows:
> 
> |
> # in django/db/models/options.py:
> def_property_names(self):
> returnfrozenset({
>attr forattr in
>dir(self.model)ifisinstance(getattr(self.model,attr),property)
> })
> |
> 
> The problem is when a custom field installs a field descriptor on the
> model class (during `contribute_to_class()`), with a `__get__()` method
> like this:
> 
> |
> classSomeFieldDescriptor(object):
> # ...
> def__get__(self,instance,type=None):
> ifinstance isNone:
> raiseAttributeError("Can only be accessed via an instance.")
> # ...
> |

I can see two things here that could be done better, one on Django side
and one on third-party app side.

1) I've never seen a good reason for a descriptor to raise an
AttributeError like that. Typically `return self` is a much more useful
option for the "access on the class" scenario, if the descriptor can't
provide useful behavior in that case, as it allows introspecting the
class and finding the descriptor object.

2) On the Django side, I think we should switch to using
`inspect.getattr_static`, to avoid any possibility of triggering
side-effecty descriptor code of any kind. AttributeError is only the
most visible problem here; there could be much subtler problems (e.g.
performance issues) caused by e.g. accessing a descriptor that does a
database query or something.

Carl

-- 
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/fbd639ad-6a51-7657-f647-753cbc3b6b90%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

Re: Cython usage within Django

2017-05-21 Thread 'Carl Meyer' via Django developers (Contributions to Django itself)

On 05/21/2017 02:59 PM, Tom Forbes wrote:
> There are lots of considerations to take into account (like ensuring the
> Cython functions are in sync with the fallback ones)

It's possible to only have one version of the code, using only Python
syntax, and conditionally compile it with Cython if available. This
gives up some potential efficiency wins from type annotation, but avoids
the need to keep two copies in sync.

Regardless, though, I think CI would need to run the tests both with
Cython and with non-Cython fallback.

We've moved toward releasing wheels instead of sdist on PyPI for recent
versions; for this to be useful it would mean releasing multiple binary
wheels for different platforms.

There's no question this could make a big difference to Django CPU
usage; the question is whether it's worth the added CI and release
complexity when it would likely provide little value to the majority of
Django users.

Carl

--
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/ff2d35c1-e384-e010-b57f-d249df3340b2%40instagram.com.
For more options, visit https://groups.google.com/d/optout.

Re: Database "execute hooks" for instrumentation

2017-04-07 Thread Carl Meyer

Hi Shai,

On 04/07/2017 06:02 AM, Shai Berger wrote:
> This is an idea that came up during the djangocon-europe conference: Add the 
> ability to install general instrumentation hooks around the database 
> "execute" 
> and "executemany" calls.
> 
> Such hooks would allow all sorts of interesting features. For one, they could 
> replace the current special-case allowing assertNumQueries & friends to 
> record 
> queries out of debug mode (it's an ugly hack, really), but they could also 
> support my imagined use case -- a context-manager which could prevent 
> database 
> access during execution of some code (I'm thinking mostly of using it around 
> "render()" calls and serialization, to make sure all database access is being 
> done in the view).

Another use-case is for preventing database access during tests unless
specifically requested by the test (e.g. pytest-django does this,
currently via monkeypatching).

> My idea for implementation is to keep a thread-local stack of context-
> managers, and have them wrap each call of "execute". We could actually even 
> use one such context-manager instead of the existing CursorDebugWrapper.

Why a new thread-local instead of explicitly per-connection and stored
on the connection?

Carl

-- 
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/5d5ee8f1-6b22-c48c-7a6b-11eac2928b64%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: A proposal for a new auto-reloader in Django

2017-04-02 Thread Carl Meyer

Hi David,

I wouldn't bother with the wsgiwatcher repo; it's proof-of-concept code
from one sprint's worth of hacking, not used by anyone. Look at hupper
instead, it is based on wsgiwatcher, but much changed, and actually used
in production.

Carl

On 04/02/2017 04:27 PM, qingnian...@gmail.com wrote:
> Hi Carl,
>   I don't quite understand why get_module_paths() in your wsgiwatcher
> project is returning a list of python module paths. I thought it would
> return the directory that needs to be monitored. Could you please tell
> me how this part works? Thanks.
> 
> David Ma
> 
> On Thursday, March 30, 2017 at 7:47:13 AM UTC-7, Carl Meyer wrote:
> 
> Anyone working on this project should at least be aware of
> https://github.com/Pylons/hupper <https://github.com/Pylons/hupper>
> (based on work David Glick and I
> originally did in https://github.com/carljm/wsgiwatcher
> <https://github.com/carljm/wsgiwatcher>), which aims to
> be a framework-agnostic solution to this problem for any Python web
> project. Docs at
> http://docs.pylonsproject.org/projects/hupper/en/latest/
> 
> <http://www.google.com/url?q=http%3A%2F%2Fdocs.pylonsproject.org%2Fprojects%2Fhupper%2Fen%2Flatest%2F=D=1=AFQjCNHhMlzZ6K6HLWsxUxOPanWzxLeMlg>
> 
> 
> Carl
> 
> -- 
> 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
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com
> <mailto: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/4fac9a8a-231d-41c5-a5fb-6eaeb2bd148f%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/4fac9a8a-231d-41c5-a5fb-6eaeb2bd148f%40googlegroups.com?utm_medium=email_source=footer>.
> 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/99fbed1c-3ac4-64b9-5030-3d5e2533cef4%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: A proposal for a new auto-reloader in Django

2017-03-30 Thread Carl Meyer

Anyone working on this project should at least be aware of
https://github.com/Pylons/hupper (based on work David Glick and I
originally did in https://github.com/carljm/wsgiwatcher), which aims to
be a framework-agnostic solution to this problem for any Python web
project. Docs at http://docs.pylonsproject.org/projects/hupper/en/latest/

Carl

-- 
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/af0d4ea6-e97e-522e-947a-83db87c6ebd0%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Adding a middleware to match cookies

2017-01-07 Thread Carl Meyer

On 01/07/2017 03:25 AM, Florian Apolloner wrote:
> On Saturday, January 7, 2017 at 3:50:56 AM UTC+1, Jeff Willette wrote:
> 
> What if there was an optional middleware early in the request
> processing that matched cookies based on a regex in settings and
> then modified the header to only include the matched cookies?
> 
> 
> I do not see how this would help -- you'd still have to set "Vary:
> Cookie" on the response as soon as you are accessing request.user. Or is
> the goal of this to allow Django's internal page caching stuff to ignore
> some cookies? That seems doable, but very very dangerous.

Right, the latter is how I understood it; you'd still use Vary: Cookie,
but strip some cookies before the request reaches the cache middleware.

I don't think it's too dangerous, if you're conservative about the
cookies you strip (e.g. only strip cookies that are known for sure to be
unused on the server, like Google Analytics cookies for instance.)

> 
> This issue reminds me of another issue I came up with (or as Carl puts
> it: "…presenting the hypothetical case that exposed this bug."), namely
> https://code.djangoproject.com/ticket/19649 -- Basically as soon as
> Django accesses __any__ cookie we should set "Vary: Cookie", with all
> the downsides this entails. I think we finally should fix that and put a
> fix for it into the BaseHandler.

+1

> What would be great would be an HTTP header which allowed for something
> ala "Cache: if-request-did-not-have-cookies" -- usually it is pointless
> to cache __anything__ with cookies anyways. That said, with all the
> analytics super cookies out there, there are not many pages without
> cookies anymore :(

+1. Basically analytics have already effectively broken HTTP caching as
it was designed to work.

Carl

-- 
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/709febeb-8336-aafa-7faa-74d1e2b46802%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Adding a middleware to match cookies

2017-01-07 Thread Carl Meyer

On 01/06/2017 11:26 PM, Jeff Willette wrote:
> Wy would this not help the efficiency of the downstream caches? Is it
> because the request has already passed through them with the cookies
> intact? and when it comes back through the response they have no way to
> know they have been stripped?

That's correct. Stripping cookies from the request in Django is far too
late to have any effect on an external cache. If the request has reached
Django, then it's already passed through any external caching proxies,
with all cookies, and the cache has already decided not to serve a
cached response. (And if the cache holds on to the response, it'll
associate with the the request it saw, which still had all its cookies).

Carl

-- 
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/d1383be4-749e-3183-4354-ac0047bd0517%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

Re: Adding a middleware to match cookies

2017-01-06 Thread Carl Meyer

Hi Jeff,

On 01/06/2017 06:21 PM, Jeff Willette wrote:
> I understand that calling is_authenticated on a user will require the
> session to be accessed and the vary by cookie header to be in the
> response, but if I understand how caching systems work then this will
> cause all cookies in the request to be taken into account, correct?

Yes. HTTP doesn't provide any way to say "vary only on this cookie, not
the others." Be nice if it did!

> What if there was an optional middleware early in the request
> processing that matched cookies based on a regex in settings and then
> modified the header to only include the matched cookies?
> 
> That way...the unauthed users request will vary by cookies, but we
> would have removed all inconsequential cookies so all unauthed users
> will have the same set of cookies (likely none), and authed users
> will have (sessionid) or whatever else you wish to match and everyone
> will be happily cached correctly.
> 
> Is there a hole in my thinking anywhere? Would this work as I
> expect?

I think it could work, yeah. It won't help the efficiency of any other
downstream HTTP caches, but they would still be safe (not serve anyone
the wrong response). And you should be able to help efficiency of
Django's own cache this way, if you strip cookies that Django / your
code doesn't care about before the request ever reaches the caching
middleware. Try it and experiment!

Carl

-- 
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/65281bd7-a2f6-d428-9743-683714c83057%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Template handling of undefined variables

2017-01-04 Thread Carl Meyer

Hi Tim,

On 01/04/2017 03:39 PM, Tim Martin wrote:
> I've been looking at bug #24977 (Template variables with a value of
> None are considered to be == to non-existent properties).
...
> The suggestion on the ticket is to use an instance of a special
> `Undefined` class to indicate an undefined variable, which could never
> compare equal to anything else.
> 
> This sounds sensible, but in implementing it I got to thinking about
> whether this can generalise and simplify. It seems like it might be
> possible to combine both Engine.string_if_invalid and the
> ignore_failures parameter to FilterExpression.resolve:
> 
> * The Undefined object can have a __str__() that returns the
>   string_if_invalid value, so it acts like a string for the purposes
>   of rendering.
> 
> * Returning the Undefined value is also sufficient to provide the
>   behaviour we need in the ignore_failures case: the calling code can
>   check for Undefined in the same case where it currently checks for
>   None.
> 
> Overall the code is simpler, because a bunch of code paths are
> eliminated.

Sounds great!

> However, there are 2 issues:
>
> 1) There are test cases where we have templates that should treat "x
>is y" as True where x and y are both undefined.

Really? Is this an accidental side effect of some historical change, or
really the intent of the test? That behavior seems buggy to me; more
likely to be a bug-magnet than useful.

...
>I don't see any way to satisfy both these requirements. Is it
>reasonable to relax the requirement that "x is y" should be treated
>as True when both variables are undefined?

Seems reasonable to me.

> 2) There appears to be an inconsistency in the default_if_none
>modifier. If I have a template with
> 
>x|default_if_none:y = {{x|default_if_none:y}}
>{% if x|default_if_none:y %}
>x|default_if_none:y is apparently True
>{% endif %}
> 
>with y defined to True and x undefined, then it produces:
> 
>x|default_if_none:y =
>x|default_if_none:y is apparently True
>   
>IOW it appears that the default_if_none doesn't cause y's value to
>be used in the case where the variable is being printed, even
>though it causes the expression to have y's value when evaluated in
>an if. I think this is something to do with the fact that the two
>ways of handling failures (ignore_failures and string_if_invalid)
>do different things.
> 
>I don't see a way to make backward compatible code here.
> 
>I think this is just a bug, does anyone think otherwise?

I agree.

Carl

-- 
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/14c76486-2649-c68f-a463-b5acf41b9556%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Changing {% include %} to strip a trailing newline

2017-01-04 Thread Carl Meyer

On 01/04/2017 02:53 PM, Tim Graham wrote:
> I'd like to know from Carl, Adam, and others, how much effort would be
> required to adapt the templates in your project for the new behavior. I
> imagine a script could be written to add newlines after all {% include
> %} in all plain text templates, for example.

Not much, I'd expect. Plain text templates aren't the common case, and
many of them don't use {% include %} anyway. And as you say, it is a
scriptable change if necessary.

That said, IMO the perceived cost of backwards-incompatible changes at
upgrade time scales with the number of changes required, even when
individually they don't require much work to fix. In theory, we promise
backwards-compatibility, and I don't think "call it a bugfix" can be a
universal escape hatch; it's clear that the current behavior has been
known and accepted for years. If we change this, it's a small but
incompatible change in the known and intended behavior, it's not fixing
a bug. But we've bitten the bullet and made far larger
backwards-incompatible changes in the past, so...

There is also the possibility that someone is relying on this behavior
in a more intentional way than I've ever done myself; e.g. has an
include file with multiple trailing newlines or other trailing
whitespace, specifically because it's desired in multiple different
places (in a preformatted text context). This (admittedly hypothetical)
case isn't quite as trivial to work around, if you propose to strip all
trailing whitespace. Or do you propose to strip only exactly one
trailing newline character?

In the end, I'm happy to abstain from this decision; I wouldn't really
be upset by any of the three options Aymeric listed.

Carl

-- 
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/d0dd9fb3-a009-bbe6-64fa-906d5cc44ff3%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

1 2 3 4 5 6 7 >

1 - 100 of 667 matches

Mail list logo