Hi all,
Calendar Week 43 -- ending 28 October.
Triaged:
https://code.djangoproject.com/ticket/29889 -- ArrayField cannot contain
JSONField; causes SQL error (needsinfo)
https://code.djangoproject.com/ticket/29879 -- CSRF AJAX section should
warn about the CSRF_COOKIE_HTTPONLY setting (Accept
i'm creating a online movie booking website, and i want to add a seat
selection site before it records the seats chosen and the bill is
calculated.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubsc
This mailing list is for the development of Django itself, not how to use
Django. The mailing list django-users is where you can ask this type of
question, but you will need to make your question a bit more detailed, if
you'd like to get a helpful response.
Regards,
Michael Manfre
On Wed, Oct 31,
Hi,
I'm creating this topic to see if there is interest to implement positional
arguments in queryset filtering.
Current situation
Currently the only way to use positional arguments to filter can be either:
- Passing a single or multiple Q objects:
MyClass.objects.filter(Q(key=valu
Hi,
Long story short, I discovered [1] there is no concensus [2] on which
formatting to use in the Django tutorial.
An argument for % (or against the format method) was
https://savannah.gnu.org/bugs/?30854 but it has been fixed 5 years ago, its
stays an argument against f-strings.
It seemed o
Please check urls.py on the root project
It should contain :
urlpatterns = [ Path('admin/', admin.site.urls), ]
On Sat, Oct 20, 2018, 8:37 AM Adam Johnson wrote:
> This mailing list is for the development of Django itself, not for
> support. Use the django-users mailing list for that, or IRC #dj
I don't have a strong opinion on whether or not we should make the switch
but
if the consensus is too move forward with this I'd suggest we wait until
Django
master's branch only supports Python 3.6+.
That would allow us to switch directly to f-strings and avoid doubling the
already
large diff
As I've mentioned on the ticket I've been wishing get(pk) could translate
to get(pk=pk) for a while but I never got to suggest it. Probably because I
didn't feel like adding (pk=...) was really that long. I'd note that most
of the
times I wished this existed was when doing some object manipulation
*I'm not convinced this would be as useful for `filter()` though as I don't*
*recall wanting to retrieve a set of objects matching a value I know will*
*be unique.*
The .filter() could be used for update
e.g.:
Mymodel.objects.filter(1).update(key=value)
This is also bringing consistency in the c
My main concern with allowing extra args and kwargs to be mixed with the
proposed
pk arg notation is that it would allow lookups such as
get(Q(is_active=True), pk)
Simon
Le mercredi 31 octobre 2018 14:53:35 UTC-4, Antwan a écrit :
>
> *I'm not convinced this would be as useful for `filter()` th
We had a bit of a discussion of this on
Python 2 docs have got this re format():
> This method of string formatting is the new standard in Python 3, and
should be preferred to the % formatting described in String Formatting
Operations in new code.
https://docs.python.org/2/library/stdtypes
Sorry, I typed that up and forgot to paste the link 🙄
On Wednesday, 31 October 2018 20:14:14 UTC+1, Carlton Gibson wrote:
>
> We had a bit of a discussion of this on
>
https://code.djangoproject.com/ticket/29623
--
You received this message because you are subscribed to the Google Groups
"Dj
There was a push to deprecated % formatting but too many people complained and that never happened.While .format and g-strings are superior, % is here to stay for the foreseeable future. Too many people still use it (including myself sometimes).On 1 Nov. 2018 08:14, Carlton Gibson wrote:We had a b
In my experience f strings are vastly more expressive than .format, but not
much better than % based formatting.
If we can make this change after we drop 3.5 I think it will be a lot
easier.
On Wed, 31 Oct 2018, 21:09 Adrian Turjak There was a push to deprecated % formatting but too many people
Another discussion is
https://groups.google.com/d/topic/django-developers/J9CfWIgrgbY/discussion
- % vs {} string formatting for public APIs
I haven't seen any practical benefits to prefer format() over %s. I find
the latter less verbose.
I'm not certain what this argument is (things like
htt
I'm not in favour of this, it's too implicit for my liking and I don't
think any gains outweigh the increased complexity of implementation.
Ian
On Wed, 31 Oct 2018 at 19:04, charettes wrote:
> My main concern with allowing extra args and kwargs to be mixed with the
> proposed
> pk arg notation
16 matches
Mail list logo
