date:20170206


Raymond Hettinger added the comment:

This mostly looks correct.

I would change "bitwise-OR‘ed" to "bitwise ORed".  That latter form without the 
hyphen or apostrophe matches what is used in library/winsound.rst.

Once that change is made (in two places), go ahead an apply the patch.

--

___
Python tracker 

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

[issue29459] `contains` and `get` methods for match objects?

2017-02-06 Thread irdb


New submission from irdb:

__getitem__ was added to match objects as a resolution of issue24454.

Wouldn't it be nice to also have `__contains__` and `get` methods for match 
objects? Is it even feasible to implement them in neat way?

They should work similar to dictionaries, i.e:

```
match = re.match('(?Pa)', 'a')
match.get('b')  # should return None
match.get(1)  # should return 'a'
'a' in match # True
'b' in match # False
```

--
components: Library (Lib)
messages: 287096
nosy: eric.smith, irdb, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: `__contains__` and `get` methods for match objects?
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue29449] clear() should return prior state in threading.Event


Raymond Hettinger added the comment:

> A return value from clear will indicate to a thread if it 
> won the race to clear the event.

Why would we care who won the race to clear? I would think that the important 
thing is that the event is cleared, not who did it.

--
nosy: +rhettinger
priority: normal -> low

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


New submission from Serhiy Storchaka:

Proposed patch makes _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and 
_PyArg_NoPositional() macros. This eliminates the overhead of the cross-module 
function call in common case.

This idea was previously discussed in issue26822 and raised again in issue29452.

--
components: Interpreter Core
files: _PyArg_NoKeywords_macro.patch
keywords: patch
messages: 287098
nosy: haypo, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Speed up _PyArg_NoKeywords() and like
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file46537/_PyArg_NoKeywords_macro.patch

___
Python tracker 

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

[issue26822] itemgetter/attrgetter/methodcaller objects ignore keyword arguments


Serhiy Storchaka added the comment:

Seems I missed to attach a patch. Opened issue29460 for this tweak.

--

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate


Serhiy Storchaka added the comment:

This already was discussed in issue26822. Issue29460 makes 
_PyArg_NoStackKeywords() cheaper.

--

___
Python tracker 

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

[issue29459] `contains` and `get` methods for match objects?


Serhiy Storchaka added the comment:

I predicted that that change will open a can of worms.

The match object is not a dictionary. I don't see a need in new methods. The 
get() method you propose looks virtually the same as the group() method. "'a' 
in match" is virtually the same as "match.get('a') is not None".

--

___
Python tracker 

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

[issue29028] Use-After-Free in PyString_FromStringAndSize() of stringobject.c


Serhiy Storchaka added the comment:

I wanted first to finish issue27867 (expose new API as public). But this is not 
needed for this issue.

--
dependencies:  -various issues due to misuse of PySlice_GetIndicesEx
resolution:  -> fixed
stage: patch review -> 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

[issue29459] `contains` and `get` methods for match objects?


Raymond Hettinger added the comment:

+1 for m.get(key[, default])
-1 for __contains__

The get() makes logical sense and it is perfectly reasonable to want a default 
value for a missing group.

The contains idea makes less sense and is problematic on several fronts.  "'a' 
in match" only works if the match object is not None but it looks like a 
traditional membership test.  Also, I think it will lead to confusion over 
whether contains is testing the key or the value:

  m = re.match('(?P[ab])', 'a')
  'a' in m# True
  'b' in m# False

  m = re.match('(?P[ab])', 'b')
  'a' in m# True  
  'b' in m# False

  m = re.match('(?P[ab])', 'c')
  'a' in m# TypeError
  'b' in m# TypeError

IMO, it is better to leave out __contains__ and let people just use groupdict() 
where they know for sure that normal dict semantics apply.

--
nosy: +rhettinger

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


Raymond Hettinger added the comment:

+1

--

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


Roundup Robot added the comment:

New changeset 82d1c8d15e18 by Serhiy Storchaka in branch 'default':
Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and
https://hg.python.org/cpython/rev/82d1c8d15e18

--
nosy: +python-dev

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> 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

[issue29460] Speed up _PyArg_NoKeywords() and like


STINNER Victor added the comment:

Oh right, I recall that I proposed it. Thanks for this change :-)

The next question might it: would it be worth it to try using unlikely() macro 
on (kwargs == NULL) test in the macro? ;-)

I'm talking about GCC/Clang __builtin_expect:

#define unlikely(x) __builtin_expect((x),0)

--

___
Python tracker 

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

[issue29455] Mention coverage.py in trace module documentation

2017-02-06 Thread Marco Buttu


Marco Buttu added the comment:

I added a "seealso" at the end of the page.

--
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file46538/issue29455.patch

___
Python tracker 

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

[issue29449] clear() should return prior state in threading.Event

2017-02-06 Thread Jyotirmoy Bhattacharya


Jyotirmoy Bhattacharya added the comment:

> > A return value from clear will indicate to a thread if it
> > won the race to clear the event.
>
> Why would we care who won the race to clear? I would think that the
> important thing is that the event is cleared, not who did it.
>

Here's the scenario that prompted my report: the Event is set to indicate
that certain 'work' has accumulated and one among a pool of workers uses
clear() to claim the work accumulated till that point. If clear() returned
a value, we could easily ensure that only one among the workers woken up
actually does the work.

Of course, in this case it would be more efficient to wake up just one
worker using a Condition object and notify() but then one has to write the
logic to maintain the state of the event. An Event whose clear() returned a
value would allow for a quick and dirty solution.

--

___
Python tracker 

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

[issue29449] clear() should return prior state in threading.Event


Serhiy Storchaka added the comment:

> A return value from clear will indicate to a thread if it won the race to 
> clear the event.

I think other synchronization primitives should be used for this. I'm not sure 
that other implementations of Event (e.g. multiprocessing.Event) can 
efficiently return the previous state.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


Roundup Robot added the comment:


New changeset f5ef851ff6b26529382747cfea4674158c7c1ebc by Serhiy Storchaka in 
branch 'master':
Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and
https://github.com/python/cpython/commit/f5ef851ff6b26529382747cfea4674158c7c1ebc


--

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


Serhiy Storchaka added the comment:

> The next question might it: would it be worth it to try using unlikely()
> macro on (kwargs == NULL) test in the macro? ;-)

Perhaps this may help in some critical tight loops (in implementations of 
dict, string operations or long integer arithmetic), but I doubt it can have 
any measurable effect when used once per a call of a function calling 
PyArg_Parse* and using many other stuff.

--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

New submission from STINNER Victor:

Attached patch is an attempt to use the GCC/Clang __builtin_expect() attribute
to provide the compiler with branch prediction information, it adds
_Py_likely() and _Py_unlikely() macros, similar to the Linux kernel macros.

I always wanted to experiment this change. I opened this issue to collect
information and benchmark results to take a decision. I doubt that the change
will really make Python faster, there is a risk of modifying a lot of code for
no value, or worse: make Python slower. Extract of GCC doc:

"as programmers are notoriously bad at predicting how their programs actually
perform."

My patch marks error cases as unlikely. A profiler like Linux perf should be
used to check which branches are less likely, but I tried to use my guesses to
expeeriment a first change.

Since there is a risk that using such macro makes the code slower, or has no
effect, I tried to restrict changes to the hot code and the most common
functions/macros:

* Py_EnterRecursiveCall()
* _PyArg_NoKeywords()
* Py_DECREF()... not sure about this case, is it really more likely that refcnt
!= 0 than refcnt==0?
* Functions to call functions: _PyObject_FastCallKeywords(), fast_function(),
etc.
* etc.

I'm not sure about the methodology to benchmark such patch neither. Is it worth
it to benchmark a Python compiled without PGO?

By the way, does GCC/Clang use __builtin_expect() information when Python is
compiled with PGO? If PGO ignores this information, it would be better to not
use it, since I now strongly recommend to use PGO. Otherwise, Python
performance is too random because of the joy of code placement.

Some links on __builtin_expect():

* http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html
*
http://stackoverflow.com/questions/109710/likely-unlikely-macros-in-the-linux-kernel-how-do-they-work-whats-their
* https://news.ycombinator.com/item?id=9411227

--
files: likely.patch
keywords: patch
messages: 287112
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Experiment usage of likely/unlikely in CPython core
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file46539/likely.patch

___
Python tracker

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

[issue29461] Experiment usage of likely/unlikely in CPython core


STINNER Victor added the comment:

Copy of msg287111 (issue #29460), Serhiy Storchaka (serhiy.storchaka):

> The next question might it: would it be worth it to try using unlikely()
> macro on (kwargs == NULL) test in the macro? ;-)

Perhaps this may help in some critical tight loops (in implementations of 
dict, string operations or long integer arithmetic), but I doubt it can have 
any measurable effect when used once per a call of a function calling 
PyArg_Parse* and using many other stuff.

--

___
Python tracker 

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

[issue29460] Speed up _PyArg_NoKeywords() and like


STINNER Victor added the comment:

I created the issue #29461: "Experiment usage of likely/unlikely in CPython 
core".

--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

2017-02-06 Thread Christian Heimes


Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core


STINNER Victor added the comment:

http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html

Using __builtin_expect() in a very long loop 10^9 iteratos (1,000,000,000) 
makes the loop 15% faster (2.67 sec => 2.28 sec), *but*  using PGO avoids the 
need of using __builtin_expect() explicitly and makes the code 27% faster (2.67 
sec => 1.95 sec):

"This optimized version runs significantly faster (1.95 versus 2.28 seconds) 
than our version that used __builtin_expect(). This is because, in addition to 
the branching in the if statement, the branching in the for loops was also 
optimized."

The article also confirms that if __builtin_expect() is misused, it makes the 
code 5% slower (2.67 sec => 2.79 sec).

--

Another story related to micro-optimization in the Linux kernel.

The Linux kernel used explicit prefetch in some tiny loops. After many 
benchmarks, it was concluded that letting the developer uses prefetch makes the 
code slower, and so the micro-optimization was removed:

https://lwn.net/Articles/444336/

“So the conclusion is: prefetches are absolutely toxic, even if the NULL ones 
are excluded.”

--

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

2017-02-06 Thread Berker Peksag


Berker Peksag added the comment:

Thanks for the patch and sorry for my late response. I did some tweaks and am 
planning to commit the tweaked version of your patch this week.

--
Added file: http://bugs.python.org/file46540/issue24459_cleanup.diff

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate


STINNER Victor added the comment:

> Over this looks good.  Just one other minor tweak (one that has served me 
> well elsewhere) would be to bypass the cross-module function call with a 
> cheap (near zero cost) register variable test: (...)

This has just been optimized by Serhiy, change 82d1c8d15e18.

So, is deque-2.patch good now?

--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core


STINNER Victor added the comment:

Benchmarks with Python compiled by gcc -O3 (without PGO).

haypo@smithers$ ./python -m perf timeit 'len("abc")' --duplicate=1000 
--compare-to=../default-ref/python
Median +- std dev: [ref] 40.4 ns +- 0.8 ns -> [likely] 40.8 ns +- 2.1 ns: 1.01x 
slower (+1%)

haypo@smithers$ ./python -m perf timeit 'sum(())' --duplicate=1000 
--compare-to=../default-ref/python -p3
Median +- std dev: [ref] 86.4 ns +- 2.8 ns -> [likely] 86.3 ns +- 0.3 ns: 1.00x 
faster (-0%)
Not significant!

haypo@smithers$ ./python -m perf timeit -s 's=list("abc")' 'sorted(s)' 
--duplicate=100 --compare-to=../default-ref/python -p3
Median +- std dev: [ref] 224 ns +- 3 ns -> [likely] 222 ns +- 1 ns: 1.01x 
faster (-1%)

--

___
Python tracker 

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

[issue24459] Mention PYTHONFAULTHANDLER in the man page

2017-02-06 Thread Berker Peksag


Changes by Berker Peksag :


Added file: http://bugs.python.org/file46541/issue24459_cleanup_2.diff

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

2017-02-06 Thread Alessandro Vesely


New submission from Alessandro Vesely:

Comments are allowed almost everywhere in an email message, and should be 
eliminated before attributing any meaning to a field.  In the words of RFC5322, 
any CRLF that appears in FWS is semantically "invisible".

In particular, some note that comments can be used to deceive an email filter.  
For example, like so:

Content-Disposition: attachment;
 filename=''attached%2E";
 filename*1*="%62";
 filename*2=(fool filters)at

(I don't know which, if any, email clients would execute that batch...)

Anyway, removing comments is needed for any structured header field.  One is 
usually interested in the unfolded, de-commented value.  It is difficult to do 
correctly, because of nesting and quoting possibilities.

This issue seems to be ignored, except for address lists (there is a 
getcomment() member in AddrlistClass).  Why?

--
components: email
messages: 287119
nosy: ale2017, barry, r.david.murray
priority: normal
severity: normal
status: open
title: RFC822-comments in email header fields can fool, e.g., get_filename()
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

2017-02-06 Thread INADA Naoki


INADA Naoki added the comment:

I've tried to update ast_opt.c[t] without changing AST.
But I can't find clear way to solve "foo" + "bar" docstring problem.

This patch adds only docstring to AST.

--
Added file: http://bugs.python.org/file46542/ast-docstring.patch

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer


STINNER Victor added the comment:

Naoki: Can you please open a new issue for your ast-docstring.patch change? I 
like it, but this issue became too big, and I'm not sure that everyone in the 
nosy list is interested by this specific change.

--

___
Python tracker 

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

[issue29362] regrtest: don't fail immediately if a child does crash


Roundup Robot added the comment:

New changeset 4446613000a3 by Victor Stinner in branch 'default':
regrtest: don't fail immediately if a child does crash
https://hg.python.org/cpython/rev/4446613000a3

--
nosy: +python-dev

___
Python tracker 

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

[issue29362] regrtest: don't fail immediately if a child does crash


Roundup Robot added the comment:


New changeset 99e4e687145a76ac28055a651ee31470496c3ac7 by Victor Stinner in 
branch 'master':
regrtest: don't fail immediately if a child does crash
https://github.com/python/cpython/commit/99e4e687145a76ac28055a651ee31470496c3ac7


--

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

2017-02-06 Thread Alex Gaynor


Changes by Alex Gaynor :


--
nosy:  -alex

___
Python tracker 

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

[issue29362] regrtest: don't fail immediately if a child does crash


STINNER Victor added the comment:

I fixed regrtest in Python 3.7. Maybe I will backport the fix later to other 
branches, but I prefer to limit regrtest changes in stable branches.

--
resolution:  -> fixed
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

[issue26901] Argument Clinic test is broken


Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue29300] Modify the _struct module to use FASTCALL and Argument Clinic


STINNER Victor added the comment:

@Serhiy: Can we please now close this issue? Or is there still something to do?

--

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations


Roundup Robot added the comment:

New changeset ca2f024ce7cb by Victor Stinner in branch 'default':
Prohibit implicit C function declarations
https://hg.python.org/cpython/rev/ca2f024ce7cb

--
nosy: +python-dev

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations


STINNER Victor added the comment:

Martin Panter: "If there is an obscure platform where we don’t include the 
right header file for a function, changing the warning into an error would 
cause the build to fail."

In my experience, calling a function which was not declared is very likely to 
cause a bug, or a crash in the worst case. For example, on 64-bit, if the 
return type is a pointer, the C compiler uses the int type by default, whereas 
a pointer is 32-bit, not 64-bit, and so it will immediately crash.

Martin: "If we do make it an error, it should only be so for 3.7."

Ok. I pushed the patch to Python 3.6.


@Chi Hsuan Yen: Thanks for the patch! Is this change enough to fix the crypt 
build issue? If yes, can we close the issue?

It is likely that the cause causes compilation errors on some platforms where 
we call non-existent functions or call functions with a missing header. IMHO 
it's a good thing to get a build error rather than a crash at runtime.

A concrete issue is that the compilation of the curses module will probably 
fails now on Solaris: issue #13552, whereas before the build only emitted 
warnings. The curses module is broken for years on Solaris, and it seems like 
nobody is able to fix it, so it's not a big deal.

--

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations

2017-02-06 Thread Chi Hsuan Yen


Chi Hsuan Yen added the comment:

> If yes, can we close the issue?

Yes and thanks! As a side note, on Android it prevents broken 
grp.cpython-37m.so, too.

--
resolution:  -> fixed
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

[issue29457] strftime('%x') does not use my locale


R. David Murray added the comment:

Yes, it is the default behavior, because the default locale, as for most 
(almost all?) programming languages (not just Python), is the C locale, until 
you change it.  The reason for this is to get consistent behavior no matter 
what the locale is set to, unless you explicitly enable the local locale (or 
some other locale) in your program.

Whether it is worth adding a link is a separate question, but we really don't 
get this question often, unlike some other FAQs.

--
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

[issue27659] Prohibit implicit C function declarations


STINNER Victor added the comment:

Oh by the way, if someone sees a build error because of a missing function 
declaration, please report a new issue.

--

___
Python tracker 

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

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

2017-02-06 Thread Stefan Krah


Stefan Krah added the comment:

If the API can still change (msg287083), I think I'll wait with this until 
shortly before 3.7 beta.

--

___
Python tracker 

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

[issue27659] Prohibit implicit C function declarations


Roundup Robot added the comment:


New changeset 9a26d20d2baa27407501b13435d733dcc26f3d53 by Victor Stinner in 
branch 'master':
Prohibit implicit C function declarations
https://github.com/python/cpython/commit/9a26d20d2baa27407501b13435d733dcc26f3d53


--

___
Python tracker 

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

[issue29301] decimal: Use FASTCALL and/or Argument Clinic


STINNER Victor added the comment:

> If the API can still change (msg287083), I think I'll wait with this until 
> shortly before 3.7 beta.

I do not understand why Serhiy keeps repeating that the API is going to change, 
I have no such plan. IMHO the FASTCALL API is now very well defined: (PyObject 
**args, Py_ssize_t nargs, PyObject *kwnames), and helper functions are now well 
tested.

We might optimize Argument Clinic further, but for decimal, it seems like it's 
a no-no and that direct usage of METH_FASTCALL is preferred.

So no, I don't plan or expect any API change.

--

___
Python tracker 

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

[issue23980] Documentation for format units starting with 'e' is inconsistent


Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()


R. David Murray added the comment:

My reading of rfc 2231 is that CFWS is not allowed in that position.  Can you 
explain your interpretation with specific cites to the RFC?

Also please provide an example of specific behavior of the email package that 
you think is incorrect.  An email processor should always be treating a 
filename as a dirty string, so I'm not clear on what you are worried about here.

--

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()


R. David Murray added the comment:

Oh, and the answer to you "why" is that the email package is only dealing with 
content semantically in address lists.  Everywhere else it is up to the library 
using program to interpret the structured headers.  In 2.7 the email package 
provides you the tools to process emails, but does not do very much hand 
holding.  The python3 email package tries to do a much better job; but, 
frankly, I skimped on handling comments and have done almost no testing of the 
code that theoretically handles them, since they are so rarely encountered in 
the wild.  Specifically they are supposed to be correctly parsed, but there is 
no way to access comment content and, as I said, there are few to zero tests 
that include comments to validate that syntactic handling. 

I would be interested in patches to complete the comment support in 
_header_value_parser in python3.

--

___
Python tracker 

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

[issue29463] Change docstring to attribute from first statement.

2017-02-06 Thread INADA Naoki


New submission from INADA Naoki:

spin off of #11549.

http://bugs.python.org/issue11549#msg130955

> b) Docstring is now an attribute of Module, FunctionDef and ClassDef, > 
> rather than a first statement. Docstring is a special syntactic 
> construction, it's not an executable code, so it makes sense to separate it. 
> Otherwise, optimizer would have to take extra care not to introduce, change 
> or remove docstring. For example:
>
>  def foo():
>"doc" + "string"
>
>Without optimizations foo doesn't have a docstring. After folding, however, 
>the first statement in foo is a string literal. This means that docstring 
>depends on the level of optimizations. Making it an attribute avoids the 
>problem.

--
files: ast-docstring.patch
keywords: patch
messages: 287136
nosy: haypo, inada.naoki
priority: normal
severity: normal
status: open
title: Change docstring to attribute from first statement.
versions: Python 3.7
Added file: http://bugs.python.org/file46543/ast-docstring.patch

___
Python tracker 

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

[issue27051] Create PIP gui

2017-02-06 Thread Nick Coghlan


Nick Coghlan added the comment:

Regarding pip installability, the intended beneficiaries of that are:

* folks *collaborating* on the GUI, since it means it can be installed into 
virtual environments, tested across multiple versions with tox, etc
* developers that would like a pip GUI, and already know how to use "pipsi" to 
install command line applications from PyPI into their own virtual environments
* folks *distributing* the GUI, since being pip installable means that various 
tools like pyp2rpm, PyInstaller, etc, should be better able to work with it

You can look at the PyPA sample project for more guidance on getting started 
with that: https://github.com/pypa/sampleproject

--

___
Python tracker 

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

[issue29453] Remove reference to undefined dictionary ordering in Tutorial

2017-02-06 Thread Jim Fasarakis-Hilliard


Jim Fasarakis-Hilliard added the comment:

> But maybe it is worth to mention that the output corresponds to the order of 
> passed keyword arguments
 
Should I add this note? It looks fine to me as is but I'm not the experienced 
one here :-)

--

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate


Raymond Hettinger added the comment:

Yes, go ahead and apply.

--

___
Python tracker 

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

[issue26355] Emit major version based canonical URLs for docs

2017-02-06 Thread Nick Coghlan


Nick Coghlan added the comment:

Thanks Matthias!

Regarding 2v3, the layout differences aren't a problem, since the canonical 
URLs are separate (/2/* vs /3/*). That's one of the benefits I actually hope 
for with this change - due to PEP 430, deep links still go to the Python 2 
documentation by default, and once this change is made in the Python 2.7 branch 
it should teach search engines that those should start being presented in 
results as "/2/*" qualified links.

We also don't tend to make wholesale changes to the URL layouts in the docs in 
X.Y releases, so I think the assumption of "the relative path of this page 
won't change" is fine.

Georg, Berker - any further thoughts before we make this change to 3.4+ and the 
2.7 docs?

--

___
Python tracker 

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

[issue28870] Reduce stack consumption of PyObject_CallFunctionObjArgs() and like


Changes by STINNER Victor :


--
resolution:  -> fixed
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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate


Roundup Robot added the comment:

New changeset 1c048539200c by Victor Stinner in branch 'default':
Optimize deque index, insert and rotate() methods
https://hg.python.org/cpython/rev/1c048539200c

--
nosy: +python-dev

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate


STINNER Victor added the comment:

Raymond: "Yes, go ahead and apply."

Great, done. Thanks for the reviews Serhiy and Raymond.

As I wrote, you can consider to use Argument Clinic later, but there is no 
urgency for that ;-) I close the issue.

--
resolution:  -> fixed
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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


Changes by Serhiy Storchaka :


--
nosy: +haypo

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


New submission from Serhiy Storchaka:

Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes 
bare METH_FASTCALL be used for functions with positional-only parameters. This 
eliminates small cost that these functions pay for handling empty keywords: 
calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing kwnames. 
This also can slightly reduce stack consumption.

--
components: Interpreter Core
files: fastcall-no-keywords.patch
keywords: patch
messages: 287143
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Specialize FASTCALL for functions with positional-only parameters
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file46544/fastcall-no-keywords.patch

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core


Raymond Hettinger added the comment:

I had read that likely/unlikely were hard to use well and often not worth the 
trouble.   IIRC, they are used extensively in the Linux kernel but people were 
finding zero measurable effect when enabling or disabling the constructs.

--
nosy: +rhettinger

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core

2017-02-06 Thread Christian Heimes


Christian Heimes added the comment:

I would expect that PGO/LGO builds give better improvements with less coding 
bloat. Did you compare a PGO likely/unlikely build against a standard PGO build?

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


STINNER Victor added the comment:

> Proposed patch renames METH_FASTCALL to METH_FASTCALL|METH_KEYWORDS and makes 
> bare METH_FASTCALL be used for functions with positional-only parameters.

While I tried to keep everything related to FASTCALL private, it seems like 
Cython uses some FASTCALL features. I don't know which ones exactly. Well, if 
only one project in the world uses FASTCALL, we can help them to support such 
backward incompatible change ;-)


> This eliminates small cost that these functions pay for handling empty 
> keywords: calling _PyStack_UnpackDict() and _PyArg_NoStackKeywords(), passing 
> kwnames.

My idea when I designed FASTCALL was to move code to parse arguments in the 
function body rather than in _PyCFunction_FastCallKeywords(), and to have a 
single calling function METH_FASTCALL, rather than two (METH_FASTCALL and 
METH_FASTCALL|METH_KEYWORDS).

The long term plan is also to support passing arguments by keyword in more 
functions. IMHO many functions don't accept keywords for technical reasons, but 
once we converted a module, function or type to Argument Clinic, it becomes 
trivial to accept keywords. If most functions accept keywords, I'm not sure 
that having a special case for positional-only is still worth it. But this plan 
was before I had discussions on supporting keywords in unicode methods. In 
fact, it's deliberate to not accept keywords in many functions or methods.

Well, when I see your patch, I see that it removes a lot of code. So it's 
likely to be a good idea :-)


> This also can slightly reduce stack consumption.

You mean the removal of the "PyObject *kwnames" for METH_FASTCALL (positional 
arguments only)? Do you have an idea of the stack usage? Try maybe 
testcapi_stacksize.patch of the issue #28870? It would help to take a decision 
on this change.

--

___
Python tracker 

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

[issue29452] Use FASTCALL for collections.deque methods: index, insert, rotate


Roundup Robot added the comment:


New changeset 55949f988dc1b943796d9852cc4d588c58cc4255 by Victor Stinner in 
branch 'master':
Optimize deque index, insert and rotate() methods
https://github.com/python/cpython/commit/55949f988dc1b943796d9852cc4d588c58cc4255


--

___
Python tracker 

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

[issue29461] Experiment usage of likely/unlikely in CPython core


Serhiy Storchaka added the comment:

I also always wanted to experiment this change. But I was afraid that providing 
such macros can encourage of overusing it. I don't want to wrap any test for 
NULL or -1 with these macros.

If we expect some benefit from using these macros, I would play with them in 
hot loops. For example in dict lookup function (unlikely comparing keys raise 
an exception or dict is modified in process of searching), in codecs (unlikely 
illegal sequence is occurred), etc.

--

___
Python tracker 

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

[issue29301] decimal: Use FASTCALL and/or Argument Clinic


STINNER Victor added the comment:

Oh ok, it seems like Serhiy wants to change METH_FASTCALL. I didn't know :-) He 
just opened the issue #29464: "Specialize FASTCALL for functions with 
positional-only parameters". Interesting idea.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


Serhiy Storchaka added the comment:

We can avoid breaking backward compatibility and introduce new call method 
METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. 
FASTCALL is not a part of stable ABI.

I still didn't do any benchmarking or stack usage measurements.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


STINNER Victor added the comment:

> I still didn't do any benchmarking or stack usage measurements.

I'm running benchmarks on the speed-python server.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters

2017-02-06 Thread Stefan Krah


Stefan Krah added the comment:

Adding Stefan Behnel, perhaps Cython doesn't need backwards compatibility.

--
nosy: +scoder, skrah

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption


New submission from STINNER Victor:

While testing issue #29464 patch, I failed to see a major enhancement on the 
stack usage of fast calls without keyword arguments.

The problem is that functions like _PyObject_FastCallKeywords() and 
_PyObject_FastCallDict() still have to pass a NULL argument for kwargs/kwnames, 
and have code to handle keyword arguments.


Attached patch adds _PyObject_FastCall() to reduce the stack consumption. At 
the C level, keyword arguments are almost never used. For example, 
PyObject_CallFunctionObjArgs() is commonly used, whereas it only uses 
positional arguments.

The patch changes also _PyObject_FastCallKeywords() and 
_PyObject_FastCallDict() to move the "slow" path creating temporary tuple and 
dict in a subfunction which is not inlined. The slow path requires more stack 
memory.

Morecall, _PyObject_FastCallKeywords() and _PyObject_FastCallDict() are 
modified to call _PyObject_FastCall() if there is no keyword.

The patch might make function calls without keyword arguments faster, I didn't 
check.


Stack usage.

$ ./python -c 'import _testcapi, sys; sys.setrecursionlimit(10**5); n=1000; 
s=_testcapi.meth_fastcall_stacksize(n); print("%.1f B/call" % (s/n))'

* Reference: 832.8 B/call
* Patch: 656.6 B/call (-176.2 B)

I don't know why the stack usage is not an integer number of bytes?


Combined with the issue #29464 "Specialize FASTCALL for functions with 
positional-only parameters", the stack usage can be even more reduced by a few 
bytes.


See the issue #28870 for the previous work on reducing stack consumption.

--
components: Interpreter Core
files: pyobject_fastcall.patch
keywords: patch
messages: 287153
nosy: haypo, inada.naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add _PyObject_FastCall() to reduce stack consumption
type: resource usage
versions: Python 3.7
Added file: http://bugs.python.org/file46545/pyobject_fastcall.patch

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption


STINNER Victor added the comment:

meth_fastcall_stacksize.patch: Patch adding 
_testcapi.meth_fastcall_stacksize() to measure the stack usage to call a 
METH_FASTCALL function.

--
Added file: http://bugs.python.org/file46546/meth_fastcall_stacksize.patch

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


STINNER Victor added the comment:

> We can avoid breaking backward compatibility and introduce new call method 
> METH_FASTCALL_NO_KEYWORDS. But combining existing flags looks better to me. 
> FASTCALL is not a part of stable ABI.

If we decide that having two FASTCALL calling convention, I prefer what you 
proposed: METH_FASTCALL (pos only) and METH_FASTCALL|METH_KEYWORDS (pos+kw). As 
you wrote, I like reusing the existing METH_KEYWORDS flag, it reduces the 
surprises if someone ports existing code using METH_VARARGS and 
METH_VARARGS|METH_KEYWORDS.

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


STINNER Victor added the comment:

I measured the stack consumption, it's not better. But I created the issue 
#29465 "Add _PyObject_FastCall() to reduce stack consumption" which would allow 
to reduce the stack consumption with this patch.

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

2017-02-06 Thread George King


George King added the comment:

Attached is a new patch, which does not settrace/gettrace and instead offers 
new settraceinst/gettraceinst per Victor's recommendation.

I did not implement the proposed behavior of raising an exception if the old 
APIs are used when the inst_tracing flag is set. However I do think it makes 
sense to do so.

The new sys.settraceinst function takes two arguments: a function and an 
integer flag that is currently interpreted as a boolean (whether or not to 
enable instruction level tracing).

I did it this way because I would like to consider adding a third mode, which 
would only trigger tracing for interesting control-flow events, namely steps 
for which the previous instruction was a branch. The motivation is that I 
expect per-instruction tracing to be very slow, and for the code coverage use 
case at least, these are the interesting events. For this to be useful, a 
(prev_offset, current_offset) pair would need to be passed as to the trace 
callback. I am not sure if this would be useful to other applications, e.g. pdb.

--
Added file: http://bugs.python.org/file46547/settraceinst.diff

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace


STINNER Victor added the comment:

> I did it this way because I would like to consider adding a third mode, which 
> would only trigger tracing for interesting control-flow events, namely steps 
> for which the previous instruction was a branch.

Hum, let's use https://en.wikipedia.org/wiki/Basic_block terminology.

The callback would be called when you enter and exit a basic block? Or only on 
exit?

Only on conditional branches? Or also on unconditional branches?

In term of instructions, can give examples of instructions which would be 
traced or not?

IMHO the two instruction level modes would be useful.

--

___
Python tracker 

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

[issue29455] Mention coverage.py in trace module documentation

2017-02-06 Thread Brett Cannon


Brett Cannon added the comment:

Thanks for the patch, Marco! Typically we put the mention at the top to give 
the 3rd-party library a better chance of being noticed (see the urllib.request 
docs to see how requests is mentioned).

--
assignee: docs@python -> brett.cannon

___
Python tracker 

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

[issue29441] Update examples to use async and await keywords in asyncio-task.rst

2017-02-06 Thread Guido van Rossum


Guido van Rossum added the comment:

LGTM. Thanks!

--

___
Python tracker 

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

[issue29455] Mention coverage.py in trace module documentation

2017-02-06 Thread Marco Buttu


Marco Buttu added the comment:

Thank you Brett, here is another patch. I added the seealso directive right 
after the introduction of the trace module, in the same way as urllib.request 
does for requests.

--
Added file: http://bugs.python.org/file46548/issue29455_2nd.patch

___
Python tracker 

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

[issue24905] Allow incremental I/O to blobs in sqlite3

2017-02-06 Thread Aviv Palivoda


Aviv Palivoda added the comment:

Uploading patch after fixes from berker CR.

The `blob_open` API can can have the following options:

1. The table, column and row must be mandatory parameters.
2. The read/write permissions can have the following options:
   a. No default (mandatory parameter).
   b. default read-only
   c. default write-only
3. The dbname can be without a default of "main" and then it will be a 
mandatory parameter.

I don't think that there is enough differences between the possible API's to 
justify sending a message to the mailing lists.

--
Added file: http://bugs.python.org/file46549/blob4.patch

___
Python tracker 

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

[issue29466] pickle does not serialize Exception cause field

2017-02-06 Thread Mark Diekhans


New submission from Mark Diekhans:

python3 pickle does not serialize the __cause__ field, as shown by the attached 
demo program.

--
components: Library (Lib)
files: cause_pickle.py
messages: 287163
nosy: diekhans
priority: normal
severity: normal
status: open
title: pickle does not serialize Exception __cause__ field
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46550/cause_pickle.py

___
Python tracker 

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

[issue29425] File-altering aspects of pathlib should return new pathlib objects

2017-02-06 Thread Brett Cannon


Brett Cannon added the comment:

The idea in general seems reasonable. Anyone else have an opinion?

--
nosy: +brett.cannon

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

2017-02-06 Thread George King


George King added the comment:

I'm not sure exactly, but the way I see it (for code coverage), we want to 
trace transitions between basic blocks. So I would define it as: each entry 
into a BB is traced, with a tuple of (previous_offset, current_offset). This 
way when a function call starts, we callback with (-1, 0), and then get a 
callback for every transition between BBs. The code is well covered if we 
observe every possible transition.

I am not clear on the precise details, e.g. regarding unconditional branches. 
Since for code coverage this is essentially on optimization over 
per-instruction mode, I intend to first work out correctness details and test 
cases for the coverage tool, and then once the tests solid add the optimization.

I'm happy to discuss more, but this aspect is a lower priority for me (I still 
have to work out remaining correctness issues with my opcode analysis). Would 
it make sense to split it out into a second issue?

--

___
Python tracker 

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

[issue29466] pickle does not serialize Exception cause field

2017-02-06 Thread Mark Diekhans


Changes by Mark Diekhans :


--
nosy: +alexandre.vassalotti

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()

2017-02-06 Thread Alessandro Vesely


Alessandro Vesely added the comment:

Neither I found CFWS in rfc2231.  In addition, rfc 2045 (Introduction) says 
that Content-Disposition —where filename is defined— cannot include comments.  
However, Content-Type can include RFC 822 comments, so the filename should be 
de-commented in case it is inferred from the name parameter there.

I'm rather new to Python, and sticking to version 2 because of the packages I 
work with.  I see Python3's email has a much more robust design.  Does this 
mean Python2 cannot get fixed?

I attach a de_comment() function, copied from the one I mentioned this morning. 
 The rest of the file shows its intended use.  (Oops, it removes comments even 
from where they are not supposed to be allowed ;-)
Having that kind of functionality in email.utils would make it easier to read 
Message's, no?

--
Added file: http://bugs.python.org/file46551/attachments.py

___
Python tracker 

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

[issue29439] _decimal on Android requires linking with libm

2017-02-06 Thread Xavier de Gaye


Xavier de Gaye added the comment:

With the following module named dlsym.py, the command 'python dlsym.py log10' 
produces the same successful output on linux and on Android API 21 (when 
_decimal is not explicitly linked with libm.so, i.e.without changeset 
b60b46ad8751):
  'The symbol "log10" is resolved.'

-- dlsym.py ---
import sys, os
from ctypes import *

if len(sys.argv) != 2:
sys.exit('Error: the symbol name is required.')
symbol = sys.argv[1]
libdl = CDLL('libdl.so')
libdl.dlopen.restype = c_void_p
libdl.dlsym.restype = c_void_p
hdle = libdl.dlopen(None, os.RTLD_NOW | RTLD_GLOBAL)
if hdle is None:
print('Cannot get a handle on the global symbol object.')
else:
v = libdl.dlsym(c_void_p(hdle), symbol.encode())
_not = 'not ' if v is None else ''
print('The symbol "%s" is %sresolved.' % (symbol, _not))
---

This is as expected since the python executable is linked with the math 
library. However on Android API 21 importing _decimal fails with the error 
message reported earlier:
  'dlopen failed: cannot locate symbol "log10"'.

So this seems to be a bug with Android dlopen() at API 21 since the 'log10' 
symbol does exist in the process image relocation tables as shown by dlsym.py. 
This is confirmed by the fact that the import does not fail anymore at API 24 
(still without changeset b60b46ad8751). This change of behavior may be a side 
effect of the changes reported in this bionic (Android libc) changelog entry:

https://android.googlesource.com/platform/bionic/+show/refs/heads/master/android-changes-for-ndk-developers.md#36

For completness, my (possibly wrong) interpretation of why changeset 
b60b46ad8751 fixes the problem at API 21:
Changeset b60b46ad8751 adds the '-lm' command line option to the linker and 
this adds [1] a new DT_NEEDED entry to the .dynamic section of the shared 
library ELF file as shown by the command 'readelf -d 
build/lib.linux-x86_64-3.7-pydebug/_decimal.cpython-37dm-x86_64-linux-gnu.so':

Dynamic section at offset 0x54d30 contains 26 entries:
  TagType Name/Value
 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libpthread.so.0]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 ...

The Android loader lookup for 'log10' is now successful at API 21 and the 
symbol is found in the libm.so.6 library listed in the DT_NEEDED lists of 
needed libraries.

[1] See option '--as-needed' in the 'ld' man pages or see the ELF 
specification. Note that the Android toolchains use the clang compiler but 
continue to use the GNU binutils tools including the linker 'ld'.

--

___
Python tracker 

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

[issue29439] _decimal on Android requires linking with libm

2017-02-06 Thread Xavier de Gaye


Xavier de Gaye added the comment:

> Perhaps test_decimal should fail for CPython if _decimal can't be imported.
This is not a problem specific to _decimal, the same problem exists for 
third-party extension modules, for example pyephem 
(https://github.com/brandon-rhodes/pyephem/issues/114) and existed with some 
other Python extension modules (issue 21668).

--

___
Python tracker 

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

[issue29232] Quiet Install

2017-02-06 Thread Earl Maier


Earl Maier added the comment:

I have since rebuilt the machine that I was doing my testing on, so I am unable 
grab log files from the installs.  I have not been able to reproduce the issue 
since the rebuild of the machine.  On a good note: Everything is working as it 
should. I appreciate you looking into the issue.  

Thank you

--

___
Python tracker 

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

[issue29462] RFC822-comments in email header fields can fool, e.g., get_filename()


R. David Murray added the comment:

Your thought is correct: python2 no longer gets enhancements.  So improved 
comment handling can only be added to python3, assuming anyone is interested in 
doing it :)

--

___
Python tracker 

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

[issue29371] Typo in doctest documentation

2017-02-06 Thread Mariatta Wijaya


Mariatta Wijaya added the comment:

Thanks, Raymond. I have an updated patch there the hypen and apostrophe are 
removed.

--
versions:  -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file46552/issue29371v2.patch

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

2017-02-06 Thread Riccardo Polignieri


Riccardo Polignieri added the comment:

> I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" 
> undefined. 

I can't say I'm really happy with this answer. Fact is, 
1) you almost always have to work from within a virtual env these days, 
2) you really want to have meaningful shebangs (ie, version-specific) in your 
scripts because, well, 2017 and the world is still split between py2 and py3, 
3) the py.exe launcher is the new shiny thing and we all just want to use it.

So, it *could* annoy some people to find out that py.exe just can't handle both 
venvs and shebangs in a meaningful way, and you must give up on either venvs, 
or shebangs, or py.exe. 

As far as I know (3.6.0 and 2.7.13), you have 3 ways to invoke a script:

1) "version-specific" launcher (eg "py -3 foo.py"): this will always pick the 
system interpreter, never abides neither venvs nor shebangs. A perfectly 
defined, utterly useless behavior. 

2) invoke interpreter (eg "python foo.py", the good old way): this will always 
be venvs-complaint, will never parse shebangs. And yet at the moment, it's 
probably your best option *when* inside a venv - and the worst when outside, of 
course. 

3) "version-agnostic" launcher (eg "py foo.py"). Outside a venv, this will 
always abide version-specific shebangs (ie, "#!python3"); the only quirk being 
that when facing a generic shebang instead, it will pick Python 2 (because, 
2017 and Linux...). Oh well, I can live with that. 
But when you are inside a venv, then
- if it finds a "not-env" shebang (ie "python" or "/usr/bin/python"), then it 
will NOT abide the venv - frustrating, yet correct I suppose;
- if it finds any kind of version-specific shebang (EVEN a "env"-type of 
shebang!), then again it will follow the shebang but NOT the venv, and will 
pick up the system interpreter. That, even when you are inside a venv that 
perfectly matches the shebang prescription. 

Now, this can be very frustrating because a useless "/usr/bin/env python" 
shebang triggers the correct behavior both inside and outside a venv, BUT a 
much more useful "usr/bin/env python3" will fail even if we are inside a 
matching venv. 

I feel that all it needs to be perfect is some kind of behavior like this: dear 
py.exe, 
- when you are invoked in a version-agnostic way, and 
- when you find an "env"-and-version-specific shebang in the script, 
then please, 
- just look at my %path% before doing anything else. It could be that the first 
interpreter you find there will just match the requirement from the shebang 
(that is, because on occasion I just know what I'm doing, and I've just 
activated a matching venv, you see). If so, just give me that Python and I will 
be ok; 
- otherwise, my bad: feel free to resume any other search strategy you find 
appropriate, and I will humbly accept whatever interpreter you may fetch, even 
a php one. 

I think this would be just reasonable enough. What I'm missing here?

--
nosy: +ricpol

___
Python tracker 

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

[issue29467] Allow return mismatch to be caught by function

2017-02-06 Thread Ted Shaneyfelt


New submission from Ted Shaneyfelt:

def f():
try: return 0
except: return 1,2

x = f() # x is 0
x,y = f() # proposal: x,y should be 1,2 instead of uncaught TypeError

It would make sense to be able to catch [TypeError: 'int' object is not 
iterable] and return the correct number of values. Yes, the way it's done now, 
the function is no longer running when it is caught - but is it possible and 
practical to determine if parameters match before the function returns instead 
of afterward, allowing the called function to catch the error attempting to 
return?

--
components: Interpreter Core
messages: 287173
nosy: Ted Shaneyfelt
priority: normal
severity: normal
status: open
title: Allow return mismatch to be caught by function
type: enhancement
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

[issue28686] py.exe ignored PATH when using python3 shebang

2017-02-06 Thread Paul Moore


Paul Moore added the comment:

> 2) you really want to have meaningful shebangs (ie, version-specific) in your 
> scripts because, well, 2017 and the world is still split between py2 and py3, 

This is the one I think is overspecifying. I don't see a really *good* reason 
for not just saying /usr/bin/env python.

What would you want to happen if you said /usr/bin/env python3 if you had 
Python 2 on your PATH? The only reasonable answer I can see is "give an error", 
so why not just put

if sys.version_info < (3,0):
raise RuntimeError("Needs python 3")

at the top of your script?

Add to this the fact that I don't even know how you'd check if a python 
interpreter that's on PATH is Python 2 or 3 without executing it (and the 
overhead of running it an extra time to query its version is unacceptable) and 
I still don't see the justification.

> - just look at my %path% before doing anything else. It could be that the 
> first interpreter you find there will just match the requirement from the 
> shebang (that is, because on occasion I just know what I'm doing, and I've 
> just activated a matching venv, you see). If so, just give me that Python and 
> I will be ok; 
> - otherwise, my bad: feel free to resume any other search strategy you find 
> appropriate, and I will humbly accept whatever interpreter you may fetch, 
> even a php one. 

> I think this would be just reasonable enough. What I'm missing here?

You're missing the fact that it's not possible to tell by inspection the 
version of a Python interpreter. On Unix, the executable name includes the 
version, so it's easy. If Python on Windows changed to ship python3.exe and 
python37.exe alongside python.exe, then it might be worth revisiting this 
discussion, but not as things stand (IMO).

--

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

2017-02-06 Thread Steve Dower


Steve Dower added the comment:

> If Python on Windows changed to ship python3.exe and python37.exe alongside 
> python.exe, then it might be worth revisiting this discussion

Agreed, though if we started including versioned executables wouldn't that 
resolve this issue naturally? (As in, we'd search for python3.exe and find it?)

FWIW, I'm not a huge fan of including versioned executables - I would much 
rather include versioned *launchers*, so we can put them all in the one 
directory and avoid cluttering the search path (i.e. rename "py.exe" to 
"python.exe", "python2.exe" and "python3.exe" and have it check its own name 
before searching).

--

___
Python tracker 

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

[issue29464] Specialize FASTCALL for functions with positional-only parameters


STINNER Victor added the comment:

Hum, benchmark results don't seem good. There is probably a performance bug 
somewhere. I should investigate further to analyze these results. M aybe 
combined with the issue #29465, results will be better.

haypo@speed-python$ python3 -m perf compare_to 
~/benchmarks/2017-02-06_07-15-default-e06af4027546.json 
fastcall-no-keywords_ref_e06af4027546.json -G --min-speed=5

Slower (19):
- unpickle_list: 6.36 us +- 0.11 us -> 8.08 us +- 0.14 us: 1.27x slower (+27%)
- pickle_list: 7.53 us +- 0.41 us -> 8.62 us +- 0.49 us: 1.14x slower (+14%)
- crypto_pyaes: 199 ms +- 2 ms -> 226 ms +- 2 ms: 1.13x slower (+13%)
- pickle: 22.1 us +- 0.3 us -> 24.9 us +- 0.3 us: 1.12x slower (+12%)
- nbody: 233 ms +- 2 ms -> 260 ms +- 2 ms: 1.12x slower (+12%)
- xml_etree_iterparse: 179 ms +- 4 ms -> 198 ms +- 5 ms: 1.11x slower (+11%)
- telco: 14.7 ms +- 0.3 ms -> 16.3 ms +- 0.5 ms: 1.11x slower (+11%)
- pickle_dict: 56.6 us +- 4.3 us -> 62.7 us +- 4.7 us: 1.11x slower (+11%)
- pidigits: 291 ms +- 1 ms -> 319 ms +- 1 ms: 1.10x slower (+10%)
- scimark_fft: 662 ms +- 10 ms -> 717 ms +- 8 ms: 1.08x slower (+8%)
- scimark_monte_carlo: 207 ms +- 4 ms -> 224 ms +- 6 ms: 1.08x slower (+8%)
- regex_v8: 43.7 ms +- 0.6 ms -> 47.0 ms +- 0.3 ms: 1.08x slower (+8%)
- float: 238 ms +- 3 ms -> 254 ms +- 4 ms: 1.07x slower (+7%)
- xml_etree_parse: 242 ms +- 5 ms -> 257 ms +- 9 ms: 1.06x slower (+6%)
- raytrace: 1.04 sec +- 0.01 sec -> 1.11 sec +- 0.01 sec: 1.06x slower (+6%)
- unpickle: 30.0 us +- 0.3 us -> 31.8 us +- 0.3 us: 1.06x slower (+6%)
- go: 493 ms +- 7 ms -> 520 ms +- 6 ms: 1.05x slower (+5%)
- scimark_sparse_mat_mult: 8.24 ms +- 0.14 ms -> 8.69 ms +- 0.14 ms: 1.05x 
slower (+5%)
- chaos: 234 ms +- 2 ms -> 246 ms +- 4 ms: 1.05x slower (+5%)

Faster (2):
- chameleon: 21.9 ms +- 0.2 ms -> 20.7 ms +- 0.3 ms: 1.06x faster (-5%)
- sympy_expand: 949 ms +- 12 ms -> 899 ms +- 11 ms: 1.06x faster (-5%)

Benchmark hidden because not significant (43): (...)

--

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths


Roundup Robot added the comment:

New changeset 4463e311f5bd by Steve Dower in branch '3.6':
Issue #28164: Improves test on Windows 7
https://hg.python.org/cpython/rev/4463e311f5bd

New changeset 8132bcc1522d by Steve Dower in branch 'default':
Issue #28164: Improves test on Windows 7
https://hg.python.org/cpython/rev/8132bcc1522d

--

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths

2017-02-06 Thread Steve Dower


Steve Dower added the comment:

That test looks good for me, and I verified it on both Win7 and Win10. 
(Hopefully we don't have any Win8.1 edge cases in here...)

--
status: open -> closed

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths


Roundup Robot added the comment:


New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch 
'master':
Issue #28164: Improves test on Windows 7
https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b

New changeset dc5c4bc90770d6a5875666434cf797c77eb3dcad by Steve Dower in branch 
'master':
Issue #28164: Improves test on Windows 7
https://github.com/python/cpython/commit/dc5c4bc90770d6a5875666434cf797c77eb3dcad


--

___
Python tracker 

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

[issue28164] _PyIO_get_console_type fails for various paths


Roundup Robot added the comment:


New changeset c6c32889c9d80ffd599a57fd0d4c4a88deece29b by Steve Dower in branch 
'3.6':
Issue #28164: Improves test on Windows 7
https://github.com/python/cpython/commit/c6c32889c9d80ffd599a57fd0d4c4a88deece29b


--

___
Python tracker 

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

[issue28686] py.exe ignored PATH when using python3 shebang

2017-02-06 Thread Paul Moore


Paul Moore added the comment:

I agree, I don't particularly want versioned executables. I'm not sure I see 
much point to even having versioned launchers - "py -2" and "py -3" seem fine 
to me if needed.

The only use cases I can see are:

1. Use the Python executable that's first on PATH: "py"
2. Use the specific system installation of Python X[.Y]: "py -X[.Y]"

For shebang usage:

1. Use the Python executable that's first on PATH: "#!/usr/bin/env python"
2. Use the specific system installation of Python X[.Y]: 
"#!/usr/bin/pythonX[.Y]"
3. Use a specific interpreter: "#!"

The Unix ability to have 2 different versions of Python on PATH and select 
which you use based on executable name doesn't exist on Windows, and so there's 
no equivalent of the Unix "#!/usr/bin/env pythonX[.Y]"

If you want your script to fail under certain conditions - whether it's that 
the interpreter is a version you don't support, or something else, then test 
for that case and fail with an error. Checking runtime conditions doesn't need 
to be handled by the shebang.

The only change I'd consider reasonable here would be a doc change to explain 
the behaviour a bit more clearly. I might try to put something together if I 
have the time.

--

___
Python tracker 

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

[issue29467] Allow return mismatch to be caught by function

2017-02-06 Thread Eric V. Smith


Eric V. Smith added the comment:

Thanks for the suggestion. However, I don't think it's possible or desirable 
for python to implement this.

There are two problems: 1) the internals of python would have to be drastically 
changed to support this, and 2) you'd need different syntax to support this.

For item 2, consider:

def f():
try: return some_other_function()
except: return 1,2

You can't distinguish between your proposed type mis-match exception and 
some_other_function() raising a TypeError. I suppose you could invent another 
exception type, but you'll always have a similar problem.

A larger problem is that this behavior would be confusing to both newcomers and 
existing programmers, it adds nothing that can't currently be done, and it 
would be a source of subtle bugs.

If you really want to explore this, I suggest working out a more complete 
example and bringing it up on the python-ideas mailing list.

You'll want to include code that currently exists that would be made simpler 
with your proposal. If you can find any such code in the standard library, that 
would be a bonus.

Thanks again.

--
nosy: +eric.smith
resolution:  -> rejected
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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption


STINNER Victor added the comment:

pyobject_fastcall-2.patch: More complete changes. Sorry, the patch also 
contains unrelated refactoring! It's a more advanced implementation which tries 
to reduce the depth of the C backtrace. For example, _PyObject_FastCall() is 
now inlined manually in _PyObject_FastCallDict(). PyObject_Call() is also 
rewritten. If the overall approach is validated, I will rewriten the patch 
differently to limit changes, or push some changes in multiple commits.

Results of testcapi_stacksize.patch + stack_overflow_28870-sp.py (from issue 
#28870).

Reference:

haypo@smithers$ ../default-ref/python stack_overflow_28870-sp.py 
test_python_call: 8586 calls before crash, stack: 976 bytes/call
test_python_getitem: 9188 calls before crash, stack: 912 bytes/call
test_python_iterator: 7936 calls before crash, stack: 1056 bytes/call

=> total: 25710 calls, 2944 bytes

Patch:

haypo@smithers$ ./python stack_overflow_28870-sp.py 
test_python_call: 9883 calls before crash, stack: 848 bytes/call (-128 B)
test_python_getitem: 10476 calls before crash, stack: 800 bytes/call (- 112 B)
test_python_iterator: 8878 calls before crash, stack: 944 bytes/call (- 112 B)

=> total: 29237 calls (+3616), 2592 bytes (- 352 B)

--
Added file: http://bugs.python.org/file46553/pyobject_fastcall-2.patch

___
Python tracker 

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

[issue29465] Add _PyObject_FastCall() to reduce stack consumption