Re: auth.User refactor: reboot

[Joe Tennies]

> illustrate how you would make your own User model. In the case where
> you want a foreign key to User you can import the default user model
> from newauth.models as User much like you do with the current django
> auth app.
>
> See: http://ianlewis.bitbucket.org/django-newauth/third_party.html
>
> >> This is going to be the biggest problem with my solution. There would
> >> probably have to be some kind of compatibility layer added to make
> >> existing apps work or to provide a simpler migration path.
> >
> > Isn't the compatibility layer just an implementation of the existing
> auth.User class that extends from BaseUser? We're going to have to ship
> this user class anyway, so that everything works out of the box; then if
> anyone wants to define their own User class, they can.
>
> Perhaps. I think in reality it will be a bit more complicated though I
> haven't really thought about it. I didn't really consider
> authorization or backwards compatibility as a goal of the project when
> first writing it.
>
> >>>  * It solves the immediate problem ...
> >>>
> >>> As I see it, the immediate problem is that developers want to be able
> to modify the base requirements of auth.User. There may well be people who
> want to completely change contrib.auth, but for the moment, the 90% case
> can be solved by modifying max_length or setting unique=True on the email
> field, and/or removing the username field. The rest of auth.User is fine,
> at least for now.
> >>
> >> I agree this is the most immediate problem. If you could do this it
> >> would be ok though I have other issues with auth that prevent me from
> >> using it so even if I could modify the fields on auth.User I still
> >> won't use it.
> >
> > I'm not completely convinced that your proposal isn't just the "long
> term refactor" of auth that I referred to. I've only had a quick look at
> your code, but it seems to share a lot of similarities with oldauth. Yes,
> there have been modifications to remove dependencies on certain attributes
> of User, but from my quick check, I didn't see anything that we couldn't
> achieve through a process of modification of the existing code (if we
> didn't have an existing pret-a-porter implementation like yours)
>
> That's perhaps true. I suppose the primary key thing and being able to
> separate admin and regular users were the things I personally wanted
> the most.
>
> >> There isn't much you need on a user object besides a primary key and
> >> maybe a way to authenticate it. Everything else is profile so things
> >> like the name, email, etc. are all profile. I just don't really see
> >> the benefit of breaking all this up and requiring you to do multiple
> >> lookups in every view or make a middleware that goes and gets the
> >> profile object for you. It's terribly inconvenient. On top of that the
> >> difference between a user and a profile isn't really all that clear
> >> in a lot of apps. I think if you need or want this kind of topology
> >> you can create it yourself in your project.
> >
> > Yes, all that is strictly needed is a PK and a way to authenticate --
> but in practice, a user object isn't much use unless you can say "Hello
> ", so I don't see why basic identity mechanisms shouldn't be part of
> the basic User contract (not necessarily defined at a data level, just at a
> data access level).
>
> Sure. That's kind of why I defined an method for getting how to
> display the user's name. I think that when you say "but in practice, a
> user object isn't much use unless you can say "Hello "", you are
> really saying that the user isn't much without the profile data. It's
> a very short step from wanting to display the user's name to wanting
> to display his email or something else.
>
> > Personally, I don't have a problem with UserProfile as a pattern,
> especially when it comes to per-app settings. However, the good news is
> that both approaches are possible once the User model is configurable. We
> can describe the approach of a generic User with UserProfile objects
> containing app settings; and also document the fact that if you have
> performance (or taste/convenience) concerns about the joins to a
> UserProfile object, you can define a per-project User object that
> incorporates all the profile data you want.
>
> Yes. That's what I thought as well. There isn't stopping you from
> using the user profile approach or even defining multiple profiles.
>
> Thanks for taking a look at it,
> Ian
>
> --
> Ian
>
> http://www.ianlewis.org/
>
> --
> 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.
>
>


-- 
Joe Tennies
tenn...@gmail.com

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

Re: Schema Alteration API proposal

[Joe Tennies]

I have been updating the Wiki a bit (
https://code.djangoproject.com/wiki/SchemaEvolutionDesign). If you see the
linked page about the design, it's based on a general approval I got from
Russell. I haven't finished writing it up, but it has been in the 60's and
70's in Wisconsin in March. Needless to say, I've been outside.

I've been thinking of splitting it into 2 sections. The main part missing
is that the database layer needs to grow modification APIs. Then there
needs to be a contrib app for actually doing the migrations. Note that
detecting changes is not part of this (as has been pointed out on this
conversation already).

If you look, you can tell the ideas are mainly based off South at this
point, but I have been looking at nashvegas to see if they have anything
else to add.

--
Joe Tennies
tenn...@gmail.com

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

Re: Redesign of djangoproject.com?

[Joe Tennies]

A lot of these mockups are good, but I have a couple comments.

I'd like to see more "interesting" grid layout. Django comes from the world
of newpapers. I think that should be honored with an power 12/16 column
layout. I'm seeing something like "Power Grid" from
http://designshack.net/articles/layouts/10-rock-solid-website-layout-examples
Other prior art to look at:
http://demos.dojotoolkit.org/demos/fonts/demo.html
I think http://dl.dropbox.com/u/10320/djangoproject/dp.com-home.png did a
decent job of this. I love the sections on the top looking like sections of
a newspaper.


Another thing I like to see in every decent site is something to direct
people into where they want to get by categorizing them. I'm seeing
sections like "Considering Django" w/ the sales pitch, case studies, who
uses it, etc. I'll have to think about how to categorize the rest, but I am
usually annoyed by ending up on someone's site and not exactly knowing
where to go.

I've been messing with Adobe Proto lately. I'll see if I can put more
showin' and less jibber-jabberin' ;)

- Joe Tennies

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

Re: Single record models

[Joe Tennies]

Please use the django-users mailing list. This is for the development
of Django itself.

Thanks,
Joe

On Wed, Aug 22, 2012 at 7:30 PM, Richard Dodd  wrote:
> Is this the solution I'm looking for
> https://github.com/sciyoshi/django-dbsettings? I'm looking for similar
> fields to the models, but 1 offs
>
>
> On Thursday, August 23, 2012 1:05:05 AM UTC+1, Richard Dodd wrote:
>>
>> I want to design a website where the user can edit sections such as their
>> contact details, and I would like it to be integrated into the admin
>> interface. A model would not be suitable since there would only be 1 record.
>> Do you think the community would be interested in this functionality, and if
>> so, how should the data be stored? I would be happy to write a patch, but I
>> would need some guidance as to how to structure it.
>
> --
> 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/-/IjYBgLMpYZsJ.
>
> 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.



-- 
Joe Tennies
tenn...@gmail.com

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

Re: Transforming django-admin.py to a shell script

[Joe Tennies]

So, you are asking for the startproject (which again, you only run once, so
I wouldn't think it would be TOO bad) to create a manage.bat that had the
following line in it?

python manage.py %*

I'm not saying that this is a bad idea. It does make it fairly easy for
Windows people. In the case of Linux and Mac, I think the old way "just
works" in 90+% of the cases.

That stated, could we get the following lines added to virtualenv's
activate.bat:

assoc .py=Python.File
ftype Python.File=(magic path to python.exe or pythonw.exe)

>From what I'm reading*, that would solve this problem not just for Django
but for everyone. I'll create a patch for virtualenv once I get a chance to
test this theory.

*(
http://stackoverflow.com/questions/8012956/python-django-virtualenv-windows)




On Sat, Mar 2, 2013 at 2:57 PM, Alon Nisser  wrote:

> much simpler. simply making it run with simple `manage somecommand`
> instead of `python manage.py somecommand`. using setuptools or something
> similiar
>
> On Saturday, March 2, 2013 12:17:25 AM UTC+2, Łukasz Rekucki wrote:
>
>> On 1 March 2013 22:38, Alon Nisser  wrote:
>>
>>> at least from my windows exprience with Django (yes, I know this isn't a
>>> common use case, but still) the current django-admin.py and manage.py do
>>> need python preface to run right (while inside a virtualenv)
>>
>>
>> I'm not 100% sure if the Windows Python Launcher[1] works with
>> virtualenv, but it most likely works with venv support in Python 3.3. It
>> should also allow you to run Python scripts without the .py suffix
>>
>> Anyways, what kind of "shell" you had in mind? Batch ? Powershell ? Bash
>> ?.
>>
>> [1]: http://blog.python.org/**2011/07/python-launcher-for-**
>> windows_11.html<http://blog.python.org/2011/07/python-launcher-for-windows_11.html>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Joe Tennies]

As a fellow lurker (sorry I've been using Flask more recently), I think
this could simply be fixed via a form response. Here's a simple example:

This bug is being marked as "WONTFIX" because 

Please realize that every API/feature added to Django needs to be
maintained across several versions. The more public APIs that are exposed
to users, the more difficult it is to refactor and add other features. This
request currently lacks enough merit to exceed the cost it will add to the
maintenance of Django.

Possible solutions:
* Create a separate library to implement this feature. With enough use, the
merit may be more obvious.
* Start a discussion on https://groups.google.com/group/django-developers.
Please note that a stronger case will be needed to overturn this decision,
though the community may be able to help build that case. That community
may be best reached on https://groups.google.com/group/django-users or on
IRC at #django on irc.freenode.net.

Even the reasoning in the comment and the above via a link would help (to
allow the form to be updated if someone words it better). (can you make the
"WONTFIX" link to that description or do a mouse over comment box?


On Mon, May 13, 2013 at 5:21 PM, Peter  wrote:

> I have a thought on an action we could take out of this that might be
> constructive.
>
> Would it be possible to customise trak at all to make the workflow clearer?
>
> I'm thinking if someone tries to open a ticket that was closed by a
> committer then they should get an intermediate page pointing them to this
> group and asking them to confirm before the ticket is reopened.
>
> I don't know if Trak is customisable to that extent, or if this would even
> be effective, but it would be nice to get something out of this.
>
> Thanks,
> Pete
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>


-- 
Joe Tennies
tenn...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Joe Tennies]

Is there a specific reason to call this "django-fastcgi"? I think it should
most likely be a generic wsgi to fastcgi binding, right? Or is this project
mainly the django management commands?
On Jul 22, 2013 8:07 PM, "Curtis Maloney" 
wrote:

> Well, having started looking over the flup source, I can see a lot of
> useful code to crib, as well as a few critical path bits that can be
> optimised [without even reducing readability!]
>
> So, if you feel like helping out with django-fastcgi ... I'm happy for the
> help :)
>
> --
> Curtis
>
>
>
> On 23 July 2013 03:25, Some Developer  wrote:
>
>> On 22/07/13 10:00, Russell Keith-Magee wrote:
>>
>>> The hope is to start accelerating the release cycle slightly; however,
>>> this also depends on someone actually doing the work :-)
>>>
>>
>> Sounds good. I'd love to start helping with Django myself but I feel a
>> bit lost when it comes to useful things to do. Maybe I'll start checking
>> out the bug tracker and seeing what I can do there.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> django-developers+unsubscribe@**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
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: What are the best reasons for when and why people should use Django?

[Joe Tennies]

First, the obvious alternative: Rails.

I would argue that many of the advantages RoR had are starting to go away.
The two obvious advantages were Heroku and schema migration. Heroku now
supports Python and Django... done. While Django has had South, the problem
is that not everyone used it. This should obviously be getting fixed with
Django 1.7. This is a bit of an issue as 1.7 isn't out and not every
reusable app has released support for it yet. That stated, unless people
are working quick, I assume that any reasonable sized site will not finish
before 1.7 releases, though this is obviously still an issue.

I'll agree with all the Python is good. I had a person that liked RoR
explain Ruby as a great language to build a Domain Specific Language on top
of. This means that I can learn Django and eventually reuse the stuff I
learned to build pretty much any other kind of app. Ruby, on the other
hand, may have a steeper learning curve as RoR tended to do more
monkey-patching of how things worked. Also, I like that I can pick up most
anyone's Python code and generally understand what it's doing. Perhaps I
don't do enough Ruby, but I think the Perl roots of it make that harder.

Both seem to be solve the problems of building a small-to-medium site and
helping with the common problems. They both have a decent collection of
reusable apps that one can use to help build up their site quickly. I'm
sure both have the ability to slowly whittle the framework away to handle
large sites. Large sites tend to have very specific problems that need very
specific solutions that the average person doesn't need. See Jacob's PyCon
2009 speech @ about 24 min in (
http://pyvideo.org/video/225/pycon-2009--designing-a-web-framework--django--39).
You also have the interesting ability to use a fair amount of the knowledge
you gained from Django and take it to Flask if you end up needing a system
that is quite different from the problems that Django tries to solve.

But in the end, Django and Rails are quite similar in the problem scope
they attempted to solve. They took many similar approaches and I'm sure
borrowed from each other heavily. They are both quite stable at this point,
and I don't expect either to just disappear.

Now completely different frameworks.

Java has some decent large scale frameworks and I remember hearing about
some ones for smaller sites (and reduce the XML needed). They also have the
.war file standard which I hear makes deployment standardized. The biggest
question in my mind is whether Oracle will either step-up or let someone
else take Java and innovate with it.

PHP has several frameworks that seem similar in scope to Django (CakePHP
and Symfony for example). I don't know these well. There's also Drupal.
Drupal is interesting in that it's not only components but also
integration. You can probably start out and get a site built with many
simple problems without writing so much as a line of code. This leads to
the problem of that "I need to go outside the framework" being quite the
learning curve, but you can build a site quite quickly. My bigger concern
has been the security issues that have plagued Drupal.

The other obvious language is Javascript and Node.js. This is one has a
distinct advantage when thinking of real-time async things, especially
websockets. I'm uncertain of the more "standard"/classical style things.
This is a definite "horses for courses" thing. I'll admit to not following
Node.js much, but I just don't think any framework has been around long
enough to not be concerned whether they'll still be around in 2 years.


On Sun, Aug 10, 2014 at 3:05 PM, Tim Chase 
wrote:

> On 2014-08-10 01:06, Josh Johnson wrote:
> > Django documentation is phenomenal,
>
> I second Josh's comment.  I'd naively assumed that all "big Python
> web-framework" documentation was as good as Django's.  However, when I
> had to do some work on a contract involving CherryPy and
> SQLObject...marcy was it a painful wake-up.  Bottle's documentation
> was better than CP/SQLObject, but still not up to the high bar set by
> Django's.
>
> -tkc
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/20140810150538.7097b91b%40bigbox.christie.dr
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
You

Re: A new approach for migrations?

[Joe Tennies]

First this is really a question for the django-users group. This is more
for actually developing Django. I think the root of your issue is actually
the app loading feature and not migrations. Your models should be lazy
loading each other (using the string version not directly importing).

Secondly, the diff approach is difficult to get right, especially when you
consider data migration as well as schema migration. You can have a tested
path from a to d via b and c. It's tough to know how to get from a to d
without b and c.  And the permutations grow exponentially. The Python
Community and especially the Django people are heavily into testing being
an important (read required) part of development and change integration
testing.
On Oct 16, 2014 5:38 AM, "Uri P"  wrote:

> I have to admit I don't know the ins and outs of the new migration system
> in django1.7+, and I don't quite understand why it fails to handle circular
> dependencies which the old fashioned syncdb does. I would love to hear an
> explanation, but my main question is:
>
> I*f the initial syncdb is actually capable of creating the database for
> the models despite of the circular dependencies, why not base the migrating
> mechanism simply on some kind of DIFF between the existing database and the
> one that would have been created by syncdb for the newly changed models?*
>
> --
> 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/cef5b6e4-9f2e-4c81-aaee-0eede10d55b6%40googlegroups.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACiOJ6s4APj4fWcugVA3Bn2_Z1NvtE64dWg65Xoch5vb8xSQ8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

[Joe Tennies]

p 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/CAPDLAU6%3DHgWC_PTfRaGbQL6Tmj6tqPzcn5wdG46rkF4mBSpX0g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CAPDLAU6%3DHgWC_PTfRaGbQL6Tmj6tqPzcn5wdG46rkF4mBSpX0g%40mail.gmail.com?utm_medium=email&utm_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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFRnB2XA6dunCScyrfT%3DqN53ZFYD3JEd9HCAxGkbCSwEdaAiFg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFRnB2XA6dunCScyrfT%3DqN53ZFYD3JEd9HCAxGkbCSwEdaAiFg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Joe Tennies
tenn...@gmail.com

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

Re: Feature: Support Server-Sent Events

[Joe Tennies]

I'm going to kind of reiterate what Florian said.

The fact that you keep describing your idea as another process/thread that
has back and forth communication with the actual Django instance seems to
indicate to me that it's another program. I think people here tend to
follow more of the UNIX philosophy of a collection of smaller simple
programs that can easily interact (monolithic stack being ignored as that's
a much older decision). If you want tighter integration with Django, I
think it would best be done via your program instead of Django itself.

Now that stated, you may work on your project and discover that there is
some additional things that would be easier if done in Django. I'm thinking
some kind of way to register on the Django Signals on a separate processor
or another feature that is useful outside just your project. That would be
a good time to discuss such a feature.

Keep up the good work.

- Joe

On Sun, May 31, 2015 at 8:56 AM, Florian Apolloner 
wrote:

>
>
> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>>
>> Client A clicks a button on the site, that sends an normal ajax request
>> to Django. In the view a message is passed from Django to the SSE process.
>>
>
> How, you still need some kind of interprocess communication
>
> So the SSE process is VERY simple. It just connects to clients and passes
>> on messages the all clients connected.
>>
>
> VERY simple is an oversimplification in my opinion. I also do not see any
> reason for supporting it inside Django currently when things like
> autobahn.ws exist, the only thing missing there is the communication
> between the processes. I am not sure what people are expecting here from
> Django (and from your explanations I am still not really convinced or see a
> usecase at all). Since the message passing between the server processes
> should be language/framework agnostic anyways, this would be better suited
> for a third party project anyways. Reimplementing one of the existing
> SSE/Websockets implementations does not really seem like a win to me either.
>
> Cheers,
> Florian
>
> --
> 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/86b8ff28-b35f-49cd-8e95-30ace07c9d51%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/86b8ff28-b35f-49cd-8e95-30ace07c9d51%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6tK%3D%2BmRiE55Y_fg4y-KWtiroMR7fowPkec%2Bx4C5jwuUWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Joe Tennies]

I actually think this is a great idea. In my mind it parallels Drupal's
"block" idea. (This is actually what I keep hoping DjangoCMS is.)

That stated, it is more of a construct. I think a great idea is to make an
extension module.

I don't know how long you've been in this community, but Django is now
quite stable and people rely on their APIs. Your bold ideas really need to
be tested by fire before they go into the Django proper. There's been lots
of discussion about a year ago to remove/reduce a lot of the contrib.

Being in Django is where things go to die. Once an API is released to the
public, it takes a fair amount of work to remove/change it. You don't even
want to know how long it took to get schema migrations into Django. South
had been the defacto way for quite a few years. That stated, Andrew had to
make some changes to South due to design decisions that were made earlier
in South. Before that, there was other projects like django-evolution
(which just got an update 2 months ago).

So, I followed the Drupal group for a while. The thing the Django community
really needs is a couple good opinionated groups of how to put together a
good Django site. Drupal has Lullabot (who have quite a few core devs on
staff). Django is not going to be the people telling people how to use
Django. You seem like a great person to start this for Django. Note that
you'll have to have a thick skin and create some pretty great sites in your
own right to prove out your ideas to others. You'll also need to get your
ideas out via things like blog posts, tutorials, and podcasts.

I would like the Caktus, DjangoCMS, FeinCMS, etc people to do the same.
This would help people to see some different ideas on how to use and extend
Django.

On Sun, May 31, 2015 at 5:26 AM, Emil Stenström  wrote:

> On Sunday, 31 May 2015 11:36:51 UTC+2, riccardo.magliocchetti wrote:
>>
>> Il 31/05/2015 11:00, Emil Stenström ha scritto:
>> > On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote:
>> > Il 30/05/2015 18:52, Emil Stenström ha scritto:
>> > But your proposal keeps html and js separated. I think you are
>> solving a
>> > problem
>> > for the one that just want to use a component but you are not
>> solving the
>> > problem for the one that is writing components. At least not in the
>> react.js
>> > way, especially from such a bold premise :)
>> >
>> > I agree that I don't quite do it the same way as React. But that's not
>> the point
>> > here either, to somehow bundle Reacts ideas inside Django. My point is
>> that
>> > keeping the four parts that make a component closely together in the
>> project
>> > source, would make for a better structure. They only idea that comes
>> from React
>> > is thinking in components rather than nested templates and template
>> tags, which
>> > are Django's current way of solving this.
>>
>> I see, but who are going to do a big js app without using a framework
>> like
>> angular / react.js / ember / whatever? I'm not saying your Component
>> proposal is
>> without merit but i can't see how it can fit where the js app is done
>> with a
>> framework.
>>
>
> The idea is simply to keep interface components together in the Django
> project tree. That wouldn't change your options in regards to what
> javascript framework to use, just give you some help with organizing your
> code.
>
> Say you decide to use React as just JS framework. Since React puts the
> HTML inside your javascript your Django component would simply be:
>
> class ReactCalendar(component.Component):
> def context(self, date):
> return {"date": date}
> class Media:
> template = None
> css = {'all': ('app/components/calendar/calendar.css',)}
> js = ('app/components/calendar/calendar.js',)
>
> Since React doesn't handle CSS the component model would give you a way of
> tying thing together anyway. And with the component template tag you would
> be able to decide where to include your React component.
>
> --
> 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-d

Re: Vote on Jira as bugtracker

[Joe Tennies]

I'm not a lawyer, but I care about licensing.

The MIT License would allow you to relicense it, but you must keep the
original copyrights in tact. (From license: Redistribution and use in
source and binary forms, *with or without modification*, are permitted...)

It does have a list of "buts" too.

You must keep the copyright and disclaimer in the source files you used,
and your documentation must also do that.

Typical answer is to add a header above it in the source and then state
that all modifications from the original are AGPL... Original code is:
leave theirs alone.

You typically add "Portions of the code are based on Django Rest Framework
which is *paste copyright and lack of warranty etc disclaimer*"
 to your documentation.

On Thu, Jan 7, 2016 at 7:12 PM, Carl Meyer  wrote:

> Hi Andrey,
>
> On 01/07/2016 04:23 PM, Andrey Antukh wrote:
> > On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner
> > The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive
> > license that does not impide take the source and re-license it under
> > other license.
> >
> > taiga.io <http://taiga.io> initially have started using the DRF just
> > like a dependency but over time the dev-team found the needs monky-patch
> > many and many parts of it... Later, the dev-team have decided just
> > include it in the code base and remove useless (for taiga) code and add
> > additional features.
> >
> > Much of code/improvements is contributed back to the DRF (v2), other as
> > third party packages and some other is no, because the approaches are
> > diverged and the changes are just to much opinionated/coupled to the
> > taiga usage.
> >
> > I hope I have solved your question.
>
> I am not a lawyer, but it seems to me the problem is not the use of the
> code (which the license does allow), but the re-licensing and the lack
> of the original DRF license in your codebase.
>
> You are allowed to use the code and re-distribute it, but AFAIK you are
> not allowed to re-license it unless you are the copyright owner. And the
> terms of the DRF license do require that the DRF license text be
> preserved along with any redistribution of the DRF code, which (as far
> as I can see) Taiga currently doesn't do.
>
> So if I'm right (which I may well not be), I think the issue is easily
> resolved by including the original DRF license text in your base/api/
> directory, and clarifying that that license (not the AGPL) is the
> license that applies to all code taken from DRF.
>
> 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/568F0D05.3050901%40meyerloewen.net
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6sFEP%3D-i3z8ge3JDXm7%3Dn0xDgg3bOE%2BjHJDJruuvz8ONw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vote on Jira as bugtracker

[Joe Tennies]

No problem. Don't forget the documentation too. That was called out in the
original license. For instance, I'd put it right on the README.md on the
correct project(s) on GitHub under the license section.

OTOH, I'm now interested in checking it out, so thanks.

On Fri, Jan 8, 2016 at 3:42 AM, Andrey Antukh  wrote:

> Hi Joe
>
> On Fri, Jan 8, 2016 at 7:16 AM, Joe Tennies  wrote:
>
>> I'm not a lawyer, but I care about licensing.
>>
>> The MIT License would allow you to relicense it, but you must keep the
>> original copyrights in tact. (From license: Redistribution and use in
>> source and binary forms, *with or without modification*, are
>> permitted...)
>>
>> It does have a list of "buts" too.
>>
>> You must keep the copyright and disclaimer in the source files you used,
>> and your documentation must also do that.
>>
>> Typical answer is to add a header above it in the source and then state
>> that all modifications from the original are AGPL... Original code is:
>> leave theirs alone.
>>
>> You typically add "Portions of the code are based on Django Rest
>> Framework which is *paste copyright and lack of warranty etc disclaimer*"
>>  to your documentation.
>>
>
> On each file imported from DRF we have a notice about the original
> copyright:
>
> # This code is partially taken from django-rest-framework:
> # Copyright (c) 2011-2014, Tom Christie
>
> But as you are suggesting, the best approach would be paste the entire
> original license preamble. We will do it ASAP.
>
> Thank you very much.
>
> Regards.
> Andrey
>
>
>>
>> On Thu, Jan 7, 2016 at 7:12 PM, Carl Meyer  wrote:
>>
>>> Hi Andrey,
>>>
>>> On 01/07/2016 04:23 PM, Andrey Antukh wrote:
>>> > On Fri, Jan 8, 2016 at 12:42 AM, Florian Apolloner
>>> > The DRFv2 (as DRFv3) as far as I know is licensed using MIT permissive
>>> > license that does not impide take the source and re-license it under
>>> > other license.
>>> >
>>> > taiga.io <http://taiga.io> initially have started using the DRF just
>>> > like a dependency but over time the dev-team found the needs
>>> monky-patch
>>> > many and many parts of it... Later, the dev-team have decided just
>>> > include it in the code base and remove useless (for taiga) code and add
>>> > additional features.
>>> >
>>> > Much of code/improvements is contributed back to the DRF (v2), other as
>>> > third party packages and some other is no, because the approaches are
>>> > diverged and the changes are just to much opinionated/coupled to the
>>> > taiga usage.
>>> >
>>> > I hope I have solved your question.
>>>
>>> I am not a lawyer, but it seems to me the problem is not the use of the
>>> code (which the license does allow), but the re-licensing and the lack
>>> of the original DRF license in your codebase.
>>>
>>> You are allowed to use the code and re-distribute it, but AFAIK you are
>>> not allowed to re-license it unless you are the copyright owner. And the
>>> terms of the DRF license do require that the DRF license text be
>>> preserved along with any redistribution of the DRF code, which (as far
>>> as I can see) Taiga currently doesn't do.
>>>
>>> So if I'm right (which I may well not be), I think the issue is easily
>>> resolved by including the original DRF license text in your base/api/
>>> directory, and clarifying that that license (not the AGPL) is the
>>> license that applies to all code taken from DRF.
>>>
>>> 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/568F0D05.3050901%40meyerloewen.net
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Joe Tennies
>> tenn...@gmail.com
>>
>> --
>> You received this message because you are subscribed to the Go

Re: Model inheritance in different modules

[Joe Tennies]

I think this is more of a django-users comment, so I'll post Adam's
template for places.

I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at
https://forum.djangoproject.com , django-users mailing list, or IRC #django
on Freenode, or a site like Stack Overflow. There are people out there
willing to help on those channels, but they might not respond if you don't
ask your question well. Stack Overflow's question guide can help you frame
it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

Thanks for your understanding,

Adam

I'll send you a direct message.

Joe


On Thu, Jan 30, 2020 at 6:02 AM LBris  wrote:

> Hi everyone,
>
> Would it be possible to provide a new inheritance mechanism between
> classes in Django ?
>
> I explain my point :
>
> I have an app, for instance "HR": In this app, I would manage a model that
> is called "Employee". I store several information on this model and it's
> fine.
>
> Suppose I have a SECOND app, for instance "Fleet". In this app, I would
> manage a model that is called "Vehicle" and of course I store several
> information on this model.
>
> Suppose I only use the app "HR"  and one day, I decide to use the app
> "Fleet". That's okey, no problem. Both will work.
>
> But what if I decide to create a THIRD app, for instance "HR-Fleet" that
> does the bridge between the two others ?
>
> That means that HR can be used ALONE and same for Fleet.
>
> But HR-Fleet would add additional information. For instance, on the
> employee we would add a field "company_car" that points to a vehicle. The
> trick is, it would be GREAT to be able to do that without creating
> additional table in the database.
>
> Here is a sample of code to illustrate the behavior I'm trying to explain :
>
> In app "HR" :
>
> hr/employee.py :
>
> class Employee(models.model):
>name = ...
>email = ...
>
> In app "Fleet" :
>
> fleet/vehicle.py
>
> class Vehicle(models.model):
>brand = ...
>model = ...
>fuel_type = ...
>
> In app "HR-Fleet" :
>
> hr_fleet/employee.py :
>
> class HRFleetEmployee(models.model):
>_inherit = 
>
>company_car = models.ForeignKey(...)
>
>
> And that would add an extra field on the Employee model without adding any
> table in the database or using proxy model or ...
>
> Can you guys tell me if that behavior is possible ?
>
> If you don't get the point of such a functionnality, I can try to give
> more details or be more clear.
>
> Thanks in advance.
>
> --
> 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/7800872b-6191-4505-b3bb-f726b0b92db3%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7800872b-6191-4505-b3bb-f726b0b92db3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6s%3DBnPo_6BNtA7vs5S8Cv%3DOqCBm%3DaNv8G1UM6AkZ%2BW6fg%40mail.gmail.com.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Joe Tennies]

I agree that allowing more people to be able to do development against
Django 2.0 is important. That stated, please be very explicit in the
release notes and documentation that "Versions below Python 3.6 are
expected to be dropped before the next Django LTS will be released, so
please keep that in your project planning." (Language too informal, but I
think the idea is correct.)



On Wed, Jan 18, 2017 at 2:28 AM, Claude Paroz  wrote:

> Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :
>>
>> I propose to tentatively target Python 3.5+ for Django 2.0 but not to
>> remove the current workarounds for Python 3.4 at this time. Shortly before
>> the alpha for Django 2.0, an interested person can look into how much work
>> is required to fix any test failures on Python 3.4 and we'll make a
>> decision then.
>>
>
> I'm strongly advocating for keeping 3.4 support for now, as I would have
> difficulty to continue contributing to Django.
> My main system is still using 3.4 and will be for some months. Even if I
> could rather easily installing manually a more recent Python, I very much
> like relying on my stable distro packages. Sorry for my dumbness!
>
> Claude
>
> --
> 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/09570028-4eea-41ac-b364-
> 93ae2c946b21%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/09570028-4eea-41ac-b364-93ae2c946b21%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6tnEqkJdkaWv%2B6%2BP3eFUGz4uwY_0tHu8qfg6m0o%3D-T6zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.0 Python version support (Python 3.6+ only?)

[Joe Tennies]

Looking at the list, I think the only gain that required 3.5+ was typing.
The performance was due to which version was installed and not a real
feature. That stated, should the installer add typing from pypi as a
requirement (assuming someone adds typing info).

On Wed, Aug 9, 2017, 3:01 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> I took a look at this thread again and I still reach the same conclusion
> as Claude.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 9 Aug 2017, at 09:02, Claude Paroz  wrote:
>
> Le mardi 8 août 2017 01:45:55 UTC+2, Tim Graham a écrit :
>
>> Has anyone changed their thinking in the last few months? If not, I guess
>> we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.
>>
>
> I am not strongly opposed to dropping 3.4 support, but I still think we
> should keep it for Django 2.0.
> The speed improvements in 3.5/3.6 are still available if you run more
> recent versions in your own projects.
> I have not yet read any compelling reason to drop Python 3.4 support now.
>
> Claude
>
> --
> 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/7d30960d-41d8-4864-b749-dfa62810ed39%40googlegroups.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/16F0CFA9-6AE8-457D-A07D-50630DE36BD5%40polytechnique.org
> 
> .
> 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/CACiOJ6uPOL-XZ00ePq1ERs8C49BLmm-rMyskdAFjKLtMkCST0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Additional PostgreSQL-specific functions

[Joe Tennies]

e 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 this group, send email to django-d...@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/ms
>>>> gid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL
>>>> <https://groups.google.com/d/msgid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL?utm_medium=email&utm_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/6560985c-9d33-4837-9af5-
> ee467ae5369b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/6560985c-9d33-4837-9af5-ee467ae5369b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6tvZ8BiBJ8_xYaxvsoHkKXAOqyOsaHXbnrxaYppcM%2BFbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a database-agnostic JSONField into Django

[Joe Tennies]

t;> --
>>> Aymeric.
>>>
>>>
>> --
> 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/54f8d071-dc0c-47f6-b63e-
> c9ec68288527%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/54f8d071-dc0c-47f6-b63e-c9ec68288527%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

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

Re: GSoC 2018

[Joe Tennies]

While I'm not a deciding member by any means, I have seen enough proposals
to get a feel for what may be chosen. You left a very open idea of what you
plan to do. You are going to need to be specific as to what you plan to do
to accomplish your end goals and probably provide at least some sample that
shows off that you can do what you plan to do. Think launching a
Kickstarter campaign.

Do you intend to use one of the existing libraries like Brython or pyjs for
the Javascript side? I can think of some interesting things that could be
brought over from the Drupal world that could later be leveraged into
something like Wagtail.

On Wed, Mar 14, 2018 at 3:09 AM, Manasvi Saxena  wrote:

> Hello,
>
> My name is Manasvi Saxena and I wish to spend my summer coding for Django.
>
> *NOTE:* This is not a formal proposal. I only intend to introduce my idea
> to the Django-developer community for your valuable feedback and guidance.
>
> *My proposal-*
>
> Create libraries in python and integrate them with Django to generate HTML
> code for front-end development and thus contributing to make Django a
> full-stack framework.
>
> *About my proposal-*
>
> *A Short story...*
> *"I started writing codes in python four years back and ever since I have
> been passionate about the language. *
> *A few months ago when I was given a task of making a blog for my friend,
> I learned the basics of HTML, CSS, and Bootstrap and made a static website
> for her. But it was not enough as the content needed to be added
> dynamically and it is when I was introduced to Django, a framework written
> in the language I love.*
> *And ever since I have been using it."*
>
> *Why this idea?*
> For Python developers, it is an extra work to learn HTML and CSS to create
> a Front-end for a website. I intend to simplify their life by creating
> libraries that will convert Python code into HTML code to generate an HTML
> page. This feature, if implemented in Django will make it a
> one-stop solution for any python developer looking forward to making a
> website requiring only the knowledge of his or her programming skills in
> Python.
>
> *Conclusion...*
> Details of how I intend to implement my idea along with the detailed
> description of what I intend to do will be mentioned in my GSoC proposal.
> Please let me know what do you think of the idea and help me refine it.
>
>
> *About me-*
>
> I am a penultimate year Electronics and Communication student.
> Having done multiple projects in past, I have also recently completed a
> two-month internship at the position of Back-end web developer at a
> startup. And hence I'm experienced enough to build things from scratch and
> work under pressure with short deadlines.
>
> Github username- minusv23
>
> --
> 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/CADwzVRvSLYGOAyxsRWm%
> 2BRN4hKwK3S3ig3dQNQzhNj2PRSebP2A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADwzVRvSLYGOAyxsRWm%2BRN4hKwK3S3ig3dQNQzhNj2PRSebP2A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6uELJVspe180gdp2dCMnNKmfy4G7190A0gvWLrn9%2BUBMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC]GSoC 2018 Test framework improvement

[Joe Tennies]

Django does have a testing framework that's based on the unittest module
from Python standard library. That stated, I've seen people use nose and
other frameworks in the past. (More info at:
https://docs.djangoproject.com/en/2.0/topics/testing/)

I feel there is always a need for better helper utilities to make writing
tests so easy that people have no excuse NOT to write them. That stated,
the GSoC's that have been accepted in the past have been very specific
about what they are proposing and milestones as to what will be done and
when. There is no time in schedule to discover or define the scope.
Obviously, there will always be issues that come up and changes are
inevitable, but Django has a limited number of slots and wants to choose
projects that not only provide good benefits to the project but are likely
to succeed as well,

Hopefully this is helpful. You may be on the right track, but you'll have
to not only sell on what you will do but that you're the correct person to
do it and you understand the scope.

On Fri, Mar 16, 2018 at 12:56 PM Su Billy  wrote:

> Hello developers,
>
> My name is BING-LI SU from Taiwan, you can simply call me Billy.
>
> *Background*
> I'm an undergraduate student at National Chiao Tung University, major in
> Computer Science.
> I have been contributed to several open source projects for one year, such
> as CDNJS, pyqtgraph, and I host my own project using Tornado Web to build a
> simple digital signage system which contain a little bit unit test, CI, and
> docker image for fast deployment.
> I have know Django when I chose the framework of the digital signage, but
> I haven't used it util these few days, knowing that Django is a more
> sophisticated and handy framework compared to Tornado. In my opinion, the
> best way to be familiar with a project is to understand the test of the
> project (if there has one), therefore I choose test framework as my
> proposal idea.
>
> *Ideas*
> I'd like to add some new feature to the test framework, it is mainly about
> provide some groups of common used tests for user to choose, and maybe
> provide hook function to add their own test before, after, during each
> group of tests.
>
> *Plan*
> Here is my draft plan to achieve above ideas
> 1. To make me better understand the whole test framework, I will briefly
> trace the test framework in May
> 2. Find out and discuss with mentor about how to group up the tests and
> what this feature should look like.
> 3. Implementation and discuss with mentor once or twice a week.
>
> Thanks for any suggestion or comments, i.e: I should start to trace which
> part of test framework? The idea has some problem...? etc.
>
> sincerely
> Billy Su
>
> --
> 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/ad1d498b-c14b-40a5-9ca0-fee65814ed59%40googlegroups.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/CACiOJ6upNb%2BGpdxBMt2n31k6WciAfNWog%2B1_O9MtmN-uSukeZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2018

[Joe Tennies]

I'll give some background. The Django Templating Language was very
specifically designed to NOT allow putting business logic or allow calling
arbitrary functions in the template. Jinja2 loosened up that a bit, but it
still doesn't let you do whatever you want. There's a couple reasons, but
one is performance. Django gains a lot of optimizations because all
database queries can happen in a small region. It also means one cannot
potentially have 3 functions that each request the same data thus doing 3
DB queries, which is very slow.

It is also generally "bad form" to mix your business logic and your display
logic. I get that there's some times where it's much simpler to break that
separation. That is part of why Jinja2 gained some traction (though I
personally really like the better whitespace control). It also creates a
much better chance for a security flaw and maintenance issues. Obviously,
there is nothing stopping you from creating such a templating language. It
may get really popular.

Finally, I'll mention that there's nothing in Django that stops you from
just changing the template language used. It's as simple as not using the
render shortcut function. The joy of Python is that you just need to
generally match the interface.

Not to be mean, but I wanted to point out what's being proposed. Your
proposal is that Django pays you to create yet another templating language
that they have to support. This leads to three separate paths that the code
can take. There then needs to be some ability to cross communicate between
all three languages. Then there's the "sales" end of explaining why there's
3 templating languages and why one needs to choose another. One of the real
selling points of Django over other frameworks is that they're opinionated
and chose a specific set of tools. I started back in Pylons/TurboGears, and
I would spend a long time looking over which DB layer to chose and which
templating language to chose. In the end, I'll say that it was refreshing
to go to Django and have some of that chosen for you and to just start
working.

I really do wish you the best of luck if you attempt to make this. I'm sure
there is a need, but I personally do not see it being a direct fit into
Django.

Best of luck,
Joe

On Fri, Mar 16, 2018 at 3:27 PM Josh Smeaton  wrote:

> I'm confused by your proposal. You state one of the drawbacks with current
> templating is the readability issues for frontend developers that have
> templating logic defined within the template. But isn't your proposal to
> replace html templates with one defined in python? How does this make it
> any better for a frontend developer? It sounds like it'd be strictly worse.
>
> Further, sites will still need to query the ORM and inject that data into
> the template. I don't see how your point number 3 is addressed at all - and
> don't even think it can be.
>
> A new templating engine will also be incompatible with the thousands of
> django and python libraries already available in the wild.
>
> It sounds like you're attached to your project, which is a good thing, but
> I'd encourage you to work on this separately from GSoC as a learning
> experience, as Aymeric mentioned before. This is definitely not a project
> that would be accepted for GSoC, without actual proof that the project was
> **already used by people** and provably better than the options we already
> have.
>
> Regards,
>
>
> On Saturday, 17 March 2018 04:09:41 UTC+11, Manasvi Saxena wrote:
>>
>> Hello Sir,
>>
>> On Thursday, March 15, 2018 at 11:29:46 PM UTC+5:30, Aymeric Augustin
>> wrote:
>>>
>>> Hello,
>>>
>>> 2018-03-15 14:24 GMT+01:00 Manasvi Saxena :
>>>
 Think of this library as a bridge between Python and HTML, you don't
 need to know the syntax of HTML, just need to know which function of the
 library creates what output. After you have created the content of your
 page just pass it to a function in a list and you have your HTML page.
 Have a look at the prototype and let me know what you think of it.

>>>
>>> Thanks for the example.
>>>
>>> To be honest the sample.py file doesn't strike me as a convenient way to
>>> write HTML.
>>>
>>> I think someone who's confortable writing Python code should be able to
>>> learn the HTML syntax very quickly.
>>>
>>> content isn't more complicated
>>> than pyhtml.tag("content", attr1="value1", attr2="value2"), is it?
>>>
>>> This idea is not a good fit for Django. Perhaps it can be a learning
>>> experiment for you, though?
>>>
>>> Best regards,
>>>
>>> --
>>> Aymeric.
>>>
>>
>>
>> After keeping in mind your valuable feedback I have decided to change my
>> project proposal.
>>
>> I'm halfway through my formal proposal which contains the details
>> required as per the guidelines provided on Django GSoC page.
>> But would like to discuss with you the idea first for your valuable
>> feedback.
>>
>> Django templating engine and jinja2 while being very efficient in their
>> way still have some drawbacks.
>> 1)

Re: GSoC 2018

[Joe Tennies]

Okay, so the idea is to render HTML by generally defining it in Python. I
could've sworn that I'd seen something like this years ago, but I'm failing
to find it. That stated, I think this is basically a generating version of
BeautifulSoup (https://www.crummy.com/software/BeautifulSoup/bs4/doc/) as
opposed to a parsing version.

It's roughly like the Storm ORM (https://storm.canonical.com/) but for HTML
instead of database queries.

It's interesting, but I'll ask if one can get 90% of the functionality from
xml.etree, which is in the standard Python Library.

import xml.etree.ElementTree as ET

a = ET.Element('p', style='{color: red;}')
a.text = "hello world"
ET.dump(a) # will match yours

Note that this gets even weirder with something like "hello ignore
this world".

b = ET.Element('p')
b.text = "hello "
c = ET.Element('i')
c.text = "ignore this"
c.tail = " world"
b.append(c)
ET.dump(b) # will match above

On Fri, Mar 16, 2018 at 3:48 PM Manasvi Saxena  wrote:

> Hello Sir,
>
>
> On Saturday, March 17, 2018 at 1:57:00 AM UTC+5:30, Josh Smeaton wrote:
>>
>> I'm confused by your proposal. You state one of the drawbacks with
>> current templating is the readability issues for frontend developers that
>> have templating logic defined within the template. But isn't your proposal
>> to replace html templates with one defined in python? How does this make it
>> any better for a frontend developer? It sounds like it'd be strictly worse.
>>
>> Further, sites will still need to query the ORM and inject that data into
>> the template. I don't see how your point number 3 is addressed at all - and
>> don't even think it can be.
>>
>> A new templating engine will also be incompatible with the thousands of
>> django and python libraries already available in the wild.
>>
>> It sounds like you're attached to your project, which is a good thing,
>> but I'd encourage you to work on this separately from GSoC as a learning
>> experience, as Aymeric mentioned before. This is definitely not a project
>> that would be accepted for GSoC, without actual proof that the project was
>> **already used by people** and provably better than the options we already
>> have.
>>
>> Regards,
>>
>> On Saturday, 17 March 2018 04:09:41 UTC+11, Manasvi Saxena wrote:
>>>
>>> Hello Sir,
>>>
>>> On Thursday, March 15, 2018 at 11:29:46 PM UTC+5:30, Aymeric Augustin
>>> wrote:

 Hello,

 2018-03-15 14:24 GMT+01:00 Manasvi Saxena :

> Think of this library as a bridge between Python and HTML, you don't
> need to know the syntax of HTML, just need to know which function of the
> library creates what output. After you have created the content of your
> page just pass it to a function in a list and you have your HTML page.
> Have a look at the prototype and let me know what you think of it.
>

 Thanks for the example.

 To be honest the sample.py file doesn't strike me as a convenient way
 to write HTML.

 I think someone who's confortable writing Python code should be able to
 learn the HTML syntax very quickly.

 content isn't more complicated
 than pyhtml.tag("content", attr1="value1", attr2="value2"), is it?

 This idea is not a good fit for Django. Perhaps it can be a learning
 experiment for you, though?

 Best regards,

 --
 Aymeric.

>>>
>>>
>>> After keeping in mind your valuable feedback I have decided to change my
>>> project proposal.
>>>
>>> I'm halfway through my formal proposal which contains the details
>>> required as per the guidelines provided on Django GSoC page.
>>> But would like to discuss with you the idea first for your valuable
>>> feedback.
>>>
>>> Django templating engine and jinja2 while being very efficient in their
>>> way still have some drawbacks.
>>> 1)Not enough freedom to implement logic in a template. Python functions
>>> can't be called inside the template.
>>> 2)Once the templating language syntax is applied to the template it
>>> creates readability issues for the front-end developer. This leads to two
>>> different development branches.
>>> If a front-end developer changes some of the parts in his template then
>>> the back-end developer has to make amendments manually each time.
>>> His job is not finished even after he has generated the content of the
>>> page dynamically.
>>> 3)The time required by the engines to generate the HTML content is more
>>> for large data. First, the QRM fetches the data from the database, then
>>> templating engine populates it on the template.
>>>
>>> I intend to first generate the HTML content according to the
>>> requirements of the developer using his programming skills in an exact way
>>> required and then place it inside the template.
>>>
>>> The library will have functions exactly similar to the HTML tags so that
>>> a python developer can reproduce the HTML code made by the front-end
>>> developer.
>>> Or a person with some knowledge of HTML or following 

Re: revisiting the Python version support policy

[Joe Tennies]

I'm not going to argue one way or the other, as it doesn't really affect me
either way. (I will say that Python 3.5 is no longer a supported version on
Heroku.)

On the other hand, I will argue how supporting 3.5 might affect the
upcoming Django version. I've included my opinionated breakdown below. I
will say that the biggest item I see is the security in
django/utils/crypto.py. It could get rid of the less than ideal fallback
and just use secrets for the RNG. The descriptor improvements may be
important, but I couldn't tell.

On Tue, Jan 22, 2019 at 11:16 PM Josh Smeaton 
wrote:

> Don't discount being able to use features from newer versions of python
> within Django itself.
>
> https://docs.python.org/3/whatsnew/3.6.html
>
> - dicts are more performant
>
This should just make 3.6 faster, right? It doesn't actually break 3.5.

> - dicts/kwargs/class attributes are ordered (cpython implementation detail
> for 3.6 - allowing us to consider removing descriptor counters)
>
According to the documentation you posted, this is not to be relied upon
(until 3.7 that is).

> - fstrings
>
 While this is interesting, I must state that I'm more than a little
concerned of the security implications for grabbing variables from the
global memory space.

> - type annotations (something some people are quite in favour of)
>
According to the documentation, these changes were backported to 3.5,
though saying you need 3.5.x where x> something is... painful to support.
Also, unlikely to make it in *this* version of Django. They are also much
more useful in 3.7 when PEP 563 is implemented to allow for forward
declarations and not evaluating them at startup (though this will require a
__future__ import even then).

> - async comprehensions and generators (less important for Django right now
> - may be more important for Channels)
>
 Agreed, and perhaps Channels has a higher requirement. I'll also point out
async improvements and usability is also in the Python 3.7 release notes.

> - secrets module
>
This could be a security concern that should at least be documented. It is
solely a cryptographically sound random number generator currently.

> - pathlib
>
 This would be interesting to add support for.

> - descriptor improvements (set_name, __init_subclass__)
>
I'm not sure I'm smart enough to understand this... at least at this point
in the night.

>
> I'm more in favour of maintaining the existing policy than playing
> favourites with distro support, but not strongly so. The LTS Django is
> already covering Python 3.5 for 18 months **longer** than the EOL. I don't
> think the newest versions of Django need to be so concerned with distro
> compatibility.
>
> --
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6szy2GKbNF9QuyzYHyitqQhhGk3eF%2BTyju00rNCEjOZ1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Joe Tennies]

ee when they visit docs.djangoproject.com.
>>
>> I don't agree this is theoretical at all.
>>
>> It's not just Debian. (Which doesn't fit my mental model here really...)
>>
>> It's all those few-years-old computers out there.
>>
>> It's for example Raspbian, which as of this month is still shipping
>> Python 3.5.
>>
>> So my boy, who's 10, says,
>>
>> - What would you use?
>> - Well I'd use Django (obviously)
>> - Can I use that?
>> - Yeah...
>>
>> If we do drop Python 3.5 I have to say, "Well, no. But you can use this
>> old one." That's not as cool.
>> But there will be people who are more seriously affected.
>>
>> > Who is saying, "I want to use the latest version of Django, but I want
>> to use a really old version of Python."
>>
>> No one is saying this. The notion of versions doesn't come into it. We're
>> well beyond the barrier-to-entry before we get there.
>> I (just my opinion on this) think we mistake our audience if we forget
>> this.
>> (For this reason I don't think the deployment issue is the relevant one.
>> It's about people learning to programme, not professionals.)
>>
>> We can't support everything forever, and I'm as keen as anyone to push
>> forward, but following Python is (for me) the thing we should do.
>> I think Django's position in the Python eco-system requires it.
>>
>> Of course if we don't, things are easier for us, yes.
>>
>> Again, just my opinion.
>> C.
>> --
>> 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 this group, send email to django-d...@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/19e099cf-6087-4efd-9138-d338f12bbf2c%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/19e099cf-6087-4efd-9138-d338f12bbf2c%40googlegroups.com?utm_medium=email&utm_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/c25bb851-f334-48d4-bdd4-470c0ff10e2c%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c25bb851-f334-48d4-bdd4-470c0ff10e2c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6sbkajr9_P%3D5kG32sHrE7p3GKmmd_4%2BW%3D-ByDvb-FzOEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: revisiting the Python version support policy

[Joe Tennies]

Carlton,

I read your response, and I think what you said is very important. I would
like to ask you a few questions, if you don't mind. I'm not trying to back
you into a corner; I'm trying to understand what you see with your teaching
and getting insight from that.

Do you think it makes sense to have beginners working off non-LTS versions?
Personally, I think the LTS is the version that beginner's should run.
They're "real" projects are likely to take longer, and they aren't going to
want to track the latest and greatest. I also think that any non-LTS
version of the docs should have a similar heading to the dev version to
suggest that beginners likely would benefit from using the latest LTS
version.

How many people coming to your trainings are running a stable/enterprise
Linux distro? It's pretty quick to get the right version for Windows. As
far as Linux, I would expect to see mainly the big couple Linux distros.
The more esoteric rolling releases should obviously be fine due to their
rolling nature. Therefore, I want to just do an analysis. As far as
supported Ubuntu releases go, 18.04LTS and all supported non-LTS are fine.
Ubuntu 16.04 and 14.04 are both LTS version and still supported by
Canonical. I believe Mint still follows Ubuntu. As far as Debian, testing
and unstable have 3.7, but stable has 3.5.3. As far as Fedora, Version 26
and above have python 3.6 or newer. I believe we've discussed RHEL/CentOS,
but it appears that anything before 8 doesn't have Python 3 at all, and the
CentOS7 SCL has Python 3.6 in it. I don't know which other Linux distros
are still generally relevant. I don't know the OSX world, but I assume you
can get a binary installer that's no harder than any other Python version.

On Sat, Jan 26, 2019 at 3:10 AM Carlton Gibson 
wrote:

> I worry about us making this kind of decision in the rarified air of the
> developer mailing list. It's a technical question yes, but it affects the
> entire community.
>
> I think, here, we underplay just how hard it is for people out there. IMO
> expecting that people suffering from massive information overload to
> successfully switch docs version is already setting the bar too high.
> People really struggle.
>
> I'll give you one concrete example.
>
> Teaching DjangoGirls in Barcelona, one student—presumably for EXACTLY the
> kind of version mis-match we're talking about here—had her project created
> with a different version of the template than everybody else's. It didn't
> have contrib.staticfiles in INSTALLED_APPS. As such, where everyone else
> was able to deploy, her deployment failed. In the end there were
> instructors from three tables around here laptop trying who-knows-what in
> the shell before it was worked out and resolved. ("Try `collectstatic`
> locally" led to the answer.)
>
> Without those instructors present that student would have been stuck at
> that point, and lost.
>
> I don't have figures, and we never hear from most of these people, but I
> guess this sort of difficulty happens a lot.
> A quick scan of django-users suggests it's all the time.
>
> > ...there's a new test failure after a recent patch due to
> non-deterministic dict ordering in Python 3.5 which demonstrates the sort
> of minor annoyances that take time away from making useful improvements to
> Django.
>
> It's not that I don't hear you hear. I do.
>
> It's just that I think of this as an accessibility issue, and
> accessibility is a feature too.
>
> For me, if the cost of including someone is that we have to use
> OrderedDict for a wee-bit longer, then so be it.
>
> Kind Regards,
>
> Carlton
>
>
> --
> 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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Joe Tennies
tenn...@gmail.com

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

Re: revisiting the Python version support policy

[Joe Tennies]

ct ordering in Python 3.5 which demonstrates the sort
>>> of minor annoyances that take time away from making useful improvements to
>>> Django.
>>>
>>> It's not that I don't hear you hear. I do.
>>>
>>> It's just that I think of this as an accessibility issue, and
>>> accessibility is a feature too.
>>>
>>> For me, if the cost of including someone is that we have to use
>>> OrderedDict for a wee-bit longer, then so be it.
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>>
>>> --
>>> 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 this group, send email to django-d...@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/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/2c23caa4-b83a-4e45-9811-a62af2b4c311%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Joe Tennies
>> ten...@gmail.com
>>
> --
> 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/c948baf5-91a2-4577-aeaa-89735bb2e444%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/c948baf5-91a2-4577-aeaa-89735bb2e444%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Joe Tennies
tenn...@gmail.com

-- 
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/CACiOJ6sSRut8TAqB0XT1ak2%2BFiHhtvRezsoXb_25EajcuZGDaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: cacheif template tag

[Joe Tennies]

Looking at the code Carlton provided sounds like it meets what was being
requested, but it fails "There should be one-- and preferably only one
--obvious way to do it." in that it wasn't immediately obvious, but adding
the cacheif tag would lead to more than one way. Therefore I'm suggesting
that either the new template tag gets added or this gets documented in
https://docs.djangoproject.com/en/4.1/topics/cache/#template-fragment-caching
. I think the suggestion from Carlton is readable enough that it just
should be documented as an example, so it becomes more obvious how to put
it together when glancing at this section.

This section also mentions that "The fragment is cached forever if timeout
is None." But it's missing the "A timeout of 0 won’t cache the value." Note
that appears in other references for the timeout value.

- Joe

PS: If I remember, I'll make a PR for those when I get home from work, but
I'm more than happy for someone to beat me to it.

On Wed, Nov 2, 2022 at 2:39 AM Carlton Gibson 
wrote:

> Hi Igor,
>
> The sort of thing I had in mind was:
>
> {% with cache_timeout=request.user.is_authenticated|yesno:"0,500" %}
>   {% cache cache_timeout sidebar %}
>
> ...
>
>   {% endcache %}
> {% endwith %}
>
> Kind Regards,
>
> Carlton
>
> On Wednesday, 12 October 2022 at 17:17:57 UTC+2 des...@gmail.com wrote:
>
>> Hey Carlton,
>> I am not sure I got your idea.
>> The point of proposal is not in user.is_authenticated.
>> user.is_authenticated is just a boolean. Conditional caching for non logged
>> in user is just very simple and common use case when `cacheif` could be
>> used.
>>
>> пʼятниця, 30 вересня 2022 р. о 09:09:53 UTC+2 carlton...@gmail.com пише:
>>
>>> Hey Igor,
>>>
>>> I wonder if you can achieve the same varying the timeout parameter based
>>> in user.is_authenticated?
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>> On Sat, 24 Sept 2022 at 15:35, Igor Margitich  wrote:
>>>
 Hi django-developers,

 I would like to propose new template tag `cacheif`. Could be useful
 when you need to cache part of html and it depends on some condition.
 Template tag is similar to built-in `cache` tag but accepts extra boolean
 parameter. See example:

 {% cacheif user.is_anonymous 10 homepage %}
   
  .
   
 {% endcacheif %}


 --
 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 view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/bcf8ffee-6497-4a55-ba40-913446d15b06n%40googlegroups.com
 
 .

>>> --
> 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/476159b3-7f5f-4264-994b-1b62b8adaf8fn%40googlegroups.com
> 
> .
>

-- 
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/CACiOJ6uEnody-Pe1qfQJ3s5%2B10WvXerEANN0SHtZCZOSLvTY0A%40mail.gmail.com.