[issue10697] host and port attributes not documented well in function urllib.parse.urlparse and urlsplit

[Senthil Kumaran]

Senthil Kumaran added the comment:

I am unsure of the change too. I am willing to close this report as .port 
attribute is already documented.

--
resolution:  -> not a bug
stage: needs patch -> resolved
status: pending -> closed

___
Python tracker 

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

[issue13312] test_time fails: strftime('%Y', y) for negative year

[Martin Panter]

Martin Panter added the comment:

If you enable GCC’s -ftrapv option, the subtraction overflow triggers an abort. 
Alexander’s patch works around the problem for asctime(), but the problem still 
exists in other cases, such as:

>>> time.mktime((-2**31 + 1899, *(0,) * 8))
Aborted (core dumped)
[Exit 134]

Attaching a version of the patch without the conflicting whitespace changes.

Why does Python even need to support such extreme time values? It would seem 
much simpler to raise an exception.

--
nosy: +martin.panter
Added file: http://bugs.python.org/file43709/issue13312.v2.patch

___
Python tracker 

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

[issue27369] Tests break with --with-system-expat and Expat 2.2.0

[Berker Peksag]

Changes by Berker Peksag :


--
stage: patch review -> resolved
title: [PATCH] Tests break with --with-system-expat and Expat 2.2.0 -> Tests 
break with --with-system-expat and Expat 2.2.0

___
Python tracker 

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

[issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC

[Berker Peksag]

Berker Peksag added the comment:

Sorry, I finally found some time to clear my CPython TODO list. Thanks for the 
patch, Evelyn!

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

[issue26446] Mention in the devguide that core dev stuff falls under the PSF CoC

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6b4b73ebb054 by Berker Peksag in branch 'default':
Issue #26446: Mention PSF CoC in core developer responsibilities
https://hg.python.org/devguide/rev/6b4b73ebb054

--
nosy: +python-dev

___
Python tracker 

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

[issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename())

[Roundup Robot]

Roundup Robot added the comment:

New changeset 270fd4493195 by Berker Peksag in branch '3.5':
Issue #27180: Clarify Path.rename() behavior on Unix systems
https://hg.python.org/cpython/rev/270fd4493195

New changeset 89821243621b by Berker Peksag in branch 'default':
Issue #27180: Merge from 3.5
https://hg.python.org/cpython/rev/89821243621b

--
nosy: +python-dev

___
Python tracker 

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

[issue27180] Doc/pathlib: Please describe the behaviour of Path().rename() is depends on the platform (same as os.rename())

[Berker Peksag]

Berker Peksag added the comment:

Thanks!

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Xiang Zhang]

Xiang Zhang added the comment:

Nice to see the real example. I don't think of that.

--

___
Python tracker 

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

[issue27455] Fix tkinter examples to be PEP8 compliant

[Berker Peksag]

Berker Peksag added the comment:

Since Terry is already busy with IDLE maintenance, I went ahead and commit the 
patch with minor modifications. Thanks for the patch, John! :)

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

[issue27455] Fix tkinter examples to be PEP8 compliant

[Roundup Robot]

Roundup Robot added the comment:

New changeset 453a88a41a58 by Berker Peksag in branch '3.5':
Issue #27455: Improve examples in tkinter documentation
https://hg.python.org/cpython/rev/453a88a41a58

New changeset 800c069e16a0 by Berker Peksag in branch 'default':
Issue #27455: Merge from 3.5
https://hg.python.org/cpython/rev/800c069e16a0

--
nosy: +python-dev

___
Python tracker 

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

[issue27497] csv module: Add return value to DictWriter.writeheader

[Berker Peksag]

Berker Peksag added the comment:

By the way, there is an open ticket about changing the recipe in Django 
documentation: https://code.djangoproject.com/ticket/26040

--
nosy: +berker.peksag

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Martin Panter]

Martin Panter added the comment:

It is possible to make an infinite iterable, e.g. iter(int, 1), so it is 
definitely worth checking for overflow. The patch looks okay to me. An 
alternative would be to raise the error without trying to allocate 
Py_SSIZE_T_MAX first, but I am okay with either way.

--
nosy: +martin.panter
stage:  -> patch review
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

[issue27498] Regression in repr() of class object

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4f11e6b72e8f by Benjamin Peterson in branch 'default':
Backed out changeset af29d89083b3 (closes #25548) (closes #27498)
https://hg.python.org/cpython/rev/4f11e6b72e8f

--
nosy: +ned.deily, python-dev
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

[issue25548] Show the address in the repr for class objects

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4f11e6b72e8f by Benjamin Peterson in branch 'default':
Backed out changeset af29d89083b3 (closes #25548) (closes #27498)
https://hg.python.org/cpython/rev/4f11e6b72e8f

--
nosy: +ned.deily
resolution:  -> fixed
stage: commit 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

[issue27369] [PATCH] Tests break with --with-system-expat and Expat 2.2.0

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Nick Coghlan]

Nick Coghlan added the comment:

Perhaps a suitable outcome here would be to just add an unconditional 
RuntimeWarning when the target of "-m" is already in sys.modules after the 
parent package import, along the lines of:

"RuntimeWarning: '' already in sys.modules prior to '__main__' 
execution; this may result in unpredictable behaviour"

Then if folks get the "ValueError: package.module.__spec__ is not set" message, 
that would be an example of the noted "unpredictable behaviour", and the 
suggested resolution would be the path Wolfgang took: find a way to eliminate 
the warning when executing that particular module as __main__.

--

___
Python tracker 

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

[issue22758] Regression in Python 3.2 cookie parsing

[Roundup Robot]

Roundup Robot added the comment:

New changeset a0bf31e50da5 by Martin Panter in branch '3.2':
Issue #22758: Move NEWS entry to Library section
https://hg.python.org/cpython/rev/a0bf31e50da5

--

___
Python tracker 

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

[issue27369] [PATCH] Tests break with --with-system-expat and Expat 2.2.0

[Roundup Robot]

Roundup Robot added the comment:

New changeset 5b64175c6c24 by Martin Panter in branch '3.2':
Issue #27369: Don’t test error message detail that changed in Expat 2.2.0
https://hg.python.org/cpython/rev/5b64175c6c24

New changeset 1c06e02b968a by Martin Panter in branch '3.3':
Issue #27369: Merge test_pyexpat from 3.2 into 3.3
https://hg.python.org/cpython/rev/1c06e02b968a

New changeset 17ec4d58c046 by Martin Panter in branch '3.4':
Issue #27369: Merge test_pyexpat from 3.3 into 3.4
https://hg.python.org/cpython/rev/17ec4d58c046

New changeset 2d6e6600c210 by Martin Panter in branch '2.7':
Issue #27369: Don’t test error message detail that changed in Expat 2.2.0
https://hg.python.org/cpython/rev/2d6e6600c210

New changeset 0fbf3b88eed8 by Martin Panter in branch '3.5':
Issue #27369: Merge test_pyexpat from 3.4 into 3.5
https://hg.python.org/cpython/rev/0fbf3b88eed8

New changeset 31dc480102fc by Martin Panter in branch 'default':
Issue #27369: Merge test_pyexpat from 3.5
https://hg.python.org/cpython/rev/31dc480102fc

--
nosy: +python-dev

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Nick Coghlan]

Nick Coghlan added the comment:

In http://bugs.python.org/issue27487#msg270300, Wolfgang noted: "In fact, for 
my own case I have now refactored things a bit so I can avoid the import from 
__init__.py."

So I take that to mean that Wolfgang's particular project is now compatible 
with the new 3.5.2 behaviour, or at least will be as of its next release 
(Wolfgang, please correct me if I've misinterpreted your comment).

The "double import" implications involved here aren't entirely clearcut though, 
as even in 3.5.2 if a leaf module invoked via "-m" is a normal module, 
importing it from the parent package's __init__ module (or any other part of 
the startup process, like a .pth file) will still lead to it being executed 
twice.

What's changed is that if the leaf module replaces itself in sys.modules with 
an object that doesn't have a __spec__ attribute, then executing it with -m 
will fail, rather than re-running the module level code as __main__ the way it 
will for a normal module.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Tim Peters]

Tim Peters added the comment:

About ""No parents, no children", that's fine so far as it goes.  But Python 
isn't C, a threading.Thread is not a POSIX thread, and threading.py _does_ have 
a concept of "the main thread".  There's no conceptual problem _in Python_ with 
saying "the main thread" waits to .join() other non-daemon threading.Threads at 
process exit.  No parent/child relationships are implied by that either - it's 
just the concept that one thread is distinguished.

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Xiang Zhang]

Xiang Zhang added the comment:

Thanks for your comment Martin. I'll apply them later when we reach agreement 
on functions. 

I have already used object = NULL, the C default is not necessary here, and it 
works as you like I think. In patch version 1, b'abc'.translate(None, None) 
raises exception as before. I change it in patch version 2 because argument 
clinic generates function signature as "($self, table, /, delete=None)". So I 
don't want users get surprised when they provide None as the signature but get 
an exception. And using None as a placeholder for a keyword argument is normal 
in Python. But I'm OK to keep the previous behaviour and actually I prefer that.

As for making the first argument optional, I don't quite like that since the 
doc seems to encourage users to set None explicitly.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Eryk Sun]

Eryk Sun added the comment:

> Per Eryk's point about the difference in multiprocessing's behavior
> when using spawn vs. fork, the explanation for why it's done that
> way is also described in the DeveloperWorks article I mentioned above.

Please spell this out for me. Why can't the "fork" and "forkserver" variations 
call sys.exit(), and thus Py_Finalize? I don't see why it's OK to call the 
_shutdown function in Lib/threading.py from a spawned child but not a forked 
child.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Tim Peters]

Tim Peters added the comment:

Devin, a primary point of `threading.py` is to provide a sane alternative to 
the cross-platform thread mess.  None of these reports are about making it 
easier for threads to go away "by magic" when the process ends.  It's the 
contrary:  they're asking for multiprocessing to respect threading.py's default 
behavior of making it the programmer's responsibility to shut down their 
threads cleanly.  "Shut down your threads, or we refuse to let the process end."

It doesn't matter that native OS threads may behave differently.  threading.py 
very deliberately makes _its_ thread abstraction "non-daemonic" by default, and 
advertises that behavior for all platforms.  So it's at best surprising that 
threading.Thread's default semantics get turned inside out when multiprocessing 
creates a process.  I still see no reason to believe that's "a feature".

As to docs, if it boils down to the difference between `sys.exit()` and 
`os._exit()`, then _those_ are the places to put details, and multiprocessing 
docs just need to point out when a created process will use one or the other.

As is, the docs don't contain the slightest clue anywhere that a 
threading.Thread may violate its own docs (with respect to process-exit 
behavior) when created by a process launched by multiprocessing (or also by a 
concurrent.futures.ProcessPoolExecutor?  I didn't check).

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Davin Potts]

Davin Potts added the comment:

It is a general rule that when a process terminates, it likewise terminates all 
its threads (unless a thread has been explicitly detached).  How it goes about 
doing so is complicated.

Remember that POSIX threads have no concept of parent/child among themselves 
and all threads are viewed as a single pool.  The section "No parents, no 
children" at 
http://www.ibm.com/developerworks/library/l-posix1/ offers us motivation for 
why waiting on a pthread should be explicitly requested and not assumed as a 
default behavior.

There are numerous differences between what a UNIX-style process and a win32 
process does at termination.  Though an older post from Microsoft, a strong 
sense of how complicated the process-termination-begets-thread-termination 
truly is can be had from reading 
https://blogs.msdn.microsoft.com/oldnewthing/20070503-00/?p=27003 which also 
helps reinforce the sentiment above (needs explicit instructions on what to do, 
no general solution can exist).  Whereas the prior provided some sense of 
motivation, this link walks us through ugly complications and consequences that 
arise.

The short of it is that the current use of os._exit() is most appropriate in 
multiprocessing.  Threads should be signaled that the process is terminating 
but we are not generally expected to wait on those threads.

These and many other reference-worthy links help support the call for 
atexit-like functionality to be exposed on multiprocessing.Process.  There have 
been multiple issues opened on the bug tracker ultimately requesting this 
enhancement (do a search for multiprocessing and atexit).  I think it's a very 
sensible enhancement (Antoine did too and perhaps still does) and worth taking 
the time to pursue.  As an aside, I wonder if an equivalent to 
pthread_cleanup_push should also be exposed on threading.Thread.

When it comes to documentation, I am of two minds.  There seem to be an 
increasing number of people coming to Python without much prior exposure to the 
concepts of threads and processes and so it would be wrong for us to ignore 
this reality.  On the flip side, attempting to convey all the core concepts of 
threads and processes and how they interact would result in a large 
documentation effort that ultimately few people would eagerly read to 
completion.  Adding a one-sentence caveat hiding somewhere in the docs won't do 
much to help.  Given this topic and a few other issues that have come up very 
recently, I suggest that a concise paragraph be added on the topic of using 
threads and processes together -- likely placed at the beginning of the docs on 
the Process class.  I think I'm up for taking a crack at that but I'd very much 
appreciate critical eyes to review it with me.





Per Eryk's point about the difference in multiprocessing's behavior when using 
spawn vs. fork, the explanation for why it's done that way is also described in 
the DeveloperWorks article I mentioned above.

Finally, per the original post from pietvo for future readers, not only is it 
*not* weird to start a Thread within a Process, it's a popular and useful 
technique.

--

___
Python tracker 

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

[issue27455] Fix tkinter examples to be PEP8 compliant

[John Hagen]

John Hagen added the comment:

The patch was reviewed and marked ready to commit.  Could someone with commit 
privileges perform the final commit?  Thanks.

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Martin Panter]

Martin Panter added the comment:

Instead of allowing delete=None (which is not in the RST documentation), 
perhaps it is possible to change the doc string. I can’t remember the details, 
but I think Argument Clinic allows a virtual Python-level default, something 
like “object(py_default=b"") = NULL”.

Also, I think I like the change. What do you think about making the first 
argument optional (default to None), allowing calls like 
x.translate(delete=b'aeiou')?

--
nosy: +martin.panter

___
Python tracker 

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

[issue25548] Show the address in the repr for class objects

[Ned Deily]

Changes by Ned Deily :


--
priority: normal -> release blocker

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Ned Deily]

Changes by Ned Deily :


--
nosy: +davin

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Ned Deily]

Changes by Ned Deily :


--
priority: normal -> release blocker

___
Python tracker 

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

[issue27157] Unhelpful error message when one calls a subclass of type with a custom metaclass

[ppperry]

ppperry added the comment:

Ping

--

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Antti Haapala]

Antti Haapala added the comment:

Thanks Serhiy, I was writing my comment for a long time, and only now noticed 
that you'd already posted the patch.

Indeed, it seems that not only is this the fastest method, it might also be the 
fastest string concatenation method in the history of Python. I did some 
comparison with 8-bit strings in Python 2, doing the equivalent of 

f'http://{domain}/{lang}/{path}'

with

domain = 'some_really_long_example.com'
lang = 'en'
path = 'some/really/long/path/'


and the results look quite favourable: 0.151 µs with your patch; 0.250ish for 
the second fastest method in Python 3.6 (''.join(tuple))

And the fastest method in Python 2 is a tie between concatenating with + or 
''.join with bound method reference; both of them take 0.203 µs on Python 2.7 
with 8-bit strings and about 0.245 - 0.255 µs if everything is Unicode.

--

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Demur Rumed]

Changes by Demur Rumed :


--
nosy: +rhettinger

___
Python tracker 

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

[issue27497] csv module: Add return value to DictWriter.writeheader

[STINNER Victor]

STINNER Victor added the comment:

Oh. I missed the django recipe to implement "streaming csv". It uses an
Echo object, its write() method returns its parameter.

This recipe looks like an abuse of the API, but I understand that there is
a need for a kind of "partial write": give control to I/O to the caller.

Maybe we should extend the API?

--

___
Python tracker 

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

[issue25548] Show the address in the repr for class objects

[Guido van Rossum]

Guido van Rossum added the comment:

Thanks, let's roll it back.

The reason it never was an issue for old-style classes is that they
behaved like this from the start, so nobody wrote tests that depended
on the predictability of repr(). But new-style classes have had this
nice clean repr() since they were introduced (in 2.3?) so it's
unsurprising that this is now depended upon.

Here's a link to some test code for mypy that broke:
https://github.com/python/mypy/blob/master/mypy/util.py#L22-L23

It may be irreprehensible code but it works for Python 3.2-3.5 (and
for new-style classes in Python 2, except mypy requires Python 3), and
broke in 3.6.

--

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Antti Haapala]

Antti Haapala added the comment:

It seems Eric has done some special casing for strings already in FORMAT_VALUE. 
Here are the results from my computer after applying Demur's patch for 
concatenating *strings*.

python3.6 -m timeit -s "x = 'a'" -- '"X is %s" % x'
100 loops, best of 3: 0.187 usec per loop

python3.6 -m timeit -s "x = 'a'" -- 'f"X is {x}"' 
1000 loops, best of 3: 0.0972 usec per loop

But then as more components are added, it starts to slow down rapidly:

python3.6 -m timeit -s "x = 'a'" -- 'f"X is {x}a"'   
100 loops, best of 3: 0.191 usec per loop

python3.6 -m timeit -s "x = 'a'" -- '"X is %sa" % x'
100 loops, best of 3: 0.216 usec per loop

Of course there is also the matter of string conversion vs "look up __format__":

python3.6 -m timeit -s "x = 1" -- 'f"X is {x}"'
100 loops, best of 3: 0.349 usec per loop

python3.6 -m timeit -s "x = 1" -- 'f"X is {x!s}"'
1000 loops, best of 3: 0.168 usec per loop

For FORMAT_VALUE opcode already has a special case for the latter. 

However I'd too say that switch/case for the some fastest builtin types in 
`PyObject_Format` as Eric has intended to do with Unicode in PyObject_Format 
(str, int, float), as those are commonly used to build strings such as text 
templates, text-like protocols like emails, HTTP protocol headers and such.

For others the speed-up wouldn't really matter either way: either 
PyObject_Format would fall back to object.__format__ (for example functions) - 
no one really cares about efficiency when doing such debug dumps - if you 
cared, you'd not do them at all; or they'd have complex representations (say, 
lists, dictionaries) - and their use again would mostly be that of debug dumps; 
or they'd have `__format__` written in Python and that'd be dwarfed by anything 
so far.

--

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Eryk Sun]

Eryk Sun added the comment:

In 3.4+ it works correctly with the "spawn" start method. This uses 
multiprocessing.spawn.spawn_main, which exits the child via sys.exit(exitcode). 
"fork" and "forkserver" exit the child via os._exit(code), respectively in 
multiprocessing.popen_fork.Popen._launch and multiprocessing.forkserver.main.

--
nosy: +eryksun
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

___
Python tracker 

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

[issue25548] Show the address in the repr for class objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

+1 on rolling this back.  It sounds like it hurt more than it would have helped.

To satisfy my curiosity, can you post one of the tests that broke.  It would be 
nice to see what kind of tests are depend the repr of the class.  AFAICT, there 
was never an issue with this for old-style classes in Python2.7, so something 
new must be occurring in the wild.

--

___
Python tracker 

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

[issue27497] csv module: Add return value to DictWriter.writeheader

[R. David Murray]

R. David Murray added the comment:

It doesn't make sense when the return value is that provided by io.write.  It 
does make sense in the context of the linked example (a psuedo-file object).  
However, it *is* an undocumented API, even if people are using it.

--

___
Python tracker 

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

[issue27497] csv module: Add return value to DictWriter.writeheader

[Raymond Hettinger]

Raymond Hettinger added the comment:

It is a bit irritating to have this small API inconsistency, but I'm a little 
wary of propagating this undocumented and untested behavior especially given 
Victor's concern about whether it makes any sense in this context.

Skip, what do you think?

--
assignee:  -> skip.montanaro
nosy: +rhettinger, skip.montanaro

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed patch adds the BUILD_STRING opcode and speeds up PyObject_Format() in 
common cases. It makes f-strings the fastest method for simple formatting.

$ ./python -m timeit -s "x = 2" -- 'f"X is {x}"'
100 loops, best of 3: 0.347 usec per loop

--
Added file: http://bugs.python.org/file43708/fstring_build_string.patch

___
Python tracker 

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

[issue18966] Threads within multiprocessing Process terminate early

[Tim Peters]

Tim Peters added the comment:

This came up again today as bug 27508.  In the absence of "fixing it", we 
should add docs to multiprocessing explaining the high-level consequences of 
skipping "normal" exit processing (BTW, I'm unclear on why it's skipped).

I've certainly mixed threads with multiprocessing too, but I always explicitly 
.join() my threads so never noticed this.  It's sure a puzzle when it happens 
;-)

--
nosy: +tim.peters

___
Python tracker 

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

[issue27508] process thread with implicit join is killed unexpectedly

[Tim Peters]

Tim Peters added the comment:

Ah - good catch!  I'm closing this as a duplicate of bug18966.  The real 
mystery now is why the threads _don't_ terminate early under Windows 3.5.2 - 
heh.

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Threads within multiprocessing Process terminate early

___
Python tracker 

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

[issue27508] process thread with implicit join is killed unexpectedly

[R. David Murray]

R. David Murray added the comment:

On my gentoo system it prints hi four times in 2.7, and 3.2 through 3.6.  I 
suspect multiprocessing is killing threads, daemon or not, when the main 
process thread ends.  I expect that's a feature, although I didn't find it 
documented.

Ah, found the explanation: issue 18966.  Antoine indicates this could indeed be 
considered a bug but is part of a larger issue.  If we aren't going to fix it, 
we should probably document it.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python, r.david.murray
versions: +Python 2.7, Python 3.6

___
Python tracker 

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

[issue27508] process thread with implicit join is killed unexpectedly

[Tim Peters]

Tim Peters added the comment:

Curious:  under Python 2.7.11 on Windows, the threads also terminate early 
(they run "forever" - as intended - under 3.5.2).

--

___
Python tracker 

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

[issue27501] Add typing.py class describing a PEP 3118 buffer object

[Daniel Moisset]

Daniel Moisset added the comment:

OK. Just to give an obvious example of a place where this would be useful for 
annotations is in the argument for the memoryview() builtin (currently declared 
with "# TODO arg can be any obj supporting the buffer protocol" in the standard 
library typesheds)

--

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yet one case for comparison (with msg270095):

$ ./python -m timeit -s "x = 2" -- 'f"X is {x!s}"'
100 loops, best of 3: 0.625 usec per loop

Seems f'{x!s}' is the fastest way to stringify a value. Thus there is an 
opportunity to speed up default formatting by special casing PyObject_Format() 
for most popular types (str and int).

--

___
Python tracker 

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

[issue27495] Pretty printing sorting for set and frozenset instances

[Danilo J. S. Bellini]

Danilo J. S. Bellini added the comment:

Wouldn't a fix for all standard collections be a fix for Python 3.5+, therefore 
another issue? http://bugs.python.org/issue23870

This issue is about sets/frozensets Python 3.2+, and I'm pretty sure it's 
backwards compatible, as I don't think any code running on Python 3.2.6 would 
depend on pprint randomness (how could?). Also, a multiline pprint would sort 
(tested with Python 3.2.6):

>>> pprint.pprint(set(string.digits), width=7)
{'0',
 '1',
 '2',
 '3',
 '4',
 '5',
 '6',
 '7',
 '8',
 '9'}

I see no reason to see a fix to this inconsistent behavior (sorting on 
multiline, not sorting on single line) as an enhancement just for a new Python 
3.6 version. Besides being backwards compatible, the test_pprint was really 
verifying the order on set(range(n)) for small n, something that is already 
sorted by set.__repr__ but appears in test_pprint, which make me think it was 
intended as a pretty printer test, not as a set.__repr__ test.

--

___
Python tracker 

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

[issue27508] process thread with implicit join is killed unexpectedly

[Tim Peters]

Changes by Tim Peters :


--
components: +Library (Lib)
type:  -> behavior

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Xiang Zhang]

Xiang Zhang added the comment:

Sorry, after checking again, this is still needed but maybe `if (len == 
PY_SSIZE_T_MAX)` part is not necessary since the iterable's length should not 
be larger than PY_SSIZE_T_MAX. But keep it to avoid theoretically bug is not a 
bad idea.

--
status: closed -> open

___
Python tracker 

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

[issue27508] process thread with implicit join is killed unexpectedly

[Tim Peters]

Tim Peters added the comment:

Note:  this started on stackoverflow:

https://stackoverflow.com/questions/38356584/python-multiprocessing-threading-code-exits-early

I may be missing something obvious, but the only explanation I could think of 
for the behavior seen on Ubuntu is that the threads in the worker processes are 
being treated as daemon threads.  The program works as intended for me on 
Windows - but, of course, there's a universe of differences between spawning 
(Windows) and forking (Ubuntu) processes too.

--
nosy: +tim.peters

___
Python tracker 

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

[issue27508] process thread with implicit join is killed unexpectedly

[JA]

New submission from JA:

On Ubuntu 16.04 
python '3.5.1+ (default, Mar 30 2016, 22:46:26) \n[GCC 5.3.1 20160330]'

The following code prints "hi" 4 times: 
import multiprocessing
import time
import threading

class dumb(threading.Thread):
def __init__(self):
super(dumb, self).__init__()
def run(self):
while True:
print("hi")
time.sleep(1)

def test():
for i in range(2):
bar = dumb()
bar.start()
def main():
p = []
for i in range(2):
p.append(multiprocessing.Process(target=test))
for i in p:
i.start()
for i in p:
i.join()
if __name__ == '__main__':
main()

Note: The above code runs fine on Python 3.5.2 (64-bit) on Windows 10

Joining the threads in test fixes the problem: 
def test():
p = []
for i in range(2):
bar = dumb()
bar.start()
p.append(bar)
for i in p:
i.join()

--
messages: 270329
nosy: JA
priority: normal
severity: normal
status: open
title: process thread with implicit join is killed unexpectedly
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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Xiang Zhang]

Xiang Zhang added the comment:

Ohh, sorry for the disturb. I made a mistake. This is not needed and now close 
it.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue27507] bytearray.extend lacks overflow check when increasing buffer

[Xiang Zhang]

New submission from Xiang Zhang:

As the title, bytearray.extend simply use `buf_size = len + (len >> 1) + 1;` to 
determine next *buf_size* when increasing buffer. But this can overflow in 
theory. So I suggest adding overflow check.

--
components: Interpreter Core
files: add_bytearray_extend_overflow_check.patch
keywords: patch
messages: 270327
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: bytearray.extend lacks overflow check when increasing buffer
type: enhancement
versions: Python 3.5, Python 3.6
Added file: 
http://bugs.python.org/file43707/add_bytearray_extend_overflow_check.patch

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Demur Rumed]

Changes by Demur Rumed :


--
type: enhancement -> performance

___
Python tracker 

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

[issue27495] Pretty printing sorting for set and frozenset instances

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Since pprint() now supports all standard collections, I think it is worth to 
support them in saferepr() too. I have written an implementation and am 
finishing writing tests.

--

___
Python tracker 

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

[issue27495] Pretty printing sorting for set and frozenset instances

[Raymond Hettinger]

Raymond Hettinger added the comment:

+1 for treating this as a bug fix.

--

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Brett Cannon]

Brett Cannon added the comment:

So what I'm gathering is that Martin fixed a bug that accidentally introduced a 
new one in 3.5.2 (which Martin should not feel responsible for; this import 
stuff is all very subtle and people use every nuance of it). To me, the 
question is whether there is a way to not revert Martin's fix -- or any other 
fixes -- while fixing Wolfgang's problem.

If the answer is yes, then great and we just need to know what the answer is in 
the form of a patch. :) My hope is someone will be inspired enough to figure 
out a solution and we can fix this for Wolfgang.

But if the answer is no, then we need to decide what the lesser of two bugs 
are. For me, I see Wolfgang's issue is the lesser of two bugs and thus the one 
that stays broken if we can't fix it reasonably (sorry, Wolfgang). Because we 
are trying to eliminate the double-import as that causes serious problems for 
anyone using import side-effects, I don't want to suddenly slide backwards in 
3.5.3 by letting that happen again (and I think Nick agrees w/ me on that 
point). I also don't want people continuing down a path where they think that 
they can blank out critical import metadata and have import continue to work 
(not that I'm blaming Wolfgang for relying on it, just that it won't hold in 
the future). And since the reliance on __spec__ is just going to grow thanks to 
the elimination of double imports and slowly making that attribute the ground 
truth for import metadata, Wolfgang's code would need to be updated for Python 
3.6 or later anyway.

But as I said, I'm sure everyone's utmost preference is if someone can figure 
out how to fix this in 3.5.3 without undoing another fix.

--

___
Python tracker 

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

[issue27501] Add typing.py class describing a PEP 3118 buffer object

[Raymond Hettinger]

Raymond Hettinger added the comment:

Since collections.abc is the wrong place, I'll change the title of this to 
typing and see if any of the typing aficionados think it is sufficiently useful 
(they are deliberately focusing on common use cases first since the whole 
static typing endeavor is exploratory and this limits of what should be done 
and what isn't really needed or useful isn't yet well understood).

--
title: Create a collections.abc class that describes PEP 3118 buffer -> Add 
typing.py class describing a PEP 3118 buffer object

___
Python tracker 

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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[R. David Murray]

R. David Murray added the comment:

There's actually programmatic way to generate a deprecation warning when the 
function is called (and then we'd want a test to make sure it gets generated).  
if you don't feel like working through that hopefully someone else will pick it 
up.  If you want to work on it, you can find examples by grepping for 
DeprecationWarning.

--

___
Python tracker 

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

[issue27501] Create a collections.abc class that describes PEP 3118 buffer

[Daniel Moisset]

Daniel Moisset added the comment:

Thanks for the feedback. Just for the context, I opened this issue also based 
on this email: http://permalink.gmane.org/gmane.comp.python.devel/156411

 Probably there are two different discussions to have here:

1) Is the "Buffer" a useful ABC to have even if there's no python API involved? 
My thoughts (that come from working with typing and PEP 484 and numpy) are "yes"

2) Where is the right place to put it? I suggested collections.abc after seeing 
the thread I linked, although I wouldn't mind if this was in typing.py or 
somewhere else.

--

___
Python tracker 

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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[Michael Lazar]

Changes by Michael Lazar :


Added file: http://bugs.python.org/file43706/mailcap_v3.patch

___
Python tracker 

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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[Michael Lazar]

Michael Lazar added the comment:

Whoops

--

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Demur Rumed]

Demur Rumed added the comment:

I'm not understanding your message. We don't call FORMAT_VALUE on constant 
strings in f"x is {x}" & FORMAT_VALUE doesn't take an argument. Are you saying 
in a hypothetical FORMAT_VALUE where BUILD_STRING takes a set of objects & 
applies formatting to them, thus allowing us to remove FORMAT_VALUE as an 
opcode? That seems like I'm imposing my own internal thoughts on what you're 
saying, but when I don't understand what someone's saying I'm prone to raise my 
own imaginations. Also note that f'{x}' compiles to 'LOAD X, FORMAT_VALUE' so 
there is no join lookup in the last benchmarks I posted

Nitpick about fstrtup2: it assumes compiler_joined_str's len is at least 2. 
Either an assert should be added or the last if-else should be `else if (len == 
1)` instead of a plain `else`

--

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[R. David Murray]

R. David Murray added the comment:

Ah, I was looking at the 2.7 docs.

--
nosy: +r.david.murray
title: make bytes/bytearray deletechars a keyword argument named delete -> make 
bytes/bytearray delete a keyword argument

___
Python tracker 

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

[issue27506] make bytes/bytearray delete a keyword argument

[Xiang Zhang]

Xiang Zhang added the comment:

Please review the new version. It makes two changes comparing with the last one.

1. It exposes Python parameter as "delete" (which the document always uses so I 
think it's the API) while still use "deletechars" (which I prefer as a C 
variable name) in C code.

2. It allows *delete* to be None. Before this is not allowed but I don't think 
this change breaks backwards compatibility. The reason for this change is that 
I don't want users to get surprised when they pass the default value to 
translate but then get an exception.

--
Added file: 
http://bugs.python.org/file43705/bytes_translate_delete_as_keyword_arguments_v2.patch

___
Python tracker 

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

[issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency

[Thomas Perl]

Thomas Perl added the comment:

Adding "-mfloat-abi=hard" to LDFLAGS fixes the issue for me, and also allows 
$(BUILDPYTHON) to be built correctly in addition to $(PGEN).

So I guess the resolution to this issue is "works for me" (with setting CC or 
LDFLAGS properly for cross-compilation being the resolution/workaround).

Does it make sense to create a new bug "Do not build pgen when it's not going 
to be used" as follow-up to this discussion (with a patch similar to the one in 
http://bugs.python.org/msg270304)? If so, I'll create one. Or maybe there 
should be a generic configure flag "do not run any generators" (like 
https://bugs.python.org/issue26662#msg270162, but including not running pgen), 
with the flag only issuing warnings instead of failing.

--

___
Python tracker 

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

[issue27501] Create a collections.abc class that describes PEP 3118 buffer

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'll defer to typing gurus as to whether something like this might make sense 
in typing.py, but it doesn't make much sense as a collections.abc without an 
API exposed in pure python and without useful mixin methods.  By way of 
comparison, consider that the named tuple protocol is in typing.NamedTuple but  
not in collections.abc; instead, we just use _fields to recognize it when the 
need arises (which is almost never).   

I would like collections.abc to remain a place for ABCs that can be usefully 
subclassed, that provide guaranteed behaviors, and that are in fact related to 
collections.  The module's utility will be impaired if it becomes a dumping 
ground for miscellaneous type hinting concepts and registrations.

Early on there was some experimentation with the "one-trick ponies" in 
collections.abc such as Callable and Hashable that turned-out to almost never 
be used in practice, so we don't want to continue to that line of development 
when there are more promising avenues such as typing.py.

--
nosy: +rhettinger
versions: +Python 3.6

___
Python tracker 

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

[issue25548] Show the address in the repr for class objects

[Guido van Rossum]

Guido van Rossum added the comment:

Doing it only for user-defined types would still break my tests.

--

___
Python tracker 

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

[issue25548] Show the address in the repr for class objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

Would there be a way to confine this to just heap types?  The user defined 
classes are where there is the most benefit.  For the built-in types, it just 
seems to add noise.

--

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Antti Haapala]

Antti Haapala added the comment:

Yet the test cases just prove what is so expensive there: name lookups (global 
name `str`; looking up `join` on a string instance); building a tuple (for 
function arguments) is expensive as well. Of course `__format__` will be costly 
as well as it is not a slot-method, needs to build a new string etc. 

However for strings, 'foo'.format() already returns the instance itself, so if 
you were formatting other strings into strings there are cheap shortcuts 
available to even overtake 

a = 'Hello'
b = 'World'
'%s %s' % (a, b)

for fast string templates, namely, make FORMAT_VALUE without args return the 
original if `PyUnicode_CheckExact` and no arguments, don't need to build a 
tuple to join it.

--

___
Python tracker 

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

[issue19142] Cross-compile fails trying to execute foreign pgen on build host

[Xavier de Gaye]

Xavier de Gaye added the comment:

I confirm that, on 3.6 and after the changesets that fixed issue 22359, pgen is 
always cross-compiled whatever the timestamps and that pgen is not run on a 
cross-build for Android. So I think it should work as well now for Trevor with 
v2.7.12.

--
nosy: +xdegaye

___
Python tracker 

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

[issue27506] make bytes/bytearray deletechars a keyword argument named delete

[Xiang Zhang]

Xiang Zhang added the comment:

Hmm, David, that may be not quite right. Users only reading the doc never know 
it's deletechars not delete. The doc is always delete, though conflicting with 
__doc__.

>>> print(bytes.translate.__doc__)
B.translate(table[, deletechars]) -> bytes
...

I deliberately change deletechars to delete to keep consistent with doc. But 
actually I think using deletechars won't break backwards compatibility too.

--

___
Python tracker 

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

[issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency

[Xavier de Gaye]

Xavier de Gaye added the comment:

> the underlying problem is that pgen gets built in cases where it shouldn't

This statement does not take into account the following note of your initial 
post: "note that the same $(CFLAGS) needs to be added to the rule for 
$(BUILDPYTHON) if one wants to build that as well".

I agree with Martin that you should either use CC or set LDFLAGS to fix the 
problems that occur at the link stages of your cross-build.

--
nosy: +xdegaye

___
Python tracker 

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

[issue27366] PEP487: Simpler customization of class creation

[Martin Teichmann]

Changes by Martin Teichmann :


Removed file: http://bugs.python.org/file43506/pep487.patch

___
Python tracker 

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

[issue27498] Regression in repr() of class object

[Emanuel Barry]

Changes by Emanuel Barry :


--
nosy: +ebarry

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Demur Rumed]

Demur Rumed added the comment:

fstrtup2.patch is a bit more of an involved optimization for when we are 
joining 2 strings. Instead it emits BINARY_ADD. This may be considered too 
'niche' since it only triggers when the substitution occurs at the start or end 
of a string & there is only one substitution

However, it reduces the "X is {x}" testcase on my machine to 4.9 usec

Interesting thing, to consider ceiling of what we can do,

Prefixing ./python -m timeit -s "x=1"
'%s'%x 1.08 usec
'%s'%(x,) 2.04 usec
str(x) 2.9 usec
f'{x}' 3.65 usec

So we should not be aiming to compete with %. It may be worthy to convert the 
code to generate "x is {}".format calls tho

--
Added file: http://bugs.python.org/file43704/fstrtup2.patch

___
Python tracker 

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

[issue27506] make bytes/bytearray deletechars a keyword argument named delete

[R. David Murray]

Changes by R. David Murray :


--
title: bytes/bytearray delete acts as keyword argument -> make bytes/bytearray 
deletechars a keyword argument named delete

___
Python tracker 

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

[issue22125] Cure signedness warnings introduced by #22003

[Berker Peksag]

Berker Peksag added the comment:

Since 2e29d54843a4 this is no longer needed. Thanks for the patches!

--
nosy: +berker.peksag
resolution:  -> out of date
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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[R. David Murray]

R. David Murray added the comment:

Looks like you didn't attach the new patch.

--

___
Python tracker 

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

[issue27504] Missing assertion methods in unittest documentation

[R. David Murray]

R. David Murray added the comment:

No problem.  Personally I'd like to see a table of all of them at the top; 
however, that wasn't the decision that was made in issue 9796 when the tables 
were added.

--

___
Python tracker 

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

[issue27490] ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) dependency

[Thomas Perl]

Thomas Perl added the comment:

Yes setting "CC" would fix the problem, but i guess the CFLAGS issue was just 
the original symptom (and my first reaction to fixing it), whereas the 
underlying problem is that pgen gets built in cases where it shouldn't be built 
at all.

The solution with "ifeq" does seem to require GNU make, and since these 
conditionals would still appear in the Makefile even for non-cross-builds, we 
can't really use this if compatibility with non-GNU make is a requirement.

Based on http://gallium.inria.fr/blog/portable-conditionals-in-makefiles/, here 
is something that seems to work ($(PGEN_DEPS) will be $(PGEN) when 
cross_compiling=no, and empty when cross_compiling=yes, and configure.ac errors 
out if cross_compiling is "maybe", so we do not need to handle that case at the 
moment):

=
diff -ru Python-2.7.12/Makefile.pre.in Python-2.7.12-fix/Makefile.pre.in
--- Python-2.7.12/Makefile.pre.in   2016-06-25 23:49:31.0 +0200
+++ Python-2.7.12-fix/Makefile.pre.in   2016-07-13 12:21:27.0 +0200
@@ -246,6 +246,8 @@
 ##
 # Parser
 PGEN=  Parser/pgen$(EXE)
+PGEN_DEPS0= ${cross_compiling:yes=}
+PGEN_DEPS=  ${PGEN_DEPS0:no=$(PGEN)}
 
 PSRCS= \
Parser/acceler.c \
@@ -680,7 +682,7 @@
 
 Modules/pwdmodule.o: $(srcdir)/Modules/pwdmodule.c 
$(srcdir)/Modules/posixmodule.h
 
-$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN)
+$(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGEN_DEPS)
@$(MKDIR_P) Include
# Avoid copying the file onto itself for an in-tree build
if test "$(cross_compiling)" != "yes"; then \
=

--

___
Python tracker 

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

[issue27506] bytes/bytearray delete acts as keyword argument

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
stage:  -> patch review

___
Python tracker 

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

[issue27506] bytes/bytearray delete acts as keyword argument

[Xiang Zhang]

New submission from Xiang Zhang:

Write a patch to make bytes/bytearray.translate's delete argument support 
acting as keyword arguments. This won't break any backwards compatibility and 
make the method more flexible to use. Besides, in the C code level, it stops 
using argument clinic's legacy optional group feature and removes the 
unnecessary group_right_1 parameter.

--
components: Interpreter Core
files: bytes_translate_delete_as_keyword_arguments.patch
keywords: patch
messages: 270303
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: bytes/bytearray delete acts as keyword argument
type: enhancement
versions: Python 3.6
Added file: 
http://bugs.python.org/file43703/bytes_translate_delete_as_keyword_arguments.patch

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Nick Coghlan]

Nick Coghlan added the comment:

Sorry, I got the levels slightly confused there - a bit more experimentation 
shows it isn't the parent package that needs a __spec__ attribute, but only the 
package being executed.

# Parent package needs __path__ rather than __spec__
>>> find_spec("unittest.mock")
ModuleSpec(name='unittest.mock', 
loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fa7b6434b38>, 
origin='/usr/lib64/python3.5/unittest/mock.py')
>>> sys.modules["unittest"] = object()
>>> find_spec("unittest.mock")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/importlib/util.py", line 89, in find_spec
return _find_spec(fullname, parent.__path__)
AttributeError: 'object' object has no attribute '__path__'

# Leaf package needs __spec__
>>> del sys.modules["unittest"]
>>> find_spec("unittest.mock")
ModuleSpec(name='unittest.mock', 
loader=<_frozen_importlib_external.SourceFileLoader object at 0x7fa7b64344e0>, 
origin='/usr/lib64/python3.5/unittest/mock.py')
>>> import unittest.mock
>>> del sys.modules["unittest.mock"].__spec__
>>> find_spec("unittest.mock")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/importlib/util.py", line 99, in find_spec
raise ValueError('{}.__spec__ is not set'.format(name)) from None
ValueError: unittest.mock.__spec__ is not set

--

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Nick Coghlan]

Nick Coghlan added the comment:

Aye, the report is definitely appreciated - the interaction between "__main__" 
execution and normal module imports has always been tricky, so it's always good 
to be informed of new problems folks encounter.

As an example illustrating the underlying problem here without involving the 
"-m" switch at all:

>>> from importlib.util import find_spec
>>> find_spec("dis")
ModuleSpec(name='dis', loader=<_frozen_importlib_external.SourceFileLoader 
object at 0x7fa7ba859fd0>, origin='/usr/lib64/python3.5/dis.py')
>>> import sys
>>> sys.modules["dis"] = object()
>>> find_spec("dis")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.5/importlib/util.py", line 99, in find_spec
raise ValueError('{}.__spec__ is not set'.format(name)) from None
ValueError: dis.__spec__ is not set


The difference between 3.5.1 and 3.5.2 is that if you do 
"find_spec('mypkg.mymod')" *before* "mypkg" is imported, then find_spec will 
use the original module object rather than the replacement inserted into 
sys.modules when it recurses down to look for "mypkg.mymod". However, if 
"mypkg" is already in sys.modules before find_spec is called, then find_spec 
will attempt to use that existing object, rather than the (potentially no 
longer available) original module object.

--

___
Python tracker 

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

[issue27487] -m switch regression in Python 3.5.2 (under rare circumstances)

[Wolfgang Maier]

Wolfgang Maier added the comment:

@Martin and regarding Python3.3: Right, you cannot do the replacement when 
running the module as __main__. For my use case that's not required though so 
in 
the module I can just do:

if __name__ == '__main__':
print('running module as a script')
else:
# do not attempt this when __name__ == '__main__' in Python 3.3
sys.modules[__name__] = object()

Apart from this limitation, such code is compatible with Python 3.2 - 3.5.1, 
but 
breaks under 3.5.2. It's the fact that it breaks in a maintenance release that 
I find disturbing. In fact, I learnt about the breakage only from an end-user 
who bought a new laptop with OS X, downloaded the latest Python release and 
suddenly could not get our package to run that had worked on his previous 
machine. Turns out, none of our test machines was running 3.5.2 yet, but were 
running 3.5.0 and 3.5.1.

OTOH, I agree with you that the circumstances under which your change causes 
trouble are pretty exotic. As Nick points out, modules replacing themselves in 
sys.modules are not that special. What *makes* the situation special is that 

1) the package __init__.py has to import the self-replacing module and that
2) the self-replacing module is intended to be run via python3 -m package.module

That's why I wrote initially that I don't know if many (or, in fact, any other 
package would be affected by this).

Nick's concern about the double import situation is more general, but since 
this is something earlier releases have been doing, an improvement here would 
be relevant only for a major release (3.6 or 3.7).

Regarding 3.5.3, I'm not sure what the best solution would be:

- the suggestion to copy over the __spec__ attribute to the replacement object 
  is putting the burden on package maintainers. Given that probably only few 
  packages will be affected that may well be acceptable. In fact, for my own 
  case I have now refactored things a bit so I can avoid the import from 
  __init__.py.
  
- from a strict versioning perspective, you may also argue like Nick that if it 
  was working in 3.5.0-1 it should work again in 3.5.3.
  
I'm personally pretty neutral here. I just thought it may be good to report the 
issue so that it becomes easier for others to understand what is going on if 
they encounter the same error. Maybe even the fact that this issue exists now 
is serving this purpose as well as documenting the changed behaviour?

--

___
Python tracker 

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

[issue14977] mailcap does not respect precedence in the presence of wildcards

[Michael Lazar]

Michael Lazar added the comment:

That works for me, patch updated to match your suggestion. So to recap, the 
proposed fix implements the following changes to the api:

getcaps()
   The returned dict now has an additional `lineno` field. There's a *slim* 
chance that this could break behavior for somebody who relies on the output for 
something other than passing it to findmatch().

readmailcapfiles()
Marked as deprecated, but the behavior will remain the same.

lookup(caps, ...)
If the caps dict contains `lineno`, the metadata will be used to sort the 
matching entries. If the caps dict does not contain `lineno`, for example if it 
was constructed manually, the behavior will remain the same.

findmatch(caps, ...)
Same as lookup()

--

___
Python tracker 

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

[issue27492] Enhance bytearray_repr with bytes_repr's logic

[Xiang Zhang]

Xiang Zhang added the comment:

Hi, Serhiy. I've tried one version factoring the common parts out. I make them 
one function but it seems not very elegant. I also think about passing the 
object and use it to get the type and then determine how to get the string, 
what the pre/postfix are, and the exception message, but that seems not elegant 
either. And I don't figure out what the two function's advantage. Let me know 
your considerations.

BTW, I am still not sure repr could be put into bytes_methods.c. The functions 
in it are all tp->methods.

--
Added file: http://bugs.python.org/file43702/_Py_bytes_repr.patch

___
Python tracker 

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