date:20170920

Re: ConnectionResetError in test_closes_connection_without_content_length

2017-09-20 Thread Adam Johnson

Hi Zhiqiang

It's hard to tell what the problem is with more details. From your
traceback it looks like you're running Python3.4 on MacOS but there's no
indication of your database or other settings.

If you run the tests on the 1.11 branch, does it pass? If so, you can
bisect to find the regression and report that as a proper bug, instructions
here:
https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#bisecting-a-regression

Otherwise, more information is needed to debug.

On 20 September 2017 at 03:46, Zhiqiang Liu  wrote:

> I run the test suits for master and get the following error.
>
> Traceback (most recent call last):
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.
> framework/Versions/3.4/lib/python3.4/unittest/case.py", line 58, in
> testPartExecutor
> yield
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.
> framework/Versions/3.4/lib/python3.4/unittest/case.py", line 577, in run
> testMethod()
>   File "/Users/ZachLiu/CS/Python/Projects/Django/django/django/test/utils.py",
> line 371, in inner
> return func(*args, **kwargs)
>   File 
> "/Users/ZachLiu/CS/Python/Projects/Django/django/tests/servers/tests.py",
> line 80, in test_closes_connection_without_content_length
> conn.getresponse()
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.
> framework/Versions/3.4/lib/python3.4/http/client.py", line 1171, in
> getresponse
> response.begin()
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.
> framework/Versions/3.4/lib/python3.4/http/client.py", line 351, in begin
> version, status, reason = self._read_status()
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.
> framework/Versions/3.4/lib/python3.4/http/client.py", line 313, in
> _read_status
> line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.
> framework/Versions/3.4/lib/python3.4/socket.py", line 374, in readinto
> return self._sock.recv_into(b)
> ConnectionResetError: [Errno 54] Connection reset by peer
>
> Is there anything I missed? Anyone can help?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/9b97b2a3-160f-4c34-b4fd-
> c447cd1f6895%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0nGnmWyjatkYhk695O%3DPc-bJVAbKGqaXV4xVQxF96vGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ConnectionResetError in test_closes_connection_without_content_length

2017-09-20 Thread Tom Forbes

I added this test for the keep-alive release blocker. It's possible that
the exceptions raised in that test vary by OS at least on 3.4, the docs
suggest that it should throw BadStatusLine instead.

ConnectionResetError is also a correct exception to raise in that specific
case, we should just add that to the try/catch statement I think.

On 20 Sep 2017 10:14 am, "Adam Johnson"  wrote:

Hi Zhiqiang

It's hard to tell what the problem is with more details. From your
traceback it looks like you're running Python3.4 on MacOS but there's no
indication of your database or other settings.

If you run the tests on the 1.11 branch, does it pass? If so, you can
bisect to find the regression and report that as a proper bug, instructions
here: https://docs.djangoproject.com/en/dev/internals/contributing/
triaging-tickets/#bisecting-a-regression

Otherwise, more information is needed to debug.

On 20 September 2017 at 03:46, Zhiqiang Liu  wrote:

> I run the test suits for master and get the following error.
>
> Traceback (most recent call last):
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework
> /Versions/3.4/lib/python3.4/unittest/case.py", line 58, in
> testPartExecutor
> yield
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework
> /Versions/3.4/lib/python3.4/unittest/case.py", line 577, in run
> testMethod()
>   File "/Users/ZachLiu/CS/Python/Projects/Django/django/django/test/utils.py",
> line 371, in inner
> return func(*args, **kwargs)
>   File 
> "/Users/ZachLiu/CS/Python/Projects/Django/django/tests/servers/tests.py",
> line 80, in test_closes_connection_without_content_length
> conn.getresponse()
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework
> /Versions/3.4/lib/python3.4/http/client.py", line 1171, in getresponse
> response.begin()
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework
> /Versions/3.4/lib/python3.4/http/client.py", line 351, in begin
> version, status, reason = self._read_status()
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework
> /Versions/3.4/lib/python3.4/http/client.py", line 313, in _read_status
> line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
>   File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework
> /Versions/3.4/lib/python3.4/socket.py", line 374, in readinto
> return self._sock.recv_into(b)
> ConnectionResetError: [Errno 54] Connection reset by peer
>
> Is there anything I missed? Anyone can help?
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/9b97b2a3-160f-4c34-b4fd-c447cd1f6895%
> 40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/CAMyDDM0nGnmWyjatkYhk695O%
3DPc-bJVAbKGqaXV4xVQxF96vGg%40mail.gmail.com

.

For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJP264dGhLfVVVxqc%3Dnn5PmFtSdDGOBwrkRU8_2RSJ%2BxeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 2.0 release blockers

2017-09-20 Thread Tim Graham

Thanks for the feedback. I think the indentation changes are correct, but 
please leave a comment on the PR so I can be sure which lines you're 
referring to. I added this text to the release notes per your suggestion:

The ``django.conf.urls.url()`` function from previous versions is now 
available
as :func:`django.urls.re_path`, however, the old location remains for 
backwards
compatibility, without an imminent deprecation. The old
``django.conf.urls.include()`` function is now importable from 
``django.urls``
so you can use ``from django.urls import include, path, re_path`` in your
URLconfs.

On Wednesday, September 20, 2017 at 5:15:03 AM UTC-4, contact wrote:
>
> Hi Tim,
>
> I've taken a look at this one:
> https://github.com/django/django/pull/9072 - Simplified URL routing 
> syntax. (docs)
>
> Seems good to me (there are some indentation changes, like in 
> docs/ref/contrib/sitemaps.txt 
> 
>  
> that are not systematic in the urlpatterns, but I don't know if it's 
> important). 
>
> I would just have added something in docs/releases/2.0.txt 
> 
>  
> to tell that previous behaviour (with url()) has been moved to 
> django.urls.re_path(). 
> If I understood it well at least... There might be cases where the new 
> syntax won't be sufficient (or at least I believe so, like in urls like 
> /ab/cd/abcdefghi for example), and pushing upgraders to start using 
> re_match directly instead of url() might be a good idea, IMHO. Does it 
> make sense or did I miss something?
>
> - Brice
>
> Le 20/09/17 à 04:21, Tim Graham a écrit :
>
> I spent today finishing up writing and then reviewing the documentation 
> for URL routing. I'll give that and the code one more look tomorrow before 
> merging. In the meantime, other reviews (especially from anyone less 
> familiar with the feature) are certainly welcome.
> https://github.com/django/django/pull/7482 - Simplified URL routing 
> syntax. (code)
> https://github.com/django/django/pull/9072 - Simplified URL routing 
> syntax. (docs)
>
> 
> other todos for the alpha:
> https://github.com/django/django/pull/9086 - Refs #28595 -- Added execute 
> wrappers for database queries.
> https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
> support for conditional joins in the ORM.
>
> On Monday, September 18, 2017 at 9:44:05 PM UTC-4, Tim Graham wrote: 
>>
>> completed today:
>> https://github.com/django/django/pull/6385 - Fixed #14370 -- Added 
>> select2 widget for related object fields in admin.
>> https://github.com/django/django/pull/7611 - Fixed #26608 -- Add support 
>> for OVER-clause (window expressions).
>>
>> 
>> todo:
>> https://github.com/django/django/pull/7482 - Simplified URL routing 
>> syntax. (code)
>> https://github.com/django/django/pull/9072 - Simplified URL routing 
>> syntax. (docs)
>> https://github.com/django/django/pull/9086 - Refs #28595 -- Added 
>> execute wrappers for database queries.
>> https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
>> support for conditional joins in the ORM.
>>
>> On Sunday, September 17, 2017 at 5:11:43 PM UTC-4, Florian Apolloner 
>> wrote: 
>>>
>>> Looks good to me. 
>>> https://github.com/django/django/commit/01c6a3e227b645e8dea97e9befecd23d1d3b8581
>>>  
>>> resulted in test failures, we might have to revert that.
>>>
>>> I do have to add https://github.com/django/django/pull/9100 to the mix, 
>>> but since it is a bugfix we can easily do this after the alpha.
>>>
>>> cheers,
>>> Florian
>>>
>>> On Sunday, September 17, 2017 at 1:30:01 AM UTC+2, Tim Graham wrote: 

 Time to kickoff the progress tracker for the next major release!

 The 2.0 alpha is scheduled (according to 
 https://code.djangoproject.com/wiki/Version2.0Roadmap) for Monday, 
 September 18. Typically we've release the alpha a few days later to finish 
 up a few last minutes things. Here are the PRs on my list to polish off 
 before the alpha release. I'll send another update on Monday.

 https://github.com/django/django/pull/6385 - Fixed #14370 -- Added 
 select2 widget for related object fields in admin.
 https://github.com/django/django/pull/7611 - Fixed #26608 -- Add 
 support for OVER-clause (window expressions).
 https://github.com/django/django/pull/7482 - Simplified URL routing 
 syntax. (code)
 https://github.com/django/django/pull/9072 - Simplified URL routing 
 syntax. (docs)
 https://github.com/django/django/pull/9086 - Refs #28595 -- Added 
 execute wrappers for database queries.
 https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
 support for conditional joins in

Re: ConnectionResetError in test_closes_connection_without_content_length

2017-09-20 Thread Zhiqiang Liu


>
> Yeah I believe it is a new test, so I can't test if it is working for 1.11.
>

I did get it to pass after adding except like this

 try:
conn.request('GET', '/example_view/', headers={'Connection': 
'keep-alive'})
response = conn.getresponse().read()
conn.request('GET', '/example_view/', headers={'Connection': 
'close'})
with self.assertRaises(RemoteDisconnected, msg='Server did not 
close the connection'):
try:
conn.getresponse()
except ConnectionAbortedError:
if sys.platform == 'win32':
self.skipTest('Ignore nondeterministic failure on 
Windows.')
except ConnectionResetError:
self.skipTest('Ignore failure.')

Tom because you said it varies by OS, so I am not sure which message to add 
so I just used 'Ignore failure', should I use something else? I can submit 
a simple PR for that.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5eafe681-9fa6-4bdb-a12e-433f51bcb2f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 2.0 release blockers

2017-09-20 Thread Tim Graham

completed today:
https://github.com/django/django/pull/7482 - Simplified URL routing syntax. 
(code)
https://github.com/django/django/pull/9072 - Simplified URL routing syntax. 
(docs)

https://github.com/django/django/pull/9100 

 
- Fixed #28488 -- Reallowed error handlers to access CSRF tokens.


todo:
https://github.com/django/django/pull/9086 - Refs #28595 -- Added execute 
wrappers for database queries.
https://github.com/django/django/pull/9081 - Fixed #27332 -- Added support 
for conditional joins in the ORM.

I hope to finish those two issues tomorrow and release the alpha on Friday 
or Saturday. Thanks to everyone who's been helping to work on and review 
the remaining PRs. :-)

On Monday, September 18, 2017 at 9:44:05 PM UTC-4, Tim Graham wrote:
>
> completed today:
> https://github.com/django/django/pull/6385 - Fixed #14370 -- Added 
> select2 widget for related object fields in admin.
> https://github.com/django/django/pull/7611 - Fixed #26608 -- Add support 
> for OVER-clause (window expressions).
>
> 
> todo:
> https://github.com/django/django/pull/7482 - Simplified URL routing 
> syntax. (code)
> https://github.com/django/django/pull/9072 - Simplified URL routing 
> syntax. (docs)
> https://github.com/django/django/pull/9086 - Refs #28595 -- Added execute 
> wrappers for database queries.
> https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
> support for conditional joins in the ORM.
>
> On Sunday, September 17, 2017 at 5:11:43 PM UTC-4, Florian Apolloner wrote:
>>
>> Looks good to me. 
>> https://github.com/django/django/commit/01c6a3e227b645e8dea97e9befecd23d1d3b8581
>>  
>> resulted in test failures, we might have to revert that.
>>
>> I do have to add https://github.com/django/django/pull/9100 to the mix, 
>> but since it is a bugfix we can easily do this after the alpha.
>>
>> cheers,
>> Florian
>>
>> On Sunday, September 17, 2017 at 1:30:01 AM UTC+2, Tim Graham wrote:
>>>
>>> Time to kickoff the progress tracker for the next major release!
>>>
>>> The 2.0 alpha is scheduled (according to 
>>> https://code.djangoproject.com/wiki/Version2.0Roadmap) for Monday, 
>>> September 18. Typically we've release the alpha a few days later to finish 
>>> up a few last minutes things. Here are the PRs on my list to polish off 
>>> before the alpha release. I'll send another update on Monday.
>>>
>>> https://github.com/django/django/pull/6385 - Fixed #14370 -- Added 
>>> select2 widget for related object fields in admin.
>>> https://github.com/django/django/pull/7611 - Fixed #26608 -- Add 
>>> support for OVER-clause (window expressions).
>>> https://github.com/django/django/pull/7482 - Simplified URL routing 
>>> syntax. (code)
>>> https://github.com/django/django/pull/9072 - Simplified URL routing 
>>> syntax. (docs)
>>> https://github.com/django/django/pull/9086 - Refs #28595 -- Added 
>>> execute wrappers for database queries.
>>> https://github.com/django/django/pull/9081 - Fixed #27332 -- Added 
>>> support for conditional joins in the ORM.
>>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/03cd2668-bde4-4570-835e-0cf1ac50d72a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

New Feature: Allow password reset token to expire in under a day

2017-09-20 Thread Zhiqiang Liu

I need general consensus on how to proceed with supporting password expire 
time to be under a day. Currently it is not possible because we use 
PASSWORD_RESET_TIMEOUT_DAYS.

In ticket 28622  we have two 
options. 

One is to continue to use the same setting PASSWORD_RESET_TIMEOUT_DAYS, but 
change the value to non-integer (such as timedelta) so we can send hours, 
minutes, etc to it.

The other one is to create a new setting like PASSWORD_RESET_TIMEOUT which 
takes seconds.To support backward compatibility, I think we should keep 
PASSWORD_RESET_TIMEOUT_DAYS and its default value of 3. Only use 
PASSWORD_RESET_TIMEOUT when provided.

I'm unsure which one is better, so inputs are welcome.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c8e96008-eb95-4924-8e5e-9b02d6b90c99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ConnectionResetError in test_closes_connection_without_content_length

Re: ConnectionResetError in test_closes_connection_without_content_length

Re: status of 2.0 release blockers

Re: ConnectionResetError in test_closes_connection_without_content_length

Re: status of 2.0 release blockers

New Feature: Allow password reset token to expire in under a day

6 matches

Site Navigation

Mail list logo

Footer information