Request decompression looks scary: how are you going to implement
protection against zip bombs (http://en.wikipedia.org/wiki/Zip_bomb)? See
also: http://bugs.python.org/issue16043
суббота, 25 мая 2013 г., 20:34:44 UTC+6 пользователь Sébastien Béal написал:
>
> Hi,
>
> I would like to suggest to
среда, 20 марта 2013 г., 21:22:10 UTC+6 пользователь Aymeric Augustin
написал:
>
> On 20 mars 2013, at 11:22, Russell Keith-Magee
> >
> wrote:
>
> > Personally, I'd rather see the opposite -- contrib apps containing their
> own tests, and the tests directory containing just the tests for Dja
A good idea, +1.
четверг, 7 марта 2013 г., 22:48:11 UTC+6 пользователь Jacob Kaplan-Moss
написал:
>
> Hi folks --
>
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care mu
пятница, 28 декабря 2012 г., 14:37:46 UTC+6 пользователь Aymeric Augustin
написал:
>
> 2012/12/28 Karen Tracey >
>
>> On Thu, Dec 27, 2012 at 7:15 PM, Aymeric Augustin <
>> aymeric@polytechnique.org > wrote:
>>
>>> 2) under Python 2.x __str__ is implemented as __unicode__
>>>encoded to u
Hi Aymeric,
FYI: I didn't check anything in my message manually, this is a "code
review" based on grepping over django source code for common problems.
пятница, 28 декабря 2012 г., 6:15:06 UTC+6 пользователь Aymeric Augustin
написал:
>
> Hi Mikhail,
>
> Thanks for your feedback! Your email tou
). The argument about
"%r" % object_with_non_ascii__repr__ still apply.
пятница, 28 декабря 2012 г., 1:20:24 UTC+6 пользователь Mikhail Korobov
написал:
>
> Hi there,
>
> First of all, many kudos for the Python 3.x support in upcoming django
> 1.5, and for the way it
Hi there,
First of all, many kudos for the Python 3.x support in upcoming django 1.5,
and for the way it is handled (the approach, the docs, etc)!
I think there are some pitfalls with @python_2_unicode_compatible decorator
as it currently implemented in django (and __str__/__repr__ in general)
Python 3.2 is a default python in Ububtu 12.04 LTS so I think Python 3.2
support is pretty important.
And what are the gains of having "u" prefixes all over the codebase? This
makes the codebase less Python3-like. With PEP414-based code there must be
explicit "b" and explicit "u" prefixes all
Some people prefer argparse, some people prefer decorator-based syntax
(like django-boss or argh), there are people prefer other methods (e.g.
docopt). I think it is better not to invent yet another command-line
framework.
Maybe delegate option parsing to user favorive library and provide some
If you pollute the namespace with small helper functions you can test them
independently and use them outside single CBV. This style also helps to
write less coupled code - all dependencies are visible (they are all in
functions' params list) so this forces developer to rethink the
decompositio
Thanks man!
PASSWORD_HASHERS = ('django.contrib.auth.hashers.MD5PasswordHasher',)
in test_settings.py made tests of our project 2x faster (I was not
upgrading from 1.3).
понедельник, 16 апреля 2012 г., 20:33:31 UTC+6 пользователь Dan Fairs
написал:
>
> Hi,
>
> Both of these were fixed by using
Standard python 2.6 json is a bundled and cleaned up simplejson without C
extension and pre-26 compatibility - even if json serialization is not a
common bottleneck why make things worse? Simplejson and python 2.6 json are
arguably the same libraries, I think this is like choosing between
cStri
Hi django developers,
GSoC'11 Gregor Müllegger's and Carl Meyer's project (Revised form
rendering) seems to get stuck because of performance issues.
Question 1. Am I understand this correctly and the limiting factor is the
template rendering speed?
Question 2. Is it true that templates are not
суббота, 17 марта 2012 г. 0:15:39 UTC+6 пользователь dstufft написал:
>
> On Friday, March 16, 2012 at 2:08 PM, Luke Sneeringer wrote:
>
> Here's my hit list of perceived benefits:
> 1. It regains the efficiency of a single table (which is minor, to be
> sure, but since Jacob already brought it up
Hi Alisue,
Django already have a way to create models only for tests: put model
definitions to tests.py. Such models will be available in tests but won't
be created with ./manage.py syncdb.
вторник, 28 февраля 2012 г. 9:11:25 UTC+6 пользователь Alisue написал:
>
> (2012年02月28日 01:34), Florian A
воскресенье, 26 февраля 2012 г. 15:38:33 UTC+6 пользователь Łukasz Rekucki
написал:
>
> On 26 February 2012 05:55, Joe & Anne Tennies wrote:
> > While this would be a valid argument if Django templates only rendered
> HTML,
> > that is not the only thing it can be used to render.
>
> > The origi
A heavy bitbucket user here.
I personally prefer hg to git and bitbucket to github but I think github +
git would be better for django because of much larger community.
Guys, but please stop bashing bitbucket. Bitbucket supports both hg and git
(github don't), has nice bugtracker; bitbucket has
+1 for Paul's concerns. I think this at least should be opt-in.
It can be also more or less implemented without custom widgets but
using Gregor Müllegger's form-rendering branch (which is not merged but
available as https://github.com/SmileyChris/django-forms app if I
understand it properly) -
The similar applies to octal constant suggestion: If python 2.5 is not
supported is may be better to replace 0777 with 0o777.
* http://docs.python.org/whatsnew/2.6.html#pep-3112-byte-literals
*
http://docs.python.org/whatsnew/2.6.html#pep-3127-integer-literal-support-and-syntax
--
You received
Great effort!
What about using
from __future__ import unicode_literals
instead of wrapping every constant with a "u" or "b" functions?
Python 2.6 support 'b' notation so if python 2.5 is not supported there is
no need for "u" and "b" functions.
--
You received this message because you
I don't agree with most points because they are assuming functions are less
fancy, less customizable, less clean, more complex, etc than classes and
this is not true (but let's not start FP vs OOP holywar here, FP and OOP are
friends in python).
I like Jacob's proposal because there should be o
Hi all,
There are a lot of projects for making django deployment easier (a bit of
them are listed here: http://djangopackages.com/grids/g/deployment/ ) but
there is no clear winner, everybody have different preferences and
requirements. I think this all doesn't relate to development of django
I gave up defining this template tag with existing template tag libraries:
{% easy_map [ ] [] [using ] %}
Can positional arguments be optional? Will it be possible to express this
syntax?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
Great job on summarizing the issue!
I have one concern though. Can you please explain why is USE_TZ option
better than introducing e.g. UtcDateTimeField?
USE_TZ=True will break all existing code (including external apps) which
relies on django 1.3 documented DateTimeField behavior, this can be
Hi all,
One thing I always like about django is how the community is peaceful and
how the django itself is peaceful and engineer-minded, not marketing-minded:
I can't imagine whydjangoisbetterthanx.com website bashing zend, rails,
pyramid and flask, for example. That's why the idea of putting s
Hi Gregor & others,
I've noticed the https://github.com/idangazit/formrendering and it reminds
me the approach I'm using for all my django 1.3 projects:
{# forms/fields/as_dl.html #}
{{ field.label_tag }}} {{ field }}
{% include "forms/fields/errors.html" %}
and then:
{% csrf_token %} {
Not exactly related, but this is how help_text (and other field options) can
be moved out from the field definition without patching
django: http://djangosnippets.org/snippets/2180/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
I think the alternative for python 2.5 may be not to use urllib2 and set
socket timeouts directly, this is supported from python 2.3 (basic
implementation:
https://bitbucket.org/kmike/vkontakte/src/e89d4cb94902/vkontakte/http.py ).
Feels like a hack though.
--
You received this message becaus
@Fabiant
The code linked does not set global default socket timeout and so it
shouldn't have concurrency issues; it sets socket timeout for HTTPConnection
instance's socket.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
Hi folks,
what do you think about deprecating AUTH_PROFILE_MODULE and .get_profile()
or removing the suggestion to use it from the docs in 1.4 release?
There are broader issues with extending User model but I think this one can
be handled separately.
Some links:
* http://code.djangoproject.com
Hi Carl,
The issue is not only with unique_together indeed. Please correct me if I'm
wrong, but it seems there is no way currently to use model validation with
fields dependent on each other when one of these fields is not POSTed
directly by user. Example:
# models.py
class Ticket(models.Mode
Hi Julien,
Thanks for working on this!
Will your patch simplify creating filters not based on choices? E.g.
min/max filters where exact minimun and maximum values can be entered
(using form with method=GET and input fields for values)? I want a
pony ;)
It would also be good to make FilterSpec.ou
Hi James,
Some notes:
> One of the great advantages of uWSGI_ is its ability to gradually
> restart each worker without loosing any request.
I think mod_wsgi in daemon mode is doing the same.
> Nginx provides the uwsgi module by default these days.
Stock nginx does not provide uwsgi module on
Hi Carl and Gregor,
On 2 апр, 01:17, Carl Meyer wrote:
>
> > 3. The designers I worked with are often interested on adding custom css
> > class
> > or an attribute to a form field. Most of the time this is really a pain
> > to
> > do if you don't have control over the python form code. Im
./manage.py dumpdata --format=json
command produces unreadable output for non-ascii symbols now (they are
encoded as \u ).
Such encoding is not required according to http://www.ietf.org/rfc/rfc4627.txt
(section 2.5):
"All Unicode characters may be placed within the quotation marks
except for
Just for the record: I'm with Ivan here and think that
from django.template.response import TemplateResponse
def my_view(request):
return TemplateResponse(request, 'foo.html')
is worse than
from django.shortcuts import render
def my_view(request):
return render(request, 'foo.html')
I th
Btw, not all settings can be patched just by overriding values because
some of them are cached and the change of the value doesn't change
django behaviour (e.g. TEMPLATE_CONTEXT_PROCESSORS option behaves like
this).
On 5 ноя, 02:23, Łukasz Rekucki wrote:
> Funny, I had exactly the same problem to
I'm quite busy now and don't think I'll be able to make the patch
ready by 1.3 alpha 1.
On 2 ноя, 20:06, Mikhail Korobov wrote:
> Hi all.
>
> The new patch is attached to ticket
> (seehttp://code.djangoproject.com/attachment/ticket/12816/render_shortcut...
&g
Hi all.
The new patch is attached to ticket (see
http://code.djangoproject.com/attachment/ticket/12816/render_shortcut.6.diff?format=raw
). Docs are cumbersome (and incomplete), and a couple of middleware
tests are missing.
1) Template response middleware is introduced. It is applied only for
res
Hi Waldemar,
The problem was really hard to understand for me because I was
assuming you're trying to describe django.contrib.staticfiles flaw
while you were describing the problem with third-party asset managers.
I think you have described a real problem here but (as you said) this
problem is no
On 29 окт, 10:09, Russell Keith-Magee wrote:
>
> Ah - I wasn't aware there was a working implementation of this idea --
> did I miss a link somewhere?
>
No, there is no full working implementation. I'm talking about Ivan's
code snippet:
response = get_response(...)
if hastattr(response
Hi Russel,
Thank you for your reviews and moving things on!
On 29 окт, 07:35, Russell Keith-Magee wrote:
>
> I like this idea -- it's is an elegant solution to the problem, and
> avoids all the backwards compatibility issues I can think of.
>
> I have two comments:
>
> Firstly, there needs to be
On 28 окт, 12:55, Ivan Sagalaev wrote:
> On 10/27/2010 04:55 PM, Mikhail Korobov wrote:
>
> > 1. 'Border' middleware is a backwards-compatible change, the
> > requirement to bake response in middleware isn't.
>
> > The
> > difference is only
force_bake' and even
'bake' on responses.
On 27 окт, 19:55, Mikhail Korobov wrote:
> Hi Ivan,
>
> Let me explain why I prefer 'border' middleware way (that is
> implemented) over explicit baking in messages middleware (that was
> implemented but then replaced
Hi Ivan,
Let me explain why I prefer 'border' middleware way (that is
implemented) over explicit baking in messages middleware (that was
implemented but then replaced with 'border' middleware).
1. 'Border' middleware is a backwards-compatible change, the
requirement to bake response in middleware
olves a problem of media files customizing - where to put
customized media files so that they can survive app upgrade. And
that's all. Why do you see django.contrib.staticfiles as a framework
for css/js combiners?
On 27 окт, 17:38, Waldemar Kornewald wrote:
> Hi Mikhail,
>
>
>
Hi Waldemar,
Could you explain why is this should belong to django staticfiles app?
This app has nothing to do with combining css files. It has one view
(django.contrib.staticfiles.views.serve) in order to serve files in
development. This is only a helper view used in development and I
don't see w
Hi Alex and Yuri,
To make it clear: is this only a syntax change and all other benefits
can be achieved with current implementation?
The benefits from the wiki:
1. ability to customize and localize 3rd-party application without
fork it - it is as easy with current ModelAdmin. ModelAdmin looks up
if
it is available.
Implementation (no tests and docs):
http://bitbucket.org/kmike/django/changeset/68571aa0e5a3
On 25 окт, 20:36, Mikhail Korobov wrote:
> contrib.messages middleware was broken because it relies on something
> that should happen on template rendering (iteration ov
/c61c1b8d5426c1cb?lnk=gst&q=http+content#c61c1b8d5426c1cb)
and maybe there are some ideas from that thread which may be useful.
On 25 окт, 19:33, Russell Keith-Magee wrote:
> 2010/10/25 Mikhail Korobov :
>
> > Sorry for massive email spam on this list :)
>
> > I came up with
duplication between TemplateResponse and
TemplateResponseMixin with this implementation. Custom template
loading and context instantiation go to TemplateResponse subclasses.
On 24 окт, 17:32, Mikhail Korobov wrote:
> new changes (integration with generic views, test client and messages
> middleware
tpResponse.bake method but this
way HttpResponse will be aware of TemplateResponse and it doesn't seem
clean for me.
On 24 окт, 02:14, Mikhail Korobov wrote:
> Yes, you're right and I was wrong, the messages middleware doesn't
> return response as-is. I'll take a look.
>
> Regarding the messages middleware, I *know* there's a problem. A
> message won't be marked as "read", since the template hasn't iterated
> the messages object by the time the middleware is triggered
>
> On Oct 23, 8:35 am, Mikhail Korobov wro
Hi all again!
I've done some research on generic views integration and think that
TemplateResponseMixin should be refactored in order to use
TemplateResponse (SimpleTemplateResponse actually) because it
currently assumes that template must be rendered before the response
is returned.
'render_temp
On 22 окт, 18:10, Łukasz Rekucki wrote:
> On 22 October 2010 03:59, Russell Keith-Magee wrote:
> > 2010/10/21 Łukasz Rekucki :
> >> Both render_to_response() and direct_to_template() have one very
> >> annoying flaw:http://code.djangoproject.com/ticket/12669. Please add
> >> a "response_class" ke
ing
> assertContains
> 2. You need to explicitly bake the response before the
> contrib.messages middleware
>
> On Oct 23, 1:32 am, Russell Keith-Magee
> wrote:
>
>
>
> > On Fri, Oct 22, 2010 at 7:32 PM, Mikhail Korobov
> > wrote:
> > > Russell's comm
Russell's comments were helpful in discovering the edge case.
_set_content behaves differently for baked and non-baked responses:
response = render(request, Template('foo'))
response.content = 'bar'
print response.content# 'foo'
response.content = 'baz'
print response.content# 'baz'
This
'egg'})
response.template_name = 'spam.json'
response.status_code = 400
return response
On 21 окт, 23:56, Mikhail Korobov wrote:
> I love programming: two-liner shortcut turns to be a massive core
> refactoring ;) Ivan, thank you for the research.
>
>
hortcut is complicated much by TemplateResponse because
SimpleTemplateResponse is inherited from HttpResponse.
On 21 окт, 22:34, Ivan Sagalaev wrote:
> On 10/21/2010 03:22 PM, Ivan Sagalaev wrote:
>
> > On 10/21/2010 11:49 AM, Mikhail Korobov wrote:
> >> 2. Does TemplateRes
I think that staticfiles in contrib is a good idea because with it
authors of reusable apps have an answer for the "How should user
install app's static files?" question. They already know how to make
python code and django templates available, but static files was a bit
of pain before. Now the puz
Well, I don't mean that now we all must write only class-based views.
I was talking about reusable views and most views don't have to be
reusable (though it would be nice). Django now can help developer in
writing reusable views and it was not the case when TemplateResponse
was invented. That's wha
Hi Ivan!
On 21 окт, 03:00, Ivan Sagalaev wrote:
>
> Wait!!!
>
> Sorry… Hello everyone :-)
>
> If I remember correctly TemplateResponse was solving a problem of some
> middleware wanting to mess with a view context before it's baked into
> final string representation. This would solve in a good wa
On 20 October 2010 21:57, Jacob Kaplan-Moss wrote:
>
>
>
>
>
> > 2010/10/20 Mikhail Korobov :
> >> There is an unresolved question in the ticket: "The only hesitation is
> >> the relationship with #12815; we should resolve that decision before
>
logic (and change view
context in particular) now and TemplateResponse (which was a good
addition to django 1.2/1.1/1.0) seems to only complicate things in
django 1.3.
On 21 окт, 01:02, Jacob Kaplan-Moss wrote:
> On Wed, Oct 20, 2010 at 1:48 PM, Mikhail Korobov
> wrote:
> > So ple
Hi all,
I'm talking about this ticket: http://code.djangoproject.com/ticket/12816
With class-based views landed and the deprecation of
django.views.generic.simple (and direct_to_template in particular)
there won't be simple and undeprecated shortcut for
render_to_response.
So please add the 'ren
Hi all,
If it will be a contextmanager then it can also be extended to perform
like a decorator: http://gist.github.com/573536
I think this can be useful.
On 11 окт, 04:17, Alex Gaynor wrote:
> Hey all,
>
> I've been spending some time with ticket #5416[0], which is a request
> for assertNumQuer
Hi Thomas,
there is a ticket for that:
http://code.djangoproject.com/ticket/4992
On 29 сен, 16:36, Thomas Guettler wrote:
> Hi,
>
> I got not response on django-users, now I ask here:
>
> requests with a query string (http://example.com?foo=bar) are not cached in
> Django:
>
> http://code.dja
Hi all. I'm not a django core developer but have some thoughts about
provided patch.
1. The patch is for django 1.1 and django 1.2 have jQuery available so
some parts may be simplified.
2. Some 'var' declarations are missing (check
'dismissChangeCurrentPopup' method and 'i' variable, 'href' and
'
This is a good feature and I also have my custom cache backend with
project-level key prefixes. It was easy to implement and doesn't
require changes in django core. But if this backend is in django core
(that's a good idea) then some other changes should be done. There
will be 2 similar options aft
So you're aware of this, great! Sorry for mailing list noise then.
On May 26, 1:32 pm, Russell Keith-Magee
wrote:
> On Wed, May 26, 2010 at 8:22 AM, Mikhail Korobov
> wrote:
> > I want to raise the question about stable django micro-releases.
>
> > 1.1 - July 2009
I want to raise the question about stable django micro-releases.
1.1 - July 2009,
1.1.1 - October 2009 (released because of security bug),
1.1.2 - May 2010
So if some abstract developer want to use stable django release and
follow all the instructions in docs he can get the half-year outdated
dja
That's great news, thanks!
A very minor issue: web server returns 'Content-Type:text/
html;charset=ISO-8859-1' header for this page:
http://hudson.djangoproject.com/monitor/?
but the actual page encoding is utf-8 so there are strange symbols
instead of translated strings.
--
You received this m
72 matches
Mail list logo
