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 codeb
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
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 g
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
ango 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,
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
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 -- t
;> https://docs.djangoproject.com/en/dev/releases/1.11/
>>
>> That's what Tim was talking about. You can target inclusion in django
>> 2 and forget about the quite uglier #type comment.
>>
>> 2016-08-17 16:13 GMT+02:00 Daniel Moisset :
>> > Thanks for the
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
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 curr
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 <
aymeri
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,
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
n 9, 2014 at 4:00 PM, Daniel Moisset
> 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:
>
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 t
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
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 lin
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 me
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, fir
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 vas
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 tracke
On Tue, Jan 24, 2012 at 2:22 AM, Anssi Kääriäinen
wrote:
> On Jan 24, 3:07 am, Daniel Moisset 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
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 PostgreSQ
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 i
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
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'".
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
> funct
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 deb
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/dj
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 stat
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 dow
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
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 logarithmi
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 d
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.
>
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 firs
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
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
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/43703
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.
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 r
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:
>
> """
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
On Sat, Nov 13, 2010 at 5:09 PM, Daniel Moisset wrote:
> 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 &
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 shoul
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 aftern
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 deve
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 pr
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 submitt
49 matches
Mail list logo
