Re: PEP 484 type hinting in Django

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 >

Re: PEP 484 type hinting in Django

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

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

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

Re: Javascript Templating Package

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

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 a

Re: PEP 484 type hinting in Django

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

Re: PEP 484 type hinting in Django

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

Re: PEP 484 type hinting in Django

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

Re: PEP 484 type hinting in Django

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

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

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 <

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

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,

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

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

Re: Support for function application in ORDER BY

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

Re: Support for function application in ORDER BY

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

Re: A.objects.getdefault

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

Re: Test runner with search

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

Re: django admin missing meta tag for charcter encoding in the head

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,

Re: Revisiting multiline tags

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

Re: Revisiting multiline tags

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

Re: Getting a traceback out of connection.queries

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

Re: More about test speedup

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

More about test speedup

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

Re: confusing things in Trac UI (was: Design decision for #1625...)

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

Re: Django test documentation example not respecting xUnit convention

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

Re: Django test documentation example not respecting xUnit convention

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

Re: RFC: "universal" view decorators

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

Re: Forced password reset in django-admin

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

Re: Django Design Czar

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

Re: Form Rendering API Proposal

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

Re: Form Rendering API Proposal

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

Re: Proposal: remove "Change" links on admin index page

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

Re: math tag

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:

Re: math tag

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

Re: RFC: new backports policy

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

Re: Ticket reports page redesign

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

Re: Suggestion: a new "nature" field in Trac

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

Re: Suggestion: a new "nature" field in Trac

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

Re: django/trunk/django/core/files/base.py -- File, why not a subclass of file ?

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 >

Re: RFC: Add a "needinfo" state to triaging

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

Re: One Django instance, hundreds of websites

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 >

Re: i18n bug in inlines (failing silently)

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

Re: i18n bug in inlines (failing silently)

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

Re: RFC: Add a "needinfo" state to triaging

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

Re: Doc. patch

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

Re: RFC: Add a "needinfo" state to triaging

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

Re: RFC: Add a "needinfo" state to triaging

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

RFC: Add a "needinfo" state to triaging

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