[issue25077] Compiler warnings: initialization from incompatible pointer type

[Marius Gedminas]

New submission from Marius Gedminas:

I'm seeing these compiler warnings while trying to build Python 3.5 on Ubuntu 
15.04:

In file included from Python/ceval.c:300:0:
Python/ceval_gil.h: In function ‘drop_gil’:
Python/ceval_gil.h:181:144: warning: initialization from incompatible pointer 
type
 _Py_atomic_store_relaxed(&gil_last_holder, tstate);

^

In file included from Python/ceval.c:300:0:
Python/ceval_gil.h: In function ‘take_gil’:
Python/ceval_gil.h:243:144: warning: initialization from incompatible pointer 
type
 _Py_atomic_store_relaxed(&gil_last_holder, tstate);

^

Python/pystate.c: In function ‘PyThreadState_Swap’:
Python/pystate.c:509:147: warning: initialization from incompatible pointer type
 _Py_atomic_store_relaxed(&_PyThreadState_Current, newts);

^

/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function 
‘classify_argument’:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:224:16: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (i = 0; i < words; i++)
^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:245:20: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (i = 0; i < num; i++)
^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:264:20: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (i = 1; i < words; i++)
^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:270:16: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (i = 0; i < words; i++)
^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function 
‘examine_argument’:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:323:17: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
   for (i = 0; i < n; ++i)
 ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function 
‘ffi_call’:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:484:18: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j = 0; j < n; j++, a += 8, size -= 8)
  ^
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function 
‘ffi_closure_unix64_inner’:
/home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:659:18: warning: 
comparison between signed and unsigned integer expressions [-Wsign-compare]
for (j = 0; j < n; j++, a += 8)
  ^

I saw bug #1616 and thought you might want to know about these.

--
components: Build
messages: 250513
nosy: mgedmin
priority: normal
severity: normal
status: open
title: Compiler warnings: initialization from incompatible pointer type
type: compile error
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

[issue16473] quopri module differences in quoted-printable text with whitespace

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Mentioned functions are not exact equivalents of codecs. They are preferable 
way to to obtain the similar (apart from minor details) output.

--
nosy: +ncoghlan, serhiy.storchaka

___
Python tracker 

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

[issue25078] Document InstallAllUsers installer parameter default 0

[Thomas Kluyver]

New submission from Thomas Kluyver:

In testing the 3.5.0rc4 default installer, I found that the default for 
InstallAllUsers appears to be 0, whereas it's currently documented as 1.

--
assignee: docs@python
components: Documentation
files: installallusers-default.patch
keywords: patch
messages: 250515
nosy: docs@python, steve.dower, takluyver
priority: normal
severity: normal
status: open
title: Document InstallAllUsers installer parameter default 0
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40445/installallusers-default.patch

___
Python tracker 

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

[issue25079] Tokenize generates NL instead of NEWLINE for comments

[Optimal BPM]

New submission from Optimal BPM:

Quoting the documentation:

tokenize.NL
Token value used to indicate a non-terminating newline. The NEWLINE token 
indicates the end of a logical line of Python code; NL tokens are generated 
when a logical line of code is continued over multiple physical lines.

This doesn't seem to be entirely true.
At the end of comments, an .NL, not .NEWLINE is generated:
TokenInfo(type=55 (NL), string='\n', start=(5, 22), end=(5, 23), line='# Some 
docs for the IF\n')

As a comment cannot extend over several lines, if would appear that a NEWLINE 
would be appropriate?

--
components: Interpreter Core
messages: 250516
nosy: Optimal BPM
priority: normal
severity: normal
status: open
title: Tokenize generates NL instead of NEWLINE for comments
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue25079] Tokenize generates NL instead of NEWLINE for comments

[Stefan Krah]

Stefan Krah added the comment:

See:

https://docs.python.org/3/reference/lexical_analysis.html#blank-lines

--
assignee:  -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python, skrah
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: behavior -> 

___
Python tracker 

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

[issue25080] The example-code for making XLM-RPC requests through proxy, fail!

[Kostis ankostis]

New submission from Kostis ankostis:

The example code provided at the bottom of the reference-page: 
  https://docs.python.org/2/library/xmlrpclib.html#example-of-client-usage
for making XML-RPC requests through a proxy by defining a custom transport 
fails (at least) in python-3.4!

Obviously it has been kept intact from `xmlrpclib` python-2 but `xmlrpc.client` 
API has changed and consequently the code fails.
Here is a IPython session demonstratin the problem:

>>> import xmlrpc.client, http.client
>>>
>>> class ProxiedTransport(xmlrpc.client.Transport):
... def set_proxy(self, proxy):
... self.proxy = proxy
... def make_connection(self, host):
... self.realhost = host
... h = http.client.HTTP(self.proxy)
... return h
... def send_request(self, connection, handler, request_body):
... connection.putrequest("POST", 'http://%s%s' % (self.realhost, 
handler))
... def send_host(self, connection, host):
... connection.putheader('Host', self.realhost)
...
>>> p = ProxiedTransport()
>>> p.set_proxy('proxy-server:8080')
>>> server = xmlrpc.client.Server('http://time.xmlrpc.com/RPC2', 
transport=p)
>>> print(server.currentTime.getCurrentTime())
Traceback (most recent call last):
  File 
"D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\site-packages\IPython\core\interactiveshell.py",
 line 3035, in run_code
exec(code_obj, self.user_global_ns, self.user_ns)
  File "", line 1, in 
print(server.currentTime.getCurrentTime())
  File 
"D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 
1098, in __call__
return self.__send(self.__name, args)
  File 
"D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 
1437, in __request
verbose=self.__verbose
  File 
"D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 
1140, in request
return self.single_request(host, handler, request_body, verbose)
  File 
"D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 
1152, in single_request
http_conn = self.send_request(host, handler, request_body, verbose)
TypeError: send_request() takes 4 positional arguments but 5 were given

--
assignee: docs@python
components: Demos and Tools, Documentation
messages: 250518
nosy: Kostis ankostis, docs@python
priority: normal
severity: normal
status: open
title: The example-code for making XLM-RPC requests through proxy, fail!
versions: Python 3.4

___
Python tracker 

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

[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5

[Stefan Krah]

Stefan Krah added the comment:

I think the issue can be closed (after updating "what's new").

Even if we wanted to keep backwards compatibility, it's too
late now.

--

___
Python tracker 

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

[issue16473] quopri module differences in quoted-printable text with whitespace

[Martin Panter]

Martin Panter added the comment:

The list of functions were added in Issue 17844. I made the change today 
because I forgot that the listed functions weren’t exactly equivalent when 
investigating Issue 25075.

Base64-codec encodes to multiple lines, but b64encode() returns the raw 
encoding without line breaks. I see that base64.encodebytes() is listed as a 
“legacy interface”, but as far as I can tell nothing outside the legacy 
interface does any line splitting.

Hex-codec encodes to lowercase, but b16encode() returns uppercase, following 
RFC 4648.

Quopri-codec encodes all whitespace, but quopri.encodestring() lets most 
whitespace through verbatim by default. In this case I think it would be 
reasonable to change back to encodestring() if we say that quotetabs=True is 
passed in.

--

___
Python tracker 

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

[issue25007] Add support of copy protocol to zlib compressors and decompressors

[shiyao.ma]

shiyao.ma added the comment:

per serhiy's suggestion, added two aliases.

--
keywords: +patch
nosy: +introom
Added file: http://bugs.python.org/file40446/patch.diff

___
Python tracker 

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

[issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules

[Larry Hastings]

Larry Hastings added the comment:

Pull request accepted.  Please forward-merge, 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

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

[Davin Potts]

Davin Potts added the comment:

The patches make good sense to me -- I have no comments to add in a review.

I spent more time than I care to admit concerned with the idea that 
error_callback (exposed by map_async which map sits on top of) should perhaps 
be called not just once at the end but each time an exception occurs.  
Motivated by past jobs which failed overall to yield any results because one 
out of a million of the inputs triggered an error, I thought the idea very 
appealing and experimented with implementing it (with happy results).  Googling 
for it though, I found plenty of examples of people asking questions about how 
callback and error_callback are intended to work -- though the documentation is 
not explicit on this particular point, most of those search results correctly 
document in the wild that error_callback is called only once at the end just 
like callback.  I think it best to leave that functionality just as you have it 
now.

Thanks for creating the patch -- looks great to me.

--

___
Python tracker 

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

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

[Davin Potts]

Changes by Davin Potts :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue22980] C extension naming doesn't take bitness into account

[Larry Hastings]

Larry Hastings added the comment:

It's fixed!  So it's finally closed.

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

After discussing it with Guido, I've removed the ability to combine 'f' with 
'u'.

--

___
Python tracker 

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

[issue25021] product_setstate() Out-of-bounds Read

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8cc052c28910 by Kristján Valur Jónsson in branch '3.3':
Issue #25021: Correctly make sure that product.__setstate__ does not access
https://hg.python.org/cpython/rev/8cc052c28910

New changeset 4f85b6228697 by Kristján Valur Jónsson in branch '3.4':
Issue #25021: Merge from 3.3 to 3.4
https://hg.python.org/cpython/rev/4f85b6228697

New changeset ca628ccec846 by Kristján Valur Jónsson in branch '3.5':
Issue #25021: Merge 3.4 to 3.5
https://hg.python.org/cpython/rev/ca628ccec846

New changeset 92e7ac79c681 by Kristján Valur Jónsson in branch 'default':
Issue #25021: Merge 3.5 to default
https://hg.python.org/cpython/rev/92e7ac79c681

--
nosy: +python-dev

___
Python tracker 

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

[issue25021] product_setstate() Out-of-bounds Read

[Kristján Valur Jónsson]

Changes by Kristján Valur Jónsson :


--
stage:  -> resolved

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Jelle Zijlstra]

Jelle Zijlstra added the comment:

I've started working on implementing this feature in Cython and I'd like to 
confirm a few edge cases:

- f'{ {1: 2\N{RIGHT CURLY BRACKET}[1]}' == '2' (string escape rules work even 
within the expressions)
- f'{ '''foo''' }' is a syntax error
- f'{ """foo 'bar'""" }' is a syntax error

--
nosy: +Jelle Zijlstra

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

Yes, Jelle, you are correct in all 3 cases. Remember that the steps are to 
extract the string from the source code, decode backslash escapes, and only 
then treat it as an f-string.

For the first case, without the 'f' prefix:
'{ {1: 2\N{RIGHT CURLY BRACKET}[1]}' == '{ {1: 2}[1]}'

Then, applying the 'f':
f'{ {1: 2}[1]}' == '2'.

For the last 2, since they're syntax errors without the 'f', they're also 
syntax errors with the 'f'.

I'll have a new version, with tests for all of these cases, posted in the next 
few hours. You can leverage the tests.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Jelle Zijlstra]

Jelle Zijlstra added the comment:

Thanks! Here are a few more cases I came across with the existing 
implementation:

>>> f"{'a\\'b'}"
  File "", line 1
SyntaxError: missing '}' in format string expression

I believe this is valid and should produce "a'b".

>>> f"{x!s!s}"
  File "", line 1
SyntaxError: single '}' encountered in format string

Could use a better error message.

>>> x = 3
>>> f"{x!s{y}}"
'3y}'

Not sure how this happened.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

This one has been fixed:
>>> f"{'a\\'b'}"
"a'b"

This one was a bug that I previously fixed, that Martin pointed out:
>>> f"{x!s!s}"
  File "", line 1
SyntaxError: invalid character following conversion character

And this is the same bug:
>>> f"{x!s{y}}"
  File "", line 1
SyntaxError: invalid character following conversion character

I'm wrapping up my new code plus tests. I'll post it Real Soon Now.

Thanks for your help.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Martin Panter]

Martin Panter added the comment:

Regarding wrong error messages, I’ve learnt the hard way that it is often best 
to use assertRaisesRegex() instead of assertRaises(), to ensure that the actual 
exception you have in mind is being triggered, rather than a typo or something. 
Though that might upset your assertSyntaxErrors() helper.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

Agreed on checking the error messages better. Especially since even the 
simplest of errors (like leaving out a quote) results in a syntax error in 
parsing the string, not parsing inside the f-string.

I'll look at it eventually.

--

___
Python tracker 

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

[issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs

[Nikita Klimov]

Nikita Klimov added the comment:

I make a correlation table, plan to finish by September 16 or earlier

--

___
Python tracker 

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

[issue24948] Multiprocessing not timely flushing stack trace to stderr

[Davin Potts]

Davin Potts added the comment:

If I understand your motivations correctly, I'd restate them as:  you want a 
mechanism for being immediately notified of an exception in a parent process 
without waiting on any child processes of that parent to finish and furthermore 
propose this should be the default behavior.

Quick side note:  As the docs explain and as the code you propose modifying in 
Lib/multiprocessing/process.py shows, a Process is designed to track its live 
children.  Interrupting or otherwise destroying a parent process's ability to 
track its children even after experiencing an exception in its target function 
would not be desirable.

I think we agree that the current behavior you describe is not catastrophic in 
any sense -- the exception occurs, the process finishes waiting on its 
children, and that exception bubbles up at the end -- nothing is lost or 
suppressed.

This becomes a question of when should a calling routine be notified of such an 
exception (happening in what I was just calling a parent process):  
immediately, if we ask for it, or when it's otherwise done?  Different use 
cases motivate different answers to this question.  The current behavior 
satisfies many common use cases and  thankfully it is not difficult to 
implement the other behaviors in your own code.  It can start with a try-except 
inside the example function 'f' where the except clause's code takes some 
appropriate action right away rather than waiting on the children, if that is 
what is desired.

def f():
try:
p = mp.Process(target=g)
p.start()
1/0
p.join()
except Exception as e:
# Take action, sound the alarm, call out the guards, notify the 
BDFL!
raise e


I'm not sure I see the relation to issue13812 which is concerned with traceback 
text that was sent to stderr but surprisingly wasn't getting flushed to stderr. 
 This issue has no such problem with flushes on stderr -- we are not waiting on 
stderr here, we are waiting on the parent to finish waiting on its children 
before any traceback gets written to stderr.

--
nosy: +davin

___
Python tracker 

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

[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5

[Roundup Robot]

Roundup Robot added the comment:

New changeset 10a9d4acd9cb by Yury Selivanov in branch '3.5':
whatsnew/3.5 More edits
https://hg.python.org/cpython/rev/10a9d4acd9cb

--
nosy: +python-dev

___
Python tracker 

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

[issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5

[Yury Selivanov]

Yury Selivanov added the comment:

What's new is now updated with description of this issue.  Closing it now.

--
resolution:  -> wont fix
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

[issue24948] Multiprocessing not timely flushing stack trace to stderr

[Davin Potts]

Changes by Davin Potts :


--
nosy: +jnoller, sbt

___
Python tracker 

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

[issue24948] Multiprocessing not timely flushing stack trace to stderr

[Davin Potts]

Changes by Davin Potts :


--
type:  -> behavior

___
Python tracker 

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

[issue23992] multiprocessing: MapResult shouldn't fail fast upon exception

[Davin Potts]

Davin Potts added the comment:

As an aside:  issue24948 seems to show there are others who would find the 
immediate-multiple-error_callback idea attractive.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

This patch fixes triple-quoted strings, plus a few bugs. I'm going to commit it 
tomorrow, barring any unforeseen issues.

--
Added file: http://bugs.python.org/file40447/pep-498-5.diff

___
Python tracker 

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

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

[Andre Merzky]

Andre Merzky added the comment:

Yes, I have a workaround (and even a clean solution) in my code.  My interest 
in this ticket is more academic than anything else :)

Thanks for the pointer to issue1731717.  While I am not sure which 'comment at 
the end' you exactly refer to, the whole discussion provides some more insight 
on why SIGCHLD is handled the way it is, so that was interesting.  

I agree that changing the behavior in a way which is unexpected for existing 
applications is something one wants to avoid, generally.  I can't judge if it 
is worth to break existing code to get more correctness in a corner case -- 
depends on how much (and what kind of) code relies on it, which I have no idea 
about.

One option to minimize change and improve correctness might be to keep track of 
the parent process.  So one would keep self.parent=os.getpid() along with 
self.pid.  In the implementation of _internal_poll one can then check if 
self.parent==os.getpid() still holds, and raise an ECHILD or EINVAL otherwise.  
That would catch the pickle/unpickle across processes case (I don't know Python 
well enough to see if there are easier ways to check if a class instance is 
passed across process boundaries).

The above would still not be fully POSIX (it ignores process groups which would 
allow to wait on non-direct descendants), but going down that route would 
probably almost result in a reimplementation of what libc does...

--

___
Python tracker 

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

[issue25036] IDLE - infrastructure changes so editors don't assume they're in a toplevel

[Mark Roseman]

Mark Roseman added the comment:

FYI, I've gone past this point in my own playground, to the point of having a 
working tabbed editor implementation.  It's not that much further actually. 
Here are the next steps:

1. Change so that Container is passed to Components on creation, rather than 
Component creating its own container.

2. Change statusbar so that it's in control of what is displayed, and 
EditorWindow just pings it to update itself; statusbar calls into EditorWindow 
and chooses what info to get.

3. Change so that container decides how to display title, EditorWindow just 
says title has changed. Add saved/dirty status info to Container.

4. Create Container subclass TabbedContainer using the separate uitabs.py 
widget I put together. Manages the tabs and switching in different content as 
tabs are switched. Altogether < 100 lines of code.

5. Create Container subclass ProxyContainer, representing what's managed by a 
single tab. Just passes things off to TabbedContainer. < 50 lines of code.

6. Change FileList to created a TabbedContainer and then ProxyContainers for 
each  shell/editor added.

--

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

I'll probably ensure that all of the parsing errors contain "format string" or 
"f-string" or similar. That way the regex check is easier, and the user can 
search for it more easily.

It remains to be seen how these are referenced in the documentation. "f-string" 
seems much easier to say and search for, but seems too slangy for the docs. But 
"format string" seems ambiguous and hard to search for. I guess time will tell.

--

___
Python tracker 

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

[issue20917] Idle: Enhance font change notification system

[Mark Roseman]

Mark Roseman added the comment:

The new 'component' infrastructure provides the mechanism for passing these 
kinds of notifications around. Allowing extensions (in whatever form they'll 
exist with the new stuff) to take part in this notification mechanism would be  
a small (and sensible) addition to that.

--
nosy: +markroseman

___
Python tracker 

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

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

[Andre Merzky]

Andre Merzky added the comment:

This is patch is meant to be illustrative rather than functional (but it works 
in the limited set of cases I tested).

--
keywords: +patch
Added file: http://bugs.python.org/file40448/subprocess.py.diff

___
Python tracker 

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

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

[Andre Merzky]

Changes by Andre Merzky :


Removed file: http://bugs.python.org/file40448/subprocess.py.diff

___
Python tracker 

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

[issue24862] subprocess.Popen behaves incorrect when moved in process tree

[Andre Merzky]

Changes by Andre Merzky :


Added file: http://bugs.python.org/file40449/subprocess.py.diff

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Jelle Zijlstra]

Jelle Zijlstra added the comment:

Is this behavior intentional?

>>> str = len
>>> x = 'foo'
>>> f'{x!s}'
'3'
>>> '{!s}'.format(x)
'foo'

Or similarly:

>>> import builtins
>>> del builtins.repr
>>> f'{x!r}'
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'repr' is not defined

--

___
Python tracker 

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

[issue25076] Wrong parameter name in distutils documentation

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1208c85af6d5 by Benjamin Peterson in branch '3.4':
fix name of argument in docstring and the docs (closes #25076)
https://hg.python.org/cpython/rev/1208c85af6d5

New changeset 63bbe9f80909 by Benjamin Peterson in branch '2.7':
fix name of argument in docstring and the docs (closes #25076)
https://hg.python.org/cpython/rev/63bbe9f80909

New changeset f4dc1b8bb4b6 by Benjamin Peterson in branch 'default':
merge 3.5 (#25076)
https://hg.python.org/cpython/rev/f4dc1b8bb4b6

--
nosy: +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

[issue24965] Implement PEP 498: Literal String Formatting

[Eric V. Smith]

Eric V. Smith added the comment:

Both of those are known (to me!) byproducts of the current implementation. If 
my crazy idea of adding opcodes to speed up f-strings flies, then this issue 
will go away. I consider this a corner case that doesn't need to be addressed 
before committing this code. I wouldn't emulate it one way or the other just 
yet.

--

___
Python tracker 

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

[issue25081] Windows installer Upgrade->Customize->Back goes to Install page

[Steve Dower]

New submission from Steve Dower:

If you already have Python 3.5.0b4 or later installed and you go to install a 
later version, it starts with an "Upgrade" page.

If you hit customize from the page, then Back, you end up at the original 
Install page. You should be at the Customize page.

--
components: Windows
messages: 250547
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: low
severity: normal
status: open
title: Windows installer Upgrade->Customize->Back goes to Install page
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker 

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

[issue24965] Implement PEP 498: Literal String Formatting

[Martin Panter]

Martin Panter added the comment:

I’m actually trying out your patch now. A couple strange errors and 
observations:

>>> f"{'{'}"  # Why is this allowed in an outer format expression--
'{'
>>> f"{3:{'{'}>10}"  # --but not inside a format specifier?
SyntaxError: nesting of '{' in format specifier is not allowed
>>> opening = "{"; f"{3:{opening}>10}"  # Workaround
'{3'
>>> f"{3:{'}'}<10}"  # Error message is very strange!
SyntaxError: missing '}' in format string expression
>>> f"{\x00}"  # It seems this is treated as a null terminator
  File "", line 1
(
^
SyntaxError: unexpected EOF while parsing
>>> f"{'s'!\x00:.<10}"  # Default conversion is the null character?
's.'

--

___
Python tracker 

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

[issue25021] product_setstate() Out-of-bounds Read

[Raymond Hettinger]

Changes by Raymond Hettinger :


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

[issue25082] Editing What's New In Python 3.5

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Added this issue as a place for discussion and release blocker for 3.5.

--
assignee: yselivanov
components: Documentation
messages: 250549
nosy: larry, serhiy.storchaka, yselivanov
priority: release blocker
severity: normal
status: open
title: Editing What's New In Python 3.5
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