On Fri, Jan 25, 2019 at 8:27 PM James Bennett wrote:
> My immediate thought here is: if people already aren't taking the time to
> patch using the existing mechanism, they also aren't going to take the time
> to opt out of patching. So what you're proposing is effectively still "any
> accessed
On Fri, Jan 25, 2019 at 9:39 AM Linus Lewandowski <
linus.lewandow...@netguru.co> wrote:
> True, probably a way to access headers without marking them as used would
> be required - maybe something like request.headers.get(XYZ,
> vary_response=False).
>
> However, right now people are commonly
I would like this - Django is a framework with batteries, and my
development group tells me "Django is too hard". This is because they
don't understand HTTP; mostly they understand HTML/CSS and SQL, with maybe
some easy jquery level of SQL. So, this kind of solution would fit well for
my
While reading this thread https://code.djangoproject.com/ticket/19649 came
to mind. I think most (if not all) from there basically is the same issue,
even though that one just concerns itself with the Cookie header.
I do not agree that request.headers is __now__ the single place for
accessing
> Accessing the value of a header doesn't necessarily mean that the
response varies based up on, for example it might simply be accessed for
storage in informational logs.
True, probably a way to access headers without marking them as used would
be required - maybe something like
I just want to recap what I'm hearing.
After listening to the arguments, it doesn't sound like many seasoned
developers/Django users would need the 3.5 support to remain for
development purposes. Therefore, their needs don't seem to need to be
considered.
Larger organizations may have issues with
FWIW, most of my problems with python version dependencies went away when I
started to use a custom build on our servers. Allows easy upgrades and a
good environment for our programs.
On Friday, January 25, 2019 at 4:01:28 PM UTC+1, Dan Davis wrote:
>
> My employer is still using CPython 3.4.6
Accessing the value of a header doesn't necessarily mean that the response
varies based up on, for example it might simply be accessed for storage in
informational logs. Additionally, Request.headers is not the only way to
access the values now, Request.META has not been removed. I don't believe
Can you explain more about what they struggled with? Maybe there's other
ways to solve those problems.
On Friday, January 25, 2019 at 9:43:37 AM UTC-5, Tom Forbes wrote:
>
> This message really resonated with me, especially after helping a few
> beginners get started with Python and watching
Right now, it's hard to report Vary header correctly. Headers might get
accessed in many different places, like middlewares, subroutines (which
can't use patch_vary_headers as they don't have access to the response
object), etc - and all those cases should be reflected in the Vary header,
or
My employer is still using CPython 3.4.6 on the servers, and CPython 3.5.1
on the desktop. I've been instrumental in developing a plan to move
forward. I know of one established company and one start-up, by name,
where they are still using CPython 2.7 (and a horrendously old version of
Django),
`pip install Django` gives the latest version of Django that's compatible
for the current version of Python. Yes, users will have to switch versions
at docs.djangoproject.com and they'll be in the same situation at
docs.python.org if they're using Python 3.5. For learning Django, I'd think
the
This message really resonated with me, especially after helping a few
beginners get started with Python and watching them struggle with exactly
this kind of thing.
I'd be +1 on following Python. Looking through the diff there is not a huge
amount of things to remove and IMO none of them are
Agree
Feel free to make a script that does startproject, git init, and anything
else you need.
Did you know startproject supports templates so if you’re really cranking
out projects with a standard format, you can make one for yourself to save
much more time there?
On Fri, 25 Jan 2019 at 12:42,
I am against this. It assumes too much about the user's system and version
management preferences.
I think there is little to gain given that `git init .` is 10 characters.
On Fri, Jan 25, 2019 at 8:35 PM mihir karbelkar
wrote:
> Hi,
> I have made several projects with Django but every time I
Hi,
I have made several projects with Django but every time I create a new
project I have to initialize the repo for git. It would be better if the
project initialized itself. Maybe we can add this feature in to help make
development "even faster to meet goals in record time".
I would love to
On Thursday, January 24, 2019 at 4:01:00 PM UTC+1, Adam Johnson wrote:
>
> I'd be happy to help mentor a cross-DB JSONField, it's something I'd like
> to see done so I can deprecate the one I maintain in Django-MySQL.
>
Not sure if GSOC changed that much, but it seems like somewhat small for a
Other ideas can be found in the DEPS repo
too: https://github.com/django/deps/pulls
The only one of those 3 that would be GSOC doable (IMO) would be the query
expression language one.
On Friday, 25 January 2019 01:43:13 UTC+11, Carlton Gibson wrote:
>
> Perhaps it's partly the GSoC doesn't
18 matches
Mail list logo
