[issue6625] UnicodeEncodeError on pydoc's CLI

2014-01-13 Thread Berker Peksag 

Berker Peksag added the comment:

> I suppose this is a duplicate of #1065986.

Yes, it is. I created a test file from the tests in issue6625_pydoc.diff and 
ran it on the current 2.7 branch.

def foo():
u"""fooo bar
baz
\xfcnicode\u2026"""
return 42

def bar():
u"f\xfcr Elise"
return 11

--
nosy: +berker.peksag
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1185124] pydoc doesn't find all module doc strings

2014-01-13 Thread Akira Kitada 

Akira Kitada added the comment:

I tried pydoc_2.7.patch with the following test file and
found source_synopsis returns \x escaped string instead of \u escaped one.


# -*- coding: utf-8 -*-

u"""ツ"""

class Spam(object):
u"""ツ"""


>>> import utf8
>>> utf8.__doc__
u'\u30c4'
>>> print(utf8.__doc__)
ツ
>>> import pydoc
>>> pydoc.source_synopsis(file('utf8.py'))
u'\xe3\x83\x84'
>>> print pydoc.source_synopsis(file('utf8.py'))
ツ
>>> print pydoc.source_synopsis(file('utf8.py')).encode('latin-1')
ツ

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20237] Ambiguous sentence in document of xml package.

2014-01-13 Thread INADA Naoki 

New submission from INADA Naoki:

http://docs.python.org/3.3/library/xml.html#defused-packages

"The courses of action are recommended for any server code that parses 
untrusted XML data."

What this sentence means?
What "The courses" is?

--
assignee: docs@python
components: Documentation
messages: 208015
nosy: docs@python, naoki
priority: normal
severity: normal
status: open
title: Ambiguous sentence in document of xml package.
versions: Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20229] platform.py uses deprecated feature of plistlib

2014-01-13 Thread Serhiy Storchaka 

Serhiy Storchaka added the comment:

There is no need to indent any except the "pl = plistlib.load(f)" line.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz")

2014-01-13 Thread Martin Panter 

New submission from Martin Panter:

I am trying to create a tar file after opening it as a temporary file, and it 
seems to be writing truncated output when I use mode="w:gz". My workaround 
looks like it will be to use mode="w|gz" instead. It’s not clear what the 
difference is: am I losing anything practical by disallowing “random” seeking?

Simplified demonstration:

>>> from io import BytesIO; b = BytesIO()
>>> import tarfile; t = tarfile.open(fileobj=b, mode="w:gz")
>>> t._extfileobj
True
>>> type(t.fileobj)

>>> t.close()
>>> b.getvalue()
b'\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff'
>>> del t
>>> b.getvalue()
b"\x1f\x8b\x08\x00]\xb8\xd3R\x02\xff\xed\xc1\x01\r\x00\x00\x00\xc2\xa0\xf7Om\x0e7\xa0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x807\x03\x9a\xde\x1d'\x00(\x00\x00"

Looking at the code, the TarFile.close() method would not be closing the 
GzipFile object because of this condition:

if not self._extfileobj:
self.fileobj.close()

Perhaps it needs to also check if file compression is being used or something; 
I’m not familiar with the internals.

I did notice that the bug happens with Python 3.3.3 and 3.2.3, but not 2.7.5. 
Also, I do not see the issue when a file name is passed to tarfile.open() 
rather than a file object, nor do I see it with the bzip or XZ compressors, 
uncompressed tar creation, or the “special purposes” w|gz mode.

--
components: Library (Lib)
messages: 208017
nosy: vadmium
priority: normal
severity: normal
status: open
title: Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz")
type: behavior
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6625] UnicodeEncodeError on pydoc's CLI

2014-01-13 Thread Torsten Landschoff 

Torsten Landschoff added the comment:

I tested this as well and it seems to work now. :-) Thanks for fixing it!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4356] Add "key" argument to "bisect" module functions

2014-01-13 Thread Dima Tisnek 

Dima Tisnek added the comment:

I've worked around this in 2.6/2.7 like this:

class Arr:
def __getitem__(self, i):
return foo(i)  # your key function
def __len__(self):
return 1000  # your max index value

bisect.bisect(Arr(), value, ...)

--
nosy: +Dima.Tisnek

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20239] Allow repeated deletion of unittest.mock.Mock attributes

2014-01-13 Thread Michael Foord 

New submission from Michael Foord:

Reported as mock issue 221: http://code.google.com/p/mock/issues/detail?id=221

>>> from unittest.mock import Mock
>>> m = Mock()
>>> m.foo = 3
>>> del m.foo
>>> m.foo = 4
>>> del m.foo
Traceback (most recent call last):
  File "", line 1, in 
  File "/compile/py3k-cpython/Lib/unittest/mock.py", line 687, in __delattr__
raise AttributeError(name)
AttributeError: foo

Suggested change:

Previous:

   def __delattr__(self, name):
   if name in _all_magics and name in type(self).__dict__:
   delattr(type(self), name)
   if name not in self.__dict__:
   # for magic methods that are still MagicProxy objects and
   # not set on the instance itself
   return

   if name in self.__dict__:
   object.__delattr__(self, name)

   obj = self._mock_children.get(name, _missing)
   if obj is _deleted:
   raise AttributeError(name)
   if obj is not _missing:
   del self._mock_children[name]
   self._mock_children[name] = _deleted


Change:

   def __delattr__(self, name):
   if name in _all_magics and name in type(self).__dict__:
   delattr(type(self), name)
   if name not in self.__dict__:
   # for magic methods that are still MagicProxy objects and
   # not set on the instance itself
   return

   obj = self._mock_children.get(name, _missing)
   if name in self.__dict__:
   object.__delattr__(self, name)
   elif obj is _deleted:
   raise AttributeError(name)
   if obj is not _missing:
   del self._mock_children[name]
   self._mock_children[name] = _deleted


Incidentally the if ‘obj is not _missing’ line seems superfluous.

--
assignee: michael.foord
messages: 208019
nosy: michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow repeated deletion of unittest.mock.Mock attributes
type: behavior
versions: Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files

2014-01-13 Thread Vajrasky Kok 

Vajrasky Kok added the comment:

Here is the patch for _codecs module.

--
Added file: http://bugs.python.org/file33443/clinic_codecsmodule.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax

2014-01-13 Thread Jacek Szpot 

New submission from Jacek Szpot:

Just wanted to let you know that missing whitespace between "from" and a 
dot-prefixed name is not considered invalid:

from.foo import bar 

.. does not raise an error. Perhaps it should?

--
messages: 208022
nosy: maligree
priority: normal
severity: normal
status: open
title: Whitespace ignored in relative imports: from.package import something is 
valid syntax
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20137] Logging: RotatingFileHandler computes string length instead of byte representation length.

2014-01-13 Thread A. Libotean 

A. Libotean added the comment:

Sure, will come back shortly with a patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20136] Logging: StreamHandler does not use OS line separator.

2014-01-13 Thread A. Libotean 

A. Libotean added the comment:

Let me write also a test for this and come back with a reply.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz")

2014-01-13 Thread Serhiy Storchaka 

Changes by Serhiy Storchaka :


--
nosy: +lars.gustaebel, nadeem.vawda, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax

2014-01-13 Thread Eric V. Smith 

Eric V. Smith added the comment:

This is no different from other places in python where white space is optional. 
As long as the parser can tell the end of a token, there need not be white 
space before the next token.

For example:
>>> 1+2
3
>>> 1 + 2
3

However, if the parser cannot tell the end of a token, white space is required:
>>> 1.__add__
  File "", line 1
1.__add__
^
SyntaxError: invalid syntax
>>> 1 .__add__


We're not likely to add "required white space" after the "from" token.

[I realize that in a "whitespace required" language, this is a slightly odd 
statement!]

--
nosy: +eric.smith
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20238] Incomplete gzip output with tarfile.open(fileobj=..., mode="w:gz")

2014-01-13 Thread Serhiy Storchaka 

Serhiy Storchaka added the comment:

Thank you Martin for you report.

Here is a patch which fixes this issue.

--
assignee:  -> serhiy.storchaka
keywords: +patch
stage:  -> patch review
versions: +Python 3.4
Added file: http://bugs.python.org/file33444/tarfile_fobj_gz_close.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files

2014-01-13 Thread Vajrasky Kok 

Changes by Vajrasky Kok :


Removed file: http://bugs.python.org/file33443/clinic_codecsmodule.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20241] Bad reference to RFC in document of ipaddress?

2014-01-13 Thread INADA Naoki 

New submission from INADA Naoki:

http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Address.is_unspecified

> True if the address is unspecified. See RFC 5375 (for IPv4) or RFC 2373 
> (for IPv6).

RFC 5375 is "IPv6 Unicast Address Assignment Considerations".

--
assignee: docs@python
components: Documentation
messages: 208027
nosy: docs@python, naoki
priority: normal
severity: normal
status: open
title: Bad reference to RFC in document of ipaddress?
versions: Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files

2014-01-13 Thread Vajrasky Kok 

Changes by Vajrasky Kok :


Added file: http://bugs.python.org/file33445/clinic_codecsmodule.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20241] Bad reference to RFC in document of ipaddress?

2014-01-13 Thread INADA Naoki 

INADA Naoki added the comment:

Is it 5735 ?


Next sentence may be wrong, too.

> True if the address is otherwise IETF reserved.

Is it "True if the address is IETF reserved." ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18622] reset_mock on mock created by mock_open causes infinite recursion

2014-01-13 Thread Laurent De Buyst 

Laurent De Buyst added the comment:

The proposed patch does solve the infinite recursion bug, but a different 
problem appears when resetting the same mock multiple times: it only works the 
first time.

Using the patch as it stands:

>>> from unittest.mock import mock_open
>>> mo = mock_open()
>>> a = mo()
>>> mo.call_count
1
>>> mo.reset_mock()
>>> mo.call_count
0
>>> b = mo()
>>> mo.call_count
1
>>> mo.reset_mock()
>>> mo.call_count
1

And here from a version with an added print(visited) statement:

>>> from unittest.mock import mock_open
>>> mo = mock_open()
>>> a = mo()
>>> mo.call_count
1
>>> mo.reset_mock()
[]
[139803191795152]
[139803191795152, 139803181189008]
[139803191795152, 139803181189008, 139803213598416]
[139803191795152, 139803181189008, 139803213598416, 139803213652048]
[139803191795152, 139803181189008, 139803213598416, 139803213652048]
>>> mo.call_count
0
>>> b = mo()
>>> mo.call_count
1
>>> mo.reset_mock()
[139803191795152, 139803181189008, 139803213598416, 139803213652048, 
139803213598288]
>>> mo.call_count
1
>>> mo.reset_mock(visited=[])
[]
[139803191795152]
[139803191795152, 139803181189008]
[139803191795152, 139803181189008, 139803213598416]
[139803191795152, 139803181189008, 139803213598416, 139803213652048]
[139803191795152, 139803181189008, 139803213598416, 139803213652048]
>>> mo.call_count
0

As you can see, for some reason I don't quite grasp, the 'visited' parameter 
persists across calls to reset_mock(), meaning that the very first call does 
indeed reset it but subsequent calls do not.

As the last two calls show, one can force a reset by explicitly providing an 
empty list, but this is starting to become a change in API and not just a 
bugfix...

--
nosy: +Laurent.De.Buyst

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20206] email quoted-printable encoding issue

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset 4c5b1932354b by R David Murray in branch '3.3':
#20206, #5803: more efficient algorithm that doesn't truncate output.
http://hg.python.org/cpython/rev/4c5b1932354b

New changeset b6c3fc21286f by R David Murray in branch 'default':
Merge #20206, #5803: more efficient algorithm that doesn't truncate output.
http://hg.python.org/cpython/rev/b6c3fc21286f

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5803] email/quoprimime: encode and decode are very slow on large messages

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset 4c5b1932354b by R David Murray in branch '3.3':
#20206, #5803: more efficient algorithm that doesn't truncate output.
http://hg.python.org/cpython/rev/4c5b1932354b

New changeset b6c3fc21286f by R David Murray in branch 'default':
Merge #20206, #5803: more efficient algorithm that doesn't truncate output.
http://hg.python.org/cpython/rev/b6c3fc21286f

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20206] email quoted-printable encoding issue

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

Fixed.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5803] email/quoprimime: encode and decode are very slow on large messages

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

I've reviewed this and applied it to both 3.3 and 3.4 in order to fix issue 
20206.  Thanks, Serhiy.

--
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20242] logging style parameter does not work correctly

2014-01-13 Thread kespindler 

New submission from kespindler:

In Python 3.3, 3.4beta2, and bleeding edge (88411:e7d922d8ee03), the following 
occurs 

>>> import logging
>>> logging.basicConfig(style="{")
>>> logging.error("hello")
%(levelname)s:%(name)s:%(message)s


Of course, I would expect

ERROR:root:hello

to be output instead.

--
components: Library (Lib)
messages: 208035
nosy: kespindler
priority: normal
severity: normal
status: open
title: logging style parameter does not work correctly
type: behavior
versions: Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20242] logging style parameter does not work correctly

2014-01-13 Thread kespindler 

kespindler added the comment:

I created a patch that fixes this behavior for both { and $ style formats.

Previously, default format strings were not being set correctly for those 
styles. This patch ensures that the correct default_format string is used.

There is a minor "weirdness" issue that, due to there previously being 2 
different default format strings for % style formatting, some tests rely on 
one, and some tests rely on the other. My patch remains backwards compatible 
with both default styles of format strings.

This patch also includes test cases for behavior with the style keyword, which 
was not being tested before.

--
keywords: +patch
Added file: http://bugs.python.org/file33446/Issue20242.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20237] Ambiguous sentence in document of xml package.

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

It means that the package suggests what courses of action to take when parsing 
untrusted data.  I don't know how it goes about doing that, though, so we'll 
have to ask Christian to clarify.

--
assignee: docs@python -> 
nosy: +christian.heimes, r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20237] Ambiguous sentence in document of xml package.

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

s/courses of action/kinds of actions/ in my explanation, otherwise it might be 
just as confusing :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20236] Invalid inline markup in xml document.

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset fb1dd44d1f76 by R David Murray in branch '3.3':
#20236: Fix sphinx markup.
http://hg.python.org/cpython/rev/fb1dd44d1f76

New changeset 60163fc72017 by R David Murray in branch 'default':
Merge #20236: Fix sphinx markup.
http://hg.python.org/cpython/rev/60163fc72017

New changeset 3481c6f36e55 by R David Murray in branch '2.7':
#20236: Fix sphinx markup.
http://hg.python.org/cpython/rev/3481c6f36e55

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20236] Invalid inline markup in xml document.

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

Fixed, thanks.

--
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20221] #define hypot _hypot conflicts with existing definition

2014-01-13 Thread Tabrez Mohammed 

Changes by Tabrez Mohammed :


--
keywords: +patch
Added file: http://bugs.python.org/file33447/fix20221.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20242] logging style parameter does not work correctly

2014-01-13 Thread Ned Deily 

Changes by Ned Deily :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20229] platform.py uses deprecated feature of plistlib

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset cd728dc893c9 by Ned Deily in branch 'default':
Issue #20229: Avoid plistlib deprecation warning in platform.mac_ver().
http://hg.python.org/cpython/rev/cd728dc893c9

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14031] logging module cannot format str.format log messages

2014-01-13 Thread kespindler 

kespindler added the comment:

I came across this issue while fixing issue20242. This issue (14031) still 
exists and is a major source of annoyance and confusion, and I suggest 
re-opening it.

Specifying the "{" style, while still being forced to use % formatting in log 
statements is backward and incredibly confusing for a number of key reasons:

 - The `style` keyword accomplishes a single thing only, and that is changing 
the format specification of the output, which is specified once and never 
touched again. For the myriad log statements littered throughout a codebase, it 
has *absolutely* no effect.
 - This is incredibly misleading to users. Why would there be this parameter to 
basicConfig that does (next to) nothing? Furthermore, if I've specified the { 
style, **why** would I write my log statements using the % style.
 - It forces the user to keep using % style formatting. The documentation 
explicitly states that this is "old style" formatting, and "new style" should 
be used, (due to its many advantages). Why force the user to know two 
formatting styles?


I created a patch (with test cases) that allows for this functionality. The 
whole idea of this feature is giving users the choice, if their environment 
allows it, to use the new-style formatting. Users should not have to rely on 
the hack linked in the blog in order to achieve *exected* behavior!

--
keywords: +patch
nosy: +kespindler
Added file: http://bugs.python.org/file33448/issue14031.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20229] platform.py uses deprecated feature of plistlib

2014-01-13 Thread Ned Deily 

Changes by Ned Deily :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14031] logging module cannot format str.format log messages

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

The reason is simple: in the general case you do not control all of the 
statements that produce log messages.  Some of them come from 3rd party library 
code.

Perhaps the documentation needs to be clarified on this point, and document the 
technique mentioned in the blog post Vinay linked to?  Or perhaps some 
pre-built wrappers can be provided in 3.5?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20243] ReadError when open a tarfile for writing

2014-01-13 Thread Serhiy Storchaka 

New submission from Serhiy Storchaka:

ReadError can be raised when open a tarfile in write mode (e.g. 'w:gz'). Here 
is a patch wish a test. In additional it rewrites the handling errors in 
gzopen() which is too complicated now. This complication is possible the cause 
of bugs #11513 and #20238.

--
assignee: serhiy.storchaka
components: Library (Lib)
files: tarfile_readerror_write_mode.patch
keywords: patch
messages: 208044
nosy: georg.brandl, lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: ReadError when open a tarfile for writing
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33449/tarfile_readerror_write_mode.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20243] ReadError when open a tarfile for writing

2014-01-13 Thread Serhiy Storchaka 

Changes by Serhiy Storchaka :


--
dependencies: +Incomplete gzip output with tarfile.open(fileobj=..., 
mode="w:gz")

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14031] logging module cannot format str.format log messages

2014-01-13 Thread kespindler 

kespindler added the comment:

I definitely do recognize that important case. I think the proper solution,
however, to that is make a very clear warning in the documentation that
changing the style might affect the logging of 3rd party tools. Those users
would probably have to use the % style formatting, which continues to work
exactly as always. I'd also note, this issue is largely related to the
`basicConfig` command. Anybody using significant 3rd party tools is likely
using a more complicated solution. In that case, this patch gives them the
flexibility to specify both LogRecords and the Formatter in whichever way
they desire.

The problem with leaving the behavior as is is that currently the style
keyword is effectively useless and grossly misleading to users.

Furthermore, the documentation makes reference to the ability to use new
style formats. From Logging HOWTO:

> As you can see, merging of variable data into the event description
message uses the old, %-style of string formatting. This is for backwards
compatibility: the logging package pre-dates newer formatting options such
as str.format() and string.Template. **These newer formatting options are
supported, but exploring them is outside the scope of this tutorial.**

This interpretation is the most logical interpretation of the style
keyword. Again, the format string is used once and is of comparative little
consequence - there's no real need for changing its format. Log messages
are written many, many times, and so it makes sense to allow the user to
write them in the modern format.

If the behavior really cannot be changed, this patch does provide
subclasses to LogRecord that give the desired behavior. Technically these
can be used independently of the style keyword.

On Mon, Jan 13, 2014 at 11:48 AM, R. David Murray wrote:

>
> R. David Murray added the comment:
>
> The reason is simple: in the general case you do not control all of the
> statements that produce log messages.  Some of them come from 3rd party
> library code.
>
> Perhaps the documentation needs to be clarified on this point, and
> document the technique mentioned in the blog post Vinay linked to?  Or
> perhaps some pre-built wrappers can be provided in 3.5?
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20244] Possible resources leak in tarfile.open()

2014-01-13 Thread Serhiy Storchaka 

Changes by Serhiy Storchaka :


--
dependencies: +ReadError when open a tarfile for writing

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20244] Possible resources leak in tarfile.open()

2014-01-13 Thread Serhiy Storchaka 

New submission from Serhiy Storchaka:

There are possible opened file leaks when unexpected error is occurred in 
tarfile.open for bzip2- or xz-compressed files (and gzip2-compressed in 2.7). 
Here is a patch. Unfortunately I have no tests.

--
assignee: serhiy.storchaka
components: Library (Lib)
files: tarfile_file_leak.patch
keywords: patch
messages: 208046
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Possible resources leak in tarfile.open()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33450/tarfile_file_leak.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14031] logging module cannot format str.format log messages

2014-01-13 Thread Vinay Sajip 

Vinay Sajip added the comment:

> The problem with leaving the behavior as is is that currently the
> style keyword is effectively useless and grossly misleading to users.

If you are referring to the style keyword in basicConfig, it merely sets the 
style of the Formatter used. That can certainly be made more explicit in the 
documentation.

There is a danger in assuming that you can associate a style with a LogRecord 
via a Logger, because there may be cases where a named logger is used by many 
different libraries (e.g. 'django.request' might be used by a number of Django 
middleware libraries). It may not be very common practice, but there is nothing 
preventing it.

The approach suggested also conflates the functionality of Formatters and 
Loggers, which could also be confusing.

> Users should not have to rely on the hack linked in the blog

I don't see what makes it a hack. Logging has allowed the usage of arbitrary 
objects (rather than just strings) for messages, from day one, by design, for 
this type of eventuality (amongst others).

> **These newer formatting options are supported, but exploring them
> is outside the scope of this tutorial.**

I will change this slightly by adding a cookbook recipe (based on the technique 
outlined in my blog post) and updating the above text to link to the cookbook 
recipe. I can also provide links from other parts of the documentation, where 
formatting is discussed, to point to the cookbook entry.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20242] logging style parameter does not work correctly

2014-01-13 Thread Vinay Sajip 

Vinay Sajip added the comment:

Thanks for this. The patch looks good, and I expect to implement it shortly.

--
assignee:  -> vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20242] logging style parameter does not work correctly

2014-01-13 Thread Vinay Sajip 

Vinay Sajip added the comment:

On further reflection, I will implement this slightly differently. The tests I 
will commit as is, except for stripping newlines before the comparison (to 
avoid worrying about differences in line separators across different 
platforms). However, the correct fix IMO is to add the default format strings 
to the _STYLES dict values: the effect should be the same.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20214] Argument Clinic rollup fixes

2014-01-13 Thread Larry Hastings 

Changes by Larry Hastings :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20189] inspect.Signature doesn't recognize all builtin types

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

Okay, life has gotten even more complicated.

In another issue (#20172) Zachary Ware pointed out that Argument Clinic needs 
to generate "self" parameters in the text string.  But this complicates life 
for inspect.Signature, which needs to not publish the "self" parameter when 
it's been bound.  I'm busy hacking up clinic.py to fix this right now and hope 
to have a patch later today.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows)

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

> Clinic should be adding 'self' to the signature,
> which should then be picked up by the __text_signature__
> parser, and used by inspect and pydoc.

This innocent little comment has derailed my whole day.  You're right, 'self' 
should be in the signature.  But not always!  And then in
inspect.Signature we need to strip it off for bound methods.

In case you're curious, this work is happening in a separate branch, and 
tracked in a different issue (#20189).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20242] logging style parameter does not work correctly

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset e7fcf0d8008f by Vinay Sajip in branch '3.3':
Issue #20242: Fixed basicConfig() format strings for the alternative formatting 
styles.
http://hg.python.org/cpython/rev/e7fcf0d8008f

New changeset c1605d24fb35 by Vinay Sajip in branch 'default':
Closes #20242: Merged fix from 3.3.
http://hg.python.org/cpython/rev/c1605d24fb35

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20136] Logging: StreamHandler does not use OS line separator.

2014-01-13 Thread Vinay Sajip 

Vinay Sajip added the comment:

Can you please attach a short test script which shows what you consider to be 
the failure case / incorrect behaviour?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20137] Logging: RotatingFileHandler computes string length instead of byte representation length.

2014-01-13 Thread Vinay Sajip 

Vinay Sajip added the comment:

Which encoding are you using, such that the difference in length between 
encoded and decoded messages is significant?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20189] inspect.Signature doesn't recognize all builtin types

2014-01-13 Thread Yury Selivanov 

Yury Selivanov added the comment:

> But this complicates life for inspect.Signature, which needs to not publish 
> the "self" parameter when it's been bound.

That's already supported, isn't it?

>>> str(inspect.signature(F.a))
'(self, a)'
>>> str(inspect.signature(F().a))
'(a)'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20189] inspect.Signature doesn't recognize all builtin types

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

Not for builtins.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20245] Check empty mode in TarFile.*open()

2014-01-13 Thread Serhiy Storchaka 

New submission from Serhiy Storchaka:

TarFile's *open() class methods checks the mode argument to raise helpful error:

>>> t = tarfile.TarFile.taropen('xxx.tar', 'q')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1589, in taropen
raise ValueError("mode must be 'r', 'a' or 'w'")
ValueError: mode must be 'r', 'a' or 'w'

But often this check doesn't catch empty mode.

>>> t = tarfile.TarFile.taropen('xxx.tar', '')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1590, in taropen
return cls(name, mode, fileobj, **kwargs)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1411, in __init__
self._mode = {"r": "rb", "a": "r+b", "w": "wb"}[mode]
KeyError: ''
>>> t = tarfile.TarFile.gzopen('xxx.tar', '')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1608, in gzopen
fileobj = gzip.GzipFile(name, mode + "b", compresslevel, fileobj)
  File "/home/serhiy/py/cpython/Lib/gzip.py", line 181, in __init__
fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
ValueError: Must have exactly one of create/read/write/append mode and at most 
one plus
>>> t = tarfile.TarFile.bz2open('xxx.tar', '')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1640, in bz2open
t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1590, in taropen
return cls(name, mode, fileobj, **kwargs)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1411, in __init__
self._mode = {"r": "rb", "a": "r+b", "w": "wb"}[mode]
KeyError: ''

Only xzopen() works correctly.

>>> t = tarfile.TarFile.xzopen('xxx.tar', '')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1653, in xzopen
raise ValueError("mode must be 'r' or 'w'")
ValueError: mode must be 'r' or 'w'

Here is a patch which fixes the mode argument checking.

--
assignee: serhiy.storchaka
components: Library (Lib)
files: tarfile_empty_mode.patch
keywords: patch
messages: 208057
nosy: lars.gustaebel, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Check empty mode in TarFile.*open()
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33451/tarfile_empty_mode.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20189] inspect.Signature doesn't recognize all builtin types

2014-01-13 Thread Stefan Krah 

Stefan Krah added the comment:

Another issue is that with the patch applied help() is broken for certain forms
of docstrings:

from decimal import *
>>> print(setcontext.__doc__)

setcontext(c) - Set a new default context.

>>> help(setcontext)
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/stefan/hg/cpython/Lib/_sitebuiltins.py", line 99, in __call__
return pydoc.help(*args, **kwds)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1792, in __call__
self.help(request)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1842, in help
else: doc(request, 'Help on %s:', output=self._output)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1578, in doc
pager(render_doc(thing, title, forceload))
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1571, in render_doc
return title % desc + '\n\n' + renderer.document(object, name)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 358, in document
if inspect.isroutine(object): return self.docroutine(*args)
  File "/home/stefan/hg/cpython/Lib/pydoc.py", line 1323, in docroutine
signature = inspect.signature(object)
  File "/home/stefan/hg/cpython/Lib/inspect.py", line 1551, in signature
raise ValueError(msg)
ValueError: no signature found for builtin function 

Perhaps this form of docstrings is discouraged (I used it because it looks nice
in pydoc), but nevertheless it might be present in third party modules.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20189] inspect.Signature doesn't recognize all builtin types

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

Here's an updated patch.  I tried to "do it right" which wound up being a huge 
amount of work in Clinic.  The actual change to inspect.Signature was really 
easy, once I understood everything.

The churn in the .c files is because Clinic now uses the self converter's type 
for the parsing function, and (obviously) because it's now generating "self" in 
the signatures as appropriate.

Fun trivia: the "self" parameter to a builtin is always a positional-only 
parameter, even if all other argument processing for the function is 
PyArg_ParseTupleAndKeywords.  I think this patch marks the first time 
inspect.Signature will ever mark a parameter as positional-only!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20189] inspect.Signature doesn't recognize all builtin types

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

> Another issue is that with the patch applied help() is broken for
> certain forms of docstrings:

Yeah.  We discussed this briefly in #19674.  I wanted to use a marker that 
wasn't The Convention That People Have Used For Decades but I felt overruled.  
I want to revisit it for precisely the reason you cite.

(I just realized, Sphinx autodoc is irrelevant, as if the string is legitimate 
it be stripped off the docstring anyway.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20202] ArgumentClinic howto: document change in Py_buffer lifecycle management

2014-01-13 Thread Ryan Smith-Roberts 

Ryan Smith-Roberts added the comment:

Even more imperative than my version. Excellent!

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20227] Argument Clinic: rename arguments in generated C?

2014-01-13 Thread Ryan Smith-Roberts 

Changes by Ryan Smith-Roberts :


--
nosy: +rmsr

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20246] buffer overflow in socket.recvfrom_into

2014-01-13 Thread Ryan Smith-Roberts 

New submission from Ryan Smith-Roberts:

recvfrom_into fails to check that the supplied buffer object is big enough for 
the requested read and so will happily write off the end.

I will attach patches for 3.4 and 2.7, I'm not familiar with the backporting 
procedure to go further but all versions since 2.5 have this bug and while very 
highly unlikely it's technically remotely exploitable.

Quickie trigger script, crash on interpreter exit:

- BEGIN SEGFAULT -

import socket
r, w = socket.socketpair()
w.send(b'X' * 1024)
r.recvfrom_into(bytearray(), 1024)

--
components: Extension Modules
messages: 208062
nosy: rmsr
priority: normal
severity: normal
status: open
title: buffer overflow in socket.recvfrom_into
type: crash
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20246] buffer overflow in socket.recvfrom_into

2014-01-13 Thread Ryan Smith-Roberts 

Changes by Ryan Smith-Roberts :


Added file: 
http://bugs.python.org/file33453/recvfrom_into_buffer_overflow_2.7.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20246] buffer overflow in socket.recvfrom_into

2014-01-13 Thread Ryan Smith-Roberts 

Changes by Ryan Smith-Roberts :


--
keywords: +patch
Added file: 
http://bugs.python.org/file33452/recvfrom_into_buffer_overflow_3.4.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20247] Condition._is_owned is wrong

2014-01-13 Thread Antony Lee 

New submission from Antony Lee:

I believe that the implementation of Condition._is_owned is wrong, as mentioned 
here: https://mail.python.org/pipermail/python-list/2012-October/632682.html.  
Specifically, the two return values (True and False) should be inverted.

I guess this slipped through as this private function would only be called if 
one passed to a Condition object a (R)Lock-like object that doesn't define 
_is_owned.  (I noticed this when I tried to pass a custom-written reader-writer 
lock to a Condition object.)  Technically, the docs says that "If the lock 
argument is given and not None, it must be a Lock or RLock object", but in 
practice anything that defines acquire(), release() (and possibly _is_owned()) 
should work.

--
components: Library (Lib)
messages: 208063
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Condition._is_owned is wrong

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows)

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

Filed comments on everything.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20227] Argument Clinic: rename arguments in generated C?

2014-01-13 Thread Ryan Smith-Roberts 

Ryan Smith-Roberts added the comment:

Georg Brandl wrote:
> Although now is a good time to ensure sensible argument names (I 
> usually look at the docs to find the documented ones), so that 
> switching the function to keyword arg support is basically just a 
> removal of '/'

I started doing this almost without thinking while converting the socket 
module. I think matching argument names against the online docs is an important 
part of AC conversion that has gone unaddressed. I am working on an email to 
python-dev about making it explicit policy.

A way to avoid code churn that just occurred to me is to retain existing 
variable declarations (for users of PyArgs_ParseTuple) and initialize them 
using the new function arguments. For the self argument and METH_O users one 
can introduce a new declaration similarly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20246] buffer overflow in socket.recvfrom_into

2014-01-13 Thread R. David Murray 

R. David Murray added the comment:

Everything before 2.7 is already out of even security maintenance, so you've 
already checked off everything it will get fixed in.

--
nosy: +r.david.murray
type: crash -> security

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20248] docs: socket.recvmsg{,_into} are keword-compatible

2014-01-13 Thread Ryan Smith-Roberts 

New submission from Ryan Smith-Roberts:

The docs indicate their arguments are positional-only. Trivial patch attached.

--
assignee: docs@python
components: Documentation
files: docs_socket_recvmsg_args.patch
keywords: patch
messages: 208067
nosy: docs@python, rmsr
priority: normal
severity: normal
status: open
title: docs: socket.recvmsg{,_into} are keword-compatible
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33454/docs_socket_recvmsg_args.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20248] docs: socket.recvmsg{,_into} are keword-compatible

2014-01-13 Thread Ryan Smith-Roberts 

Ryan Smith-Roberts added the comment:

Never mind, it's actually recvfrom{,_into}. Sigh.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20248] docs: socket.recvmsg{,_into} are keword-compatible

2014-01-13 Thread Benjamin Peterson 

Changes by Benjamin Peterson :


--
resolution:  -> invalid

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20249] test_posix.test_initgroups fails when running with no supplementary groups

2014-01-13 Thread Chris Angelico 

New submission from Chris Angelico:

When tests are run from an Upstart job in a minimal environment, 
test_posix.test_initgroups fails as it attempts to find the max() of an empty 
list of supplementary groups.

Problem sighted with 2.7, 3.3, and 3.x branches. Patch derived from 3.x 
(default branch), applies cleanly to 2.7 and 3.3 as well.

--
components: Tests
files: test_posix.patch
keywords: patch
messages: 208069
nosy: Rosuav
priority: normal
severity: normal
status: open
title: test_posix.test_initgroups fails when running with no supplementary 
groups
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33455/test_posix.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20246] buffer overflow in socket.recvfrom_into

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset 87673659d8f7 by Benjamin Peterson in branch '2.7':
complain when nbytes > buflen to fix possible buffer overflow (closes #20246)
http://hg.python.org/cpython/rev/87673659d8f7

New changeset 715fd3d8ac93 by Benjamin Peterson in branch '3.1':
complain when nbytes > buflen to fix possible buffer overflow (closes #20246)
http://hg.python.org/cpython/rev/715fd3d8ac93

New changeset 9c56217e5c79 by Benjamin Peterson in branch '3.2':
complain when nbytes > buflen to fix possible buffer overflow (closes #20246)
http://hg.python.org/cpython/rev/9c56217e5c79

New changeset 7f176a45211f by Benjamin Peterson in branch '3.3':
merge 3.2 (#20246)
http://hg.python.org/cpython/rev/7f176a45211f

New changeset ead74e54d68f by Benjamin Peterson in branch 'default':
merge 3.3 (#20246)
http://hg.python.org/cpython/rev/ead74e54d68f

New changeset 37ed85008f51 by Benjamin Peterson in branch 'default':
merge 3.3 (#20246)
http://hg.python.org/cpython/rev/37ed85008f51

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20250] defaultdict docstring neglects the *args

2014-01-13 Thread Andrew Barnert 

New submission from Andrew Barnert:

The docstring for defaultdict shows only a single argument, default_factory, 
and gives no clue that you can pass additional arguments:

|  defaultdict(default_factory) --> dict with default factory
|
|  The default factory is called without arguments to produce
|  a new value when a key is not present, in __getitem__ only.
|  A defaultdict compares equal to a dict with the same items.

The docs, by contrast, say:

> class collections.defaultdict([default_factory[, ...]])

> … The first argument provides the initial value for the default_factory 
> attribute; it defaults to None. All remaining arguments are treated the same 
> as if they were passed to the dict constructor, including keyword arguments.

I think the docstring should have the same information—or at least have the 
correct signature, which would hopefully be enough to prompt people to look at 
the docs.

I'm not sure whether the correct signature is (default_factory, *args, 
**kwargs), like OrderedDict, or (default_factory[, ...]), like deque, but I 
don't think either one would confuse anyone.

--
components: Library (Lib)
files: collectionsmodule.diff
keywords: patch
messages: 208071
nosy: abarnert
priority: normal
severity: normal
status: open
title: defaultdict docstring neglects the *args
type: enhancement
Added file: http://bugs.python.org/file33456/collectionsmodule.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20250] defaultdict docstring neglects the *args

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset d46bf7835b45 by Benjamin Peterson in branch '3.3':
correct defaultdict signature in docstring (closes #20250)
http://hg.python.org/cpython/rev/d46bf7835b45

New changeset 950f1e83bb56 by Benjamin Peterson in branch '2.7':
correct defaultdict signature in docstring (closes #20250)
http://hg.python.org/cpython/rev/950f1e83bb56

New changeset 49ae53150ee0 by Benjamin Peterson in branch 'default':
merge 3.3 (#20250)
http://hg.python.org/cpython/rev/49ae53150ee0

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20251] socket.recvfrom_into crash with empty buffer

2014-01-13 Thread Vajrasky Kok 

New submission from Vajrasky Kok:

>>> import socket
>>> r, w = socket.socketpair()
>>> w.send(b'X' * 1024)
1024
>>> buffer = bytearray()
>>> r.recvfrom_into(buffer)
python: /home/sky/Code/python/cpython3.4/Modules/socketmodule.c:2867: 
sock_recvfrom_into: Assertion `buf != 0 && buflen > 0' failed.
Aborted (core dumped)

Attached the fix to handle the empty bytearray gracefully. The fix is for 
Python 3.4.

--
components: Extension Modules
files: recv_from_into_empty_byte_array.patch
keywords: patch
messages: 208073
nosy: benjamin.peterson, vajrasky
priority: normal
severity: normal
status: open
title: socket.recvfrom_into crash with empty buffer
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: 
http://bugs.python.org/file33457/recv_from_into_empty_byte_array.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20251] socket.recvfrom_into crash with empty buffer

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset 8712efe02dcc by Benjamin Peterson in branch '3.3':
remove overly strict assertion (closes #20251)
http://hg.python.org/cpython/rev/8712efe02dcc

New changeset ab9556830560 by Benjamin Peterson in branch 'default':
merge 3.3 (#20251)
http://hg.python.org/cpython/rev/ab9556830560

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20251] socket.recvfrom_into crash with empty buffer

2014-01-13 Thread Roundup Robot 

Roundup Robot added the comment:

New changeset 3881211cbb19 by Benjamin Peterson in branch '2.7':
remove overly strict assertion (closes #20251)
http://hg.python.org/cpython/rev/3881211cbb19

New changeset 1885e1768ff9 by Benjamin Peterson in branch '2.7':
add test for #20251
http://hg.python.org/cpython/rev/1885e1768ff9

New changeset 6ea64dcfb5e2 by Benjamin Peterson in branch '3.3':
add test for #20251
http://hg.python.org/cpython/rev/6ea64dcfb5e2

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20252] Argument Clinic howto: small typo in y# translation

2014-01-13 Thread Ryan Smith-Roberts 

New submission from Ryan Smith-Roberts:

type -> types

--
assignee: docs@python
components: Documentation
files: argument_clinic_howto_y-hash.patch
keywords: patch
messages: 208076
nosy: docs@python, larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic howto: small typo in y# translation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33458/argument_clinic_howto_y-hash.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20252] Argument Clinic howto: small typo in y# translation

2014-01-13 Thread Larry Hastings 

Larry Hastings added the comment:

Same bug for 'y' too.  Will fix in a patch probably Tuesday.  Thanks for 
pointing it out!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20253] Typo in ipaddress document

2014-01-13 Thread INADA Naoki 

New submission from INADA Naoki:

> http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Network.broadcast_address

Wrong attribute name: s/host mask/hostmask/

--
assignee: docs@python
components: Documentation
messages: 208078
nosy: docs@python, naoki
priority: normal
severity: normal
status: open
title: Typo in ipaddress document
versions: Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20253] Typo in ipaddress document

2014-01-13 Thread Berker Peksag 

Changes by Berker Peksag :


--
nosy: +zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20172] Derby #3: Convert 67 sites to Argument Clinic across 4 files (Windows)

2014-01-13 Thread Zachary Ware 

Zachary Ware added the comment:

Sandbox repo updated.  It is currently using an older version of clinic; 
running current clinic on the winreg.c in the tip of the sandbox produces this 
traceback:

Traceback (most recent call last):
  File "Tools\clinic\clinic.py", line 2981, in 
sys.exit(main(sys.argv[1:]))
  File "Tools\clinic\clinic.py", line 2977, in main
parse_file(filename, output=ns.output, verify=not ns.force)
  File "Tools\clinic\clinic.py", line 1132, in parse_file
cooked = clinic.parse(raw)
  File "Tools\clinic\clinic.py", line 1082, in parse
parser.parse(block)
  File "Tools\clinic\clinic.py", line 2259, in parse
self.state(line)
  File "Tools\clinic\clinic.py", line 2633, in state_parameter_docstring
return self.next(self.state_parameter, line)
  File "Tools\clinic\clinic.py", line 2287, in next
self.state(line)
  File "Tools\clinic\clinic.py", line 2531, in state_parameter
value = eval(py_default)
  File "", line 1, in 
NameError: name 'winreg' is not defined

I'm not terribly sure about the error handling with the return converters, that 
will need some extra scrutiny.  I may have it completely wrong :).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20254] Duplicate bytearray test on test_socket.py

2014-01-13 Thread Vajrasky Kok 

New submission from Vajrasky Kok:

testRecvIntoArray is same as testRecvIntoBytearray.
testRecvFromIntoArray  is same as testRecvFromIntoBytearray.

Attached the patch to fix the tests.

--
components: Tests
files: fix_recv_from_into_array_test_socket.patch
keywords: patch
messages: 208079
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Duplicate bytearray test on test_socket.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: 
http://bugs.python.org/file33459/fix_recv_from_into_array_test_socket.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com