Re: Django/CherryPy problem with POST data

[Russell Keith-Magee]

On Tue, Nov 2, 2010 at 4:19 AM, Ivan Sagalaev
 wrote:
> On 11/01/2010 11:21 AM, Mark wrote:
>>
>> Ticket #14594
>> 
>
> From a quick look it can be fixed in two ways:
>
> - HttpRequest.raw_post_data can always explicitly ask for content_length
> bytes. If content_length is absent just treat it as 0.
>
> - WSGIRequest can wrap all wsgi.input into a LimitedStream (now it's done
> only for known fragile sockets).
>
> I don't like pure Python wrappers moving bytes in performance critical
> places, so I'd go with the first approach. Does anyone foresee any bad
> things with it?

The former looks like the right approach to me -- in fact, it looks to
be a pretty close rendition of what the code used to do. I've made the
change in r14435.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: staticfiles defaults broke my site

[Carl Karsten]

On Oct 28, 9:45 pm, SmileyChris  wrote:

> My suggestion is that StaticFilesHandler only does its magic if
> 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
> sound acceptable?

Is it really an app?

If not, I suggest STATICFILES_URL defaults to None, and setting it
enables the functionality.

On Tue, Nov 2, 2010 at 12:31 AM, Russell Keith-Magee
 wrote:
> On Tue, Nov 2, 2010 at 10:55 AM, Carl Karsten  wrote:
>> I am not completely sure what is going on, but pretty sure the new
>> staticfiles thing is colliding with my existing
>>
>> urlpatterns += patterns('',
>> (r'^static/(?P.*)$', 'django.contrib.staticfiles.views.serve',
>>        {'document_root': 'static/','show_indexes': True}))
>>
>> That used to work, now I get:
>>  http://0.0.0.0:8080/static/
>> "Page not found: /static/"  (not the typical 404 error page, which
>> also seems like a bug, see below)
>>
>> A stupid workaround fix is:
>> STATICFILES_ROOT='foo'
>>
>> Here is what the docs show:
>> http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles
>> STATICFILES_ROOT Default: '' (Empty string)
>> STATICFILES_URL Default: '/static/'
>>
>> 404 thing:
>>
>> It does return a 404, but not the 404 page.
>>
>> c...@dc10:~/temp$ curl -v http://0.0.0.0:8080/static/
>> * About to connect() to 0.0.0.0 port 8080 (#0)
>> *   Trying 0.0.0.0... connected
>> * Connected to 0.0.0.0 (0.0.0.0) port 8080 (#0)
>>> GET /static/ HTTP/1.1
>>> User-Agent: curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o 
>>> zlib/1.2.3.4 libidn/1.18
>>> Host: 0.0.0.0:8080
>>> Accept: */*
>>>
>> * HTTP 1.0, assume close after body
>> < HTTP/1.0 404 NOT FOUND
>> < Date: Tue, 02 Nov 2010 02:52:58 GMT
>> < Server: WSGIServer/0.1 Python/2.6.6
>> < Content-type: text/plain
>> < Content-Length: 24
>> <
>> * Closing connection #0
>> Page not found: /static/
>
> Hi Carl,
>
> This is a known issue:
>
> http://code.djangoproject.com/ticket/14582
>
> The ticket links to a recent django-dev discussion with a proposed fix.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>



-- 
Carl K

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

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
response instances that can be baked.
2) Exception is raised on content access or iteration for unbaked
response.
3) 'force_bake' method is removed. 'bake' now behaves like old
'force_bake'.
4) Test client fixes are no longer needed and they are removed.
5) Some docs are added.

Am we in hurry to get 'render' shortcut into 1.3 alpha 1 or it can be
added later?

On 31 окт, 00:49, Ivan Sagalaev  wrote:
> On 10/30/2010 10:47 PM, SmileyChris wrote:
>
> > It seems a simple enough proposal that trying to access the content
> > property would raise an error until it is explicitly baked. Problem
> > solved.
>
> True. I seem to somehow missed it between the lines. Thanks! I'm +1 on
> it by the way.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Mikhail Korobov]

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...
> ). Docs are cumbersome (and incomplete), and a couple of middleware
> tests are missing.
>
> 1) Template response middleware is introduced. It is applied only for
> response instances that can be baked.
> 2) Exception is raised on content access or iteration for unbaked
> response.
> 3) 'force_bake' method is removed. 'bake' now behaves like old
> 'force_bake'.
> 4) Test client fixes are no longer needed and they are removed.
> 5) Some docs are added.
>
> Am we in hurry to get 'render' shortcut into 1.3 alpha 1 or it can be
> added later?
>
> On 31 окт, 00:49, Ivan Sagalaev  wrote:
>
>
>
> > On 10/30/2010 10:47 PM, SmileyChris wrote:
>
> > > It seems a simple enough proposal that trying to access the content
> > > property would raise an error until it is explicitly baked. Problem
> > > solved.
>
> > True. I seem to somehow missed it between the lines. Thanks! I'm +1 on
> > it by the way.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Git-using core devs: preference for merge vs. rebase?

[Tom X. Tobin]

Do the Git-using core developers have a preference for merge vs.
rebase for updating an upstream-tracking branch?  I prefer to rebase
to keep the changes in question at the branch HEAD, especially if the
branch hasn't been pushed publicly yet, but a rebase for something
that *has* been pushed means a forced overwrite is necessary, which
may trip up anyone who has already added the branch as a remote and
isn't expecting it.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Git-using core devs: preference for merge vs. rebase?

[SmileyChris]

On Nov 3, 5:58 am, "Tom X. Tobin"  wrote:
> Do the Git-using core developers have a preference for merge vs.
> rebase for updating an upstream-tracking branch?  I prefer to rebase
> to keep the changes in question at the branch HEAD, especially if the
> branch hasn't been pushed publicly yet, but a rebase for something
> that *has* been pushed means a forced overwrite is necessary, which
> may trip up anyone who has already added the branch as a remote and
> isn't expecting it.

For my ticket branches, I rebase.
If I ever have a big feature branch, I'll probably merge.
Unless it's a major feature branch, I'm not sure that'll be a huge
issue.

I also don't bother frequently updating against lastest upstream until
I'm at some stable point where I'm happy, or I know that some features
have changed.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: staticfiles defaults broke my site

[SmileyChris]

On Nov 3, 1:47 am, Carl Karsten  wrote:
> On Oct 28, 9:45 pm, SmileyChris  wrote:
>
> > My suggestion is that StaticFilesHandler only does its magic if
> > 'django.contrib.staticfiles' is found in INSTALLED_APPS. Does that
> > sound acceptable?
>
> Is it really an app?
>
> If not, I suggest STATICFILES_URL defaults to None, and setting it
> enables the functionality.

It *is* an app, in that it provides management commands when it's
enabled.

I'd could probably live with it defaulting to '', but I think trying
to treat it as an app is a better idea (even if it does permeate
through to some core code like the runserver handler).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Ivan Sagalaev]

On 11/02/2010 05:27 PM, Mikhail Korobov wrote:

I'm quite busy now and don't think I'll be able to make the patch
ready by 1.3 alpha 1.


Full feature freeze is expected only by the time of beta so I don't 
think it's absolutely necessary to push it before alpha 1.


Anyway since I care very much for the patch I can pick it up if you 
couldn't find a time to maintain it. Just drop me a line off-list in 
this case.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@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.

Re: Git-using core devs: preference for merge vs. rebase?

[Russell Keith-Magee]

On Wed, Nov 3, 2010 at 12:58 AM, Tom X. Tobin  wrote:
> Do the Git-using core developers have a preference for merge vs.
> rebase for updating an upstream-tracking branch?  I prefer to rebase
> to keep the changes in question at the branch HEAD, especially if the
> branch hasn't been pushed publicly yet, but a rebase for something
> that *has* been pushed means a forced overwrite is necessary, which
> may trip up anyone who has already added the branch as a remote and
> isn't expecting it.

First off, I'll preface my comments by saying that I'm a hg user by
habit, so I know the internals there a lot better, and my work
practices reflect that preference.

I would say that merges would be preferred -- but that's got more to
do with forced overwrites being annoying to deal with as a general
principle, rather than any specific issue with integrating with core.

With my core dev hat on, if I'm contemplating a contributed branch for
merge, I usually reviewing code using the github branch comparison
view; when I apply it, I use merge --nocommit --collapse. From a
'contribution to core' perspective, it doesn't really matter whether
you've rebased or merged upstream changes, both will collapse the
same.

The only way I can see this being a functional problem for core is if
I've historically pulled your repo to merge a different feature
branch, and I now revisit your repo to merge a second feature than has
been in development longer than the first, has been rebased, and
therefore requires a forced overwrite. In that case, merging would
have caused less trouble.

Beyond that, it's only an issue for anyone that is tracking your repo
specifically because of the new feature. Back when I was experimenting
with git, I used to rebase regularly; but then I got a few complaints
from people following my branches about what a pain that practice was.
I stopped, started using merge, and didn't really notice any
significant practical change.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Gentle Proposal: add 'render' shortcut in 1.3

[Russell Keith-Magee]

On Tue, Nov 2, 2010 at 11:06 PM, Mikhail Korobov  wrote:
> 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
> response instances that can be baked.
> 2) Exception is raised on content access or iteration for unbaked
> response.
> 3) 'force_bake' method is removed. 'bake' now behaves like old
> 'force_bake'.
> 4) Test client fixes are no longer needed and they are removed.
> 5) Some docs are added.
>
> Am we in hurry to get 'render' shortcut into 1.3 alpha 1 or it can be
> added later?

No - this isn't urgent for alpha 1; I'm happy to see it land in time
for the beta.

I've had a quick look at the patch, and it looks pretty good. Thanks
for your work on this, Mikhail.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Bug with testing framework when not using contrib.auth

[Yo-Yo Ma]

I have a large application that doesn't user contrib.auth, and when I
run `manage.py test` I get a slough of 35 errors, all of which are
DatabaseError: no such table: auth_user (differing Tracebacks for
each). I don't have any actual tests yet, just the SimpleTest that
comes free in tests.py. INSTALLED_APPS is:

'django.contrib.sessions',
'django.contrib.messages',
'myproject.myapp',  # Plus 8 more custom apps omitted.


With this bug, Django's testing framework is seemingly coupled to a
contrib app.

One of the Tracebacks:

==
ERROR: test_add
(django.contrib.messages.tests.user_messages.UserMessagesTest)
--
Traceback (most recent call last):
  File "C:\Python26\Lib\site-packages\django-trunk\django\contrib
\messages\tests\user_messages.py", line 13, in setUp
self.user = User.objects.create(username='tester')
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
\manager.py", line 138, in create
return self.get_query_set().create(**kwargs)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
\query.py", line 351, in create
obj.save(force_insert=True, using=self.db)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
\base.py", line 452, in save
self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
\base.py", line 545, in save_base
result = manager._insert(values, return_id=update_pk, using=using)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
\manager.py", line 195, in _insert
return insert_query(self.model, values, **kwargs)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
\query.py", line 1490, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
\compiler.py", line 786, in execute_sql
cursor = super(SQLInsertCompiler, self).execute_sql(None)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
\compiler.py", line 730, in execute_sql
cursor.execute(sql, params)
  File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends
\sqlite3\base.py", line 221, in execute
return Database.Cursor.execute(self, query, params)
DatabaseError: no such table: auth_user

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Bug with testing framework when not using contrib.auth

[David P. Novakovic]

This is certainly an artifact of the fact that messages recent started
supporting anonymous messages. Previously it depended on auth.

I suspect you just need to open a ticket for this.

On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma  wrote:
> I have a large application that doesn't user contrib.auth, and when I
> run `manage.py test` I get a slough of 35 errors, all of which are
> DatabaseError: no such table: auth_user (differing Tracebacks for
> each). I don't have any actual tests yet, just the SimpleTest that
> comes free in tests.py. INSTALLED_APPS is:
>
>    'django.contrib.sessions',
>    'django.contrib.messages',
>    'myproject.myapp',  # Plus 8 more custom apps omitted.
>
>
> With this bug, Django's testing framework is seemingly coupled to a
> contrib app.
>
> One of the Tracebacks:
>
> ==
> ERROR: test_add
> (django.contrib.messages.tests.user_messages.UserMessagesTest)
> --
> Traceback (most recent call last):
>  File "C:\Python26\Lib\site-packages\django-trunk\django\contrib
> \messages\tests\user_messages.py", line 13, in setUp
>    self.user = User.objects.create(username='tester')
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \manager.py", line 138, in create
>    return self.get_query_set().create(**kwargs)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \query.py", line 351, in create
>    obj.save(force_insert=True, using=self.db)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \base.py", line 452, in save
>    self.save_base(using=using, force_insert=force_insert,
> force_update=force_update)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \base.py", line 545, in save_base
>    result = manager._insert(values, return_id=update_pk, using=using)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \manager.py", line 195, in _insert
>    return insert_query(self.model, values, **kwargs)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
> \query.py", line 1490, in insert_query
>    return query.get_compiler(using=using).execute_sql(return_id)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> \compiler.py", line 786, in execute_sql
>    cursor = super(SQLInsertCompiler, self).execute_sql(None)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
> \compiler.py", line 730, in execute_sql
>    cursor.execute(sql, params)
>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends
> \sqlite3\base.py", line 221, in execute
>    return Database.Cursor.execute(self, query, params)
> DatabaseError: no such table: auth_user
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: Bug with testing framework when not using contrib.auth

[Russell Keith-Magee]

On Wed, Nov 3, 2010 at 8:18 AM, David P. Novakovic
 wrote:
> This is certainly an artifact of the fact that messages recent started
> supporting anonymous messages. Previously it depended on auth.
>
> I suspect you just need to open a ticket for this.

Yes - this is oversight, not intention.

contrib.messages depends on contrib.auth for reasons of backwards
compatibility, but unless you're using the legacy fallback storage
mechanism, that dependency doesn't exist in practice. You're the first
person to report this dependency as a practical concern.

I suspect we'll need to crack out some of the new unittest2 features
to fix this; skipping the user_messages tests unless contrib.auth is
available.

Yours,
Russ Magee %-)


> On Wed, Nov 3, 2010 at 4:43 AM, Yo-Yo Ma  wrote:
>> I have a large application that doesn't user contrib.auth, and when I
>> run `manage.py test` I get a slough of 35 errors, all of which are
>> DatabaseError: no such table: auth_user (differing Tracebacks for
>> each). I don't have any actual tests yet, just the SimpleTest that
>> comes free in tests.py. INSTALLED_APPS is:
>>
>>    'django.contrib.sessions',
>>    'django.contrib.messages',
>>    'myproject.myapp',  # Plus 8 more custom apps omitted.
>>
>>
>> With this bug, Django's testing framework is seemingly coupled to a
>> contrib app.
>>
>> One of the Tracebacks:
>>
>> ==
>> ERROR: test_add
>> (django.contrib.messages.tests.user_messages.UserMessagesTest)
>> --
>> Traceback (most recent call last):
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\contrib
>> \messages\tests\user_messages.py", line 13, in setUp
>>    self.user = User.objects.create(username='tester')
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
>> \manager.py", line 138, in create
>>    return self.get_query_set().create(**kwargs)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
>> \query.py", line 351, in create
>>    obj.save(force_insert=True, using=self.db)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
>> \base.py", line 452, in save
>>    self.save_base(using=using, force_insert=force_insert,
>> force_update=force_update)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
>> \base.py", line 545, in save_base
>>    result = manager._insert(values, return_id=update_pk, using=using)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
>> \manager.py", line 195, in _insert
>>    return insert_query(self.model, values, **kwargs)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models
>> \query.py", line 1490, in insert_query
>>    return query.get_compiler(using=using).execute_sql(return_id)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
>> \compiler.py", line 786, in execute_sql
>>    cursor = super(SQLInsertCompiler, self).execute_sql(None)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\models\sql
>> \compiler.py", line 730, in execute_sql
>>    cursor.execute(sql, params)
>>  File "C:\Python26\Lib\site-packages\django-trunk\django\db\backends
>> \sqlite3\base.py", line 221, in execute
>>    return Database.Cursor.execute(self, query, params)
>> DatabaseError: no such table: auth_user
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to django-develop...@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.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

ticket #14570 for 1.3?

[Sergiy Kuzmenko]

Sorry if I'm being impatient here but I don't want to start raising
this question when it's too close to complete feature freeze. Is it
possible to include ticket #14570[1] into 1.3 release? It is a rather
trivial change which will help generate correct long date display in
certain locales.

[1] - http://code.djangoproject.com/ticket/14570

Thank you
Sergiy

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Re: MultiWidgets

[Gabriel Hurley]

Personally, I look at this query every day, so I'm certainly aware of
what remains to be done...

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&groupdesc=1&group=stage&component=Documentation&has_patch=1&has_patch=0&order=priority

Identifying "low hanging fruit" is a tricky issue, though. I already
made one pass at the full list, and everything I marked as "easy-
pickings" (the official keyword) was patched and committed real quick.

For some perspective: In just a few weeks since the slew of new
committers, I've seen that report drop from 170 tickets to the < 130
that it's at now. And there've been plenty of new reports in the
interim.

There are no longer any docs tickets stuck in DDN... everything that
the community triaged and marked as RFC has been wrapped up and
committed... now I'm working through docs tickets with existing
patches.

So, as it always does, it comes down to someone writing a patch. If
you don't feel confident writing docs for multiwidget that's no
problem. I'd love to work with you on any other tickets you want to
take on.  And if you ever have questions about the docs or how to
write patches, I'm happy to help!

All the best,

- Gabriel Hurley


On Nov 1, 2:13 pm, Paul Oswald  wrote:
> Is it too late to have the 1.3 Milestone applied to these documentation 
> issues?
>
> http://code.djangoproject.com/ticket/13997http://code.djangoproject.com/ticket/11185
>
> I'm trying to update some old code that has a custom MultiValueField and 
> MultiWidget to be 1.2 compatible and I've never made a custom field or widget 
> before. I have run into some issues and a Google search turns up a lot of 
> varying quality noise from over the years. At this point, the official docs 
> are at risk of not being in the first page for the search term "Django 
> MultiWidget". It sure would be nice to have something authoritative from 
> someone who understands it.
>
> More generally, as a relative newcomer to Django I have hit a frustratingly 
> high number of commonly understood but undocumented usage patterns, 
> incomplete and unorganized docs and general gotchas. Here is a search query I 
> wish I had seen on day one:
>
> http://code.djangoproject.com/query?status=new&status=assigned&status...
>
> It gives a pretty good overview of where the official docs are lacking. I 
> don't think I can document subclassing MultiWidget because I can't even get 
> it to work right (in my admittedly complex use case).  Some of the issues in 
> that list seem like they would be small patches. Would it be possible to have 
> someone mark the low hanging fruit as 1.3? If I write small documentation 
> updates/fixes/editing for the things I've run into trouble with but now 
> understand, will they get applied?
>
> -Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.