[issue2445] Use The CygwinCCompiler Under Cygwin

[Masayuki Yamamoto]

Masayuki Yamamoto added the comment:

CygwinCCompiler seems legacy code.
In v3.4 latest rivision, Distutils has made to work that is a patching to 
UnixCCompiler.
So, I have a think that doesn't need to use CygwinCCompiler to build on Cygwin.
I have upload a patch for UnixCCompiler.  The patch has modified from 
http://cygwin.org package.

Other big issues and patches for build on Cygwin:
#21085, #13756 -- compile error
#14598, #21124 -- C extension module

--
nosy: +masamoto
Added file: http://bugs.python.org/file39141/3.4-distutils-shlibext.patch

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Martin Falatic]

Martin Falatic added the comment:

There may be a more uniform way to do all this that I'm not aware of. 
root.tcl.call() and root.tk.call() would be most symmetric while not creating 
extraneous windows, but that's not an option for the former, thus the methods I 
ended up using look different for Tk and Tcl.

Whatever the output, a tuple (8,5,9) or string "8.5.9" (easily converted to a 
tuple) will be nice, hiding any disparate implementation details.

--

___
Python tracker 

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

[issue23728] binascii.crc_hqx() can return negative integer

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0ead02929df2 by Serhiy Storchaka in branch '3.4':
Issue #23728: binascii.crc_hqx() could return an integer outside of the range
https://hg.python.org/cpython/rev/0ead02929df2

New changeset abb86c6b11b2 by Serhiy Storchaka in branch 'default':
Issue #23728: binascii.crc_hqx() could return an integer outside of the range
https://hg.python.org/cpython/rev/abb86c6b11b2

New changeset 17702fd8ac0d by Serhiy Storchaka in branch '2.7':
Issue #23728: Added a test for binascii.crc_hqx().
https://hg.python.org/cpython/rev/17702fd8ac0d

--
nosy: +python-dev

___
Python tracker 

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

[issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function

[Roundup Robot]

Roundup Robot added the comment:

New changeset cd7d51b5c951 by Serhiy Storchaka in branch '2.7':
Issue #23842: os.major(), os.minor() and os.makedev() now support ints again.
https://hg.python.org/cpython/rev/cd7d51b5c951

New changeset 998d967b8a57 by Serhiy Storchaka in branch '3.4':
Issue #23842: Added tests for os.major(), os.minor() and os.makedev().
https://hg.python.org/cpython/rev/998d967b8a57

New changeset d477da6f287f by Serhiy Storchaka in branch 'default':
Issue #23842: Added tests for os.major(), os.minor() and os.makedev().
https://hg.python.org/cpython/rev/d477da6f287f

--
nosy: +python-dev

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Martin Falatic]

Martin Falatic added the comment:

"Works, using" = this works, it's what I'm using (was trying to be brief - was 
too brief evidently).

--

___
Python tracker 

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

[issue10009] Automated MSI installation does not work

[Mark Lawrence]

Mark Lawrence added the comment:

Nothing from the OP so to close or not to close, that is the question?

--

___
Python tracker 

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

[issue23985] Crash when deleting slices from duplicated bytearray

[Johan Dahlberg]

Johan Dahlberg added the comment:

Thank you all for working really fast on this issue!
I'm happy to see that a fix is already being tried out.

--

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Stefan Behnel]

Stefan Behnel added the comment:

And in fact, fixing it in ceval.c would not be enough, since gen_throw() also 
calls the function. So this is really the right place to fix it.

--

___
Python tracker 

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

[issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions

[Stefan Behnel]

Changes by Stefan Behnel :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue8706] accept keyword arguments on most base type methods and builtins

[Gregory P. Smith]

Gregory P. Smith added the comment:

I wouldn't make an efficiency argument against it without trying it and
showing reproducible degradation in the hg.python.org/benchmarks suite.

On Sun, Apr 19, 2015, 10:31 PM Serhiy Storchaka 
wrote:

>
> Serhiy Storchaka added the comment:
>
> Supporting keyword arguments has performance loss. For fast builtins it
> make be significant. We should defer adding keyword arguments support until
> more efficient parsing will implemented. Note that it is easier to
> implement efficient argument parsing for functions with positional-only
> arguments (see for example issue23867).
>
> --
> nosy: +serhiy.storchaka
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue24004] avoid explicit generator type check in asyncio

[Stefan Behnel]

Stefan Behnel added the comment:

I was (silently) hoping that this patching would eventually not be necessary 
anymore because the one place (currently inspect.isgenerator()) would be 
adapted to check for the generator protocol rather than the generator type. But 
that was going to go into a separate ticket. :)

I'm not sure inspect.isgenerator() is the right place, though, as the module 
tends to deal with types, not protocols. I think the right fix overall would be 
a Generator ABC class that defines the protocol.

What Cython does now in order to make asyncio work with Cython compiled 
generators is this:

https://github.com/cython/cython/blob/4af42443bd37f6207143f8870904f780a65bb3e3/Cython/Utility/Generator.c#L824

https://github.com/cython/cython/blob/4af42443bd37f6207143f8870904f780a65bb3e3/Cython/Utility/Generator.c#L906

Aweful, but currently required due to the type check, which prevents objects 
that implement the generator protocol from being handled correctly by asyncio.

--

___
Python tracker 

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

[issue15582] Enhance inspect.getdoc to follow inheritance chains

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I were aware that this can propagate some not well appropriate docstrings from 
abstract base classes, but Martin expose worse problem: inheriting a docstring 
by the method with changed signature.

Perhaps we should check if a signature of overriding method is compatible with 
a signature of base method. But this is hard to implement, and impossible in 
some cases until all builtins will converted to Argument Clinic.

--

___
Python tracker 

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

[issue24007] Write PyArg_Parse* format in a line with a function

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Actually it is not hard to me to apply the patch locally and regenerate clinic 
output if I need it. I propose this patch for mainstream only because think 
that it can be helpful for someone other. Thanks to moving all generated code 
into separated files, the code churn does not harm.

--

___
Python tracker 

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

[issue8706] accept keyword arguments on most base type methods and builtins

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Supporting keyword arguments has performance loss. For fast builtins it make be 
significant. We should defer adding keyword arguments support until more 
efficient parsing will implemented. Note that it is easier to implement 
efficient argument parsing for functions with positional-only arguments (see 
for example issue23867).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k]

[Siegfried Gevatter]

Siegfried Gevatter added the comment:

Thomas, could you take another look? I did update the patch.

Thanks! :)

--

___
Python tracker 

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

[issue24005] Documentation Error: Extra line Break

[Tim Golden]

Tim Golden added the comment:

(Laughs). I admit, I was so close to the trees, I missed the fact that 
the doc is, as you say, a What's New, and for Python 2.4. Agree that to 
change this now would be somewhat ludicrous.

If some similar patch were proposed to some more current, relevant 
document I'd still be at least open to the change proposed for the 
reasons I gave but let's close this one now.

--

___
Python tracker 

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

[issue24005] Documentation Error: Extra line Break

[Georg Brandl]

Georg Brandl added the comment:

Yeah, agreed.

--

___
Python tracker 

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

[issue23883] __all__ lists are incomplete

[Mauro Rodrigues]

Mauro Rodrigues added the comment:

Hi guys! 

Here is a patch for the fileinput module, with some names beyond 
fileinput.fileno: fileinput.hook_compressed, fileinput.hook_encoded as 
mentioned in the docs https://docs.python.org/3/library/fileinput.html

This is my first patch as well, so feedback's appreciated!

--
nosy: +maurosr
Added file: http://bugs.python.org/file39140/issue23883_fileinput.patch

___
Python tracker 

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

[issue1818] Add named tuple reader to CSV module

[Raymond Hettinger]

Raymond Hettinger added the comment:

Skip or Barry, do you want to look at this?

--
assignee:  -> skip.montanaro
nosy: +skip.montanaro
stage: needs patch -> patch review
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

[issue13386] Document documentation conventions for optional args

[Raymond Hettinger]

Raymond Hettinger added the comment:

Please don't add a new notation that makes the docs less readable than they are 
now.  For the most part, the existing docs have done a great job communicating 
how to use our functions.  Please don't undo 20 years of tradition because it 
bugs you.

--
nosy: +rhettinger

___
Python tracker 

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

[issue1818] Add named tuple reader to CSV module

[Ilia Kurenkov]

Ilia Kurenkov added the comment:

As my contribution during the sprints at PyCon 2015, I've tweaked Jervis's 
patch a little and updated the tests/docs to work with Python 3.5.

My only real change was placing the basic reader object inside a generator 
expression that filters out empty lines. Being partial to functional 
programming I find this removes some of the code clutter in __next__(), letting 
that method focus on turning rows into tuples.

Hopefully this will rekindle the discussion!

--
nosy: +copper-head
versions: +Python 3.5
Added file: http://bugs.python.org/file39139/1818_py35.diff

___
Python tracker 

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

[issue23986] Inaccuracy about "in" keyword for list and tuple

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'll add James' suggested wording, but with the reversed-order suggested by 
David Murray.

--
assignee: docs@python -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Raymond Hettinger]

Raymond Hettinger added the comment:

Unless there are some serious objections, I propose to close this on the basis 
of "practicality beats purity" (and as David Murray noted, there may not be a 
pure answer).   Eric Snow's comments are dead-on.

AFAICT, there isn't a real problem here and the API for better-or-worse has 
proven to be usable in practice (the callable() API has been around practically 
forever and the descriptor protocol has been around since Py2.2 -- if there 
were a real issue here, it would have reared it head long ago).

--

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Terry J. Reedy]

Terry J. Reedy added the comment:

Ned, I was indeed thinking of creating the string upon startup.

Martin: "Works, using" ? using what?

--

___
Python tracker 

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

[issue23994] argparse fails to detect program name when there is a slash at the end of the program's path

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag
resolution: fixed -> 

___
Python tracker 

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

[issue23985] Crash when deleting slices from duplicated bytearray

[Martin Panter]

Martin Panter added the comment:

A test case for this that would trigger when memory debugging is enabled could 
look something like the following. Would it be appropriate to add it to the 
test suite?

a = bytearray(10)
size = sys.getsizeof(a)
a.pop()  # Defeat expanding buffer off-by-one quirk
self.assertEqual(sys.getsizeof(a), size, "Quirk not defeated")
del a[:1]
# Or a.pop(0)  # Does not trigger bug
# Or a[:1] = ()  # Triggers bug
self.assertEqual(sys.getsizeof(a), size, "Test assumes buffer not resized")
a += bytes(2)  # Add exactly the number of free bytes in buffer
# Or a.extend(bytes(2))  # Unaffected
# Or a.append(0); a.append(0)  # Unaffected
# Or a[8:] = bytes(2)  # Unaffected
del a  # Trigger memory buffer to be freed, with verification

--

___
Python tracker 

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

[issue24004] avoid explicit generator type check in asyncio

[Guido van Rossum]

Guido van Rossum added the comment:

Uh, wait. Who's patching anything? That breaks the warranty.

--

___
Python tracker 

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

[issue23911] Move path-based bootstrap code to a separate frozen file.

[Eric Snow]

Eric Snow added the comment:

s/PEP 489/PEP 488/

--

___
Python tracker 

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

[issue23911] Move path-based bootstrap code to a separate frozen file.

[Eric Snow]

Eric Snow added the comment:

Here's an updated patch, with the PEP 489 changes merged in.  Only one test 
isn't passing and it is due to something in the pip that is bundled into 
ensurepip.  I'll work on fixing that when I have some time.  I'm sure there's 
documentation near the bundle that explains how to update it.

--
Added file: http://bugs.python.org/file39138/path-based-importlib.diff

___
Python tracker 

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

[issue23738] Clarify documentation of positional-only default values

[Martin Panter]

Martin Panter added the comment:

Of course in a new release, the functions could actually grow support for 
keywords, sidestepping the problem. Issue 8706 proposes to do this.

And see Issue 13386 about the conventions for optional arguments more generally.

--

___
Python tracker 

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

[issue13386] Document documentation conventions for optional args

[Martin Panter]

Martin Panter added the comment:

When a parameter is optional but does not have a simple default value, I 
suggest using some obviously invalid pseudocode, such as

function(arg1, arg2=)

See Issue 8706 about adding more support for keyword arguments. See also Issue 
23738 for signatures that incorrectly appear to accept keywords due to 
including default values, and PEP 457’s slash (/) indicator for documenting 
positional-only parameters.

--
nosy: +vadmium

___
Python tracker 

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

[issue8706] accept keyword arguments on most base type methods and builtins

[Martin Panter]

Martin Panter added the comment:

See also Issue 23738, which identifies some functions whose documentation 
already suggests they accept keywords. Perhaps these functions could be 
prioritized.

Also, I think “version changed” notices should be added in the documentation 
when a function grows support for keyword arguments.

--
nosy: +vadmium

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Martin Falatic]

Martin Falatic added the comment:

FYI, I'm currently using calls into Tkinter to get more detailed version info. 
Some methods work better than others... I've outlined my attempts below for 
reference (the last tcl_ver and tk_ver outputs are the ones I'm using, even 
though they are somewhat different in how they are written).

try:  # Python2
import Tkinter as tk
except ImportError:  # Python3
import tkinter as tk

root = tk.Tk()

tcl_ver = tk.TclVersion  # Typical but low precsion
tcl_ver = tk.Tcl().eval('info patchlevel')  # Works but uses eval()
tcl_ver = root.tcl.call('info', 'patchlevel')  # Fails (AttributeError)
tcl_ver = tk.Tcl().call('info', 'patchlevel')  # Works, using

tk_ver = tk.TkVersion  # Typical but low precsion
tk_ver = tk.Tk().eval('info patchlevel')  # Works but makes extra window, uses 
eval()
tk_ver = tk.Tk().call('info', 'patchlevel')  # Works but makes extra window
tk_ver = root.tk.call('info', 'patchlevel')  # Works, using

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

> Ionel Cristian Mărieș added the comment:
> What exactly are you proposing? Getting rid of AttributeError masking?

That isn't really a practical thing to consider, so no. :)  Instead
I'm suggesting there isn't a lot of justification to change the
behavior of callable.  *If* we were to change anything I'd suggest
disallowing AttributeError from a descriptor's getter during special
method lookup.  However, I'm not suggesting that either.  We should
simply leave callable alone (and consistent with the other helpers
that inspect the "special" *capability* of objects).

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

> Ionel Cristian Mărieș added the comment:
> It's not. Did you see the example with iter()/__iter__? It does convert
> the AttributeError into a TypeError.

callable and iter are not the same thing though.  callable checks for
a capability.  iter invokes a capability.  The direct comparision
would be collections.abc.Iterable.__subclasshook__ (e.g.
isinstance(obj, Iterable)), which behaves exactly like callable does
(does not invoke the descriptor protocol).  See
Lib/_collections_abc.py.

--

___
Python tracker 

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

[issue22208] tarfile can't add in memory files (reopened)

[Martin Panter]

Martin Panter added the comment:

In Issue 22468, I posted a patch which encourages using TarInfo directly, and 
hopefully clarifies that gettarinfo() is only for OS files. I think that should 
cover the documentation aspect of this bug, although an enhancement to 
synthesize TarInfo objects for regular files etc might still be a good idea.

--

___
Python tracker 

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

[issue21996] gettarinfo method does not handle files without text string names

[Martin Panter]

Martin Panter added the comment:

Over in Issue 22468, I posted a documentation patch which includes wording to 
address this bug.

--

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Ned Deily]

Ned Deily added the comment:

I am im favor of adding documentation for the existing tkinter TclVerion and 
TkVersion attributes to the tkinter section of the Standard Library reference 
as well as documenting a form of tkinter.Tcl().call('info', 'patchlevel') 
and/or tkinter.Tk().call('info', 'patchlevel') to return the full patchlevel 
string.  These spellings will work with every supported version of tkinter, 
Tcl, Tk, and platform.  Note that, while Tcl and Tk do have independent patch 
level strings, Tcl and Tk should normally always be installed at the same patch 
level; AFAIK, they are always released simultaneously upstream and are intended 
to be installed together.  If one were to add Tcl and Tk patchlevel attributes 
to tkinter, the code should be careful to dynamically get patchlevels via the 
equivalent of the above calls, and should not use the compile-time strings from 
Tcl/Tk include files tcl.h and tk.h, since on many platforms Tcl and Tk are 
installed as shared libraries and can be updated to a new patch l
 evel independently of the Python distribution.

As far as documenting the exact version of Tcl/Tk used in building the Python 
provided by a python.org Windows installer, that's a special case of 
documenting the versions of all third-party libraries used in the build.  I 
believe all of the information is available in the source tree PCBuild project 
files: Steve or Zach should be able to address whether that info is and/or 
should be available as part of the install process.  Adding all of that info to 
the release download page on python.org would be overkill as would a new PEP or 
a modification to PEP 101, IMO.  We do include general license information for 
possibly-included third-party libraries at the end of the license page in the 
release documentation set (https://docs.python.org/3/license.html) but, 
correctly, do not include specific version numbers there.  As a data point, for 
the python.org OS X installers, we now do include the specific version numbers 
of included libraries when producing the installer license file displayed
  as part of the installation process on OS X, with a link to the documentation 
set license page for the full text of the third-party licenses (see the 
attached jpg for an example).

--
Added file: http://bugs.python.org/file39137/osx_installer_license_example.jpg

___
Python tracker 

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

[issue22468] Tarfile using fstat on GZip file object

[Martin Panter]

Martin Panter added the comment:

I am posting a documentation patch which I hope should clarify that objects 
like GzipFile won’t work automatically with gettarinfo(). It also has other 
modifications to address Issue 21996 (name must be text) and help with Issue 
22208 (clarify non-OS files won’t work).

--
assignee:  -> docs@python
components: +Documentation
keywords: +patch
nosy: +docs@python
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file39136/gettarinfo.patch

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow  wrote:

> It not a problem currently for callable.  It is one you are proposing
> to introduce.  It is one which current users of callable don't have to
> worry about.
>
> >
> > Were do we draw the line here?
>
> We don't add to the problem.  Instead, we work to decrease it.
>

​What exactly are you proposing? Getting rid of AttributeError masking? I'm
talking about applying an old design decision (AttributeError masking)​ in
`callable`. Doesn't seem useful to talk about not having exception making
unless you have a plan to remove that from other places (that's even harder
than fixing `callable` IMO) just to fix this inconsistent handling in
Python.

Unless you think having inconsistent handling is OK. I do not think it's
OK. There should be the same rules for attribute access everywhere.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow  wrote:

> However, that is consistent across Python and has been this
> way for a long time (so there are backward compatibility concerns that
> cannot be ignored).
>

​It's not. Did you see the example with iter()/__iter__? It does convert
the AttributeError into a TypeError.​

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Ryan Gonzalez]

Ryan Gonzalez added the comment:

That's the thing; my repo has no python.c!

On April 19, 2015 7:39:19 PM CDT, Cyd Haselton  wrote:
>
>Cyd Haselton added the comment:
>
>Ryan,
>That fix is in the android_segfault patch, but it's for frozenmain.c
>not python.c
>
>I cloned from master on Fri/Sat. Will double-check commit tomorrow but
>I think the problem is with the unpatched python.c
>
>--
>
>___
>Python tracker 
>
>___

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

Ryan,
That fix is in the android_segfault patch, but it's for frozenmain.c not 
python.c

I cloned from master on Fri/Sat. Will double-check commit tomorrow but I think 
the problem is with the unpatched python.c

--

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

Patch for python.c that prevents segfault on Android

--
Added file: http://bugs.python.org/file39135/python.patch

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Ryan Gonzalez]

Changes by Ryan Gonzalez :


Added file: http://bugs.python.org/file39134/kbox_fix.patch

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Ryan Gonzalez]

Ryan Gonzalez added the comment:

On Sun, Apr 19, 2015 at 7:16 PM, Cyd Haselton 
wrote:

>
> Cyd Haselton added the comment:
>
> Ryan,
> Found the missing fix.
>
> In ./Programs/python.c
>
> #ifndef __ANDROID__
> oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL));
> if (!oldloc) {
> fprintf(stderr, "out of memory\n");
>   return 1;
> }
>   #endif
>
> Added the #ifndef __ANDROID__ #endif around lines 46-51
>
>
...that was in android_segfault_fix.patch...

are you sure you're on the same commit as I am?

> I'm now looking at the following syntax error:
>
> File "./setup.py", line 1950
> elif host_platform.startswith('arm-linux')
>  ^
> SyntaxError: invalid syntax
> make: *** [sharedmods] Error 1
>
>
I forgot to put a colon and the end of the line. I'll upload a fixed
"kbox_fixes.patch".

> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue24005] Documentation Error: Extra line Break

[Berker Peksag]

Berker Peksag added the comment:

That document is 10 years old :) I don't think it's worth to change now. Also, 
"what's new" documents shouldn't be used as a tutorial. There are many 
tutorials about writing decorators on the internet.

(Thanks for the report and the patch, Jaivish)

--
nosy: +berker.peksag

___
Python tracker 

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

[issue23496] Steps for Android Native Build of Python 3.4.2

[Cyd Haselton]

Cyd Haselton added the comment:

Ryan, 
Found the missing fix.

In ./Programs/python.c

#ifndef __ANDROID__
oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL));
if (!oldloc) {
fprintf(stderr, "out of memory\n"); 
 return 1;
}   
 #endif

Added the #ifndef __ANDROID__ #endif around lines 46-51

I'm now looking at the following syntax error:

File "./setup.py", line 1950
elif host_platform.startswith('arm-linux')
 ^
SyntaxError: invalid syntax
make: *** [sharedmods] Error 1

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

> Ionel Cristian Mărieș added the comment:
> #1. "It's specified/documented, therefore it's intended"
>
> The first thing a maintainer does is check the docs. This is a sensible thing 
> to do - as you cannot have all the details in your hear. The main question at 
> that point: "is it really like that?".
>
> However, it's easy to miss the fact that the documentation explains an 
> implementation issue (`callable` is not really reliable, blablabla), and not 
> the intent of `callable`.
>
> I mean, the name is pretty clear on what it's supposed to do: "is the object 
> callable or not?" - simple as that. If the intent of `callable` is being 
> unreliable then maybe we should just rename it to `maybe_callable` or 
> `unreliable_callable`, or maybe even "crappy_callable_we_dont_want_to_fix".

"callable" refers to the compatibility of the object with the call
syntax - simple as that.  The call syntax is turned into a special
lookup for "__call__" that explicitly skips lookup on the instance (in
CPython it is a call to _PyObject_LookupSpecial) and then a call on
the resulting value.

You are correct that callable does not do the descriptor part of that
lookup.  However, that is consistent across Python and has been this
way for a long time (so there are backward compatibility concerns that
cannot be ignored).

>
> #2. "But the call could fail anyway, so what's the point of fixing this?"

You are correct that the availability of __call__ is the only relevant
issue here.

>
> #3. "But it's going to be too slow!"
>
> I don't want to be mean here, but this is just FUD. Lets measure this first. 
> Is there really a measurable and significant performance impact on major 
> applications?

It's not just applications.  Grep for "PyCallable_Check" in the
CPython code base.

>
> Does the argument even make sense in theory? A function call is pretty 
> expensive in python, a mere attribute lookup wouldn't increase the cost by an 
> order of magnitude (like 10x), would it?

A "mere attribute lookup" involves invoking the descriptor protocol.
This would add a discernible performance impact and the possibility of
running arbitrary code for the sake of a rare corner case.  The
overall impact would be small, especially considering the use of
PyCallable_Check in the CPython code base, but do not assume it would
be insignificant.

> Python 3 regressed performance in various aspects (and improved other things, 
> of course), why would this be a roadblock now?

My apology for being so blunt, but that's a terrible rationale!  Let's
make it better not worse.

>
> #4. "It's too tricky, and I had a bad time with pickle one time ago", or: 
> Exception masking issues
>
> This is certainly a problem, but it's not a new problem. There are already 
> dozens of places where AttributeError is masked into something else (like a 
> TypeError, or just a different result).

It not a problem currently for callable.  It is one you are proposing
to introduce.  It is one which current users of callable don't have to
worry about.

>
> Were do we draw the line here?

We don't add to the problem.  Instead, we work to decrease it.

> Do we want to eventually get rid of all exception masking in an eventual 
> Python 4.0 - what's the overarching goal here? Or is this just one of the 
> many quirks of Python?
>
> What's worse - a quirk or a inconsistent quirk?

What's the quirk here?  I'd argue that the quirk is that special
method lookup (_PyObject_LookupSpecial) doesn't turn AttributeError
from a getter into RuntimeError.

--

___
Python tracker 

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

[issue8706] accept keyword arguments on most base type methods and builtins

[Berker Peksag]

Changes by Berker Peksag :


--
components: +Extension Modules, Interpreter Core
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.3

___
Python tracker 

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

[issue12712] weave build_tools library identification

[Mark Lawrence]

Mark Lawrence added the comment:

Is case sensitivity still an issue on Windows?  I've tried searching but there 
are so many issues referring to case sensitivity that I got swamped.

--
components: +Windows
nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

I want to address the four main points of criticism in fixing this issue, just 
in case it's not clear why I think those lines of thought are wrong:

#1. "It's specified/documented, therefore it's intended"

The first thing a maintainer does is check the docs. This is a sensible thing 
to do - as you cannot have all the details in your hear. The main question at 
that point: "is it really like that?". 

However, it's easy to miss the fact that the documentation explains an 
implementation issue (`callable` is not really reliable, blablabla), and not 
the intent of `callable`.

I mean, the name is pretty clear on what it's supposed to do: "is the object 
callable or not?" - simple as that. If the intent of `callable` is being 
unreliable then maybe we should just rename it to `maybe_callable` or 
`unreliable_callable`, or maybe even "crappy_callable_we_dont_want_to_fix".

#2. "But the call could fail anyway, so what's the point of fixing this?"

The problem with this argument is that it's the same argument people bring up 
to remove the `callable` builtin. The problem is that you wouldn't use 
`callable` at all if you can just try/call/except. So this argument is not 
pertinent to the problem at hand (`callable` doing incomplete checks).

#3. "But it's going to be too slow!"

I don't want to be mean here, but this is just FUD. Lets measure this first. Is 
there really a measurable and significant performance impact on major 
applications? 

Does the argument even make sense in theory? A function call is pretty 
expensive in python, a mere attribute lookup wouldn't increase the cost by an 
order of magnitude (like 10x), would it?

> py -3 -mtimeit -s "def foo(): pass" "foo.__call__"
1000 loops, best of 3: 0.0585 usec per loop

> py -3 -mtimeit -s "def foo(): pass" "callable(foo)"
1000 loops, best of 3: 0.0392 usec per loop

Is this a significant margin? Also, I'm pretty sure those numbers can be 
improved.

Python 3 regressed performance in various aspects (and improved other things, 
of course), why would this be a roadblock now?

#4. "It's too tricky, and I had a bad time with pickle one time ago", or: 
Exception masking issues

This is certainly a problem, but it's not a new problem. There are already 
dozens of places where AttributeError is masked into something else (like a 
TypeError, or just a different result).

Were do we draw the line here? Do we want to eventually get rid of all 
exception masking in an eventual Python 4.0 - what's the overarching goal here? 
Or is this just one of the many quirks of Python?

What's worse - a quirk or a inconsistent quirk?

The problem with this argument is that it attacks a different problem, that's 
just being made more visible if and when this problem of `callable` is fixed.

Lets consider this strawman here: if a an user writes code like this:

try:
do important stuff
except:
pass # have fun debugging, haha

who's at fault here? Is it the user that wrote that debugging black hole or is 
it python for letting the user do things like that? I don't think it's 
reasonable for Python to prevent exception masking bugs if the user was brave 
enough to write a descriptor.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

s/TypeError/RuntimeError/

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

Just to be clear, I'm still -1 on any of this.  On the one hand, there's a risk 
of backward-compatibility breakage (just as much a corner-case as the need 
expressed in this issue).  On the other hand, I'd actually push for 
_PyObject_LookupSpecial to be fixed to chain AttributeError coming from a 
descriptor into a TypeError.

Allowing instances to determine the capability of a class feels wrong and 
potentially broken.  Furthermore, doing so via AttributeError is problematic 
since it may mask an AttributeError that bubbles up (which is very confusing 
and hard to debug).  I've been bitten by this with pickle.

Still, it may be a good idea to expose _PyObject_LookupSpecial via the inspect 
module, but that should be addressed in a separate issue.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Eric Snow]

Eric Snow added the comment:

> What would be the "right thing"?

My suggestion of using a metaclass is actually not effective here because 
__call__ has meaning for metaclasses.  Otherwise you could have made __call__ 
more dynamic via a metaclass.  Except that is another reason why my suggestion 
is incorrect.  What you are asking for is that, effectively, the state of the 
instance might be able to impact the resolution of special methods of a class.  
So a metaclass approach would not have helped since the instance would not have 
been involved in the lookup.

Regardless, this makes it more clear to me what you are trying to accomplish 
for the sake of a proxy type.  The question is, should an instance be able to 
influence the resolution of special methods that are called on its behalf?

Before answering that, consider why methods that are special to the interpreter 
get treated differently.  The language specifies that rather than using 
obj.__getattribute__ to look up special methods, they are effectively located 
in type(obj).__dict__.  They likewise are not looked up on 
obj.__class__.__dict__.  Here are the key reasons why this matters:

 * speed
 * the special methods will still be available even if the class implements its 
own __getattribute__

Once the methods are looked up, the descriptor protocol is invoked, if 
applicable.  However, it does not fall back to obj.__getattr__.  See 
Objects/typeobject.c:_PyObject_LookupSpecial.  So ultimately the descriptor 
protocol allows instances to have a say in both the existence and the behavior 
of special methods.  However, I think that the former is unfortunate since it 
obviously muddies the water here.  I doubt it was intentional.

Back to the question, should instances be allowed to influence the *lookup* of 
special methods?  Your request is that they should be and consistently.  As 
noted, the interpreter already uses the equivalent of the following when 
looking up special methods:

def _PyObject_LookupSpecial(obj, name):
attr = inspect.getattr_static(obj, name)
try:
f = inspect.getattr_static(attr, '__get__')
except AttributeError:
return attr
else:
return f(attr, obj, type(obj))

What you are asking is that callable should do this too, rather than skipping 
the descriptor part).  I expect the same would need to be done for any other 
helper that also checks for "special" capability.  For example, see the various 
__subclasshook__ implementations in Lib/_collections_abc.py.  We should be 
consistent about it if we are going to do it.

--

___
Python tracker 

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

[issue24007] Write PyArg_Parse* format in a line with a function

[Larry Hastings]

Larry Hastings added the comment:

I don't care about this, but the patch looks fine.  If this really helps then 
LGTM.

Please hold off checking this in until after 3.5.0 alpha 4 is released.

--

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Martin Falatic]

Martin Falatic added the comment:

Thank you. Before going down the road of revising PEP 101 (which appears to be 
very non-trivial despite the simple (and certainly always present) data 
involved), I'd like to know: is version information about the pre-compiled 
Windows binaries (of which this is one) already being captured anywhere else 
publically visible on a per-release or per-build basis? It's useful that such 
binaries exist given Windows' unique requirements versus other systems, but are 
these binaries themselves documented anywhere as they are updated (e.g., how to 
re-create them)? Such a source of truth would simplify that revision request.

--

___
Python tracker 

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

[issue22619] Possible implementation of negative limit for traceback functions

[Dmitry Kazakov]

Dmitry Kazakov added the comment:

I'll do that tomorrow. The patch still needs a review though...

--

___
Python tracker 

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

[issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup

[STINNER Victor]

STINNER Victor added the comment:

Related issues and discussions:
- [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3?
  https://mail.python.org/pipermail/python-dev/2011-June/112086.html
- Issue #12451: open: avoid the locale encoding when possible
  https://bugs.python.org/issue12451

--

___
Python tracker 

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

[issue22080] Add windows_helper module helper

[Claudiu Popa]

Claudiu Popa added the comment:

The latest patch drops the symlink check, since it can be added later.

--
Added file: http://bugs.python.org/file39133/issue22080_2.patch

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Sun, Apr 19, 2015 at 10:29 PM, Steven D'Aprano 
wrote:

> This bug report seems to be completely based on a false premise. In the
> very first message of this issue, Ionel says:
>
> "it return True even if __call__ is actually an descriptor that raise
> AttributeError (clearly not callable at all)."
>
> but that is wrong. It *is* callable, and callable() is correct to return
> True. If you look at the stack trace, the __call__ method
> (function/property, whatever you want to call it) is called, and it raises
> an exception. That is no different from any other method or function that
> raises an exception.
>
> It is wrong to think that raising AttributeError *inside* __call__ makes
> the object non-callable.
>
> Ionel, I raised these issues on Python-list here:
>
> https://mail.python.org/pipermail/python-ideas/2015-April/033078.html
>
> but you haven't responded to them.

I was hoping my other replies had addressed those issues. Note that the
presence of __call__ on the callstack is merely an artefact of how
@property works, and it's not actually the __call__ method (it's just
something that property.__get__ calls).

Here's an example that hopefully illustrates the issue more clearly:

>>> class CallDescriptor:
... def __get__(self, inst, owner):
... target = inst._get_target()
... if callable(target):
... return target
... else:
... raise AttributeError('not callable')
...
>>> class LazyProxy:
... __call__ = CallDescriptor()
... def __init__(self, get_target):
... self._get_target = get_target
...
>>> def create_stuff():
... # heavy computation here
... print("Doing heavey computation")
... return 1, 2, 3
...
>>> proxy = LazyProxy(create_stuff)
>>> callable(proxy)  ### this should be false!
True
>>> hasattr(proxy, '__call__')
Doing heavey computation
False
>>>
>>> def create_callable_stuff():
... # heavy computation here
... print("Doing heavey computation")
... def foobar():
... pass
... return foobar
...
>>> proxy = LazyProxy(create_callable_stuff)
>>> callable(proxy)
True
>>> hasattr(proxy, '__call__')
Doing heavey computation
True​

Now it appears there's a second issue, slightly related - if you actually
call the proxy object AttributeError is raised (instead of the TypeError):

>>> proxy = LazyProxy(create_stuff)
>>> callable(proxy)
True
>>> hasattr(proxy, '__call__')
Doing heavey computation
False
>>> proxy()
Doing heavey computation
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 7, in __get__
AttributeError: not callable
>>>
>>> target = create_stuff()
Doing heavey computation
>>> target()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'tuple' object is not callable

Contrast that to how iter works - if the descriptor raise AttributeError
then iter raises TypeError (as expected):

>>> class IterDescriptor:
... def __get__(self, inst, owner):
... target = inst._get_target()
... if hasattr(type(target), '__iter__') and hasattr(target,
'__iter__'):
... return target.__iter__
... else:
... raise AttributeError('not iterable')
...
>>> class LazyProxy:
... __iter__ = IterDescriptor()
... def __init__(self, get_target):
... self._get_target = get_target
...
>>> def create_iterable_stuff():
... # heavy computation here
... print("Doing heavey computation")
... return 1, 2, 3
...
>>> proxy = LazyProxy(create_iterable_stuff)
>>> iter(proxy)
Doing heavey computation

>>>
>>> def create_noniterable_stuff():
... # heavy computation here
... print("Doing heavey computation")
... def foobar():
... pass
... return foobar
...
>>> proxy = LazyProxy(create_noniterable_stuff)
>>> iter(proxy)
Doing heavey computation
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'LazyProxy' object is not iterable
>>>
>>> proxy.__iter__
Doing heavey computation
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 7, in __get__
AttributeError: not iterable

​
​So this is why I'm bringing this up. If `iter` wouldn't handle it like
that then I'd think that maybe this is the intended behaviour.​
​

I hope the blatant inconsistency is more clear​
​ now​
​, and you'll understand that this bug report is not just some flagrant
misunderstanding of how __call__ works.

To sum this up, the root of this issue is that `callable` doesn't do all
the checks that are done right before actually performing the call (like
the descriptor handling). It's like calling your doctor for an appointment
where the secretary schedules you, but forgets to check if the doctor is in
vacation or not.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

--

___
Python tracker 

[issue23917] please fall back to sequential compilation when concurrent doesn't exist

[Claudiu Popa]

Claudiu Popa added the comment:

Here's the patch.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39132/issue23917.patch

___
Python tracker 

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

[issue24013] Improve os.scandir() and DirEntry documentation

[Ben Hoyt]

New submission from Ben Hoyt:

Victor Stinner's documentation for os.scandir and DirEntry is a great start 
(https://docs.python.org/dev/library/os.html#os.scandir), however there are a 
few mistakes in it, and a few ways I think it could be improved. Attaching a 
patch with the following overall changes:

1. Tweak the "see also" note on os.listdir() to mention *why* you'd want to use 
scandir -- namely that it includes file attribute info, and performance.
2. Move that str/bytes note in the scandir() docs down a bit, as I think that's 
really a detail and the other stuff is more important.
3. More details on why you'd want to use scandir -- to "increase the 
performance of code that also needs file type or file" -- and be more specific 
about what system calls are and are not required.
4. Replace "POSIX" with "Unix", per the rest of the os module docs when talking 
about generic Unix-like operating systems. It seems "POSIX" is used 
specifically when talking about the POSIX standard.
5. Remove half-true statement in DirEntry docs, "if a file is deleted between 
calling scandir and stat, a FileNotFoundError can be raised" -- but the method 
docs state that they specifically don't raise FileNotFoundError.
6. Removed "unfortunately, the behaviour of errors depends on the platform". 
This is always the case and doesn't add anything.
7. Tried to simplify and clarify the is_dir() and is_file() docs. Not sure I've 
succeeded here. This is hard!
8. Added "Availability: Unix, Windows." to scandir docs like listdir and most 
other os functions have.
9. Remove the see also about how "the listdir function returns the names of the 
directory entries" as that's already stated/implied above.

--
assignee: docs@python
components: Documentation
files: scandir_doc_tweaks.patch
keywords: patch
messages: 241560
nosy: benhoyt, docs@python, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve os.scandir() and DirEntry documentation
versions: Python 3.5
Added file: http://bugs.python.org/file39131/scandir_doc_tweaks.patch

___
Python tracker 

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

[issue22619] Possible implementation of negative limit for traceback functions

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Needed a documentation. I'm not interested in writing it.

--

___
Python tracker 

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

[issue24000] More fixes for the Clinic mapping of converters to format units

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Not according to the documentation.  'u' explicitly says it does not allow 
> NUL characters.  'Z', 'u#', and 'Z#' all say they are "variants" of 'u' but 
> never mention that they might allow NUL characters.

I understand the note in "u" description as explicitly saying that "u#" allows 
null characters.

The documentation for format units needs an update for other reasons and there 
is an issue with ready patch for this.

--

___
Python tracker 

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

[issue24005] Documentation Error: Extra line Break

[Carol Willing]

Carol Willing added the comment:

Tim, A good point re: the interpreter. I've attached an output from IPython 
interpreter.

Georg, Given Tim's additional insight, I'm inclined to reopen the issue and 
review the patch as a positive change. Though not a bug, but as an enhancement 
for learners to copy-paste doc code into an interpreter. Thoughts?

--
Added file: http://bugs.python.org/file39130/Screen Shot 2015-04-19 at 12.19.07 
PM.png

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Joe Jevnik]

Joe Jevnik added the comment:

This is a different case from raising an AttributeError inside the __call__;


>>> class C(object):
... def __call__(self):
... raise AttributeError()
...
>>> hasattr(C(), '__call__')
True
>>> class D(object):
... @property
... def __call__(self):
... raise AttributeError()
...
>>> hasattr(C(), '__call__')
False

AttributeError was picked very intentionally for the example.

The docs show that n(args) == n.__call__(args) if n has a __call__; however, if 
a property raises an AttributeError, then it really does not have a __call__.

--

___
Python tracker 

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

[issue24012] Add error checks to PyInit_pyexpat()

[Christian Heimes]

New submission from Christian Heimes:

Similar to #24011 and #24010 the pyexpat module's init function fails to check 
some return values for NULL. The patch doesn't include proper reference 
cleanups as most of the other parts of PyInit_pyexpat() don't cleanup on error, 
too.

CID 982779 (#2 of 2): Dereference null return value (NULL_RETURNS)
dereference: Dereferencing a pointer that might be null sys_modules when 
calling PyDict_SetItem

CID 982240 (#2 of 2): Unchecked return value (CHECKED_RETURN)
check_return: Calling PyDict_SetItem without checking return value (as is done 
elsewhere 158 out of 174 times)

--
components: Extension Modules
files: pyexpat.patch
keywords: patch
messages: 241555
nosy: christian.heimes, eli.bendersky, scoder
priority: normal
severity: normal
stage: patch review
status: open
title: Add error checks to PyInit_pyexpat()
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39129/pyexpat.patch

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Steven D'Aprano]

Steven D'Aprano added the comment:

This bug report seems to be completely based on a false premise. In the very 
first message of this issue, Ionel says:

"it return True even if __call__ is actually an descriptor that raise 
AttributeError (clearly not callable at all)."

but that is wrong. It *is* callable, and callable() is correct to return True. 
If you look at the stack trace, the __call__ method (function/property, 
whatever you want to call it) is called, and it raises an exception. That is no 
different from any other method or function that raises an exception.

It is wrong to think that raising AttributeError *inside* __call__ makes the 
object non-callable.

Ionel, I raised these issues on Python-list here:

https://mail.python.org/pipermail/python-ideas/2015-April/033078.html

but you haven't responded to them.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue24011] Add error checks to PyInit_signal()

[Christian Heimes]

New submission from Christian Heimes:

The init function of the signal module fails to check for errors in a couple of 
places. The patch replaces PyDict_SetItemString() calls with 
PyModule_AddIntMacro() and error checks. An exception is unlikely so I'm OK 
when the patch just lands in 3.4 and 3.5.

CID 1295026 (#41 of 41): Dereference null return value (NULL_RETURNS)
dereference: Dereferencing a pointer that might be null x when calling 
PyDict_SetItemString

--
components: Extension Modules
files: signalmodule.patch
keywords: patch
messages: 241551
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Add error checks to PyInit_signal()
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39127/signalmodule.patch

___
Python tracker 

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

[issue24001] Clinic: use raw types in types= set

[Larry Hastings]

Larry Hastings added the comment:

Whoops.  I'll fix that.

--

___
Python tracker 

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

[issue24001] Clinic: use raw types in types= set

[Larry Hastings]

Larry Hastings added the comment:

Here's the right patch.

--
Added file: http://bugs.python.org/file39128/larry.clinic.use.raw.types.2.txt

___
Python tracker 

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

[issue24001] Clinic: use raw types in types= set

[Larry Hastings]

Changes by Larry Hastings :


Removed file: 
http://bugs.python.org/file39122/larry.one.more.clinic.format.unit.map.cleanup.2.txt

___
Python tracker 

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

[issue24010] Add error checks to PyInit__locale()

[Christian Heimes]

New submission from Christian Heimes:

The init function of the locale module fails to check for errors in a couple of 
places. The patch replaces PyDict_SetItemString() calls with 
PyModule_AddIntMacro() and error checks. An exception is unlikely so I'm OK 
when the patch just lands in 3.4 and 3.5.

CID 1295027 (#8 of 8): Dereference null return value (NULL_RETURNS)
dereference: Dereferencing a pointer that might be null x when calling 
PyDict_SetItemString

--
components: Extension Modules
files: localemodule.patch
keywords: patch
messages: 241550
nosy: christian.heimes, lemburg, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Add error checks to PyInit__locale()
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file39126/localemodule.patch

___
Python tracker 

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

[issue21574] Port image types detections from PIL to the imghdr module

[Claudiu Popa]

Changes by Claudiu Popa :


--
stage: needs patch -> test needed

___
Python tracker 

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

[issue23701] Drop extraneous comment from winreg.QueryValue's docstring

[Claudiu Popa]

Changes by Claudiu Popa :


--
stage:  -> patch review

___
Python tracker 

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

[issue24003] variable naming

[Ned Deily]

Ned Deily added the comment:

(... and is documented in The Python 3 and 2 Language Reference manuals: 
https://docs.python.org/3/reference/lexical_analysis.html#keywords and 
https://docs.python.org/2/reference/lexical_analysis.html#keywords)

--
nosy: +ned.deily

___
Python tracker 

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

[issue24008] inspect.getsource is failing for sys.excepthook

[Claudiu Popa]

Claudiu Popa added the comment:

That's actually expected, since sys.excepthook is a builtin, so there's no 
source code to be retrieved (the same holds for other builtins, such as next, 
range etc).

--
nosy: +Claudiu.Popa
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue23998] PyImport_ReInitLock() doesn't check for allocation error

[Roundup Robot]

Roundup Robot added the comment:

New changeset d70995cf44b3 by Christian Heimes in branch '2.7':
Issue #23998: PyImport_ReInitLock() now checks for lock allocation error
https://hg.python.org/cpython/rev/d70995cf44b3

New changeset 7d7bf5c34d7e by Christian Heimes in branch '3.3':
Issue #23998: PyImport_ReInitLock() now checks for lock allocation error
https://hg.python.org/cpython/rev/7d7bf5c34d7e

New changeset e0bd083fc9c1 by Christian Heimes in branch '3.4':
Issue #23998: PyImport_ReInitLock() now checks for lock allocation error
https://hg.python.org/cpython/rev/e0bd083fc9c1

New changeset 7ae8fd62d743 by Christian Heimes in branch 'default':
Issue #23998: PyImport_ReInitLock() now checks for lock allocation error
https://hg.python.org/cpython/rev/7ae8fd62d743

--
nosy: +python-dev

___
Python tracker 

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

[issue24009] Get rid of rare format units in PyArg_Parse*

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

There are a lot of format units supported in PyArg_Parse* functions, but some 
of them are rarely or never used in current CPython code. Some of format units 
are legacy from Python 2 and are not needed in modern Python 3 code or can be 
replaced with custom converter.

Here are results of grepping (not including Modules/_testcapimodule.c).

"es", "es#", "et#", "z*", "Z#" are not used.

"y#":
Modules/_io/textio.c:2334:if (!PyArg_ParseTuple(_state, "y#i", 
&dec_buffer, &dec_buffer_len, &dec_flags)) { \

"z#":
Modules/_ctypes/_ctypes.c:3327:if (!PyArg_ParseTuple(args, "is|Oz#", 
&index, &name, ¶mflags, &iid, &iid_len))

"u#":
Modules/arraymodule.c:248:if (!PyArg_Parse(v, "u#;array item must be 
unicode character", &p, &len))
PC/winreg.c:1547:if (!PyArg_ParseTuple(args, "OZiu#:SetValue",

"y":
Modules/_io/textio.c:2334:if (!PyArg_ParseTuple(_state, "y#i", 
&dec_buffer, &dec_buffer_len, &dec_flags)) { \
Modules/_cursesmodule.c:2790:if (!PyArg_ParseTuple(args,"y;str", &str))
Modules/_cursesmodule.c:3026:if (!PyArg_ParseTuple(args, 
"y|i:tparm",
Modules/posixmodule.c:3767:if (!PyArg_ParseTuple (args, 
"y:_getfullpathname",
Modules/posixmodule.c:3872:if (!PyArg_ParseTuple(args, "y:_isdir", &path))
Modules/faulthandler.c:941:if (!PyArg_ParseTuple(args, "y:fatal_error", 
&message))

"et":
Modules/socketmodule.c:4499:if (!PyArg_ParseTuple(args, "et:gethostbyname", 
"idna", &name))
Modules/socketmodule.c:4667:if (!PyArg_ParseTuple(args, 
"et:gethostbyname_ex", "idna", &name))
Modules/socketmodule.c:4744:if (!PyArg_ParseTuple(args, "et:gethostbyaddr", 
"idna", &ip_num))
Modules/_tkinter.c:2099:if (!PyArg_ParseTuple(args, "et:splitlist", 
"utf-8", &list))
Modules/_tkinter.c:2162:if (!PyArg_ParseTuple(args, "et:split", "utf-8", 
&list))
Modules/_ssl.c:3038:if (!PyArg_ParseTupleAndKeywords(args, kwds, 
"O!iet:_wrap_socket", kwlist,
Modules/_ssl.c:3070:if (!PyArg_Parse(hostname_obj, "et", "idna", 
&hostname))

"s*":
Modules/_codecsmodule.c:188:if (!PyArg_ParseTuple(args, 
"s*|z:escape_decode",
Modules/_codecsmodule.c:552:if (!PyArg_ParseTuple(args, 
"s*|z:unicode_escape_decode",
Modules/_codecsmodule.c:569:if (!PyArg_ParseTuple(args, 
"s*|z:raw_unicode_escape_decode",
Modules/_codecsmodule.c:696:if (!PyArg_ParseTuple(args, 
"s*|z:readbuffer_encode",
Modules/_ssl.c:3734:if (!PyArg_ParseTuple(args, "s*d:RAND_add", &view, 
&entropy))
Modules/fcntlmodule.c:225:if (PyArg_Parse(ob_arg, "s*:ioctl", &pstr)) {
Modules/clinic/arraymodule.c.h:278:if (!PyArg_Parse(arg, "s*:fromstring", 
&buffer))

"s#":
Modules/_gdbmmodule.c:128:if (!PyArg_Parse(key, "s#", &krec.dptr, 
&krec.dsize) )
Modules/_gdbmmodule.c:176:if (!PyArg_Parse(v, "s#", &krec.dptr, 
&krec.dsize) ) {
Modules/_gdbmmodule.c:194:if (!PyArg_Parse(w, "s#", &drec.dptr, 
&drec.dsize)) {
Modules/fcntlmodule.c:71:if (PyArg_Parse(arg, "s#", &str, &len)) {
Modules/_ctypes/_ctypes.c:2569:if (!PyArg_ParseTuple(args, "Os#", &dict, 
&data, &len))
Modules/clinic/unicodedata.c.h:361:if (!PyArg_Parse(arg, "s#:lookup", 
&name, &name_length))
Modules/clinic/_dbmmodule.c.h:62:if (!PyArg_ParseTuple(args, "s#|O:get",
Modules/clinic/_dbmmodule.c.h:95:if (!PyArg_ParseTuple(args, 
"s#|O:setdefault",
Modules/clinic/_gdbmmodule.c.h:150:if (!PyArg_Parse(arg, "s#:nextkey", 
&key, &key_length))
Modules/_dbmmodule.c:108:if (!PyArg_Parse(key, "s#", &krec.dptr, &tmp_size) 
)
Modules/_dbmmodule.c:132:if ( !PyArg_Parse(v, "s#", &krec.dptr, &tmp_size) 
) {
Modules/_dbmmodule.c:150:if ( !PyArg_Parse(w, "s#", &drec.dptr, 
&tmp_size) ) {
Modules/_dbmmodule.c:336:if ( !PyArg_Parse(default_value, "s#", 
&val.dptr, &tmp_size) ) {

In future may be we could deprecate some format units and remove them in 4.0.

This issue is a meta issue. Every case should be considered individually.

--
assignee: serhiy.storchaka
components: Interpreter Core
messages: 241546
nosy: serhiy.storchaka
priority: low
severity: normal
status: open
title: Get rid of rare format units in PyArg_Parse*
type: enhancement
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue24006] Multiprocessing fails when using functions defined in interactive interpreter.

[R. David Murray]

R. David Murray added the comment:

I'm guessing you are on Windows.  Please read 
https://docs.python.org/2/library/multiprocessing.html#windows.  You can't do 
what you show on windows (though you can on unix, since it uses fork).

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values

[Terry J. Reedy]

Terry J. Reedy added the comment:

The tkinter docs need to be expanded, but that is a different issue.

The complete tcl/tk version is displayed in Idle -> Help -> About Idle using 
"self.tk.call('info', 'patchlevel')".  Pending a reason not to, I would be in 
favor of adding this full info as a tkinter attribute (.version ?, .patch_level 
?) in addition to the current .TclVersion and .TkVersion attributes (which are 
now always the same, though once probably not).  This would be a new tracker 
issue.  

Adding the tcl/tk version included with the windows installer to the download 
web page seems reasonable to me.  This would be a third issue, involving 
revision of PEP 101 on making releases.  The first change would be the RM 
(Release Manager) getting the info from the WE (Windows Expert).  This would go 
somewhere under "The WE then generates Windows installer files". Then somewhere 
under "Now it's time [for the RM] to twiddle the web site." would be something 
about inserting the tcl/tk version is a revised template page, or whatever.  I 
leave it to you to look as the site for the specific page to revise and how, 
and to read this section of the PEP.  Proposed PEP changes are usually sent to 
PEP editors.  If you want to pursue this, you might first email Barry to see 
what he would prefer.

--

___
Python tracker 

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

[issue22619] Possible implementation of negative limit for traceback functions

[Riley Banks]

Changes by Riley Banks :


--
nosy: +vaultah

___
Python tracker 

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

[issue24005] Documentation Error: Extra line Break

[Tim Golden]

Tim Golden added the comment:

One small thing to bear in mind is that the existing code (ie with the extra 
linefeed) raises an IndentationError if cut-and-pasted into the interactive 
interpreter; with the OP's change, it succeeds. Might not have been their 
intention, but certainly is the case.

(Doesn't make it a bug, as such, but makes it more than a stylistic difference 
of opinion).

--
nosy: +tim.golden

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Sun, Apr 19, 2015 at 10:01 PM, Ethan Furman 
wrote:

> The "right thing", using a meta-class, is to have the meta-class check if
> the proxied object is callable, and if so, put in the __call__ function in
> the class that is being created.

​Yes indeed, for a plain proxy. Unfortunately for a *lazy* proxy this is
not acceptable as it ​would "create" (or "access") the target. The point is
to delay that till it's actually needed, not when the proxy is created.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

--

___
Python tracker 

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

[issue23994] argparse fails to detect program name when there is a slash at the end of the program's path

[R. David Murray]

R. David Murray added the comment:

Thanks for the patch.  We'll want a unit test for the behavior before 
committing this.

--
nosy: +r.david.murray
stage:  -> test needed
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

[issue23990] Callable builtin doesn't respect descriptors

[Ethan Furman]

Ethan Furman added the comment:

The "right thing", using a meta-class, is to have the meta-class check if the 
proxied object is callable, and if so, put in the __call__ function in the 
class that is being created.

--

___
Python tracker 

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

[issue18654] modernize mingw&cygwin compiler classes

[R. David Murray]

R. David Murray added the comment:

Find someone from the packaging sig willing to review it, maybe?  As in, get on 
that mailing list and ask.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24000] More fixes for the Clinic mapping of converters to format units

[Larry Hastings]

Larry Hastings added the comment:

New diff based on Serhiy's latest round of comments.  Thanks, Serhiy!  You are 
inexhaustable!

--
Added file: 
http://bugs.python.org/file39125/larry.one.more.clinic.format.unit.map.cleanup.3.txt

___
Python tracker 

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

[issue24000] More fixes for the Clinic mapping of converters to format units

[Larry Hastings]

Larry Hastings added the comment:

> "u#" and "Z#" allow null characters.

Not according to the documentation.  'u' explicitly says it does not allow NUL 
characters.  'Z', 'u#', and 'Z#' all say they are "variants" of 'u' but never 
mention that they might allow NUL characters.

--

___
Python tracker 

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

[issue24008] inspect.getsource is failing for sys.excepthook

[Anand Reddy Pandikunta]

New submission from Anand Reddy Pandikunta:

>>> inspect.getsource(sys.excepthook)
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/inspect.py", line 701, in getsource
lines, lnum = getsourcelines(object)
  File "/usr/local/lib/python2.7/inspect.py", line 690, in getsourcelines
lines, lnum = findsource(object)
  File "/usr/local/lib/python2.7/inspect.py", line 526, in findsource
file = getfile(object)
  File "/usr/local/lib/python2.7/inspect.py", line 420, in getfile
'function, traceback, frame, or code object'.format(object))
TypeError:  is not a module, class, method, 
function, traceback, frame, or code object

--
components: Library (Lib)
files: trace4.py
messages: 241537
nosy: ChillarAnand
priority: normal
severity: normal
status: open
title: inspect.getsource is failing for sys.excepthook
versions: Python 2.7
Added file: http://bugs.python.org/file39124/trace4.py

___
Python tracker 

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

[issue24001] Clinic: use raw types in types= set

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Looks as this is a patch for different issue.

--

___
Python tracker 

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

[issue23967] Make inspect.signature expression evaluation more powerful

[Larry Hastings]

Larry Hastings added the comment:

Whoops.  Here's the revised patch.

--
Added file: 
http://bugs.python.org/file39123/larry.improved.signature.expressions.2.txt

___
Python tracker 

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

[issue23967] Make inspect.signature expression evaluation more powerful

[Larry Hastings]

Larry Hastings added the comment:

Thanks to #24002 I now know how to write evalify_node properly.  This patch is 
now much better.

Note that I deliberately made the new function _eval_ast_expr() as a "private" 
module-level routine.  I need that same functionality in Argument Clinic too, 
so if both patches are accepted I'll have Clinic switch to calling this version.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue24001] Clinic: use raw types in types= set

[Larry Hastings]

Larry Hastings added the comment:

Thanks to #24002 I now know how to write evalify_node properly.  This revision 
of the patch is much better, and maybe ready for checkin.

--
Added file: 
http://bugs.python.org/file39122/larry.one.more.clinic.format.unit.map.cleanup.2.txt

___
Python tracker 

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

[issue24003] variable naming

[Zachary Ware]

Changes by Zachary Ware :


--
stage:  -> resolved

___
Python tracker 

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

[issue24007] Write PyArg_Parse* format in a line with a function

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Proposed patch makes Argument Clinic to output format argument of PyArg_Parse, 
PyArg_ParseTuple and PyArg_ParseTupleAndKeywords in a line with a function 
itself. First, this makes generated code more compact and easier to read and 
compare with old code. Second, it makes easier to grep sources for used format 
units. Format argument always (or almost always) is written in a line with a 
function.

--
components: Argument Clinic, Demos and Tools
files: clinic_format_argument.patch
keywords: patch
messages: 241531
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Write PyArg_Parse* format in a line with a function
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39121/clinic_format_argument.patch

___
Python tracker 

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

[issue23990] Callable builtin doesn't respect descriptors

[Ionel Cristian Mărieș]

Ionel Cristian Mărieș added the comment:

On Sun, Apr 19, 2015 at 9:01 PM, Eric Snow  wrote:

> Finally, instead of changing callable, why not use a metaclass that does
> the right thing?  I believe MagicMock does something along those lines.
>

​What would be the "right thing"? AFAIK this cannot be achieved with a
metaclass, since the check in `callable` just does a dumb check for
`x->ob_type->tp_call​`. Seriously, if you know a way to make
`x->ob_type->tp_call​` run any python code please let me know :-)

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

--

___
Python tracker 

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

[issue24000] More fixes for the Clinic mapping of converters to format units

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> I disagree. My goal with Argument Clinic is that third-party developers will 
> use it to write extensions.  And we don't know how many extension modules are 
> using es, es#, et, et#, s#, y#, z#, u#, and U#.  I don't think we can remove 
> any of this functionality until 4.0.

But we can deprecate them sooner.

--

___
Python tracker 

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