Hi,
This discussion does not seems to attract much attention but I still
feel this is a nice improvement to have.
/Cordialement/Regards,
Christophe Henry/
—
Christophe Henry
https://christophe-henry.dev/
Dev. Python/JS/Android & devops
Timon-Ethics / Coopaname <http://www.coopana
ity of the user input, even though the wrapping is
discarded immediatly after and only the raw value is transmitted. I
don't really see why the command performs a check in this situation but
not always.
--
/Cordialement/Regards,
Christophe Henry/
—
Christophe Henry
https://christophe-
ot;hard break", since unlike
> invocation of `normalize` and `localize`, subtraction operations will
> succeed if you swap out the attached tzinfo for a zoneinfo tzinfo.
>
> If we go with any variation of using shim-around-zoneinfo like
> pytz-deprecation-shim, I'd say tho
I think that the simplest approach—the one that would result in the least
amount of total work for both Django and its users—would be to adopt Nick's
suggestion and just switch to zoneinfo in 4.0. The problem is that it's
very hard to square that with Django's stability policy: "We’ll only break
> The point about the arithmetic semantics is a good one. I'm curious to
> know how often this is actually a problem.
>
That’s an interesting question. I think that doing localized datetime
arithmetic in Django is idiomatic, if not necessarily common. Let’s say we
have a calendar application t
Thanks to Paul for this proposal, and for working to put proper timezone
usage into Python itself. PEP 495 and 615 definitely make Python better,
and it seems inevitable that everyone will sooner or later switch over. I'm
all for getting this process going in Django.
I have doubts over whether
Regarding venv and bash, I filed a ticket [1] three years ago to have the
bash script included with the Windows venv installation, and it looks like
that change is in from 3.5 on. So in any case we shouldn't need to suggest
virtualenv any more.
Although I personally use bash, I definitely agree
If anyone's put off by the hectoring tone of the imperative mood, it might
be better to think of it as the indicative mood. That is:
(This will) "add password validation to prevent the usage of...".
rather than
(You must) "add password validation to prevent the usage of..."!
In English they're
Hello,
With all the talk of DEPs flying around I thought I'd finally take a look
at one in detail.
I wanted to make a suggestion about it and realized that there wasn't
really a good place to do so. The issue was too minor for a mailing list
discussion, and there was no open pull request to co
This issue was the subject of https://code.djangoproject.com/ticket/24082.
There, the accepted (but not implemented) solution is the same as suggested
here: allowing the user to opt out of the creation of the additional index
with `db_index=False`.
On Wednesday, April 15, 2015 at 2:11:25 PM UTC
>
> What kind of support do you except for third-party template tags? Suppose,
> that
> `cycle` tag is not builtin. Would it be acceptable to write sth like that:
>
> dtl cycle '1' '2' as rows
>
> It could be quite easily implemented as a Jinja2 extensions. Of course, I
> guess
> that you'd
Hi Christopher,
> ... checks the template extension and dispatch to
> corresponding function from `django.dtl` or `jinja2`.
>
The mechanism for distinguishing the two kinds of template needs to be more
flexible. For example, let's say I want to override a third-party template
with my own Ji
Russell makes the very good point that Jinja2 isn't just a faster version
of the Django template engine - it's philosophically at odds with the
original design and intent of the Django template engine.
Personally, I prefer Jinja2's approach and would love to see it become the
standard. (The ben
+1 for "is_installed"
I don't find the grammar objectionable here, just think of it as "is_(each
one of these apps)_installed"
On Sunday, January 5, 2014 3:50:45 PM UTC-6, Aymeric Augustin wrote:
>
> On 5 janv. 2014, at 22:38, Raffaele Salmaso
> >
> wrote:
>
> > Should it takes a list of app
I recently upgraded one of my projects to 1.6 and was surprised to find
that some of my tests were failing. I filed a ticket [1], and the
subsequent discussion with Aymeric makes me think that there is a tricky
issue here, worth discussing.
The basic problem is that when using TestCase you can
To summarize the possible approaches here:
1) Combine multiple with statements into one wherever possible. This seems
to be the approach of the commit in question.
2) Group with statements based on whether they logically belong together,
regardless of line length. This will involve backslashes,
>
>
> We probably cannot move checks of `primary_key` and `unique` living in
> `FileField.__init__`. We test if one of these two parameters was passed; we
> don't check their values. Consider that an user passes unique=False. This
> is
> the default value, but nevertheless, this should result in
; Marc
> On 1 Sep 2013 21:31, "Kevin Christopher Henry"
> >
> wrote:
>
>> Sorry to be late to this thread, I just came across it.
>>
>> There's another place where the order of INSTALLED_APPS matters:
>> management commands. Management commands a
Sorry to be late to this thread, I just came across it.
There's another place where the order of INSTALLED_APPS matters: management
commands. Management commands associated with apps that come later in
INSTALLED_APPS will replace those with the same name that are listed
earlier. I can't find th
Hey django developers! I am new here but I made you a design :)
http://cl.ly/3M0V3Y350B3r1n2g1209
On Saturday, April 28, 2012 3:22:59 AM UTC-4, Dana Woodman wrote:
>
> So now that Django is being moved to Git/Github (which is awesome!), maybe
> it would be a good time to think about a revamped h
> > Thanks, the accompanying discussion is very interesting and on point.
> > But as someone there points out, why stop at widgets?
>
> Because customizing widgets is a common request, unlike other attributes.
But customizing fields is quite common, no? I agree that it's rare
that you will want t
> Please file a ticket for the documentation fix it would be greatly
> appreciated. :-)
Will do.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
In terms of backward compatibility, perhaps there could be a new
keyword argument to Field, something like with_model_defaults, that
the user would use to indicate a desire to get the attributes from the
Model. How would this work? Maybe something like this (this is just a
sketch): Field.__init__(
> Well, surprise is in the eye of the participant. As noted above, it
> would be surprising to a lot of us if it did pick up the attributes
> because it removes control from the user. The current behaviour isn't
> illogical.
Oh, I wasn't suggesting that the user shouldn't be able to override
thos
Take a simple Model and ModelForm like this:
class Author(models.Model):
name = models.CharField(max_length=80, blank=True, default="Joe",
help_text="A name")
class AuthorForm(forms.ModelForm):
class Meta:
model = Author
The resulting form will reflect the desired help text, de
ould be {% from path.to.lib
load function_1, function_2, function_3 %}, so keeping the loose
relationship between "import" and "load".
Wouldn't it be less intrusive on the template api that way?
- Henry.
On Feb 6, 12:37 am, limodou <[EMAIL PROTECTED]> wrote
You're preaching to the converted :)
On Feb 5, 11:19 pm, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> On 2/5/07, Henry <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi.
>
> > On Feb 4, 11:26 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]
a local editor
with SFTP connection to the development server is slightly less
convenient than need be since I must also have a shell open for
navigating the code.
Anyway, just my $0.02.
- henry
--~--~-~--~~~---~--~~
You received this message because you are subsc
confirm that?
regards,
Henry.
--~--~-~--~~~---~--~~
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 g
29 matches
Mail list logo
