django.utils.html.urlize and mark_safe

[Gábor Farkas]

hi,

i think there is some use of unnecessary mark_safe in the above-mentioned
function, but maybe i am overlooking something, so i thought before opening
a ticket i will discuss it here.

if you check the urlize-function
https://github.com/django/django/blob/master/django/utils/html.py#L173,

it basically splits the text into parts, changes some of the parts, and
then joins them back together.

when processing the parts, if the original content was marked-safe, it will
mark_safe the parts too (more or less, i am skipping some details).
but at the end, it uses ''.join to join them.

but, joining marked-safe strings does not preserve the marked-safe status.
in other words:

type(''.join([mark_safe('')])) == str

so why do we spend time on marking the parts as safe, when we simply lose
this info at the end?

thanks,
gabor

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django 2.0 - a case for a customizable pony

[Yo-Yo Ma]

This morning read the SQLAlchemy proposal made by Luke Plant in June. I 
then decided that this would be a good time to rant about abstraction, 
extensibility, and decoupling.

Background


For years, Django has been forced to deal with most implementation issues 
from within, including the ORM, templates, etc. Even things like JSON 
support and basic timezones (for the new timezone module) were or are built 
right into the framework, in order to handle heterogeneous environments and 
Python versions, and to minimize external dependencies. This strategy 
contributed to the success of Django, in part because finding nice, well 
supported libraries was tough, and installing dependencies was too.

The Python community has grown and its processes have matured nicely. 
Nowadays, for a given problem, there are typically multiple solutions, many 
listed on services like www.djangopackages.com. Installing packages is 
easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks 
to services like GitHub. This trend can be summarized as abstraction, which 
is a good thing. Handling things at a proper abstraction level is always a 
time and heartache saver, and is of course the reason for using a framework 
like Django in the first place.

The Problem
-

Solving too many problems from the top down, and coupling things too 
tightly in a project leads to code rot, because implementations all have to 
be written by somebody who is intimate with many other parts of the 
framework, then they have to be vetted others who are intimate with many 
parts of the framework, and then the code has to be maintained. Coupling 
becomes an inevitability, simply because it is possible. Backwards 
compatibility becomes more and more difficult and costly to maintain, and 
prohibits growth. Projects built atop the framework eventually run into 
problems for which the solution is to make changes to implementation 
details (usually via subclassing, but in some cases, via monkey patches), 
which leads to code debt in a project, and subsequent contention in the 
community when implementation details are changed in a way that breaks 
backwards compatibility for those "power users".

This means that the issue of "We can't do that because it'll break things" 
isn't really the problem that Django has. It's a symptom of another 
problem, which is that Django is not nearly extensible enough (it's parts 
are not pluggable enough, and or are not well enough abstracted to be 
quickly changed and/or moved).

So, what?
-

So, Django has evolved toward being a more decoupled, less monolithic 
framework over the past couple years (e.g., the removal of auth's coupling 
to things like messages, customizable user models, etc.), but there is a 
lot left to be desired. I consider a Python web framework to be a minimum 
of A) request handling, B) URL routing to something callable (a view), and 
C) response handling. However, certain other things are good ideas to bake 
in, such as cookie handling, security related features (CSRF, click 
jacking, etc.), and probably a few others. Anything else should be 
completely pluggable, and completely decoupled from everything else.

Some examples which make me smile:

Sessions - 
Cache - includes support for plugging in a back-end and only defines a 
simple interface (cache.set, cache.get, etc.)
Mail - includes support for writing / plugging the back-end of your 
choice, only defines a simple interface (send_mail, send_mass_mail, etc.)

Some examples which make me sad:

Templates - unpluggable (importing a third party template library and 
using it in your view is not plugging it in, since this isn't compatible 
with 3rd party or contrib apps)
ORM - I'll defer to the complexities that arose from Luke's proposal
Admin - lacks abstraction, and therefore has some great tools that 
can't really be used elsewhere (e.g., filter specs, sorting, etc.), lacks 
usage of CBV, in favor of an ad hoc solution

The Solution
-

>From an interface perspective, I have some ideas about how to handle the 
templates side of things, and some pretty vague ideas of how to handle the 
ORM, but I personally think that the real solution is to work not on 
implementing new ideas and solutions to use beside or in place of existing 
ones, but rather to fix the underlying problem that Django has. We can 
fight an uphill battle constantly by trying to usher new ideas in over our 
12 foot wall, believing that it is indestructible, or we can work together 
to "Tear down this wall!" :)

Remember, we're at 1.5 now. If we have a specific goal in mind that is very 
drastically different now, we can do a lot before 2.0 without breaking 
backwards compatibility (at least not too badly).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg

Re: Django 2.0 - a case for a customizable pony

[Jacob Kaplan-Moss]

I don't really know how to respond to this other that "patches welcome".
You're proposing very vague, sweeping changes with no details. That just
doesn't work around here; if you want to make a big change you have to
actually bring some hard work to the table. I think I probably agree with
you in theory, but if you're serious about this and you want my help you
need to show me some code.

Jacob


On Tue, Dec 4, 2012 at 1:14 PM, Yo-Yo Ma  wrote:

> This morning read the SQLAlchemy proposal made by Luke Plant in June. I
> then decided that this would be a good time to rant about abstraction,
> extensibility, and decoupling.
>
> Background
> 
>
> For years, Django has been forced to deal with most implementation issues
> from within, including the ORM, templates, etc. Even things like JSON
> support and basic timezones (for the new timezone module) were or are built
> right into the framework, in order to handle heterogeneous environments and
> Python versions, and to minimize external dependencies. This strategy
> contributed to the success of Django, in part because finding nice, well
> supported libraries was tough, and installing dependencies was too.
>
> The Python community has grown and its processes have matured nicely.
> Nowadays, for a given problem, there are typically multiple solutions, many
> listed on services like www.djangopackages.com. Installing packages is
> easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks
> to services like GitHub. This trend can be summarized as abstraction, which
> is a good thing. Handling things at a proper abstraction level is always a
> time and heartache saver, and is of course the reason for using a framework
> like Django in the first place.
>
> The Problem
> -
>
> Solving too many problems from the top down, and coupling things too
> tightly in a project leads to code rot, because implementations all have to
> be written by somebody who is intimate with many other parts of the
> framework, then they have to be vetted others who are intimate with many
> parts of the framework, and then the code has to be maintained. Coupling
> becomes an inevitability, simply because it is possible. Backwards
> compatibility becomes more and more difficult and costly to maintain, and
> prohibits growth. Projects built atop the framework eventually run into
> problems for which the solution is to make changes to implementation
> details (usually via subclassing, but in some cases, via monkey patches),
> which leads to code debt in a project, and subsequent contention in the
> community when implementation details are changed in a way that breaks
> backwards compatibility for those "power users".
>
> This means that the issue of "We can't do that because it'll break things"
> isn't really the problem that Django has. It's a symptom of another
> problem, which is that Django is not nearly extensible enough (it's parts
> are not pluggable enough, and or are not well enough abstracted to be
> quickly changed and/or moved).
>
> So, what?
> -
>
> So, Django has evolved toward being a more decoupled, less monolithic
> framework over the past couple years (e.g., the removal of auth's coupling
> to things like messages, customizable user models, etc.), but there is a
> lot left to be desired. I consider a Python web framework to be a minimum
> of A) request handling, B) URL routing to something callable (a view), and
> C) response handling. However, certain other things are good ideas to bake
> in, such as cookie handling, security related features (CSRF, click
> jacking, etc.), and probably a few others. Anything else should be
> completely pluggable, and completely decoupled from everything else.
>
> Some examples which make me smile:
>
> Sessions -
> Cache - includes support for plugging in a back-end and only defines a
> simple interface (cache.set, cache.get, etc.)
> Mail - includes support for writing / plugging the back-end of your
> choice, only defines a simple interface (send_mail, send_mass_mail, etc.)
>
> Some examples which make me sad:
>
> Templates - unpluggable (importing a third party template library and
> using it in your view is not plugging it in, since this isn't compatible
> with 3rd party or contrib apps)
> ORM - I'll defer to the complexities that arose from Luke's proposal
> Admin - lacks abstraction, and therefore has some great tools that
> can't really be used elsewhere (e.g., filter specs, sorting, etc.), lacks
> usage of CBV, in favor of an ad hoc solution
>
> The Solution
> -
>
> From an interface perspective, I have some ideas about how to handle the
> templates side of things, and some pretty vague ideas of how to handle the
> ORM, but I personally think that the real solution is to work not on
> implementing new ideas and solutions to use beside or in place of existing
> ones, but rather to fix the underlying problem that Django has. We can
> fig

Re: Django 2.0 - a case for a customizable pony

[ptone]

I think you can see one pilot of future decoupling with what is happening 
with the localflavors being split into separate repos - what we learn from 
this process will be valuable when/if considering decoupling other parts of 
Django.

Another major step is the pretty-far-along schema migration work from 
Andrew, which will allow for the potential of schema changes in upgrade 
scripts.

I disagree that working on cleanly factoring and decoupling components "in 
place" isn't worth doing, in fact when you can add backends/plugability 
somewhere, and ship a BC version as the default - you've just fixed one of 
your "underlying problems"

See for example:

https://code.djangoproject.com/ticket/17093

There is no reason changes like that have to be part of a "2.0" departure, 
and in general talking about anything as being 2.0 related ultimately feels 
more distracting than productive.

Anyway - as you say - progress has been made - lets do more of that ;-)

-Preston

On Tuesday, December 4, 2012 11:14:50 AM UTC-8, Yo-Yo Ma wrote:
>
> This morning read the SQLAlchemy proposal made by Luke Plant in June. I 
> then decided that this would be a good time to rant about abstraction, 
> extensibility, and decoupling.
>
> Background
> 
>
> For years, Django has been forced to deal with most implementation issues 
> from within, including the ORM, templates, etc. Even things like JSON 
> support and basic timezones (for the new timezone module) were or are built 
> right into the framework, in order to handle heterogeneous environments and 
> Python versions, and to minimize external dependencies. This strategy 
> contributed to the success of Django, in part because finding nice, well 
> supported libraries was tough, and installing dependencies was too.
>
> The Python community has grown and its processes have matured nicely. 
> Nowadays, for a given problem, there are typically multiple solutions, many 
> listed on services like www.djangopackages.com. Installing packages is 
> easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks 
> to services like GitHub. This trend can be summarized as abstraction, which 
> is a good thing. Handling things at a proper abstraction level is always a 
> time and heartache saver, and is of course the reason for using a framework 
> like Django in the first place.
>
> The Problem
> -
>
> Solving too many problems from the top down, and coupling things too 
> tightly in a project leads to code rot, because implementations all have to 
> be written by somebody who is intimate with many other parts of the 
> framework, then they have to be vetted others who are intimate with many 
> parts of the framework, and then the code has to be maintained. Coupling 
> becomes an inevitability, simply because it is possible. Backwards 
> compatibility becomes more and more difficult and costly to maintain, and 
> prohibits growth. Projects built atop the framework eventually run into 
> problems for which the solution is to make changes to implementation 
> details (usually via subclassing, but in some cases, via monkey patches), 
> which leads to code debt in a project, and subsequent contention in the 
> community when implementation details are changed in a way that breaks 
> backwards compatibility for those "power users".
>
> This means that the issue of "We can't do that because it'll break things" 
> isn't really the problem that Django has. It's a symptom of another 
> problem, which is that Django is not nearly extensible enough (it's parts 
> are not pluggable enough, and or are not well enough abstracted to be 
> quickly changed and/or moved).
>
> So, what?
> -
>
> So, Django has evolved toward being a more decoupled, less monolithic 
> framework over the past couple years (e.g., the removal of auth's coupling 
> to things like messages, customizable user models, etc.), but there is a 
> lot left to be desired. I consider a Python web framework to be a minimum 
> of A) request handling, B) URL routing to something callable (a view), and 
> C) response handling. However, certain other things are good ideas to bake 
> in, such as cookie handling, security related features (CSRF, click 
> jacking, etc.), and probably a few others. Anything else should be 
> completely pluggable, and completely decoupled from everything else.
>
> Some examples which make me smile:
>
> Sessions - 
> Cache - includes support for plugging in a back-end and only defines a 
> simple interface (cache.set, cache.get, etc.)
> Mail - includes support for writing / plugging the back-end of your 
> choice, only defines a simple interface (send_mail, send_mass_mail, etc.)
>
> Some examples which make me sad:
>
> Templates - unpluggable (importing a third party template library and 
> using it in your view is not plugging it in, since this isn't compatible 
> with 3rd party or contrib apps)
> ORM - I'll defer to the complexities that ar

Doc fix for list_editable fields for 1.1 - 1.5

[Fred Cox]

Please consider incorporating a doc patch (attached to #11313) for this 
release, and backpatching it to previous docs (1.1 - 1.4).

The current implementation of list_editable in the Django admin is 
fundamentally broken in the face of possible changes to the data while the 
list page is up in the browser.  It has caused data destruction in our 
organization, and others.

When I get my head above water, I would be glad to help out actually fixing 
the bug, but I find it unconscionable that a known critical bug like this 
be allowed to continue to trap new users.  It should never have been marked 
as a new feature. The doc patch is simple and to the point, and was 
requested by otheres twice 13 months ago and 3 years ago, when there was 
activity on this bug in the past.

Thanks,

Fred Cox

- Forwarded Message -
*From:* Django 
*To:* 
*Cc:* django-upda...@googlegroups.com 
*Sent:* Tuesday, December 4, 2012 1:44 PM
*Subject:* Re: [Django] #11313: list_editable fields don't support 'save' 
in multiuser environment

#11313: list_editable fields don't support 'save' in multiuser environment
+--
Reporter:  margieroginski  |Owner:  nobody
Type:  Bug|  Status:  reopened
Component:  contrib.admin  |  Version:  1.1-beta-1
Severity:  Normal  |  Resolution:
Keywords:  |Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
+--
Changes (by aaugustin):

* severity:  Release blocker => Normal


Comment:

1.5 beta has been released. At this stage, only tickets that must be fixed
for RC1 can be release blockers.

Please don't abuse Trac's flags to push your personal agenda at the
expense of everyone else who's waiting for 1.5 final.

If you want to drive more attention to this issue, please write to the
django-developers mailing list.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/3FR94650of8J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.