Re: PEP 484 type hinting in Django

[Daniel Moisset]

On 11 April 2018 at 11:21, Andreas Galazis  wrote:

> To me one approach would be to put a cut off for any merged code /PR
> start inlining type hints/annotations for all new code. This seems to
> simple to be a solution but at the end of the day as code gets updated even
> bigger part of the codebase will have type hints. The question is whether
> partial type-hinting is actually useful, but at least it supports heading
> towards the right direction.
>
>
I don't think that approach will work. Partial type hinting is useful and
viable, but not randomly you need to do it bottom up (covering basic
abstractions first). So the place to start is probable the parts of django
that change less and are more solid foundations (in my case I started with
requests, views and URL resolvers, etc)



-- 
Daniel F. Moisset - UK Country Manager - Machinalis Limited
www.machinalis.co.uk 
Skype: @dmoisset T: + 44 7398 827139

1 Fore St, London, EC2Y 9DT

Machinalis Limited is a company registered in England and Wales. Registered
number: 10574987.

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

Re: PEP 484 type hinting in Django

[Daniel Moisset]

A long due update on this, given that the question popped up recently:

I worked at some time in type annotations and published some for Django
1.10 ; I'm currently not working on them, given that my current work has
not been very close to Django development

After trying a few things, the best way to get this would be:
1) Add annotations upstream. Having to maintain a separate set of
annotations is probably not sustainable and will lead to errors. This of
course needs annotations accepted by the team.
1.1) Integrate typechecking into Django's build/CI process. This would
ensure that annotations are consistent with the implementation.
1.2) Annotations do not need to be exhaustive (and there are certainly
parts of Django which could benefit from them much more than others)
2) Generate stubs from the annotated source. This was not possible when I
wrote my stubs, but I've commited the mypy improvements with that feature.
2.1)A few stubs may need to be overridden manually from the autogenerated
(I found a few examples of this when I wrote my stubs)
3) Distribute annotated files separately (not with typeshed, and probably
not with django) so people can install the version they need. Distribution
of stubs has been problematic, PEP 561 should solve it but an
implementation for it has been just merged last week into mypy, and
probably released soon.

Before PEP561 and the ability to generate stubs, I don't believe it was
practical to make this project sustainable. At this time, it might be and
it can be a good time to restart this discussion.

Best,
D

On 6 April 2018 at 12:19, Florian Apolloner  wrote:

> To the best of my knowledge JetBrains fundled the money to Django for that
> specific purpose -- so yes the funding should be here if needed. That said,
> there is no decission on a) whether we actually want type hints and b) if
> the should be inline or stubs. Those two points have to be cleared first.
>
> Cheers,
> Florian
>
> On Friday, April 6, 2018 at 9:11:04 AM UTC+2, Eddy C wrote:
>>
>> Hi Tim, do you know if JetBrains still willing to fund the project as the
>> upcoming django 2.1 will only support python 3.5+ that pave the way for
>> inline annotations.
>>
>> On Wednesday, August 17, 2016 at 11:41:03 PM UTC+10, Tim Graham wrote:
>>>
>>> The JetBrains announcement that they want to fund the project isn't a
>>> guarantee that it'll be implemented. The feature needs to go through the
>>> normal feature acceptance process, which as Markus said, might involve a
>>> DEP.
>>>
>>> Assuming the idea is accepted, my sense on timing would be to wait until
>>> January when Django drops support for Python 2.7 and 3.4 in master. Then we
>>> could use inline annotations rather than the stub files.
>>>
>>> Past discussions of type hinting:
>>> https://groups.google.com/d/topic/django-developers/z_P1TvJ6
>>> QG8/discussion
>>> https://groups.google.com/d/topic/django-developers/xOTmq93Y
>>> ZuQ/discussion
>>>
>>> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner
>>> wrote:



 On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:
>
> @Florian
> Would you care to ellaborate? I couldn't find the post you mention
> (although requests is one of the few 3rd party projects that have support
> at the official typeshed repository, https://github.com
> /python/typeshed )
>

 https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/
 -- might be that things changed by now.

>>> --
> 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/6f2b5dd9-f8e6-4b67-8e25-
> 585cbd802413%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager - Machinalis Limited
www.machinalis.co.uk 
Skype: @dmoisset T: + 44 7398 827139

1 Fore St, London, EC2Y 9DT

Machinalis Limited is a company registered in England and Wales. Registered
number: 10574987.

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

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

[Daniel Moisset]

Type hinting can be done in python 3.x by depending on the typing module
(or inlining it). Type hinting for instance/class attributes will have a
much nicer syntax in python 3.6 only (PEP 526)

Best,
   D.

On 7 January 2017 at 03:03, Tim Graham  wrote:

> I don't know if matters to anyone, but I guess as long as we support
> Python 3.4 we can't do the type hinting project (PEP 484) since that's new
> in 3.5?
>
>
> On Friday, January 6, 2017 at 12:08:07 PM UTC-5, Tim Graham wrote:
>>
>> Tom, I'm not following how Python 3.4 support in Django 2.0 will benefit
>> you if you want to stick to LTS versions of Django? I think either you or I
>> have a misunderstanding somewhere. I'll try to recap:
>>
>> Django 1.11 is the next LTS. It's supported until April 2020 and supports
>> Python 3.4. The next LTS, Django 2.2 is due in April 2019, after the Python
>> 3.4 end of life in March 2019 -- so I don't think we can justify supporting
>> Python 3.4 in that LTS unless we decide to base our supported Python policy
>> on CentOS rather than Python's own support lifecycle. Florian and Daniele
>> are proposing supporting Python 3.4 for Django 2.0 and/or 2.1. Those
>> versions have security support ending in April 2019 and December 2019,
>> respectively. If you want to use Python 3.4 and maximize the time you can
>> receive Django security updates, stick with 1.11 LTS (April 2020).
>>
>> Look at these tables if you're in doubt:
>> https://www.djangoproject.com/download/#supported-versions
>> https://docs.python.org/devguide/#status-of-python-branches
>>
>> On Friday, January 6, 2017 at 11:22:17 AM UTC-5, Tom Evans wrote:
>>>
>>> On Thu, Jan 5, 2017 at 8:10 PM, Asif Saifuddin 
>>> wrote:
>>> > Hi,
>>> >
>>> > django 2.0 will be released in december 2017 and ubuntu 18.04 will be
>>> > released in april 2018 which will default atleast 3.6, so I think this
>>> > should also be taken as consideration while deciding.
>>>
>>> I know supporting endless versions of python is not desirable, but
>>> please bear in mind that some of us are in situations where what the
>>> latest release of Ubunutu is not really relevant.
>>>
>>> Our organisation uses CentOS 6, which is not EOL until the end of
>>> 2020. In CentOS 6, the stock version of python is python 2.6; we go
>>> through special measures (EPEL) to get that up to python 2.7. If we
>>> wanted to make the move to Python 3, we'd be talking about Python 3.4,
>>> again through EPEL.
>>>
>>> We have an infrastructure team responsible for provisioning servers,
>>> and it is on their schedule that OS upgrades occur - it is not easy
>>> for us as developers to argue that this team should spend significant
>>> resource to upgrade to a later OS version or to roll custom python
>>> RPMs.
>>>
>>> Updating all of our codebase to Python 3 is going to be a pain for us,
>>> it is hard to argue a business need with "Everything stays exactly the
>>> same but is slightly more secure and easier to maintain".
>>> Realistically, when we move to Python 3, it will be because the
>>> supported Django LTS requires it. If we also have to jump through lots
>>> of hoops to get the very latest Python 3 release, it won't make it
>>> easier to argue, it will mean we are more likely to postpone it and
>>> keep using old django versions, particularly on internal intranet
>>> sites.
>>>
>>> If there is a way that Python 3.4 support can be maintained without
>>> significant detriment or penalty, this would be greatly appreciated by
>>> those of us running more conservative enterprise distributions.
>>>
>>> Cheers
>>>
>>> Tom
>>>
>> --
> 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/680d3d55-a9d4-46d9-a587-
> c49649f24cbf%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

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

Re: Javascript Templating Package

[Daniel Moisset]

Hi Nick, I'm not sure what kind of generation are you suggesting. What I've
used a couple of times is creating a template tag to convert a json-like
data structure in the context to a javascript object, so in the template I
have something like this in a 

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Just a small update on this; I've published a first usable (well, I hope)
version at https://github.com/machinalis/mypy-django/ . It's stubs only,
although I'm basing it on an annotated django fork at https://github.com/
dmoisset/django/tree/typing . I covered some high-visibility APIs only
(request/responses, url routing, generic views), and some helper modules
that hose are built on (core.files, timezones, data structures).

I think it works, although while annotating the original code I struggled
with a few things:
 - Some classes (most notably MultiValueDict/QueryDict) use inheritance
then break a bit the original interface. In that case I changed the
implementation a bit to use delegation instead of inheritance, so it's more
than "just adding annotations" in places like this. It still passes tests,
and I haven't run benchmarks but GvR suggested that the delegation version
is probably faster.
 - There are some warnings thrown by the checker in the timezone module
that I'm not sure if they're because a bad specification or if those are
actual bugs (some methods like ReferenceLocalTimezone.utcoffset crash if
passed a "None" argument, but some examples seem to imply that a tzinfo
should accept it); there's no clear spec there. In the end I think this is
a good sign (this work will help identify some tricky/underspecified corner
cases in the API).
 - The type stubs (annotations in separate files) allow to tell some "white
lies" about the API (for example saying @classmethod instead of
@classonlymethod because the latter confuses the typechecker). Those make
it more usable, but something will have to be done with that if integrating
annotations on the code is desired.

In general, the APIs in django seem to be much more structured than other
python stuff (like the requests example Florian mentioned

Feel free to comment and follow-up details on the project issue tracker. I
posted this update here in case it helps in the future to follow the
discussion about adding inline annotations.

Best,
D.



On 20 September 2016 at 16:24, Daniel Moisset <dmois...@machinalis.com>
wrote:

> Hey Graham. mypy has a structure to support multiple python versions as
> you noticed (and allows it to select them from the command line), but
> there's no mechanism for selecting library version. For me, supporting "the
> latest stable version" is a reasonable goal now. Flagging that
> appriopriately may become a problem in the future, but only if this
> succeeds, so I'm focusing on making this useful right now :).
>
> I already mentioned a naive approach (use different branches in the
> typeshed repo to support different django versions), but I'm keen to hear
> better ideas!
>
> And of course, if we get this into the django codebase itself the problem
> goes away (you get the annotations when installing django).
>
> Best,
>D.
>
>
> On Sun, Sep 18, 2016 at 9:00 AM, Graham Wideman <graham.wide...@gmail.com>
> wrote:
>
>> Just making note of the typeshed project https://github.com/python/type
>> shed, "Typeshed models function types for the Python standard library
>> and Python builtins, as well as third party packages."
>>
>> Pertaining to my earlier question about how pyi files should tell what
>> version of a library they pertain to:FWIW, typeshed uses directory branches
>> for different pyi files pertaining to different versions of Python, and
>> version-range conditionals within pyi files. These version-selective
>> devices pertain to version of Python. The interest in the discussion here
>> would relate to version of Django, of course, where it seems similar
>> measures might apply.
>>
>> --
>> 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/ms
>> gid/django-developers/5bf15a4b-8360-4ee0-a985-01f42e7e27fd%
>> 40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/5bf15a4b-8360-4ee0-a985-01f42e7e27fd%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Daniel F. Moisset - UK Country Manager
> www.machinalis.com
> Skype: @dmoisset
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

-- 
You received this message because you a

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Hey Graham. mypy has a structure to support multiple python versions as you
noticed (and allows it to select them from the command line), but there's
no mechanism for selecting library version. For me, supporting "the latest
stable version" is a reasonable goal now. Flagging that appriopriately may
become a problem in the future, but only if this succeeds, so I'm focusing
on making this useful right now :).

I already mentioned a naive approach (use different branches in the
typeshed repo to support different django versions), but I'm keen to hear
better ideas!

And of course, if we get this into the django codebase itself the problem
goes away (you get the annotations when installing django).

Best,
   D.


On Sun, Sep 18, 2016 at 9:00 AM, Graham Wideman 
wrote:

> Just making note of the typeshed project https://github.com/python/
> typeshed, "Typeshed models function types for the Python standard library
> and Python builtins, as well as third party packages."
>
> Pertaining to my earlier question about how pyi files should tell what
> version of a library they pertain to:FWIW, typeshed uses directory branches
> for different pyi files pertaining to different versions of Python, and
> version-range conditionals within pyi files. These version-selective
> devices pertain to version of Python. The interest in the discussion here
> would relate to version of Django, of course, where it seems similar
> measures might apply.
>
> --
> 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/5bf15a4b-8360-4ee0-a985-
> 01f42e7e27fd%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

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

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Hi Graham, thanks for the support.

I'm aiming at Django 1.10 right now, but given that APIs are more stable
than implementation, you may have some success with other versions. This is
just a guess, I haven't tried

Best,
D.

On Sat, Aug 27, 2016 at 7:29 AM, Graham Wideman 
wrote:

> First -- three thumbs up for Daniel's initiative and advocacy!  Count me
> in as a random enthusiastic would-be user.
>
> Question: I've looked at Daniels repo and the pyi files therein, and one
> issue is ascertaining which version of Django they apply to. Are there some
> ideas about how that's to be done?
>
> Graham
>
> On Wednesday, August 17, 2016 at 7:13:51 AM UTC-7, dmoisset wrote:
>>
>> Thanks for the replies,
>>
>> As I mentioned, I have already started implementation ...
>>
> --
> 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/ac0102f7-9106-40dd-be62-
> 17fcb30c0f1f%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

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

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Thanks for the replies,

As I mentioned, I have already started implementation (and I'm willing to
go through with it, having even some time from my work allocated to do it);
I wasn't aware of the JetBrains plan (it's a nice plus, but I don't depend
on it), and I'll probably do it as external files if the django core team
itself is not interested, but I think it's more beneficial to do it inline.

One clarification is that there is no need to drop 2.7 support to use
inline annotations; there's a python2 compatible way to annotate described
now in PEP484.

What I'd like to do is to get a reading of the room to see if there's some
degree of interest (at least a "I'm curious to see how it looks if you do
the work") before following up with the DEP process. I made a very quick
summary of what I think the benefits would be, but if it's not clear I'd be
happy to ellaborate.

Some key things that have changed since last year (regarding the links
posted by Florian and Tim) are:

* PEP-484 is now approved and standard part of python. The mypy checker is
now under the python project umbrella and getting active maintainance and
backed by key people in the python community
* Having a standard (instead of just a 3rd party tool supporting this)
means that this now annotations can help to interoperate with many tools
(type checkers, editors, documentation generators, refactoring tools), so
the impact in the ecosystem is larger
* There's some evidence that this works on production (people in dropbox
have been using it for ~ a year, according to [1])
* There are several complaints telling that "this won't be actually
optional", but I see no evidence to support it. And in any case those are
arguments around deciding to include this in the language, and that
decision has been made already. But in my experience, annotations help more
in some particular modules/APIs and not in others, so an abvious option is
to add them only where they add value (i.e. increase readbility and clarity
of interfaces)
* Cory Benfield points at some complex types, that (from a quick look) with
new type aliases and overload semantics can probably be described in a much
simpler and readable way. And again, if they don't that function (or that
argument) shouldn't be annotated.
* There's someone volunteering to do the work (me and some colleagues at
Machinalis) :)

I've already been looking at some interfaces in django and I feel that a
lot of them are as not dynamic and polymorphic as requests is, so some
success can be achieved here.

So, how do you guys feel about this? what are the risks/fears that you'd
like to have addressed? do you share my opinion that this will be positive
for both the framework and its users?

Best,

[1] http://pythonpodcast.com/david-greg-mypy.html


On Wed, Aug 17, 2016 at 2:41 PM, Tim Graham  wrote:

> The JetBrains announcement that they want to fund the project isn't a
> guarantee that it'll be implemented. The feature needs to go through the
> normal feature acceptance process, which as Markus said, might involve a
> DEP.
>
> Assuming the idea is accepted, my sense on timing would be to wait until
> January when Django drops support for Python 2.7 and 3.4 in master. Then we
> could use inline annotations rather than the stub files.
>
> Past discussions of type hinting:
> https://groups.google.com/d/topic/django-developers/z_P1TvJ6QG8/discussion
> https://groups.google.com/d/topic/django-developers/xOTmq93YZuQ/discussion
>
> On Wednesday, August 17, 2016 at 5:30:56 AM UTC-4, Florian Apolloner wrote:
>>
>>
>>
>> On Wednesday, August 17, 2016 at 11:06:47 AM UTC+2, dmoisset wrote:
>>>
>>> @Florian
>>> Would you care to ellaborate? I couldn't find the post you mention
>>> (although requests is one of the few 3rd party projects that have support
>>> at the official typeshed repository, https://github.com/python/typeshed
>>> )
>>>
>>
>> https://lwn.net/Articles/643269/ and https://lwn.net/Articles/643399/ --
>> might be that things changed by now.
>>
> --
> 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/b5dcb500-4706-407f-8e42-
> 65944d30ccf5%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset

-- 
You received this message because you are subscribed to the Google Groups 
"Django 

Re: PEP 484 type hinting in Django

[Daniel Moisset]

Hi

@Alex,

I wasn't aware of the fellowship program, but I've been getting started to
work at this and I already have some minimal things up

I have a repo with type hints (currently just covering the HttpRequest
object and other minor stuff) at https://github.com/machinalis/mypy-django ;
I'm currently working on the HttpResponse object (with that I can already
have some typehinting at my views). To work on it I'm actually doing
annotations on the source code (I have a forked django at
https://github.com/dmoisset/django/tree/typing-requests ), and then
converting those to stub files, In that way I can run the checker against
the actual code and ensure the annotations are consistent.

I was planning to make a comment about these here when they were a bit more
mature with some minimal example, but given that the discussion already got
here I think they may help.

@Markus
If there's interest in the community, I volunteer for the process of
getting in charge of the discussion and drafting of the DEP. I wanted to
know first how the community feels about these.

@Florian
Would you care to ellaborate? I couldn't find the post you mention
(although requests is one of the few 3rd party projects that have support
at the official typeshed repository, https://github.com/python/typeshed )

*
@all

For those of you wondering what all these is about, it's about adding
static type hints to the arguments/result types of the results in Django.
Currently there are 2 ways to do this:

A) As a 3rd party project, providing separate "interface files" that mimic
the ones with django, only with the function/method signatures
B) As inline annotation in the django code (think of it as structured
docstrings)

Option (A) has the benefit of not interfering at all with the project, with
the burden that it's harder to maintain and keep in sync when django makes
new releases; it only helps django users
Option (B) is easy to keep in sync and can help with django development
itself, but it may imply some process changes (integrating a checker into
CI, and in some very specific cases making contributors aware of it).
Another drawback is that given that django still supports python 2, we need
to use the "#type" comments instead of python3 annotations that are quite
uglier.

I've been working doing this for some internal projects at Machinalis and
for a couple open source projects. So let me add a few comments that I
already know that are frequently asked questions:

* This has minimal to zero impact on runtime (probably adding a few
imports). It's comparable to adding docstrings to a module that doesn't
have it. The annotation is for outside analyzer tools (checkers and
linters) running on CI, not on the django project itself
* This does not have to be done project-wide, so it's not a huge
undertaking; the point of gradual typing is that you can work at function
granularity and build up. That's why I've started in small but visible
modules like HttpRequest/HttpResponse.
* In fact, there are some parts of django that will probably not be covered
for a long time (I thinking QuerySets here) because they would need
substantial support from the tool to make sense
* The main goal of this is NOT detecting bugs (tests generally work ok).
The goal is providing accurate documentation about function inputs and
outputs that can help humans (for example people asking themselves "are the
keys of request.FILES bytes or unicode?"), and tools (for example
documentation generators that could expose this info, code editors that can
add autocompletion, etc)
* In a codebase with builtin annotations, it may help detecting simple bugs
more quickly than the test suite; it works well integrated with an editor
(in the same way that tools like pep8/flake8 detect simple things there).
The power here increases as you get more core annotated (but again, it may
work gradually).

I also wanted to reinforce that I'm not asking somebody else to do it... I
need this, so I'm already working on it, but I welcome anyone to join :)

Best,
D.




On Wed, Aug 17, 2016 at 5:08 AM, Alexander Hill  wrote:

> Hi all,
>
> I like the plan to include PEP 484 type hinting in Django, outlined in the
> PyCharm promotion blog post. [1]
>
> Has this proposal been fleshed out much? Is there any extra information
> available anywhere that I've missed? I think this will be great for Django,
> and I'd happily contribute to the effort.
>
> Cheers,
> Alex
>
> [1] https://www.djangoproject.com/weblog/2016/jun/30/
> pycharm-and-django-fundraiser/
>
> --
> 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 

Re: Should DecimalField have special rounding to make float assignments match string assignments?

[Daniel Moisset]

I'm not sure when it changed, but decimal.Decimal(some_float) was also an
error in 2.4 and 2.6 at least. I'm seeing that it works in 2.7, 3.3, 3.4,
3.5, so it's probably a recent decision, looking up the rationale for that
could be relevant

On Tue, Apr 5, 2016 at 3:30 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Small corrections:
>
> About 1) — actually decimal.Decimal() was an error Python 3.0 and
> 3.1.
>
> About 2) — I mixed up two options for the factory to build decimals from
> floats:
>
> - the decimal.Decimal.from_float class method — which I assume uses the
> global context
> - the decimal.Context..create_decimal_from_float method — which relies on
> a specific context
>
> https://docs.python.org/3.5/library/decimal.html#decimal.Decimal.from_float
>
> I assume the latter will be more convenient for low level control.
>
> --
> Aymeric.
>
> On 05 Apr 2016, at 16:17, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
> I have three ideas about this.
>
> 1) In my opinion, assigning a float to a decimal field is a programming
> error. Sadly Python doesn’t raise an exception in that case.
>
> >>> decimal.Decimal(2.15)
> Decimal('2.149911182158029987476766109466552734375')
>
> So Django has to support it as well.
>
> 2) Python 3 provides the `create_decimal_from_float()` class method
> on `decimal.Context` for this purpose. I think that’s what Django should
> use.
>
> >>> decimal.Context(prec=10).create_decimal_from_float(2.15)
> Decimal('2.15000')
>
>
> https://docs.python.org/3.5/library/decimal.html#decimal.Context.create_decimal_from_float
>
> (I don’t care much about Python 2 at this point. We should just make sure
> we don’t introduce a debatable behavior in the last LTS release supporting
> Python 2.)
>
> 3) Currently DecimalField accepts max_digits and decimal_places options. I
> think it should accept a decimal context and delegate all operations to
> that context.
>
> I suggest the following behavior:
>
> - start with the decimal context provided in a kwarg to DecimalField or,
> if there is None, the current context returned by `getcontext()`
> - modify that context to take into account max_digits and decimal_places
> - ask the context to perform whatever operations we need
>
> https://docs.python.org/3.5/library/decimal.html#decimal.getcontext
>
> I’m -1 on emulating that with arbitrary string conversions and rounding
> rules and also -1 on deviating from Python’s default behavior, which
> matches the IEEE 754 specification, without providing a way to customize
> that behavior properly.
>
> I hope this helps !
>
> --
> Aymeric.
>
> On 05 Apr 2016, at 15:49, Tim Graham  wrote:
>
> If you assign a float with more decimal places than a DecimalField field
> supports to that field, the value may round differently than if you assign
> the same value as a string. For example:
>
> class Invoice(models.Model):
> gross = models.DecimalField(max_digits=10, decimal_places=1)
>
> invoice.gross = 2.15# saves as 2.1
> invoice.gross = '2.15'  # saves as 2.2
>
> The default behavior of decimal rounding is ROUND_HALF_EVEN (to nearest
> with ties going to nearest even integer). There's a proposal to change this
> to cast floats to string and then use ROUND_HALF_UP to match the value of
> strings [0][1]. Do you have any concerns about this? Is it something we
> should even care about?
>
> [0] https://github.com/django/django/pull/6410
> [1] https://code.djangoproject.com/ticket/26459
>
> --
> 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/3749bbaf-ded7-4de3-912b-3a9e654b0207%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/07CD3A6B-EC86-42CC-A6BC-03D74112A0C3%40polytechnique.org
> 

Re: Future of the development server's auto-reloading

[Daniel Moisset]

The idea sounds awesome. A couple of corner cases that should be taken in
consideration:

 - I think it is common for small simple projects (and people doing the
tutorial) to have the sqlite db file in the same project directory. If
we're watching for writes in every file in the project directory, every
save() could trigger a reload
 - It is also usual to have the media/ directory based on filesystem
storage inside the project dir. So any project with file uploads could
trigger a reload on each file upload.

Possibly some exclusion rules with sane defaults could help here

Regards,

D.



On Sat, Aug 8, 2015 at 6:53 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> While writing some horrific code [1] related to the development server’s
> auto-reloading, I realized that its design is fundamentally flawed and I
> think that we should reconsider it.
>
> The current implementation walks through the list of all imported Python
> modules, attempts to figure out which file they come from and builds a list
> of these files. Then it watches all these files for changes by checking if
> their mtime changed every second or, since 1.7, with inotify on Linux. I
> tried to do it with kqueue on BSD (read: OS X) but I failed. This stuff is
> hard.
>
> In addition to the source of imported Python modules, the autoreloader
> watches .mo files in order to catch translation changes and source files
> for modules that failed to import — it extracts them from exception
> tracebacks. This shows the limits of basing the list on imported Python
> modules. Even with such hacks, the auto-reloader will never handle all
> cases. Two examples:
>
> - It doesn’t survive a syntax error in the settings module. I have reasons
> to believe that this would be extremely messy to fix.
> - If a module reads a configuration file on disk at startup and caches it,
> the auto-reloader doesn’t detect changes to that file.
>
> So we’re stuck with cases where the development server doesn’t reload. I
> can’t say they’re edge cases; who never made a typo in a settings file?
> People who run tutorials report that it’s a very common cause of
> frustration for beginners.
>
> It's also wasteful. There’s little need to watch every file of every
> dependency in the virtualenv for changes.
>
> I think it would be much better to remove the auto-reloading logic from
> Django and have an external process watch the current working directory for
> changes. (When virtualenv is considered appropriate for people with exactly
> 0 days of Django experience under their belt, I think we can require a
> dependency for the development server’s auto-reloading.)
>
> The behavior would be much easier to describe: if you change something in
> your source tree, it reloads automatically; if you change something
> somewhere else, you must reload manually. It would also be quite easy to
> customize with a standard include / exclude mechanism to select which files
> should be watched.
>
> We aren’t in the business of writing production web servers, neither are
> we in the business of writing a filesystem watcher :-) Watchman [2] appears
> to be a robust solution. However I would prefer a pure-Python
> implementation that could easily be installed in a virtualenv. Does someone
> have experience in this area?
>
> I’m not making a concrete proposal as I haven’t studied the details. It
> this point I’d just like to hear what you think of the general concept.
>
> Thanks!
>
> --
> Aymeric.
>
> [1] https://github.com/django/django/pull/5106
> [2] https://github.com/facebook/watchman
> [3]
> http://tutorial.djangogirls.org/en/django_installation/index.html#virtual-environment
>
> --
> 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/8E08AB59-2450-40D5-A52B-C8803DA39D5F%40polytechnique.org
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Daniel F. Moisset - Technical Leader
www.machinalis.com
Skype: @dmoisset

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

Re: Loading fixtures once for each TestCase to improve running time

[Daniel Moisset]

A long time ago (django 1.3 era) I wrote a library (no need to change
django) to do exactly this, using savepoints to rollback:
https://github.com/machinalis/django-fasttest

It worked pretty well for a large project and provided a large speedup (i
think it was about 5x) on a large test suite. But I haven't mantained it
since, I started doing everything with factories (factory boy) and
abandoning fixtures because they were hard to maintain. You might find it
useful if you can update it to newer django versions; also note that the
current code was developend with postgres, it might work on some other db
but I have no idea.

Regards,
D.





On Sat, Jun 7, 2014 at 4:34 AM, Josh Smeaton  wrote:

> I've been looking into the django testing infrastructure today to see if
> there was any particular reason why the test suite takes so long to run.
> Mainly, I didn't understand why fixtures are loaded for every single test
> method. To be honest, I didn't think fixtures were loaded for every test
> method; I assumed they were loaded once when the TestCase was created.
>
> My mental model looked like this:
>
> # for each test module:
> call_command(flush)  # flush the DB ready for this test case
> testcase = get_test_case()  # returns the next subclass of TestCase (or
> TransactionTestCase etc)
> *testcase.load_fixtures()  # populate the DB with data for the entire test
> case*
> for test_method in testcase.get_test_methods():
> with db.transaction():  # at the end of each test_method, rollback so
> that we're back to our fixtures
> testcase.setUp()
> getattr(testcase, test_method)()
> testcase.tearDown()
>
>
> Unfortunately, that's not at all what happens. For each test method,
> you're given a brand new instance of the testcase, and the initial data is
> loaded again:
>
> # for each test module:
> call_command(flush)  # flush the DB ready for this test case
> testcaseclass = get_test_case()
> for test_method in testcaseclass.get_test_methods():
> with db.transaction():  # at the end of each test_method, rollback to
> an empty database
> testcase = testcaseclass(testMethod=test_method)
> *testcase.load_fixtures()  # populate the DB with data for a
> single test_method*
> testcase.setUp()
> testcase.run()  # runs the testMethod
> testcase.tearDown()
>
>
> Note that the above isn't exactly right, but I think it demonstrates the
> problem. Each test_method is given its own TestCase (unnecessary python
> overhead), but more importantly, we're not using transactions to get back
> to the initial data. We're using transactions to get back to an empty
> database before loading fixtures again.
>
> I know lots of people have invested lots of time on the test suite,
> especially when it comes to run time. I doubt that I'm raising anything new
> for the people who have come before. But my question is why? Is there a
> reason that each test method has to have its own TestCase? Is there a
> reason that each test method has to load its own fixtures again and again,
> or is that just a symptom of how each test_method is collected by the test
> suite?
>
> There are many kinds of tests that deal with the ORM that should be able
> to rely on fixtures being loaded once for the entire TestCase, and relying
> on transactions to get back to initial data. Is this theoretically
> possible, or am I missing something? I figure we could eliminate something
> like 1/3rd of all queries.
>
> Regards,
>
> Josh
>
> --
> 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/07c8e766-43e6-4362-bba1-695d3855a77a%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" 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/CALuYSZX78Hp_Pcr-WUtFNTXHzj95T6AZ-XvQOfwDvaMpNV6d_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for function application in ORDER BY

[Daniel Moisset]

oh, nevermind, I misread the syntax spec for the order by clause


On Mon, Jun 9, 2014 at 5:07 PM, Michael Manfre <mman...@gmail.com> wrote:

> Each expression must be able to define it's own ordering because order_by
> allows you to define a sort based upon multiple expressions.
>
>
> On Mon, Jun 9, 2014 at 4:00 PM, Daniel Moisset <dmois...@machinalis.com>
> wrote:
>
>> I see everyone trying to put the direction (ascending vs decending)
>> inside the expression, while it's actually a property of the ordering
>> clause. Wouldn't it make more sense and avoid ambiguities to do:
>>
>> qs.order_by(..., descending=True)
>>
>> ?
>>
>> Then you can add functions (and even a __neg__ operator to fields mapped
>> to SQL unary minus) and still have a clear separation of functions vs order
>> direction.
>>
>> D.
>>
>>
>>
>> On Mon, Jun 9, 2014 at 4:44 PM, Tim Martin <t...@asymptotic.co.uk> wrote:
>>
>>> My concern about the filter(foobar_lt=-F('baz')) issue is that it
>>> violates the principle of least surprise: it will be accepted silently and
>>> do something that nobody could expect unless they know a bit about the
>>> internals. However, I think having some special case code in filter(),
>>> annotate() and anything else that takes expressions would be OK. Provided
>>> it throws some kind of exception, I think it resolves my concern.
>>>
>>> I'll go ahead and try to implement this using __neg__() to invert the
>>> ordering.
>>>
>>> Tim
>>>
>>> --
>>> 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/20cd8bd0-9d5d-4ed3-9748-1412188e6726%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/20cd8bd0-9d5d-4ed3-9748-1412188e6726%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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/CALuYSZVYnXHapfvf5SwPJxLYkxiv%3DTPyJg2XYGFVhCPSyc7Fgw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CALuYSZVYnXHapfvf5SwPJxLYkxiv%3DTPyJg2XYGFVhCPSyc7Fgw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAGdCwBuHBtQLsVEeftfZAVrx6hdZSvz9ED%3DMmjZvyg%2B--%3D6moQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAGdCwBuHBtQLsVEeftfZAVrx6hdZSvz9ED%3DMmjZvyg%2B--%3D6moQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CALuYSZX20zM5nvz%3DQVXShu4wR8_QgropHgjR_8ZxoRbcSfxaxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for function application in ORDER BY

[Daniel Moisset]

I see everyone trying to put the direction (ascending vs decending) inside
the expression, while it's actually a property of the ordering clause.
Wouldn't it make more sense and avoid ambiguities to do:

qs.order_by(..., descending=True)

?

Then you can add functions (and even a __neg__ operator to fields mapped to
SQL unary minus) and still have a clear separation of functions vs order
direction.

D.



On Mon, Jun 9, 2014 at 4:44 PM, Tim Martin  wrote:

> My concern about the filter(foobar_lt=-F('baz')) issue is that it
> violates the principle of least surprise: it will be accepted silently and
> do something that nobody could expect unless they know a bit about the
> internals. However, I think having some special case code in filter(),
> annotate() and anything else that takes expressions would be OK. Provided
> it throws some kind of exception, I think it resolves my concern.
>
> I'll go ahead and try to implement this using __neg__() to invert the
> ordering.
>
> Tim
>
> --
> 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/20cd8bd0-9d5d-4ed3-9748-1412188e6726%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" 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/CALuYSZVYnXHapfvf5SwPJxLYkxiv%3DTPyJg2XYGFVhCPSyc7Fgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A.objects.getdefault

[Daniel Moisset]

On Thu, Oct 11, 2012 at 2:00 PM, Marijonas Petrauskas  wrote:
> You can use:
>
> obj = next(iter(SomeModel.objects.filter(foo='bar')), None)
>
> The 'iter' part is not particularly elegant, but it's the only one-liner
> known to me.
>

obj, = SomeModel.objects.filter(foo='bar') or [None]

but we're getting deep into django-users land.

D.

-- 
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: Test runner with search

[Daniel Moisset]

On Thu, Jun 14, 2012 at 7:35 AM, Chris Wilson  wrote:
> Hi all,
>
> I've made some improvements (in my view) to the DjangoTestSuiteRunner. I
> got tired of having to remember my test class names and of typing so much:
>
>  ./manage.py test binder.BinderTest.test_can_create_users
>

In this same line, there's also
http://pypi.python.org/pypi/django-test-autocomplete ; although that's
more bash-oriented

Regards,
 D.

-- 
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: django admin missing meta tag for charcter encoding in the head

[Daniel Moisset]

On Tue, Apr 3, 2012 at 12:37 PM, Ric  wrote:
> hi,
>
> the default django template need a meta tag for character encoding in
> the head
>
> 
>

why? the Content-Type should be properly served in the HTTP headers...
(if it isn't, then you have a genuine bug)

Regards,
   D.

-- 
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: Revisiting multiline tags

[Daniel Moisset]

On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor  wrote:
>
> Folks, you seem to have missed Russell's point.  Even if 100 people +1 this,
> it's meaningless.  That's a tiny fraction of this mailing list's readership,
> much less of the Django community at large.  Django is the way it is
> because, first and foremost, of taste.  If you'd like to make an argument as
> to *why* it's useful, that's useful, but we don't take polls.
>

It's useful because it helps some templaets in some cases be more readable

-- 
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: Revisiting multiline tags

[Daniel Moisset]

On Fri, Feb 24, 2012 at 6:01 AM, Stephan Jaensch  wrote:
>> This thread contains 6 people expressing support for this change, and 2 
>> against (a BDFL, a core developer) -- and you can add me to the -0 list. 
>> There are over 6000 subscribers to django-developers. I put it to you that 
>> the vast majority of people haven't expressed an opinion -- and many of 
>> those haven't expressed an opinion because they're happy with (or 
>> indifferent to) the status quo, and a BDFL has already indicated that the 
>> status quo is his preferred option.
>
> You asked for it, so here is my +1.
>

And mine; even if I might have needed multiline tags once or twice in
several years, I think it's perfectly reasonable, and the current
behaviour non-intuitive.

+1

D.

-- 
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: Getting a traceback out of connection.queries

[Daniel Moisset]

On Tue, Jan 31, 2012 at 8:34 PM, josharian  wrote:
> Hi all,
>
> We're using connection.queries to log all sql executed during
> development. I find myself wishing that in addition to 'sql' and
> 'time', there was a 'traceback' entry, so that troublesome/mysterious
> queries could quickly be tracked back to their origins.
>
> Adding it is a pretty small patch -- an `import traceback` and a
> couple of `'traceback': traceback.extract_stack(),`s. My question is:
> Is there a better way to get at this data currently? Is there any
> interest in such a patch?
>
> Thanks,
> Josh

Using django-debug-toolbar provides that functionality, without having
to modify the django core

D.

-- 
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: More about test speedup

[Daniel Moisset]

On Tue, Jan 24, 2012 at 2:22 AM, Anssi Kääriäinen
<anssi.kaariai...@thl.fi> wrote:
> On Jan 24, 3:07 am, Daniel Moisset <dmois...@machinalis.com> wrote:
>> [1] The idea is loading fixtures once per TestCase instead of once per
>> test method, and use DB rollbacks after each test to return the DB to
>> the after-fixtures-just-loaded state.
>
> So, the idea is to do the following for each TestCase:
>
> begin
> load fixtures
> savepoint s1
> do test 1
> rollback to savepoint 1
> do test 2
> rollback to savepoint 1
> ...
> # all methods ran
> rollback
>
> I think that should work. It would be great to write this in a way
> that just checks if the connection supports savepoints. If not, then
> run the tests in the old-fashioned way, if yes, do the above trick.

OK, I can change that... there are a few other drawbacks: my current
code does not support multi-db setups, And I don't feel experienced
enough on that scenario to feel sure how to proceed in that case or
what is safe to do.

Anyway what I can do is: if connection support savepoints AND is
single db, follow this approach

Regards,
   D.

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

More about test speedup

[Daniel Moisset]

Somewhat independently from the recent thread, I had been working in
getting tests running faster. I essentially reimplemented an idea that
Erik Rose[1] posted here last year, but I did it in a way that I think
is more DB independent (although... I'm using it and have tested it
only under PostgreSQL which is what I needed :) )

My customized TestCase is quite simple and available at
https://github.com/machinalis/django-fasttest

It's a bit rough but I'm using it for a real project with a ~2x
speedup (my tests make heavy use of fixtures so YMMV).

If there's interest, something like this could be polished into a
django patch; I'd like to hear the opinion of the core devs if they
are aligned with the idea, so I can polish the implementation and
submit a patch

Regards,
D.

[1] The idea is loading fixtures once per TestCase instead of once per
test method, and use DB rollbacks after each test to return the DB to
the after-fixtures-just-loaded state.

-- 
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: confusing things in Trac UI (was: Design decision for #1625...)

[Daniel Moisset]

On Wed, Sep 28, 2011 at 1:14 PM, Jacob Kaplan-Moss wrote:

> On Tue, Sep 20, 2011 at 4:17 PM, Paul McMillan  wrote:
> > Yes! Let's get rid of [the "accept" button]. It still confuses me now
> even when I
> > know exactly what it means!
>
> If anyone knows how to do this, let me know and I'll make it happen.
>

If you ping my on IRC (Darni on freenode) I can give a hand, it should be
5-10 mins if you have your install handy

D.

-- 
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: Django test documentation example not respecting xUnit convention

[Daniel Moisset]

On Wed, Sep 21, 2011 at 2:13 AM, schinckel  wrote:

> It isn't 'enforced' by Python at a language level, but as dmoisset stated,
> it makes the failure messages actually make sense:
>
> "Expected 'foo', got 'bar'".
>
>
Actually that's not the message in Python's unittest (but I've seen messages
with that formatting in other xUnit frameworks for other languages)

D.

-- 
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: Django test documentation example not respecting xUnit convention

[Daniel Moisset]

On Tue, Sep 20, 2011 at 8:23 AM, Florian Apolloner wrote:

> Hi,
>
> a) Does this matter at all? I mean what's the difference? You ask if they
> are equal and if not you get an error ;)
>

Other xUnit framework actually show an error message explicit about it,
saying "expected 'foo', actual 'bar'". Python's unittest just says "foo !=
bar".

The difference is slightly more understandable error message when an
equality test fails: you know what the actual result was supposed to be


> b) I think it's the wrong mailing list for design decisions python took…
>

Or perhaps lack of design decision in this case? (I'm not sure it was
intentional)

Regards,
D.

-- 
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: RFC: "universal" view decorators

[Daniel Moisset]

On Thu, Sep 15, 2011 at 6:27 PM, Donald Stufft wrote:

> Gonna add this in here as well as ticket #14512
>
> I think using decorators to modify the way a CBV behaves is the wrong way
> to go about it, my reasoning is:
>
> 1) Decorators on functions make sense, since the only way to modify a
> function is to wrap it, so decorators provide a shortcut to do so.
>
> 2) There's already a standard way to add functionality to a class that has
> existed for a long time, is well tested, and as a bonus is something that
> people new to python but not new to programming will understand immediately.
>

I like the arguments here. On the other hand, I like Jacob's

«I'd like to convert all the view decorators built into Django to be
"universal" -- so they'll work to decorate *any* view, whether a function,
method, or class»

So what about providing something roughly like:

###
class LoginRequired():
# magic to check for user credentials, in a CBV style
...
def __call__(self, wrap_me):
# standard magic to apply the CBV decoration to a standard function
# This might also include Jacob's trick to work with methods too
...

login_required = LoginRequired # backwards compatibility
###

Actually that implementation of __call__ is probably the same for every
decorator, so Django can provide something more like:

###
from django.something import BaseViewDecorator
class LoginRequired(BaseViewDecorator):
# magic to check for user credentials, in a CBV style
...

login_required = LoginRequired # backwards compatibility
###

With that, user code can look like:

class SomeProtectedView(LoginRequired, TemplateView):
... as usual...

@login_required()
def some_other_protected_view(request, arg1, arg2):
as usual...

class NotAView():
@login_required()
def view_method(self, request, arg1, arg2):
   ... as usual ...

Which uses the "obvious" way of extension (decorators for functions/methods
and Mixins for classes) in each case (i.e., what Donald wants), but allows
implementing the decorator once, and not having to have specific wrappers
for each kind of view (universality, like Jacob wants).

This is a rough proposal to put another idea on the table, I know there's
the gotcha of the "login_required = LoginRequired" (which is to keep
backwards compatibility. Other alternative is rename the class to a non-PEP8
lowercase name). And I know there's the gotcha of having to use
login_required() instead of just login_required[1].

Does this sound like a good compromise between both positions?

Regards,
   Daniel

[1] I always found a bit irritating and antipythonic to have @login_required
as an alias for login_required() ; or in general, the behavior for
decorators with optional args, which besides needs to be coded explicitly
(DRY violation!) to behave like standard decorators. I know that changing
that would break a lot of code, and it's a story for another ticket, but I
couldn't miss the chance to complain :)

-- 
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: Forced password reset in django-admin

[Daniel Moisset]

On Wed, Jun 29, 2011 at 8:36 AM, benjaoming  wrote:
>
> Dear all,
>
> As a maintainer of many Django sites, I would often like to see a very
> small feature implemented, that could make life a lot easier for me:
> To force my users to set their own password.
>
> I know this could lead to a long debate about password strength, SSL,
> password reminders, secret answers etc... but for me, the most urgent
> problem is that people have to be reminded manually about their
> passwords, and I have to reset them pretty often (or find copies of
> emails that i've sent).

django.auth already provides a password reset mechanism, where users
can get a password reset link.

So, woudn't this work for you?:

1) Create users with a large random password. Destroy every copy of the password
2) Use the reset password feature with their email to force it to set
an initial value

That way you never send them actual passwords, and the only passwords
they can use are the ones they set.

all of this works with no additional support needed from django

D.

-- 
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: Django Design Czar

[Daniel Moisset]

On Mon, Jun 27, 2011 at 4:10 AM, Victor Hooi  wrote:
> heya,
> Sorry to resuscitate an old thread, but I was just wondering if there was
> any update on this? Was somebody made the Django design czar? Or is there
> any word on the Django admin redesign front?
> (https://groups.google.com/d/topic/django-developers/yk8m1haSF1M/discussion)

Yes, Idan Gazit is the BDFL (Benevelon Designer For Life)

https://groups.google.com/d/topic/django-developers/qUrDZMoihrc/discussion

Regards,
   D.

-- 
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: Form Rendering API Proposal

[Daniel Moisset]

On Thu, Jun 23, 2011 at 10:11 AM, Idan Gazit  wrote:
>
>
> On Thursday, June 23, 2011 4:06:05 PM UTC+3, dmoisset wrote:
>>
>> What is the "significant wart" ?
>
> The formconfig tag is a little bit "magical"; there's no other example in
> the template langauge of something explicitly affecting state in the same
> fashion. Even things like the "with" tag are self-bounding.
> Granted, formconfig is scoped to the form block, but stil. Feels a little
> bit dirty to me.

Maybe bikeshedding, but have you considered storing the configuration
on automatically created variables, and then setting those with a {%
with %} tag?

Automatically created variables is not a new concept ({% for %}
creates a "forloop" variable). Let me translate your previous example
to this idea to see what you think. I chose names rather arbitrarily,
probably they can be better thought out:

{% formconfig widget widgets.Textarea for "comment" %}

translates to...

{% with formconfig_widget_comment=widgets.Textarea %}
... the rest of the form here
{% endwith %}

And,

{% formconfig widget widgets.Textarea for "comment" %}

translates to...

{% with formconfig_row="forms/rows/ul.html" %}
... the rest of the form here
{% endwith %}

And,

  {% formconfig row using "forms/rows/p.html" %}
  {% formrow field1 %}
  {% formrow field2 %}
  {% formconfig row using "myrows/fancydiv.html" %}
  {% formrow field3 %}

...translates to...

{% with formconfig_row="forms/rows/p.html" %}
  {% formrow field1 %}
  {% formrow field2 %}
{% endwith %}
{% with formconfig_row="myrows/fancydiv.html" %}
  {% formrow field3 %}
{% endwith %}

Additionally, in the example above, it is easy to set a row renderer
for a single row and then go back to the default without having to
specifying explicitly:

  {% formrow field1 %}
  {% formrow field2 %}
{% with formconfig_row="myrows/fancydiv.html" %}
  {% formrow field3 %}
{% endwith %}
  {% formrow field4 %}

Actually, in my ideal world, instead of names with underscores, I'd
like to have formconfig.row and formconfig.widgets.fieldname, but that
would require adding some extra support for dotted vars to {% with %}
that might be dangerous

As an additional "I want a pony" feature, maybe if you are allowed to
define formconfig vars *outside* the form, and getting the form to
inherit it, you can make settings that span more than one form (and
still being explicitly scoped by a {% with %} tag)

What do you think?

Regards,
   D.

-- 
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: Form Rendering API Proposal

[Daniel Moisset]

On Thu, Jun 23, 2011 at 8:25 AM, Idan Gazit  wrote:
> At DjangoCon Europe 2011, Gregor Müllegger gave a great lightning talk about
> his work on a revised form rendering API:
> http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
> I sat down with Gregor, Jannis, Russell, Alex, Ericflo, Andrew Godwin, and
> many other fine minds at the sprints to think about his proposal and help
> refine it. At the risk of starting a bikeshedding war, I'd like to share the
> results of the sprints and get some feedback on our proposed approach.
> I'm very pleased with the resulting API. It has one significant wart, but
> having chewed on the alternatives, I think there is consensus that this API
> represents a good compromise between purity and practical considerations.
>

It seems really nice (said as someone who has done almost as much
frontend as backend work)

What is the "significant wart" ?

Daniel

-- 
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: Proposal: remove "Change" links on admin index page

[Daniel Moisset]

On Tue, May 24, 2011 at 3:48 AM, Anshuman Aggarwal
 wrote:
> Luke,
>  I completely agree on the need for change and personally +1 this as
> it is a completely confusing historical annoyance.
>
> However, as in all deprecation, I would suggest that we start with a
> global setting that allows these links to be hidden on an installation
> by installation basis and the default made to true for now.
> With the next release, the default can be made False and eventually
> when there is an enhancement available, that can be the option
> available.
>
> e.g.
> ADMIN_SHOW_CHANGE_LINKS  = True (defaults to False)
>

Users won't guess the existence of this setting, so any user who found
this was reading the release notes/upgrading docs (which he should :)
). So rather than adding "use the ADMIN_SHOW_CHANGE_LINKS setting" to
the docs, I'd rather add "update template X, adding line YY to get
the old behavior", instead of cluttering the setting list.

I'm +1 to the change as long as it's documented and there's an easy
and documented way to edit the template to re-add the old behavior...
maybe adding a {% block %} inside the  to make it easy to override
with template inheritance.

Regards,
D.

-- 
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: math tag

[Daniel Moisset]

On Tue, May 3, 2011 at 3:57 PM, Johannes Dollinger
 wrote:
>
> FWIW, here are some concrete use-cases for math in templates:
>
> * __mul__: Display a value of 0.42 as 42%.
> * __neg__/__abs__: Display the absolute value and signum of a number 
> separately.
> * log: Display a number on a logarithmic scale.
> * floor/ceil: Display floored or ceiled values.
>

What does the core team think about a math library with useful (like
in the examples above) filters? i.e, {% load math %} ... {{ x|abs }}
{{ y|log:"10" }}
Most cases I can think of are unary, so they lend nicely to the filter syntax..

In addition to the above, I can think of the following from the python
math module:
 * isinf (and maybe isnan)? to pretty print infinities
 * trunc. actually this/ceil/floor are somewhat covered by the float
formatting functions, but sometimes not enough.

I've found use at some project to binary conversions/bit
querying functions (to nicely display bitflags), but that might be
overkill for a general purpose library in the core.

> I'd still be -1 regarding a {%math%} tag. The cleanest solution would be 
> proper support for common operators mixed with a set of default filters for 
> primitive functions (e.g log, floor, ceil, abs).

Regards,
   D.

-- 
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: math tag

[Daniel Moisset]

On Tue, May 3, 2011 at 9:19 AM, Tom Evans  wrote:
>
> From another POV, there is no chance for the designer to screw the
> template up and calculate the wrong value, if he is only allowed to
> output data.
>

And the view writer can screw it too, using that logic...

Saying "separating logic from data display enhances the design" is a
good argument for a simpler template language. "Template writers are
dumb" isn't

Regards,
   D.

-- 
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: RFC: new backports policy

[Daniel Moisset]

On Tue, Apr 19, 2011 at 4:22 PM, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
>
> The core team has come to a rough consensus and we're planning to drop
> this backport-everything policy. Instead, we'll only backport critical
> patches. That is, we'd only backport patches for:
>
> * Security issues.
> * Data-loss bugs.
> * Crashing bugs.
> * Major functionality bugs in newly-introduced features.
>
> In other words, we'd basically only backport bugs that would have
> prevented a release in the first place.

Is this a policy against backporting fixes by default, or against the
backports themselves?

Let me put it in another way with an example: you don't want to do the
backport, and it's your policy, and it sounds like a good idea. But
I'm using 1.3 in production and there's a bugfix I really want, so I
do the backport (and write the code, tests, docs). If I submit this to
the issue tracker, is there a chance my patch will get into the next
minor release, or you won't even consider it?

The answer for this should be included in the documentation, it's
useful for end-users and also for people reviewing patches

Regards,
D.

-- 
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: Ticket reports page redesign

[Daniel Moisset]

On Wed, Mar 23, 2011 at 12:32 PM, Jacob Kaplan-Moss  wrote:
> On Wed, Mar 23, 2011 at 4:39 AM, Luke Plant  wrote:
>> It appears to me that this reports page is not nearly as useful as it
>> could be, and I'm thinking of redesigning it.
>
> Sounds just fine for me -- I really threw together the first version
> with very little thought. Feel free to go ahead!
>
> On a semi-related note, if any Trac-heads can suggest a better way of
> doing "canned queries" like this -- a plugin maybe? -- that might be
> more appropriate. But the wiki's fine if not.

Trac has a way to define reports, usually it would be at /report, but
my guess is that the django trac has it disabled.

Enabling that allows an admin to define reports (even complex SQL
queries), and/or save custom queries as canned reports. You can then
browse the list of reports, and also link them from the wiki

Regards,
   D.

-- 
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: Suggestion: a new "nature" field in Trac

[Daniel Moisset]

On Tue, Feb 22, 2011 at 11:21 AM, Russell Keith-Magee
 wrote:
>
> This is one of those areas where we need someone to step up an
> volunteer to do some Trac work and show us what is possible.
>

If http://trac-hacks.org/wiki/VotePlugin is fine for the needs, I'm ok
with helping install it; although I need proper access to install it
in the django trac.

Same offer re #14702, given that I was the one pushing for it :)

Regards,
D.

-- 
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: Suggestion: a new "nature" field in Trac

[Daniel Moisset]

On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip  wrote:
> Hello,
>
> I was wondering if others would find it useful to introduce a new
> field in Trac to characterise the nature of a ticket, allowing to
> choose from at least: "bug report", "feature request", or
> "optimisation".

Trac already has a "type" field. Default values are "defect"
"enhancement" and "task", but that can be changed. I'm not very
convinced that people will use it and that it will help, but it's so
wasy to add that I guess there's no harm in configuring it.

D.

-- 
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: django/trunk/django/core/files/base.py -- File, why not a subclass of file ?

[Daniel Moisset]

On Mon, Feb 21, 2011 at 8:55 AM, sebastien piquemal  wrote:
> Hi !
>
> It might be a stupid question, but is there a reason why
> `django.trunk.django.core.files.base.File` is not a subclass of
> `file` ?
> I ask this because after debugging my code - some urllib2 handler
> (http://dpaste.com/437031/), based on a snippet I found somewhere - I
> figured out that posted files were not handled like I wanted to ...
> just because they were not `file` objects ... Wouldn't it be cleaner
> that they would actually be `file` objects ?

Inheriting file may produce behavioral side effects in your class that
are hard to predict. The normal way in Python to do this is just
replicate the interface and substitute (duck typing). If the snippet
you have explicitly checks for inheritance (with isinstance, for
example), I'd say the snippet is not very pythonic. I suggest asking
how to fix it in django-users, posting a copy/link of the snippet

Regards,
   D.

-- 
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: RFC: Add a "needinfo" state to triaging

[Daniel Moisset]

On Wed, Nov 17, 2010 at 10:49 AM, Russell Keith-Magee
 wrote:
> On Wed, Nov 17, 2010 at 9:22 PM, Gabriel Hurley  wrote:
>> Bear in mind that this is a *very* old Trac installation... ;-)
>
> Hopefully not for long.
>
> Jacob is in the process of bringing a new server online to host
> djangoproject.com, and part of that upgrade will be an updated Trac
> install, running Trac 0.12 rather than 0.10. Once that upgrade is in
> place, it will (hopefully) be a lot easier to implement this and other
> Trac changes.
>

Hi. This message intends to be a small nudge to reactivate
http://code.djangoproject.com/ticket/14702 which was waiting on the
trac migration.

I know this probably must be handled by a trac admin, but if I can
help in some way, I have enough experience setting up trac to help
here. Just let me know. I also can help updating
http://code.djangoproject.com/wiki/ContributingHowTo (which will be
needed for the #14401 doc update) once this change is done

Regards,
   D.

-- 
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: One Django instance, hundreds of websites

[Daniel Moisset]

On Sun, Jan 30, 2011 at 2:20 AM, Russell Keith-Magee
 wrote:
>
> Every single problem associated with using global variables exists
> with threadlocals -- and then a few more. They *can* be used
> successfully. However, in almost every case, they can also be avoided
> entirely with a good dose of rigorous engineering.
>
> I *strongly* advise against the use of this technique.
>

I understand (and completely support) your objection, specially when
someone says «one could save even the request object to thread
"global" and it would be accessible anywhere.» (which would make code
using requests, i.e. a lot of it harder to reuse and to test)

But the core problem being solved here, about moving SITE_ID to a
threadlocal, doesn't look like bad engineering to me. In fact is
moving something that is already global (everything in settings.py is)
to alocation which is *less* global (thread-wise instead of
process-wise). So this is an increase in locality, if I got it
right...

In which way is this worse than the current state of a global
variable? (and in general, do you have some reference to explain
«Every single problem associated with using global variables exists
with threadlocals -- and then a few more»? I tend to think that a
thread local is generally better than a global, even if it tends to be
worse that good API design/argument passing)

Regards,
   D.

-- 
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: i18n bug in inlines (failing silently)

[Daniel Moisset]

On Mon, Jan 17, 2011 at 11:40 AM, Russell Keith-Magee
 wrote:
>> Is there any interest from the core devs in something like this (a
>> system to log template rendering exceptions, even when they're masked
>> from the user)?
>
> I thought I just gave support for exactly that idea... quoting:
>
> """Now that we have a logging framework baked into Django, there is an
> argument to be made that template errors that are silently ignored
> should, in fact, be logged so that developers can do a post-mortem and
> identify problems."""

You did, I wasn't sure that was direct support... you sayed that there
was an argument to be made, and I was making it :)

Regards,
   D.

-- 
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: i18n bug in inlines (failing silently)

[Daniel Moisset]

On Sat, Jan 15, 2011 at 9:23 PM, Marc Garcia  wrote:
> Well, I still see that policy a way of hiding symptoms, more than an
> advantage for users, but thank you so much for the explanations
> Russell.
>

I've also felt the same always... I understand and agree with the
philosophy of "always render parseable templates", and also with not
displaying this issues to the *end user* of the site. But I think a
lot of time could be saved if the exceptions which are (correctly)
masked from the end user should be reported somehow to the site
administrator/developer anyway so he can do something about those
And nwo that django has a logging mechanism perhaps inetgration with
that should go very well...

Is there any interest from the core devs in something like this (a
system to log template rendering exceptions, even when they're masked
from the user)?

D.

-- 
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: RFC: Add a "needinfo" state to triaging

[Daniel Moisset]

On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant  wrote:
>
> This will also require a change to Trac, which I for one don't know how
> to do (I don't see the configuration pages I would need in the Trac
> admin interface).
>

If you have the admin module ui enabled and TRAC_ADMIN permissions,
you should see an admin link to the right displaying a dashboard with
a "resolutions" link at the left where you can add ticket resolutions.
If you don't... you should, it helps a lot :)

Otherwise you'll need to add a row to a table in the trac db.

Regards,

   D.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Doc. patch

[Daniel Moisset]

On Tue, Nov 16, 2010 at 5:18 PM, Klaas van Schelven
 wrote:
> Hi,
>
> I believe it is customary to politely ask for attention for bugs on
> this list.
>
> http://code.djangoproject.com/ticket/14704
>
> Contains a minor patch to the documentation that would have saved me
> some headaches this afternoon.

OK, I just reviewed. Now you need to wait for the blessing of a core dev.

D.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: RFC: Add a "needinfo" state to triaging

[Daniel Moisset]

On Tue, Nov 16, 2010 at 12:02 PM, Luke Plant  wrote:
>
> Do open a ticket, because we need documentation patches for this


Done, http://code.djangoproject.com/ticket/14702

Thanks for the feedback.

Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: RFC: Add a "needinfo" state to triaging

[Daniel Moisset]

On Sat, Nov 13, 2010 at 4:58 PM, SmileyChris  wrote:
>> What are the thoughts of the core team on this?
>
> Here's another more forward solution, requiring less follow-up
> triaging:
> Have a "needsmoreinfo" resolution. Tickets can be closed with that
> with a note to reopen it when more info is provided.
>

Sounds even better

D.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

RFC: Add a "needinfo" state to triaging

[Daniel Moisset]

Hi,
   while working on the sprint today doing triaging we noticed that a
lot of tickets were in the "Unreviewed" state because actually there's
not enough information to move it to any other state (they can not be
neither accepted/DDNd nor closed). In most cases we sent a reply back
to the submitter asking for more details about their problem, but the
ticket remains in the "Unreviewed" state, still taking the time of
other triagers looking for tickets to review.

Many projects have a "need information" state to report this
situation. I think adding this to the ticket state diagram [1] would
be helpful for triagers, and to developers reviewing the ticket list
and wanting to know how many tickets actually need to be looked at
before a release.

What are the thoughts of the core team on this?

Best regards,
D.

[1] http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.