As the won't fixer person 11 years ago, I'm also more in favour of the
change now, even if it changes a bit the meaning of POT-Creation-Date from
"last time the pot file was updated" to "last time a change was detected in
the pot file".
--
You received this message because you are subscribed
, but if anyone has
something to share about those settings, it would be welcome.
Claude
Le 13.08.21 à 22:53, Claude Paroz a écrit :
So I activated mailing list mode, and chose i18n/geodjango in the watch
list. I'm still receiving all forum messages by email, which is
evidently not an option. If I have
just first posts in a
> thread or … )
>
> C.
>
> On 13 Aug 2021, at 18:24, Claude Paroz wrote:
>
> A question received privately: imagine someone wants to follow the
> Internationalization topic by email, is it possible and how? There is a
> Mailing list mod
A question received privately: imagine someone wants to follow the
Internationalization topic by email, is it possible and how? There is a
Mailing list mode in the forum prefs, but then I guess that this will send
messages from all forum topics.
--
You received this message because you are
>
> I don't think I've ever set USE_L10N to True, and I've been using
> Django in production since 0.96.
>
What would be most interesting to know is whether setting USE_L10N to True
would cause issues in your projects.
Claude
--
You received this message because you are subscribed to the
> Maybe we could start by moving django-i18n and geodjango lists?
>
>
> So, rough steps:
>
> 0: Update docs to point to Forum rather than Google Groups.
> 1. Post on django-i18n and geodjango lists that the action is now on the
> Forum. https://forum.djangoproject.com
> 2. We can create new
Le vendredi 30 juillet 2021 à 10:14:51 UTC+2, carlton...@gmail.com a écrit :
> Upvoted, but I'm not holding out hope. 廊
>
> There was discussion a while back about moving the discussion here to the
> Forum.
> Perhaps it's time to think again about doing that?
> (Andrew and Tom were discussing
Thanks a lot Jason for the link to the support thread. Let those who rely
on the RSS group feed go and upvote the thread!
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group
Hi,
It looks like from several days now, access to Google groups by RSS feeds
is producing an error.
E.g.
https://groups.google.com/forum/feed/django-developers/msgs/rss.xml?num=50
Does anyone know if this means that Google stopped supporting reading
groups by RSS?
Claude
--
You received
- not localizing those integers, unless use_l10n is forced (True)
Does this look like a plan (even without touching USE_L10N)?
On 6/11/21 6:50 PM, Claude Paroz wrote:
> > Is there a possible deprecation path?
> Maybe add a system check that warns if the setting is still present?
Sure, the
Hi,
I eventually took some time to try implementing an idea I had since some
time: remove the USE_L10N setting.
The draft PR is here:
https://github.com/django/django/pull/14519
My motivations are:
- one less setting
- simplication of the code and logic regarding USE_18N/USE_L10N/USE_TZ
Hi Jordi,
Our GDAL Raster expert is Daniel Wiesmann (https://github.com/yellowcap),
you may try to ping him somehow so that he can give his lights on the
subject here.
And how should I properly enable the `gis_tests` to confirm everything
> works as expected?
>
If you use settings configured
As you can see in the ticket you mention (see last comment), it is already
possible to do so by adding a custom version of the makemessages command in
your project.
Hope this helps,
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers
Le mercredi 20 janvier 2021 à 16:19:09 UTC+1, timog...@gmail.com a écrit :
> ... It seems like this policy makes it more likely that the last Django
> version to support a Python would be a non-LTS rather than an LTS. Maybe
> that's fine.
In my opinion, that's fine. As Python supported
When I see that Python 3.7 will be supported the whole time of the 4.0
support period, it's enough for me. For the rest, let the people choose and
see by themselves through the support graphs what their interest is. I
think we should stop patronizing developers.
Claude
--
You received this
Like others in this thread, I think that dropping Python 3.7 for Django 4.0
is too aggressive, even if it complies with the written policy.
So I would plead for an exception and ask to keep Python 3.7 for Django 4.0
at least. Is there support for this idea here?
Claude
--
You received this
Le vendredi 30 octobre 2020 à 23:14:07 UTC+1, hcharpent...@gmail.com a
écrit :
> I saw a spelling error in a menu, and I thought I could contact some
> french translators team or something? (It would be much easier to me to
> explain it in French).
>
Adam's suggestion is good, but you can
Maybe I spoke too quickly.
Now I'm asked for login again :-(
Claude
Le mardi 18 août 2020 13:27:35 UTC+2, Claude Paroz a écrit :
>
> Looks like it works again like before, now.
> It may have been a temporary "accident"…
>
> Claude
>
>
--
You received this mes
Looks like it works again like before, now.
It may have been a temporary "accident"…
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from
Hello,
Am I the only one or did Google closed anonymous access to Google groups?
Could it be a setting in the group config?
In my opinion, it is not acceptable for the project if accessing the
Django group posts require authentication.
If someone has more information about that change, that
By the way, while reviewing the SecurityMiddleware, I would suggest that
the redirection part be moved to a different middleware.
http to https redirection should preferably be done at the Web server
level, and for those doing that properly, they still pay for the unneeded
(albeit small)
Le mardi 28 juillet 2020 08:31:51 UTC+2, Aymeric Augustin a écrit :
>
> - We should focus this on usernames and ignore IP addresses, as most sites
> are behind a reverse proxy of some kind and no one handles X-Forwarded-For
> headers right (even Heroku doesn't care — when I reported they were
>
ome minimal
mitigation for Django 3.2, then we can always add a more elaborate tooling
set later.
Claude
> On Mon, 27 Jul 2020 at 12:13, Claude Paroz > wrote:
>
>> Hi all,
>>
>> I thought a bit about login rate limiting again in recent times.
>> https://code.djan
Hi all,
I thought a bit about login rate limiting again in recent times.
https://code.djangoproject.com/ticket/21289
We know that there are some packages (django-ratelimit, django-defender,
etc.) that can do the job, but the main issue here is to provide a
*default* behavior for any fresh new
Note that the term "blacklist" only appears twice in the Django tree and
only in comments/docs, as shown by David's patch. The first one can be
omitted while the second one can be replaced by "exclude". That is trivial
to do and shouldn't even require a discussion.
About replacing "whitelist"
Le samedi 23 mai 2020 16:41:04 UTC+2, Toby Such a écrit :
>
> Maybe the logic for calculating the time before formatting could be taken
> out of the function? That way it would be far easier to implement your own
> custom versions of the function without copying and pasting, and makes the
>
Hi Mariusz,
I think we should also address:
https://code.djangoproject.com/ticket/30678 - GDAL 3 support
as release blocker, because more and more installations will have GDAL 3 by
default and the backwards compatibility issues are serious. I'll try to
prepare a patch ASAP. As this is only
WT's
> > are used? Personally I can't remember from the projects I've worked on
> > which format has been used.
> >
> > Thanks,
> >
> > Adam
> >
> > On Wed, 22 Apr 2020 at 09:57, Claude Paroz > wrote:
> > > For your informatio
Le mercredi 22 avril 2020 17:22:02 UTC+2, Carlton Gibson a écrit :
>
> ...
> *Not sure* how much of this we need to pull into Django itself?
> compressor, say, does the whole combine and compress thing well. If we pull
> that in are we going to do the same for image optimization? Or pull in
>
Le mercredi 22 avril 2020 15:06:12 UTC+2, Adam Johnson a écrit :
>
> I'd like to propose using this new full coverage of operation naming to
> remove the "auto_MMDD" behaviour, and instead always combine
> operations' "suggested migration names" up until a limit of say 60
> characters. I
For your information, I now added docs to the tentative patch:
https://github.com/django/django/pull/12728
Claude
Le 15.04.20 à 21:26, Claude Paroz a écrit :
> Thanks Abhijeet for the pointer, I know there are some rather complete
> JWT libs around, but my proposal is not about a co
check out django-restframework-simplejwt. It requires the
> Django Rest Framework. But, then again, if you are making an API, you'd
> already be using it.
>
> Regards,
> Abhijeet
>
> On Thu, 16 Apr, 2020, 00:39 Claude Paroz, <mailto:cla...@2xlibre.net>> wrote:
&g
Hi all,
With the recent addition of the algorithm parameter to the signing.Signer
class, it's now rather straightforward for Django to generate HS256
(non-encrypted) JSON Web Tokens.
With a growing popularity of JS-client/Django server communications (DRF
and al.), I think there might be some
Le dimanche 5 avril 2020 00:06:15 UTC+2, charettes a écrit :
> This subquery operation would address a few other cases that I know
> Claude[3] is interested in seeing addressed as well. Maybe you'd be able to
> pair on this problem given his interest in the problem and your past
> interactions
Hey! Thanks for suggesting me as a merger!
However, I'd like to clarify that I'm not requesting this commit bit. If
the project thinks it's good that I get it, I'll accept that and do my best
to use it as the new DEP suggests. If not, I can certainly continue to
contribute as I've done in the
Le mercredi 4 décembre 2019 03:41:51 UTC+1, Matemática A3K a écrit :
>
> (...)
>
> But, then I realized that there is major caveat on this approach, and that
> is that updates on the plural equation won't reach users' catalogs, because
> their catalogs will be kept separately one the plural form
Le 20.11.19 à 22:46, Curtis Maloney a écrit :
> My reading of this discussion boils down to "if we get rid of is_ajax (a
> buy-in convention nobody can rely on), how do people decide if it's an
> AJAX call or not?". To my mind, the "content negotiation" advocates have
> it right: HTTP has a
I'm afraid that implementing a whole content negociation framework is a bit
ambitious, unless someone has much time to devote to that.
We could start smaller, similar to django-accept-header. I quickly sketched
what it could look like in:
Hi Uri,
I think you did not understand well the problem. Let me try to explain it
in more details.
Nothing was changed with "ngettext" or "ngettext_lazy" in Django. The
plural equation for Hebrew was changed on the Transifex platform and those
changes reach Django each time we synchronize
Hi,
Could you please tell us a bit more about what the specs say about numbers
in the top-level domain?
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop
Hi,
There is a specific group dedicated to translation issues:
django-i...@googlegroups.com
Please write to that group.
Claude
Le mardi 15 octobre 2019 13:40:38 UTC+2, Soyuzbek orozbek uulu a écrit :
>
> Hi all,
> I want to translate Django to Kyrghyz language using transifex. I already
>
Sorry but I would *strongly* oppose any idea of closing a ticket because
noone commented in the last x years. Most of those tickets are still valid
issues, but they remain open because noone dedicated the appropriate time
to solve them, sometimes because the problem is a corner case, sometimes
Le samedi 20 avril 2019 09:11:24 UTC+2, Carlton Gibson a écrit :
>
>
>
> On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote:
>>
>>
>> I don't think that our code style is any barrier for newcomers. ...we've
>> never blocked any patch due to stylistic nitpicks. I also don't believe
I must admit I'm rather pleased by Luke's proposal. Let's keep our current
isort/flake8 checks and relax other policies (considering the committer can
always minor edit patches, as Tim did in the past).
I'm always a bit suspicious of tools that decide the formatting for me.
Claude
--
You
migration that adds a char or text field with a default
> value. The migration it self will go through, but sqlmigrate will fail.
>
> I'll look into testcasing that.
>
> On Mon, Apr 15, 2019 at 3:25 PM Claude Paroz > wrote:
>
>> Please create a new ticket (where you can re
Please create a new ticket (where you can reference the original one).
If you can provide a failing test case, it would be great.
Claude
Le lundi 15 avril 2019 13:40:53 UTC+2, Melvyn Sopacua | 3YOURMIND a écrit :
> Hi,
>
> I've added a comment on the commit:
>
Thanks Joe for this proposal. Unfortunately, I fear it does not play well
with our current workflow, where we download files produced by Transifex.
Could you give us an example where an error revealed by this linter could
improve the quality of the resulting translations?
Claude
--
You
ad. Tell me
if you need help, even if you seems a lot more knowledgeable than me on the
subject.
Thanks.
Claude
> On Thu, 21 Feb 2019, 19:56 Claude Paroz, >
> wrote:
>
>> Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>>>
>>> Claude,
>>&g
I have a POC patch here: https://github.com/django/django/pull/11014
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>
> Claude,
>
> I've tested a Django based application on 2.2b1 without watchman on
> Windows, it does tell you about watchman, but it doesn't fail to run.
> Apparently, it falls back to the old way of reloading. Is this not the
>
Hi,
The new watchman-based autoreloader in Django 2.2 is a nice improvement.
However, the main issue in my opinion is that there are no Debian/Ubuntu
official packaging of watchman to my knowledge.
I've been able to compile it without difficulty, but I'm especially
concerned about newcomers
hink it might make a good GSoC project?
>
> C.
>
> On Monday, 23 July 2018 17:36:05 UTC+2, Claude Paroz wrote:
>>
>> Hi,
>>
>> I just created a new feature request [1] to be able to define static
>> files per application, including a POC patch [2].
>>
Le mercredi 23 janvier 2019 08:31:17 UTC+1, James Bennett a écrit :
>
> I worry about the precedent we'd set if we made an exception for Debian,
> because the next question would be "OK, can we have an exception for Red
> Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of
>
I understand my obsession for stable software puts me in a small-minority
group and I would not like to be an obstacle for all other Django users and
developers.
Let's stick to the current policy. I'll try to remember that and prevent
commenting on the next " Drop python support..." ticket :-)
Le vendredi 11 janvier 2019 07:46:04 UTC+1, Uri Even-Chen a écrit :
>
> https://code.djangoproject.com/ticket/10852
>
> I also don't like the "fuzzy" keyword and I spent hours in deleting them
> from our django.po files after running makemessages.
>
Hi Uri,
Create your own makemessages command
Le jeudi 13 décembre 2018 09:17:49 UTC+1, Carlton Gibson a écrit :
>
> ...
> I'd like to push on these avenues (and similar) before we take on the
> massive project of changing systems.
> (Ultimately I think we'd change system and find ourselves in exactly the
> same boat.)
>
Thanks Carlton,
Le jeudi 1 novembre 2018 15:37:21 UTC+1, charettes a écrit :
>
> FWIW it looks like gettext support issues were addressed a while ago[0]
>
For the .format() syntax, yes. For f-strings, I'm not sure they can be
internationalized at all. PEP 498 has not a word about it.
Claude
--
You received
We are not talking about general data encodings here, FILE_CHARSET is used
to read Django text files from disk (template files, static files (css, js)
or translation catalogs). So the question is mainly about encoding usage in
text editors.
Claude
--
You received this message because you are
Hi Osama,
You can simply do that by including a gettext_noop('your custom string')
line anywhere in your code (or in a specific file you create for that
purpose).
Regards,
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions
Le dimanche 26 août 2018 13:36:41 UTC+2, James Bennett a écrit :
>
> The only use case for pickle that I'm aware of is "I need a way to add a
> security hole to my site". So let's just get rid of it.
>
Out of memory, I think they were cases when some types were not
JSON-serializable.
Claude
Le vendredi 24 août 2018 11:35:43 UTC+2, Jamesie Pic a écrit :
>
> Thank for your feedback.
>
> It's the eternal misunderstanding of django's pattern, confusion between
> table, and model, model is de factores what couples table and form, I've
> posted articles about it already. I call this the
Hi Deniz,
Please do not cross-post your issues over several mailing lists, we are
already talking about your issue in gnome-i18n. Thanks.
https://groups.google.com/forum/#!topic/django-i18n/xSlv7gD7F4Y
Claude
Le lundi 13 août 2018 01:59:14 UTC+2, Deniz Bazan a écrit :
>
> Dear Django
Le lundi 23 juillet 2018 21:17:24 UTC+2, Claude Paroz a écrit :
> I'll see if I can add subresource integrity support to demonstrate a
> potential added value.
>
Just for feasibility's sake, here's a quick (and probably dirty) way to
implement subresource integrity based on the
Le lundi 23 juillet 2018 20:32:55 UTC+2, Florian Apolloner a écrit :
>
> Hi Claude,
>
> On Monday, July 23, 2018 at 8:14:23 PM UTC+2, Claude Paroz wrote:
>>
>> Sure, the idea is to put a base structure in place to support such
>> functionalities at a later stage
Asset() class.
> * Any thoughts on asset pipelines?
>
Sure, the idea is to put a base structure in place to support such
functionalities at a later stage (in core or as 3rd party like
django-compressor).
Thanks for your input!
On Monday, July 23, 2018 at 5:36:05 PM UTC+2, Claude Paroz wr
Hi,
I just created a new feature request [1] to be able to define static
files per application, including a POC patch [2].
[1] https://code.djangoproject.com/ticket/29586
[2] https://github.com/django/django/pull/10218
Feel free to discuss it here for general discussion on the feature
Hi all,
https://code.djangoproject.com/ticket/28540 explains that unless
FILE_UPLOAD_PERMISSION is set (not set by default), uploaded file
permissions are often a mix of 0o600 and 0o644 (or another value
depending of the default umask), based on the upload method (memory or
temporary file)
I think I'd rather do some refactoring so that creating its own filter with
custom strings is easier.
I played a bit with the idea and obtained that:
https://github.com/claudep/django/commit/b776f120f180
Claude
--
You received this message because you are subscribed to the Google Groups
Bonjour Alphonse,
Cette liste de discussion n'utilise que l'anglais et est dédiée au
développement de Django lui-même.
La liste francophone se trouve ici :
https://lists.afpy.org/mailman/listinfo/django
Cordialement.
Claude
Le lundi 29 janvier 2018 14:52:27 UTC+1, Alphonse Aka a écrit :
>
>
This looks like a reasonable improvement. Please open a ticket, and
possibly a pull request. Thanks!
Claude
Le vendredi 22 décembre 2017 03:29:56 UTC+1, Shaheed Haque a écrit :
>
> Hi,
>
> In Django 2.0, the help_text for the password field of
> django.contrib.auth.forms.UserChangeForm looks
Hi Adrian,
I don't see anything related to Django development in your post. Maybe this
was more for the django-users mailing list?
Claude
Le jeudi 30 novembre 2017 02:39:31 UTC+1, Adrian Mansilla a écrit :
>
> I am using the function 'validate_password (password, new_user)' and I
> have my
Hi,
I would like to push a bit for that functionality in Django 2.1. Adam, any
progress?
In https://github.com/django/django/pull/7778, you talked about a better
plan. Show us your plan, please :-)
Claude
--
You received this message because you are subscribed to the Google Groups
"Django
>
>
> Perhaps we can find a compromise to ship this feature in the alpha with
> minimal docs and complete the docs later?
>
>
I'm in favour.
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To
Le mardi 8 août 2017 01:45:55 UTC+2, Tim Graham a écrit :
> Has anyone changed their thinking in the last few months? If not, I guess
> we'll keep Python 3.4 support for Django 2.0 and drop it for 2.1.
>
I am not strongly opposed to dropping 3.4 support, but I still think we
should keep it for
Le samedi 10 juin 2017 14:25:49 UTC+2, Curtis Maloney a écrit :
> On 10/06/17 22:21, Claude Paroz wrote:
> > Another idea would be to offer variants of models.Model which models
> > could inherit from, like models.BigIntModel or models.UUIDModel.
>
> Ah, well.
Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :
>
> Right, hence my point of having a global setting to say "the default
> auto-field is ..."
>
> This would:
> a) ...
>
I see, but this conforms to the pattern "use the same id field type for all
models of my project". I'm not
I think we should first discuss if it makes sense to set a BigAutoField by
default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I know
As for me, I still think the current validator is valid for 99% of use
cases. And 99% of the time, an email address with dot-less domain is a user
input error.
So I would prefer fixing #25594 (validator propagation from db field to
form field), adding a "looser" validator in validators.py and
Le mardi 16 mai 2017 23:52:31 UTC+2, Tom Forbes a écrit :
>
> Hello,
> Is anyone responsible for managing the transifex organisation? A colleague
> of mine applied to join the Django organisation to contribute greek
> translations for the admin, but his application is currently pending and
>
I also think that this should be handled at serialization level (form
fields and (de)serialization framework).
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and
This might also be https://code.djangoproject.com/ticket/27086
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Le 14. 02. 17 à 16:31, Patryk Zawadzki a écrit :
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least
clean solutions as they mean none of the translated fields can be marked
as required. For other solutions
Le 14. 02. 17 à 16:16, j...@yourlabs.org a écrit :
(...)
However, there's a third alternative to changing Meta that may be worth
suggesting: adding a new Field attribute ie. translatable=True, which
could be default for CharField and TextField perhaps. It might even turn
to be an advantage that
Hi Raphael,
Le 14. 02. 17 à 14:53, Raphael Michel a écrit :
Hi Claude,
I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).
It is not only that we are not
Dear developers,
I'd like to suggest an addition to the Django Model definitions to ease the
implementation of translatable model fields. There are currently several
third-party applications for model translation, and even if I think we are
not ready yet to bless one of them to be included in
Le lundi 23 janvier 2017 20:50:03 UTC+1, Tim Graham a écrit :
>
> (...) Do you think subclassing and extending the built-in backend is a
> common enough use case that it's worth formally deprecating the
> postgresql_psycopg2 module rather than simply removing it in Django 2.0?
>
I am generally
Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :
>
> I propose to tentatively target Python 3.5+ for Django 2.0 but not to
> remove the current workarounds for Python 3.4 at this time. Shortly before
> the alpha for Django 2.0, an interested person can look into how much work
> is
Any idea why my message in this thread was deleted?
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I would like to voice my support for Florian's arguments. It's not only
RedHat, Debian is also concerned. The current Jessie stable version which
will be supported probably until mid-2018 is Python 3.4, and the upcoming
stable version will most probably be Python 3.5. So a strong -1 for
Le lundi 21 novembre 2016 23:56:56 UTC+1, Tim Graham a écrit :
>
> When reviewing the patch for the auth class-based view additions, I made
> the mistake of assuming that the existing tests would catch this type of
> obviously incorrect issue. Perhaps with the function-based views, the code
>
I wouldn't spend too much energy about Python 2.7 stuff. Let the
workarounds in place, and just wait for Python 2 to die. I don't see the
point in forcing people of stable Debian-based distributions to install a
custom Python for 1.11.
--
You received this message because you are subscribed
AFAIK Django receives the language tags from the browsers as IETF language
tags, and then convert them in locale names suitable for gettext.
https://en.wikipedia.org/wiki/IETF_language_tag
https://www.gnu.org/software/gettext/manual/gettext.html#Locale-Names
Hope this helps,
Claude
Le vendredi
Le vendredi 9 septembre 2016 07:31:42 UTC+2, Ivan Sagalaev a écrit :
> I think the best end result would be one where LOGGING simply defines the
>> full config and it is always applied (by Django) exactly once, and the
>> defaults we want are set as the global default for LOGGING, and just
>>
Le vendredi 22 juillet 2016 23:30:58 UTC+2, Jon Dufresne a écrit :
>
> Hi,
>
> I would like to propose that Django renders the "checked" attribute of
> checkbox and radio inputs using the HTML5 boolean style attributes.
>
(...)
I'm definitely +1 with this change.
Hopefully, 1.11 should come with
Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit :
>
> There are a few small issues to finish up, but if all goes well, the beta
> release will happen sometime tomorrow (at least 24 hours from now).
>
I'm a bit worried about https://code.djangoproject.com/ticket/26719 which
could
Just a note that I open a discussion on making GDAL a hard requirement for
contrib.gis, on the GeoDjango mailing list:
https://groups.google.com/forum/#!topic/geodjango/gD0-1SMOBqU
Feel free to participate in that thread if you have something to say.
Claude
--
You received this message
Hi,
I have the general feeling that too few people are testing the new Django
major releases before the .0 release. The result being that many
regressions are often reported after the release, while those could have
been detected at alpha/beta/rc stages.
I found myself in the situation where
Le vendredi 20 mai 2016 02:44:41 UTC+2, Josh Smeaton a écrit :
>
> I understand the reasoning for "use the cache", but not every site has
> caching enabled, especially lots of smaller sites.
>
That's not true. When not specified, the cache backend default to the local
memory cache:
The design and the patch look good to me. Thanks!
Claude
Le jeudi 19 mai 2016 05:01:37 UTC+2, Jon Dufresne a écrit :
>
> Hi,
>
> Occasionally I'll need to define a CharField on a model that is unique but
> also allow blank values. At the database level, this is easily handled by
> storing NULL
Hello Jani,
I'm not familiar with the Oracle backend, but you probably have to play
with the
OracleSpatialAdapter / WKTAdapter stuff to achieve what you need. Good luck!
Claude
Le mardi 17 mai 2016 14:53:28 UTC+2, Jani Tiainen a écrit :
>
> I'm toying around Oracle and latest cx_Oracle
1 - 100 of 158 matches
Mail list logo
