esday, December 21, 2022 at 12:06:44 AM UTC+9 Raphael G wrote:
> OK after looking at this some more and trying to write up a review aid,
> I'm giving up on this branch and trying to integrate DATABASE_URL support
> into Django proper.
>
> A couple reasons:
>
> - I misre
rl into django.contrib and relying on
the years of usage by everyone as "proof" that the thing works. And I think
the branch I tried reviving is "correct", I just don't have the background
in most of these backends to know if it's right.
On Tuesday, November
ut of course the specifics are important here, so I will finish up a
review aid and paste that in the PR (along with actually getting that
branch passing) discussion and crosslink it here.
On Tuesday, November 29, 2022 at 4:45:12 PM UTC+9 carlton...@gmail.com
wrote:
> Hey Raphael.
>
>
m open to any(?) way forward that leads to "I
will not need to install an extra package to handle this, nor am I
personally parsing the URL with urllib.parse", and am ready to do the
legwork.
Speaking to that, if we have consensus on the principle, what would be the
right step forward? A
Some base industry background. It's a pretty common convention to share
credentials in environment variables. For many PaaS, it's common to use
connection URLs to do so. So DATABASE_URL will have a URL like
postgres://my_user:mypassword@somedomain/database stuffed into a single
environment va
de to get this
and feeling a bit off about it, so let's try and get that use case handled
in a way that doesn't prevent further niceness in the future!
Raphael
On Monday, December 24, 2018 at 7:01:23 AM UTC+9 Raffaele Salmaso wrote:
> Hi all,
> I'm working on https://gith
nd it and because it might become very verbose adding context
managers everywhere.
Best
Raphael
--
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 e
avoid to deal with all
of these separately.
Best
Raphael
Am Sun, 10 Oct 2021 21:38:13 +0200
schrieb Aymeric Augustin :
> Hello Raphael,
>
> Oh - a use case for django-transaction-signals
> <https://github.com/aaugustin/django-transaction-signals> ;-) I'm
> bringin
cept if we were shipping entire database
backends) so it would need to be an acceptable change to Django to be a
viable option.
Thanks
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscr
your input, both of you. I have a couple ideas now that I'm
pretty tempted to try out, mainly around the "fast path and slow path"
strategies that should offer backwards compatibility.
Raphael
Markus Holtermann wrote on 2019/05/21 2:26:
Thanks Raphael for bringing this topic up
to pay
for some performance improvements?
I am still trying to wrap my head around some of this problem space, so any
insight will be very appreciated
Thanks,
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Dja
core, this could be done much more
nicely.
Still, it might be an interesting thing to look at when doing this, if
only for the test cases and the weird MySQL/MariaDB things. I'd love to
see this in core and are happy to help wherever I can with my expertise.
Best
Raphael
Am Tue, 2 Apr 2019 04:4
I saw this thread so wanted to share a bit of a gotcha we had with enums
internally for anyone trying to handle this stuff
Internally, we have a wrapper around CharField to work with enums (we go
further than just choices and actually have the values be enums), but
there's unfortunately still a
>
Yes, this is the main difference, as MySQL requires CAST(x AS JSON) calls
in many places while MariaDB does not support CAST(x AS JSON). I also noted
a number of oddities with regards to case-(in)sensitivity when comparing
values extracted from JSON, but I didn't research this d
elm/django-jsonfallback
Best
Raphael
P.S. Thanks to all organizers and attendees for an amazing conference <3
--
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 sto
Hi,
I'd be very careful about calling it bulk_save(), since calling
it something with save() very strongly suggests that it calls pre_save
or post_save signals.
Best
Raphael
Am Fri, 14 Sep 2018 07:56:38 -0700 (PDT)
schrieb Tim Graham :
>
>
> I wanted to ask about naming of
'd love to see it and maybe even collaborate on it!
> I have written a IMHO better plugin handler:
> https://gitlab.com/nerdocs/medux/MedUX/blob/develop/medux/extensionsystem/__init__.py
> …
> This way all plugins can just "implement" predefined Interfaces,
> supereasy.
NxRdzLTFik
Cheers
Raphael
[1] https://github.com/pretix/pretix
[2] https://packaging.python.org/specifications/entry-points/
[3]
https://github.com/pretix/pretix/blob/master/src/pretix/settings.py#L264
[4]
https://github.com/pretix/pretix/blob/master/src/pretix/base/signals.py#L21
[5]
https://github
sed in the talk ;)
Cheers
Raphael
[0]
https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/HBj-S8ypBgAJ
[1]
https://2017.djangocon.eu/schedule/data-internationalization-in-django/
[2]
https://groups.google.com/d/msg/django-developers/6a5Bwf5KMNA/4q7HNXysBgAJ
[3] https://speakerdeck.co
ion) RemoveFields, it
blocks a lot of possible optimizations. We could just do that (start
generating RemoveField with field info), though it would not allow for
older migrations to get optimized. I'd be good with doing either/both.
Raphael
On Fri, Feb 17, 2017 at 3:09 PM, Gaschignard, Ra
to m' because another operation will do it for them.
It's hard to generalize this across everything because there are, after
all, arbitrary migrations. But considering that RemoveField will only be
reduced with a "moral equivalent" to AddField, I think we can expand this
reasoning
ns that pass through this,
because this field could be referencing any model (theoretically).
But if we assert that RemoveField doesn't refer to any models referenced to
by its field, then our optimizer can take a couple more liberties.
Raphael
On Friday, February 17, 2017 at 2:15:47 AM UTC+
will "protect" the causal order, not "RemoveField".
Raphael
--
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
Markus: Now that I've written a command to optimize a single migration
file, I think that it's sufficient for the "squash, edit, optimize"
workflow that I was doing before. It's more about offering people to get
their squashing done well until our optimizer becomes omniscient.
Florian: Having
I ended up having some time today, so wrote up a management command for the
first suggestion!
I called it "optizemigration"
>>> ./manage.py optimizemigration appname 0001_squashed
# snipped django startup noise
Optimized from 9 operations to 4 operations
Optimized migration /Users/rtpg/pro
Model(B), AddField(A.foo)] -> [CreateModel(A),
AddField(A.foo), CreateModel(B)]) and got decent results, but I think
making the optimization code express these two concepts separately would
catch even more of the optimizations I saw that the optimizer didn't.
I hope some of this is usef
compatible with multiple of them because it would
still be very undefined how you get to the translated versions in the
different systems, how you store the data into the field, etc.
Cheers
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django develo
Le jeudi 08 décembre 2016, Raphaël Barrois a écrit :
> If I understand correctly the input, would the following proposal be an
> acceptable middle ground?
It would certainly be an improvement from my point of view, yes.
Cheers,
--
Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer
Discover
Le mercredi 07 décembre 2016, Aymeric Augustin a écrit :
> In my experience:
>
> - many Django-related packages use a django- prefix in the name of the package
> on PyPI
And the mismatch between package name and module name means that we have
many packages which are not co-installable because t
Hello,
in Debian we recently had a discussion about the package name we use for
Django applications/extensions, it's usually python-django-. But the
generic naming policy we have for all Python modules implies that this
package would provide a "django_foo" Python module and this is not always
the
Hello,
Am Fri, 21 Oct 2016 13:49:16 -0700 (PDT)
schrieb Mike Edmunds :
>1. Should the result of ugettext_lazy somehow inherit from
> unicode?
I believe this would break giant measures of code out there that use
"not isinstace(lazystr, unicode)" exectly to detect that it is a lazy
string and n
a big burden for people used to the old syntax AND newcomers
(because of the autoimport that is not helping).
Raphael
--
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
Could you just ignore that I've ever sent this mail? Apparently, I
wasn't able to finde translation.override in the docs.
Sorry for the noise.
Raphael
Am Tue, 20 Sep 2016 14:11:11 +0200
schrieb Raphael Michel :
> Hi,
>
> in my application, I regularly need to switch the acti
go
(b) the activate() method itself should be changed to optionally work as
a context manager
Cheers
Raphael
--
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 s
Hi,
Le lundi 27 juin 2016, Reinout van Rees a écrit :
> > (You must) "add password validation to prevent the usage of..."!
>
> "It might be better to think of it as...": it is exactly this extra
> thinkwork that everyone reading the messages has to do. We write it once and
> read it many times: w
Hi,
Le vendredi 24 juin 2016, Shai Berger a écrit :
> > Why would you want to discourage people? In the recent thread "Extending
> > JSONField serialization", you said yourself that the use-case for a
> > JSONField is clearly to store and retrieve data and not to make queries on
> > it with smart
Le vendredi 24 juin 2016, Aymeric Augustin a écrit :
> On 24 Jun 2016, at 09:01, Raphael Hertzog wrote:
> > Why would you want to discourage people?
> Well, this seemed to be the latest decision, but I don’t care much myself.
AFAIK only Marc Tamlyn insisted on such a requirement to
Hi,
Le jeudi 23 juin 2016, Aymeric Augustin a écrit :
> On 23 Jun 2016, at 15:40, Tim Graham wrote:
> > Marc said, "I'm happy for JSONField to be made a core field on the
> > condition that it's underlying support is more than a text blob on all
> > our main databases. It sounds like this will so
Hello,
in almost all projects I work on, I end up using a JSONField. Since
I value being able to run with any database, I'm not relying on
django.contrib.postgres.fields.JSONField. So I have been using
pypi's django-jsonfield maintained by Matthew Schinckel:
https://bitbucket.org/schinckel/django-
Le jeudi 07 avril 2016, Aymeric Augustin a écrit :
> This other ticket about a SQLite segfault may or may not be related:
> https://code.djangoproject.com/ticket/24080
Given how old it is, I was tempted to say it's entirely unrelated. But
maybe not. I discovered faulthandler thanks to this and the
[ CCing an upstream developer of SQlite too ]
Hello,
I did not want to open a ticket as I'm not sure if the problem
is in SQLite or in Django but the Django test suite fails really badly
with SQLite 3.12.0 that got recently released (and which is already
in Debian Unstable).
When using the defau
of add() is being returned. add() is documented as returning True or
False and I don't think it makes any sense to return True/False from a
method that is expected to return a cached value or a default value.
I think we need a better behaviour of get_or_set() if add() fails but
I'm unsure h
confirm that it is currently very
conveniently possible to deploy a Django application on a non-root URL
using SCRIPT_PATH without modifying the application. It is not really
important to me, but I think it would be worth keeping it in, if it is
not too much hassle.
Cheers
Raphael
--
You received this
Hello,
I'm another Debian developer co-maintaining Django in Debian.
Le lundi 30 novembre 2015, Florian Apolloner a écrit :
> I am not against including it, but depending on how packaging works in
> Debian it could be possible to call pycompile with a proper exclusion list
> instead. The PR its
from date fields
Anyways I wanted to share this experience so that anyone who has the
courage to right new docs/continue evolving things can know of at least one
team’s difficulties.
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django devel
ango 1.8 will be around for another 2.5 years, I think
dropping CI is not a good idea, considering that is comparatively easy
to compile specific python versions by oneself.
However, we should definitely document somewhere that there are
possbile unknown problems with 3.2.6 and the django admin.
mpletely without it.
Cheers,
Raphael
--
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+unsubsc
, _FILENAMES sounds as if I should pass either a path or at least
a full filename, but it is neither of both.)
Raphael
Am Tue, 28 Jul 2015 11:48:14 -0700 (PDT)
schrieb Tim Graham :
> Since adding new settings is sometimes controversial, I wanted to ask
> for thoughts about this ticket [1]
Am Sat, 25 Jul 2015 16:32:21 -0700 (PDT)
schrieb Tim Graham :
> I think it's been addressed in 1.9 to at least some extent. See
> https://github.com/django/django/commit/7f20041bca43ca33f0a9617793f2af7ab07c3fab
Oh, I didn't find that. Wonderful, sorry for the noise :)
Raphael
bonus feature.
Cheers,
Raphael
--
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-developer
ou should be able to do the migration in half an our
without any drawbacks.
Best regards,
Raphael
--
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
se (issue due dates that are required for
certain issue states) can be solved using clean() without major
drawbacks, for your use case (re-usable address fields), I'd go for
MultiValueFields[1] -- this logic does not really belong to the form.
Raphael
[1] https://docs.djangoproject.com/en/
ng in a similar fashion to the new TEMPLATES setting.
I understand why you chose this style and it might really be the best
way to do this one thing, but I fear it adds complexity because it
behaves differently than all other settings variables and thus makes it
harder to remember how Django's s
correct. The system package manager might (or
in most cases, will) distribute a _compiled_ version of 2.0.14 where you
do not need the -dev libraries to execute them, while pip will download
_sources_ and compile them for you and therefore needs the -dev
libraries.
Raphael
--
You received this mess
ell. However, if this indeed is the reason, then
a {% block … if … %} syntax would make it impossible to interpret
blocks at compile time, and I don't think Markus' proposal (or the {%
if %}{% block %} syntax, which I do like more than {% block if %}) is
worth that effort.
Raphael
--
You
my uneducated guesses of how the blocks work, this might
be very hard and not worthy to implement.)
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group
ira Mono webfont, so maybe some weird font cache
configuration issues. Does this web page work for you?
https://mozilla.github.io/Fira/
Best regards,
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itsel
7 +0100
schrieb Tino de Bruijn :
> Does anybody agree on that and should I create a pull request?
Absolutely, sounds good!
Cheers,
Raphael
[1] https://github.com/django/djangoproject.com/issues/216
[2] https://github.com/django/djangoproject.com/issues/198
--
You received this messa
r little
> gain? Too late?
No, I can tell this IS a big source of confusion not only for
beginners, so it is worth a change to me.
Cheers,
Raphael
signature.asc
Description: PGP signature
Hi Brian,
On Fri, 25 Jul 2014, Brian May wrote:
> I can't help but think this might be unrealistic (?). Changes required for
> new versions of Django often break compatibility with old versions, and
> 1.4.5 is really old now. Just because many packages don't have versioned
> dependencies on Django
Hi Andrew,
thanks for your quick answer.
On Thu, 24 Jul 2014, Andrew Godwin wrote:
> There is no way around this; it's unfortunate that the packaging situation
> means that Django will get auto-upgraded as part of a distribution upgrade;
> I'm surprised that Debian hasn't had this with packages
[ Please keep me in CC ]
Hello,
I'm one of the python-django Debian package maintainers and I have been
working on preparing the field for Django 1.7... and we have one problem
that we don't know how to handle.
Consider that Debian contains Django but also Django applications using
South. When o
le.HIGHEST_PROTOCOL is also unwanted due to the serialized string
being much larger?
In case I work on a patch to improve the unit tests for this part,
should I file a new ticket? Should this mail have actually been sent as
a comment to the ticket? :)
--
Raphael Kubo da Costa
ProFUSION embedded syste
ng expanded to something along the
lines of "Set-Cookie: foo=bar; other-parameters;", so validation failed
later.
Some investigation led me to find the problem in the cache backend I was
using, as the cookies inside the cached HttpResponse were being
serialized incorrectly and later pi
e.get('some_cookie')
+
+self.assertEqual(cached_cookie['key'].value,
+ test_cookie['key'].value)
+
def test_unicode(self):
# Unicode values can be cached
stuff = {
[1] http://bugs.python.org/issue826897
--
Raphael Kubo
his 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.
>
>
--
Atenciosam
.com/group/django-developers?hl=en.
>
>
--
Atenciosamente Raphael Passini Diniz
--
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 th
people in our community who don't speak English as a
> first language. *That's* not a problem; we're not going to be grading
> you! However, we need to see that you can communicate clearly, and so
> basic proofreading is a must.
>
>
> Next
Thanks!
Ok, I see that the problem is more complicated than I thought, so I'll
leave it that way.
I just want to add that if you decide that you don't like the current
behaviour, you can always use FutureWarning, to first warn if a value
was set and is about to be discarded, and then change the
On 7/5/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> It's a backwards-incompatible change, so we'd need a strong reason to
> change it.
[...]
> This line of reasoning is unfortunately not particularly strong. The
> problem is that one group of people might find the current behaviour of
> so
Thanks a lot - I switched to the unicode branch and it works very
nice! I'll report any bugs I encounter.
Noam
On 13/06/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-06-12 at 21:16 +, Noam wrote:
> > Hello,
> >
> > First of all, I apologize if I post this in the wrong for
Ok, I posted my patch at http://code.djangoproject.com/ticket/4529
On 10/06/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> By the way, one advantage of writing the functionality you want as an
> extra tag (something not called "block") is that you (or anybody else
> who wants to work this wa
Ok, I've implemented my suggestion.
For those concerned about the complexity of implementation, it turns
out that all that's needed is a simple change in the block parser, to
make it return the same object for all blocks with the same name in a
template. The rendering code wasn't touched at all.
> Aside from the "urgh!" factor from writing the content in multiple
> times, if you are going to do this, why not just create a "reuse-block"
> tag that re-inserts the block value the template parser has already
> worked out previously? Doesn't need any change to the behaviour of
> "block" then.
On 08/06/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> On 6/8/07, Noam <[EMAIL PROTECTED]> wrote:
> > Let me improve my suggestion, so that it mostly solves James' concern
> > and can be explained in one sentence:
> >
> > -
> > Multiple blocks with the same name would be allowed, as long
75 matches
Mail list logo
