[issue20301] Correct docs for default access argument for DeleteKeyEx

[Justin Foo]

New submission from Justin Foo:

The default access for winreg.DeleteKeyEx is winreg.KEY_WOW64_64KEY (as per the 
function signature). This the documentation for Python 2.7 has this correct.

Reference: http://hg.python.org/cpython/file/2e32462e4832/PC/winreg.c#l1089

--
assignee: docs@python
components: Documentation
files: winreg.DeleteKeyEx.docs.patch
keywords: patch
messages: 208462
nosy: docs@python, jfoo
priority: normal
severity: normal
status: open
title: Correct docs for default access argument for DeleteKeyEx
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33544/winreg.DeleteKeyEx.docs.patch

___
Python tracker 

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

[issue20301] Correct docs for default access argument for DeleteKeyEx

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +brian.curtin, tim.golden
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue19906] Typo in urllib documentation

[Ezio Melotti]

Ezio Melotti added the comment:

I think that what the note was trying to say is that urlopen in Python 3 is 
equivalent to urllib2.urlopen in Python 2, so before switching to Python 3, 
people might want to move from urllib.urlopen to urllib2.urlopen.
Does the attached patch sound better?

--
Added file: http://bugs.python.org/file33545/issue19906.diff

___
Python tracker 

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

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

[Stefan Behnel]

Changes by Stefan Behnel :


--
nosy: +eli.bendersky, scoder

___
Python tracker 

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

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

[Stefan Behnel]

Stefan Behnel added the comment:

When you write "XML PI", do you mean the XML declaration? At least that's what 
Mark used in his original example.

ET avoids writing them out when they are not necessary, i.e. for UTF-8 
compatible encodings. IMHO that's perfectly ok and definitely not an incorrect 
behaviour.

As for processing instructions (what you used in your test case patch), making 
them appear in the tree by default would be a behavioural change that might 
break existing ET code.

Note that lxml keeps PIs in the tree by default, unless you configure its 
parser explicitly with "remove_pis=True".

There is also a "remove_comments=True" in lxml. ET simply discards comments 
when parsing IIRC.

http://lxml.de/parsing.html#parser-options

IMHO, both behaviours are ok, which lxml having a tendency towards keeping the 
data as it came in rather than trying to find the easiest possible way for the 
user to work with the tree. PIs and comments are a bit 'special' to work with.

A fix could be to add the two keyword arguments also to ET's parser, but make 
them default to True (as opposed to False in lxml), so that users can enable 
them at need.

--

___
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

[Larry Hastings]

Larry Hastings added the comment:

Here is the hopefully-final patch for this issue.  I incorporated the suggested 
changes from Zachary Ware.  Also I fixed some "cls" parameters that were 
leaking into the signatures.  I think this is ready for checkin!

--
Added file: 
http://bugs.python.org/file33546/larry.support.text_signature.on.more.types.diff.5.txt

___
Python tracker 

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

[issue20293] pydoc fails with the "unspecified" default value

[Larry Hastings]

Larry Hastings added the comment:

Closing.  Reopen it if you get a reproducible test case with a fresh checkout 
of trunk.

--
resolution:  -> works for me
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

[issue20295] imghdr add openexr support

[Martin Vignali]

Martin Vignali added the comment:

New patch with formatting correction and documentation update.

I'm not sure about the place of the versionadded directive in the documentation.

--
Added file: http://bugs.python.org/file33547/img_hdr_exr_2.patch

___
Python tracker 

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

[issue20300] Argument Clinic raises exception for custom converter with default

[Roundup Robot]

Roundup Robot added the comment:

New changeset cc53c49d38c8 by Larry Hastings in branch 'default':
Issue #20300: Fix exception when setting conversion class member "default"
http://hg.python.org/cpython/rev/cc53c49d38c8

--
nosy: +python-dev

___
Python tracker 

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

[issue20300] Argument Clinic raises exception for custom converter with default

[Larry Hastings]

Larry Hastings added the comment:

Thanks for the report.  It was an easy fix.

That said, I can't say I'm excited by the idea of a custom converter with a 
built-in default value.  I hope you know what you're doing!

--
assignee:  -> larry
components: +Demos and Tools -Build
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

[issue17481] inspect.getfullargspec should use __signature__

[Terry J. Reedy]

Terry J. Reedy added the comment:

The relevant code in CallTips.py is
  argspec = ""
  if hasattr(ob, '__call__'):
...
if isinstance(fob, (types.FunctionType, types.MethodType)):
  argspec = inspect.formatargspec(*inspect.getfullargspec(fob))

So I want to broaden the second condition (or remove it), but if it returns 
something .formatargspec cannot digest, the outer call will have to be 
conditioned. My impression is that str(signature object) returns pretty much 
what .formatargspec does, but I have not experimented yet.

My #20122 patch moves currently commented out tests in CallTips.py that use the 
above to test_calltips.py. I will commit as soon as I test on 3.4. Until then, 
getfullargspec is not being used in the Idle test suite.

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Larry Hastings]

Larry Hastings added the comment:

I just want to mention, while we're all thinking about this stuff: I plan to 
enhance the Signature object to reflect "optional groups".  Right now Signature 
objects cannot express parameters that are optional but don't have a published 
default.  (e.g. a string parameter for a builtin having a default of NULL).  A 
lot of these are being converted using optional groups, and I want to make it 
at least possible for user code to introspect those functions and understand 
that those are optional parameters.

My original plan was to add a "group" member, containing an arbitrary 
identifier of the "group" this parameter belongs to.  I'm not sure that's 
sufficient; I may also need a "parent_group" parameter, or something like that, 
to represent the group that this group is nested in.  I'm still thinking about 
it.  But I'm hoping to get to this in the next two or three days.

--

___
Python tracker 

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

[issue20295] imghdr add openexr support

[SilentGhost]

SilentGhost added the comment:

Martin, it would be better if you do the check the way it's done in test_rast: 
h.startswith(b'\x76\x2f\x31\x01')

Otherwise, you need to check that that h has at least 4 elements (if it doesn't 
you'll get an IndexError).

--
nosy: +SilentGhost

___
Python tracker 

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

[issue20300] Argument Clinic raises exception for custom converter with default

[Roundup Robot]

Roundup Robot added the comment:

New changeset d0e2437136f5 by Larry Hastings in branch 'default':
Improve fix for issue #20300.
http://hg.python.org/cpython/rev/d0e2437136f5

--

___
Python tracker 

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

[issue3907] "for line in file" doesn't work for pipes

[Francis Moreau]

Francis Moreau added the comment:

Sorry for reopening this bug, but I agree with the OP, and I can still see the 
exact same behaviour on python 2.7.6 (archlinux).

At least, the documentation should clarify that doing "for line in file" is not 
strictly equivalent to the "readline" way regarding to the buffering policy 
used with pipes.

I'm also dubious about the buffering optimisation for the pipe case but 
readline() documentation should state that it will never use such buffering 
mechanism so we can safely use it when dealing with pipe.

Thanks

--
nosy: +fmoreau

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Nick Coghlan]

Nick Coghlan added the comment:

Sounds reasonable - we'll need that to convert range() and slice()
anyway (I totally failed at finding time to look at the builtins this
weekend, but I'd still like to handle those before the 3rd beta).

An alternative would be to actually add "ParameterGroup" as a new
class that contains parameters (assuming tuple isn't sufficient), so
the structure of the parameters more directly matches the underlying
signature.

--

___
Python tracker 

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

[issue20302] Argument Clinic: meaningful names for group flags

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Currently flags for optional groups are named as group_left_N and  
group_right_N. It will be better if they have names use_param, 
use_param1_param2, etc. E.g. following declaration:

/*[clinic input]
curses.window.addstr

self: self(type="PyCursesWindowObject *")
[
y: int
Y-coordinate.
x: int
X-coordinate.
]

str: object
String to add.

[
attr: long
Attributes for the character.
]
/

[clinic start generated code]*/

Should produce signature:

static PyObject *
curses_window_addstr_impl(PyCursesWindowObject *self, int use_x_y, int y, int 
x, PyObject *str, int use_attr, long attr)

(Existing non-clinicalized code use use_xy and use_attr flags).
This will make the code a little cleaner.

--
components: Build, Demos and Tools
messages: 208476
nosy: larry, serhiy.storchaka
priority: low
severity: normal
stage: needs patch
status: open
title: Argument Clinic: meaningful names for group flags
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue20293] pydoc fails with the "unspecified" default value

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I just built from a new clone of trunk (last revision is d0e2437136f5), and I 
still get the error.

--
resolution: works for me -> 
stage: committed/rejected -> 
status: closed -> open

___
Python tracker 

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

[issue20303] Argument Clinic: optional groups

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

This is very very low priority issue. Currently Argument Clinic can't process 
following declaration:
/*[clinic input]
curses.window.chgat

self: self(type="PyCursesWindowObject *")
[
y: int
Y-coordinate.
x: int
X-coordinate.
]

[
num: int
Number of characters.
]

attr: long
Attributes for the character.
/

[clinic start generated code]*/

This stops three methods in the curse module to be converted to Argument Clinic.

--
components: Build, Demos and Tools
messages: 208478
nosy: larry, serhiy.storchaka
priority: low
severity: normal
status: open
title: Argument Clinic: optional groups
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue20298] json library needs a non-strict option to decode single-quoted strings

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +ezio.melotti, pitrou, rhettinger
versions: +Python 3.5

___
Python tracker 

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

[issue20298] json library needs a non-strict option to decode single-quoted strings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think this is just not JSON. Try to use YAML parsers.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue19974] tarfile doesn't overwrite symlink by directory

[Vajrasky Kok]

Vajrasky Kok added the comment:

Ah, thanks for the review, Serhiy. My bad. There is no underlying bug of tar. I 
was confused by the behaviour of tar which is converting the absolute path to 
relative path.

So, adding '/home/user/dir/file' to tar when you are in '/home/user/dir' then 
extracting it in the same place, you'll get:
'/home/user/dir/home/user/dir/file'.

I thought it was a bug. But this is what it is supposed to be. I see that 
tarfile module is mimicking GNU tar behaviour.

This is the updated patch.

--
Added file: 
http://bugs.python.org/file33548/fix_tarfile_overwrites_symlink_v3.patch

___
Python tracker 

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

[issue20304] Argument Clinic: char convertor should use default values of type bytes

[Tal Einat]

New submission from Tal Einat:

For example, in `Object/stringlib/transmogrify.h`, the methods `ljust` and 
`rjust` have an argument named `fillchar` of type char. It's Python default 
value should be b' ', but the only way I've found to do that is by setting 
`py_default = b' '`.

--
components: Build, Demos and Tools
messages: 208481
nosy: larry, taleinat
priority: normal
severity: normal
status: open
title: Argument Clinic: char convertor should use default values of type bytes
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue19974] tarfile doesn't overwrite symlink by directory

[Vajrasky Kok]

Vajrasky Kok added the comment:

Serhiy commented, "I think we should remove targetpath in all cases. Not only 
when softlink is
extracted."

I already did that in my latest patch but I am a little bit wary of this 
behaviour.

--

___
Python tracker 

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

[issue20304] Argument Clinic: char convertor should use default values of type bytes

[Tal Einat]

Tal Einat added the comment:

Additionally, the char converter doesn't create valid c defaults. For example, 
I got " " instead of ' ' for fillchar, which has type char, so I had to 
manually set c_default = "' '".

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Yury Selivanov]

Yury Selivanov added the comment:

Larry,  

I saw your message on the tracker regarding adding support for parameters 
groups to the signature object. Would you mind if I join the discussion with my 
ideas of how this feature might be implemented? 

Yury

On Sunday, January 19, 2014 at 5:44 AM, Larry Hastings wrote:

> 
> Larry Hastings added the comment:
> 
> I just want to mention, while we're all thinking about this stuff: I plan to 
> enhance the Signature object to reflect "optional groups". Right now 
> Signature objects cannot express parameters that are optional but don't have 
> a published default. (e.g. a string parameter for a builtin having a default 
> of NULL). A lot of these are being converted using optional groups, and I 
> want to make it at least possible for user code to introspect those functions 
> and understand that those are optional parameters.
> 
> My original plan was to add a "group" member, containing an arbitrary 
> identifier of the "group" this parameter belongs to. I'm not sure that's 
> sufficient; I may also need a "parent_group" parameter, or something like 
> that, to represent the group that this group is nested in. I'm still thinking 
> about it. But I'm hoping to get to this in the next two or three days.
> 
> --
> 
> ___
> Python tracker mailto:rep...@bugs.python.org)>
> 
> ___

--
nosy: +Yury.Selivanov

___
Python tracker 

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

[issue20193] Derby: Convert the zlib, _bz2 and _lzma modules to use Argument Clinic

[Nadeem Vawda]

Nadeem Vawda added the comment:

The patches for bz2 and lzma look good to me, aside from one nit for lzma.

--

___
Python tracker 

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

[issue20305] Android's incomplete locale.h implementation prevents compilation

[Shiz]

New submission from Shiz:

As a result of Android's relatively incomplete locale.h implementation[1], some 
functions are not defined and some standard structs are lacking fields (e.g. 
decimal_point, thousand_sep).
This prevents proper cross-compilation using the Android NDK[2] from succeeding.

Attached is a patch which works around the various issues posed by Android's 
locale.h implementation, mainly involving falling back to default locale 
values, causing compilation in that department for the author to succeed.

[1]: https://groups.google.com/forum/#!topic/android-ndk/PBK4KkRpDoU
[2]: https://developer.android.com/tools/sdk/ndk/index.html

--
components: Cross-Build
files: Python-3.4.0tip-workaround-android-locale-issues.patch
keywords: patch
messages: 208486
nosy: shiz
priority: normal
severity: normal
status: open
title: Android's incomplete locale.h implementation prevents compilation
type: compile error
versions: Python 3.4
Added file: 
http://bugs.python.org/file33549/Python-3.4.0tip-workaround-android-locale-issues.patch

___
Python tracker 

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

[issue20305] Android's incomplete locale.h implementation prevents cross-compilation

[Shiz]

Changes by Shiz :


--
title: Android's incomplete locale.h implementation prevents compilation -> 
Android's incomplete locale.h implementation prevents cross-compilation

___
Python tracker 

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

[issue20305] Android's incomplete locale.h implementation prevents cross-compilation

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +lemburg, loewis

___
Python tracker 

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

[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail

[Shiz]

New submission from Shiz:

As the title states, mkpwent() in pwdmodule.c accesses `pw_gecos`, which is not 
defined for struct passwd in Bionic, Android's C library.

Attached is a patch that works around the issue by setting the field to None on 
Android.

--
components: Cross-Build
files: Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch
keywords: patch
messages: 208487
nosy: shiz
priority: normal
severity: normal
status: open
title: Lack of pw_gecos field in Android's struct passwd causes 
cross-compilation for the pwd module to fail
type: compile error
versions: Python 3.4
Added file: 
http://bugs.python.org/file33550/Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch

___
Python tracker 

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

[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail

[Shiz]

New submission from Shiz:

Bionic, Android's C library, fails to expose the SYS_* constants used for the 
syscall(1) interface, which causes compilation of the _posixsubprocess module 
to fail as it directly attempts to call SYS_getdents64.

Attached is an experimental patch that manually defines SYS_getdents64 from 
Bionic's internals.

--
components: Cross-Build
files: Python-3.4.0tip-expose-SYS_getdents64-on-android.patch
keywords: patch
messages: 208488
nosy: shiz
priority: normal
severity: normal
status: open
title: Android's failure to expose SYS_* system call constants causes 
_posixsubprocess cross-compilation to fail
type: compile error
versions: Python 3.4
Added file: 
http://bugs.python.org/file33551/Python-3.4.0tip-expose-SYS_getdents64-on-android.patch

___
Python tracker 

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

[issue20305] Android's incomplete locale.h implementation prevents cross-compilation

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I'd be +1 on such a patch if we were to officially support Android, but we'd 
need a volunteer to champion for this (which would be a good thing, IMO).

Otherwise, such changes need to be maintained externally.

--

___
Python tracker 

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

[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail

[Shiz]

Shiz added the comment:

I of course meant the syscall(2) interface, not syscall(1).

--

___
Python tracker 

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

[issue19990] Add unittests for imghdr module

[Claudiu.Popa]

Claudiu.Popa added the comment:

Hello. Here's a new version which uses real image files as testing data.

--
Added file: http://bugs.python.org/file33552/test_imghdr_2.patch

___
Python tracker 

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

[issue19997] imghdr.what doesn't accept bytes paths

[Claudiu.Popa]

Claudiu.Popa added the comment:

Updated patch to use real image files from issue #19990.

--
Added file: http://bugs.python.org/file33553/imghdr_bytes.patch

___
Python tracker 

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

[issue19906] Typo in urllib documentation

[Claudiu.Popa]

Claudiu.Popa added the comment:

Yep, it sounds better. There's an additional warning in urllib.urlopen which 
states a similar thing:

warnpy3k("urllib.urlopen() has been removed in Python 3.0 in "
 "favor of urllib2.urlopen()", stacklevel=2)

--

___
Python tracker 

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

[issue19776] Provide expanduser() on Path objects

[Claudiu.Popa]

Claudiu.Popa added the comment:

Antoine, is this feature still wanted?

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Terry J. Reedy]

Terry J. Reedy added the comment:

Yuri, I am sure your ideas for enhancing signature objects would be welcome. 
Either a new issue or a thread on pydev or python-ideas lists would be best.

When responding by email, please snip the quotation and footer, except possibly 
a line of the quoted message.

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Yury Selivanov]

Yury Selivanov added the comment:

Terry,

Thanks. 

> When responding by email, please snip the quotation and footer, except 
> possibly a line of the quoted message.

My email client played an evil (and a bit embarrassing) trick with me, showing 
Larry's name without an actual email address, which was 
"rep...@bugs.python.org". Won't happen again.

--

___
Python tracker 

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

[issue20294] Argument Clinic: add support for __init__

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Larry, now I can use Argument Clinic in the __init__ methods. But 
there is one problem.

Docstring generated for the __init__ method contains the "__init__" name in the 
signature. Therefore it can't be used as class docstring. On other hand, the 
compiler complains of not used __init__ docstring.

--

___
Python tracker 

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

[issue20295] imghdr add openexr support

[Martin Vignali]

Martin Vignali added the comment:

You're right, i make the correction, in a new patch.

I make other tests, with official sample files : 
http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.4.0.tar.gz

--
Added file: http://bugs.python.org/file33554/img_hdr_exr_3.patch

___
Python tracker 

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

[issue20295] imghdr add openexr support

[Claudiu.Popa]

Claudiu.Popa added the comment:

Hi, Martin.

Please see issue19990, which tries to add unit tests for imghdr module. It 
would be nice if you could expand on it with an exr file, for your use case.

--
nosy: +Claudiu.Popa

___
Python tracker 

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

[issue18314] Have os.unlink remove junction points

[Kim Gräsman]

Kim Gräsman added the comment:

Thanks!

There's another thing I would appreciate having somebody else test: creating 
and removing junctions in a non-elevated prompt. I haven't been able to, my IT 
department has trouble understanding the value of least-privilege.

--

___
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

[Stefan Krah]

Stefan Krah added the comment:

MSG*1024 passes. I did not look at this issue: Would changing the value to 1024
invalidate the test?

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Larry Hastings]

New submission from Larry Hastings:

Boy was I surprised by this:

>>> class C: pass
... 
>>> import inspect
>>> inspect.signature(C)
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/larry/src/python/clinic_c_types_hacking/Lib/inspect.py", line 
1557, in signature
raise ValueError('callable {!r} is not supported by signature'.format(obj))
ValueError: callable  is not supported by signature

Why not?  C is a callable object.  If you can't find a __new__ or an __init__ 
in the class, its signature should be pretty predictable.

(It returns a signature if you add either a __new__, an __init__, or both.)

--
components: Library (Lib)
messages: 208502
nosy: brett.cannon, larry, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.Signature doesn't support user classes without __init__ or 
__new__
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue19990] Add unittests for imghdr module

[Martin Vignali]

Martin Vignali added the comment:

I made a simple exr file with the lib Exr (it's a half float ZIP16 RGBA file), 
in order to add real exr file to the unit test.
When use with the patch i made here http://bugs.python.org/issue20295 ,
this sample file return 'exr'.

Sorry, i don't know how to create an update version of your patch (i just start 
to use mercurial), so i just upload the sample.

--
nosy: +mvignali
Added file: http://bugs.python.org/file33555/python.exr

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Yury Selivanov]

Yury Selivanov added the comment:

Well, the current code looks for __init__ or __new__. The only ones it can find 
is the 'object.__init__' which are blacklisted, because they are in C.

The question is do (or will) 'object.__new__' or '__init__' have a signature 
defined with the clinic?

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Yury Selivanov]

Yury Selivanov added the comment:

> Otherwise we run the risk of introducing unexpected exceptions into 
> introspection code.

That's a good catch. I'll make a new patch, keeping the old implementation of 
getfullargsspec intact, and falling back to it if no signature can be found.

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Larry Hastings]

Larry Hastings added the comment:

Yury: fire away, either here or in a new issue as is best.  (Sorry, brain 
mildly fried, not sure what would be best issue-tracker hygiene.)

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Larry Hastings]

Larry Hastings added the comment:

__new__ and __init__ methods are very special.  They can't have signatures, 
because the mechanism we use to store the signatures won't work.  (We hide them 
as a special first line of the docstring, and __new__ and __init__ can't have 
custom docstrings.)

In my next patch for #20189,

inspect.signature(object)

will return a valid signature object.  But

class C: pass
inspect.signature(C)

still fails in that branch.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Yury Selivanov]

Yury Selivanov added the comment:

In this case it would probably be best to just special case classes that don't 
have __init__ or __new__ defined to return an empty signature without 
parameters.

I can also make a special case for object.__init__ and object.__new__ 
functions, if someone would want to introspect them directly.

--

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Yury Selivanov]

Yury Selivanov added the comment:

>> Otherwise we run the risk of introducing unexpected exceptions into 
>> introspection code.

> That's a good catch. I'll make a new patch, keeping the old implementation of 
> getfullargsspec intact, and falling back to it if no signature can be found.

Nick, while I was working on the second patch (writing a new unittest for it 
specifically), I realized, that it's not that easy to make the old version of 
"getfullargsspec" to spit out any exception that it doesn't currently do with 
the proposed 'getargsspec_01.patch'.

See, the old "getfullargsspec" does the following:

1. Check if the passed object is a function, with 'inspect.isfunction'. If not 
- throw a TypeError.  That behaviour is duplicated in the patch, so we are safe 
here.

2. Call on the object's __code__ '_getfullargs', which validates that the 
passed code object is a valid code object, and simply returns its attributes 
rearranged a bit.

Now, to have any exception in (2), we need: either a broken __code__ object, or 
something that is an instance of "types.FunctionType" (hence, defined in 
python) but doesn't have the "__code__" attribute. And that's kind of hard to 
achieve.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Larry Hastings]

Larry Hastings added the comment:

If we need a special case for user classes without __new__ or __init__, then do 
that.  But I wouldn't say we should special case object.__new__ and 
object.__init__.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Yury Selivanov]

Yury Selivanov added the comment:

Please take a look at the attached patch (signature_plain_cls_01.patch)

Now, the patch addresses two kind of classes:

class C: pass
and 
class C(type): pass

For metaclasses, signature will return a signature with three positional-only 
parameters - (name, bases, dct). [let's discuss this]

The patch doesn't address 'object' or 'type' objects directly, though, so 
'signature(object)' and 'signature(type)' are still a ValueError.

--
keywords: +patch
Added file: http://bugs.python.org/file33556/signature_plain_cls_01.patch

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Larry Hastings]

Larry Hastings added the comment:

inspect.signature(object) works fine in my (not yet posted) latest #20189 patch.

inspect.signature(type) doesn't work, because it's not clear what the signature 
for type should be.  There's the one-argument and three-argument approaches.  
This is technically true:

"(object_or_name, [bases, dict])"

However,
a) it's painful to look at,
b) I can't communicate the idea of an "optional group" in an inspect.Signature 
object right now (although I guess we're going to hash that out somewhere, 
which is good).

If we can agree on a good signature for inspect.signature(type), I can make it 
happen.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Yury Selivanov]

Yury Selivanov added the comment:

Couple of thoughts:

1. "(object_or_name, [bases, dict])" is a signature for the "type" function, 
and yes, on that we need to agree how it looks like. Maybe exactly as you 
proposed, as it is what it is after all.

2. For user-defined metaclasses without __init__ or __new__ (such as "class 
C(type)"), we can just return, IMO, "(name, bases, dict)", as, although, it is 
possible to call "C" with only one argument, it's hardly a good practice, and I 
doubt it very much that someone does such things.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Larry Hastings]

Larry Hastings added the comment:

Special cases aren't special enough to break the rules.  If the signature of a 
metaclass is "(object_or_name, [bases, dict])", then we must not special-case 
it to pretend that "(object)" works.  I agree it's a bad idea to actually *do* 
that, but there are best-practice principles at stake here.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Yury Selivanov]

Yury Selivanov added the comment:

When in doubt, import this ;)

Agree. So the best course would be: make a patch for plain classes (not 
metaclasses). Fix signatures for metaclasses without __init__/__new__ when we 
have groups support for parameters, so that we can have (obj_or_name, [bases, 
dict]) kind of signatures.

--

___
Python tracker 

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

[issue20308] inspect.Signature doesn't support user classes without __init__ or __new__

[Yury Selivanov]

Yury Selivanov added the comment:

Attached is a stripped down patch that special-cases classes without 
__init__/__new__. Not metaclasses, for that we can start a new issue.

--
Added file: http://bugs.python.org/file33557/signature_plain_cls_02.patch

___
Python tracker 

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

[issue17481] inspect.getfullargspec should use __signature__

[Yury Selivanov]

Yury Selivanov added the comment:

> Yury: fire away, either here or in a new issue as is best.  (Sorry, brain 
> mildly fried, not sure what would be best issue-tracker hygiene.)

Larry, I ended up with a relatively big core dump of my thoughts, so I decided 
to post it on python-dev. Let's discuss it there, and we can create an issue 
here once we decide something.

--

___
Python tracker 

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

[issue9521] xml.etree.ElementTree skips processing instructions when parsing

[Nikolaus Rath]

Nikolaus Rath added the comment:

No, I really mean XML processing instruction. I agree with you that the XML 
declaration is a non-issue, because there is no information lost: you know that 
you're going to write XML, and you manually specify the encoding. Thus it's 
trivial to add the correct XML declaration if desired.

The fact that PIs are not read, however, is a real problem. The XML spec 
requires that PIs MUST be passed trough (http://www.w3.org/TR/REC-xml/#sec-pi). 
Furthermore, ElementTree is designed to represent XML data, so writing out an 
ElementTree as XML and reading it back in must (in my opinionn not result in 
information loss. But currently it does:

>>> import xml.etree.ElementTree as ET
>>> import tempfile
>>> root = ET.Element('body', {'text': 'some text for the body'})
>>> root.insert(1, ET.ProcessingInstruction('do-something'))
>>> tree = ET.ElementTree(root)
>>> tmp = tempfile.NamedTemporaryFile()
>>> tree.write(tmp.name)
>>> tmp.seek(0)
0
>>> tree_copy = ET.parse(tmp.name)
>>> ET.dump(tree)

>>> ET.dump(tree_copy)


I think tree and tree_copy not having the some contents is a bug.

Regarding comments: personally I think that throwing away is not a good idea 
either. But this is allowed by the XML spec 
(http://www.w3.org/TR/REC-xml/#dt-comment). This should probably go in a 
separate bug report if someone is interested in it.

As for backwards compatibility: yes, this is a concern. The keyword argument 
would be a solution. On the other hand, I'm not sure that the default should be 
something that causes dataloss...?

lxml sounds like it's doing the right things. Is there some connection between 
lxml and etree that I'm not aware of, or did you just give it as an example of 
how a different library behaves?

--

___
Python tracker 

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

[issue19871] json module won't parse a float that starts with a decimal point

[Vajrasky Kok]

Vajrasky Kok added the comment:

Attached the patch to address Ezio Melotti's concern. Thanks for the review!

--
Added file: 
http://bugs.python.org/file33558/parse_non_valid_json_float_with_unit_test_v2.patch

___
Python tracker 

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

[issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed

[Nikolaus Rath]

Nikolaus Rath added the comment:

(adding the documentation experts from 
http://docs.python.org/devguide/experts.html to noisy in the hope to push this 
forward)

--
nosy: +eric.araujo, ezio.melotti, georg.brandl

___
Python tracker 

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

[issue6627] threading.local() does not work with C-created threads

[Nikolaus Rath]

Nikolaus Rath added the comment:

(adding the documentation and ctypes experts from 
http://docs.python.org/devguide/experts.html to noisy list in the hope to get 
this moving again.)

--
nosy: +belopolsky, eric.araujo, ezio.melotti, georg.brandl, meador.inge
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

___
Python tracker 

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

[issue15955] gzip, bz2, lzma: add option to limit output size

[Nikolaus Rath]

Nikolaus Rath added the comment:

Nadeem, did you have a chance to look at this again, or do you have any partial 
patch already?

If not, I'd like to try working on a patch.

--

___
Python tracker 

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

[issue6627] threading.local() does not work with C-created threads

[Roundup Robot]

Roundup Robot added the comment:

New changeset f4eade5df217 by Benjamin Peterson in branch '3.3':
document that a new Python thread context is created in ctypes callbacks 
(closes #6627)
http://hg.python.org/cpython/rev/f4eade5df217

New changeset 9cd2d7a3f9f2 by Benjamin Peterson in branch '2.7':
document that a new Python thread context is created in ctypes callbacks 
(closes #6627)
http://hg.python.org/cpython/rev/9cd2d7a3f9f2

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

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> 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

[issue20309] Class method descriptors are different between builtin and user classes

[Larry Hastings]

New submission from Larry Hastings:

I found something curious while experimenting with types tonight.

Everybody knows, if you access a descriptor in a class through the normal 
attribute-getting methods, you actually get the result of calling its '__get__' 
method.  If you want to get your hands on the descriptor itself, you can be 
sneaky and pull it out through the class's __dict__.

I did an experiment tonight, accessing a bunch of methods in a bunch of 
different ways.

The methods I tried were
  * an instance method,
  * a class method, and
  * a static method.

I accessed them
  * as an instance attribute,
  * as a class attribute, and
  * through the class __dict__.

And for each of the above, I tried
  * one user method and
  * one built-in method.

That's a total of eighteen methods tried (3x3x2).

For each one, I printed out whether or not it was callable.  I found the 
results startling: fifteen were, but three (!) were not.

All three that weren't were accessed through the class dict.  They were:
  * Class method, from builtin class ( dict.__dict__['fromkeys'] )
  * Static method, from user class
  * Static method, from builtin class ( str.__dict__['maketrans'] )

I find it strange that the static method descriptors aren't callable.
I find it *even stranger* that *one* of the class method descriptors isn't 
callable, but the other one is.

I guess a foolish consistency is the hobgoblin of my small mind, but... 
shouldn't all eighteen of these objects be callable?

Attached is the test harness I wrote.

(p.s. I attached you guys as nosy because I thought you might be interested.)

--
components: Interpreter Core
files: curious.py
messages: 208524
nosy: arigo, larry, ncoghlan, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: Class method descriptors are different between builtin and user classes
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33559/curious.py

___
Python tracker 

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

[issue20309] Class method descriptors are different between builtin and user classes

[Larry Hastings]

Larry Hastings added the comment:

I should add, I see the same results with current trunk and with my handy 
Python 3 (currently 3.3.1rc1, huh guess I'm behind).

--

___
Python tracker 

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

[issue20309] Not all descriptors are callable

[Larry Hastings]

Changes by Larry Hastings :


--
title: Class method descriptors are different between builtin and user classes 
-> Not all descriptors are callable

___
Python tracker 

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

[issue20310] Recommend using pprint for deterministic doctest

[Charles-Axel Dein]

New submission from Charles-Axel Dein:

I just thought that using pprint.pprint was an elegant solution to the 
non-deterministic order of repr(dict) in doctest. See for instance 
http://bugs.python.org/issue3332

Contrary to sorted(foo().items()):

- It provides a nice output that is exactly like a dict.
- It supports any number of nested dicts.
- It can be used in other cases as well to make doctests elegant.

--
assignee: docs@python
components: Documentation
files: pprint_doctest.patch
keywords: patch
messages: 208526
nosy: charlax, docs@python
priority: normal
severity: normal
status: open
title: Recommend using pprint for deterministic doctest
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33560/pprint_doctest.patch

___
Python tracker 

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

[issue12704] Language Reference: Clarify behaviour of yield when generator is not resumed

[Georg Brandl]

Georg Brandl added the comment:

Hmm, the yield statement is now basically the same as any expression statement 
-- just like a function call.  The only reason it's a separate grammar symbol 
is that otherwise yield expressions would have to be parenthesized.

Can the patch be updated to make this a bit clearer?  Otherwise I like the 
approach of moving the info to the expressions page.

--

___
Python tracker 

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