[issue32123] Make the API of argparse.HelpFormatter public

[paul j3]

paul j3  added the comment:

To elaborate on my last comment, the existing subclasses that customize 
formatting modify

_fill_text
_split_lines
_get_help_string
_get_default_metavar_for_optional
_get_default_metavar_for_positional

those are all 'private' methods.

--

___
Python tracker 

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

[issue32474] argparse nargs should support string wrapped integers too

[paul j3]

paul j3  added the comment:

In https://bugs.python.org/issue11354

'argparse: nargs could accept range of options count'

I explored the option allowing regex style range arguments, such as 
nargs='{2,4}' or an equivalent tuple nargs=(2,4).

But that builds on https://bugs.python.org/issue9849, which seeks better error 
checking of the `nargs` parameter.  In the current implementation, there is no 
checking or parsing of the value. The full range of allowable values is 
determined by its use in 2 methods:

_get_nargs_pattern
_format_args

--
nosy: +paul.j3

___
Python tracker 

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

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

[Ned Deily]

Change by Ned Deily :


--
nosy: +mattbillenstein

___
Python tracker 

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

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

[Tom Karzes]

Tom Karzes  added the comment:

I'm dismayed to see that this bug was reported in 2010, yet as of January 2018 
has not yet been fixed.  This option parsing behavior is contrary to Unix 
option passing conventions.  I certainly don't mind enhancements, but the last 
thing that should *ever* be introduced into an option parser is ambiguity.  
It's dangerous.

I'm an old-school Unix guy.  I know exactly what options I want to pass to my 
program, and I know exactly how they should be passed.  Options first, with 
option arguments immediately following the option name, followed by positional 
arguments (with no more options being recognized after that point).  If the 
first positional argument begins with a hyphen, "--" can be used to end option 
parsing.  That's all I want.  Simple.  Precise.  Unambiguous.  And it doesn't 
place any constraints on what an option value can look like.

Yes, I know I can get around the problem by using "=" to join option values to 
the preceding option names, but that shouldn't be necessary.

In my opinion, the entire approach of attempting to distinguish option names 
from arguments out of context is fatally flawed.  It cannot be done.  Period.  
Furthermore, it's utterly unnecessary.  All I want is a parameter I can pass to 
argparse to tell it to accept the entire command line at face value, without 
any second-guessing.  If I specify an option that takes an integer argument, 
then the very next command line argument should be an integer.  If it isn't, I 
want an immediate error.

More to the point, if I specify an option that takes a string argument, then 
the very next command line argument is that string, period.  It doesn't matter 
if it begins with a hyphen or any other character for that matter.  It's a 
string.  It can contain *any* character.  And yet, argparse doesn't support 
this basic, fundamental functionality without the user inserting an "=" to join 
the arguments.  Why??

Here's an analogy:  Your favorite car company has released a new car.  It adds 
lots of great features, like a sun roof and a fancy navigation system.  But 
oops, the brakes no longer work if you're turning right when you apply them.  
But not to worry!  You can always just throw it into park to stop the car.  
It's worth it for the new features, right?  Wrong.

It seems to me like there are three possible solutions to this:  (1) Add a 
"traditional" mode to argparse that completely bypasses any attempt to classify 
command line arguments as "options" vs. "arguments", (2) Un-deprecate optparse, 
and resume development on it, adding support for some of the argparse features 
but without breaking standard Unix option parsing, or (3) Create yet another 
new option parsing package for Python, one which supports traditional Unix 
option parsing and doesn't introduce gratuitous ambiguities and restrictions on 
what strings can contain.

My specific case:  I have an option whose argument is a comma-separated list of 
signed integers, as a single string.  This is the format another, non-Python 
application requires, and it needs to be compatible.  But the following fails:  
--myopt -1,2

Apparently it thinks "-1,2" is an option name.  No, it's a string option value, 
and should not be interpreted in any other way.  I want it passed as the option 
value.  I would want the same no matter *what* characters it contained.  And I 
don't want to have to glue the two arguments together with "=".

--
nosy: +karzes

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I think this is a duplicate of #32007.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[杨鹏]

杨鹏  added the comment:

OK，i got it. thanks for your reply. But i have to say, the BaseHTTPServer 
document is kind of confusing. It claims to support persistent connection, but 
actually it hangs with such situation, i can't even shut it down with shudown() 
method. After diving into source code of SocketServer, i finally found the myth.

--

___
Python tracker 

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

[issue32232] building extensions as builtins is broken in 3.7

[Ned Deily]

Ned Deily  added the comment:

Can someone provide a pull request and a test for this prior to beta 1?

--

___
Python tracker 

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

[issue32248] Port importlib_resources (module and ABC) to Python 3.7

[Ned Deily]

Change by Ned Deily :


--
pull_requests: +4998

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[Martin Panter]

Change by Martin Panter :


--
superseder: HTTPServer can't deal with persistent connection properly -> 
http.server and SimpleHTTPServer hang after a few requests

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Christian Heimes]

Christian Heimes  added the comment:

I modified setup.py to look for libtirpc. In case the library is detected, it's 
added as dependency and /usr/include/tirpc is included in search path.

--
assignee: christian.heimes -> 
stage: patch review -> 
versions:  -Python 3.5, Python 3.8

___
Python tracker 

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

[issue31963] AMD64 Debian PGO 3.x buildbot: compilation failed with an internal compiler error in create_edge

[Neil Schemenauer]

Neil Schemenauer  added the comment:

That's mysterious.  I reviewed the 'stdout' log from the buildbot.  The removal 
of profile data is run early in the build:

find . -name '*.gc??' -exec rm -f {} ';'

Later, the bytearrayobject is compiled with profile generation enabled:

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes-std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -fprofile-generate  -I. -I./Include
-DPy_BUILD_CORE -o Objects/bytearrayobject.o Objects/bytearrayobject.c

When the unit tests run, we get errors:

profiling:/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Objects/bytearrayobject.gcda:Merge
 mismatch for function 35

The second build (with profile use) fails because of the missing profile 
information:

gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes-std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers 
-Werror=implicit-function-declaration -fprofile-use -fprofile-correction  -I. 
-I./Include-DPy_BUILD_CORE -o Objects/bytearrayobject.o 
Objects/bytearrayobject.c
Objects/bytearrayobject.c: In function ‘bytearray_startswith’:
Objects/bytearrayobject.c:2429:1: error: the control flow of function 
‘bytearray_startswith’ does not match its profile data (counter 
‘time_profiler’) [-Werror=coverage-mismatch]
 }
 ^
cc1: some warnings being treated as errors

Seems like a compiler bug to me.  Wild theory, could it be something to do with 
address randomization and forking?  Looks like maybe the merge mismatch errors 
come when the 'python' executable forks.

--

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt  added the comment:

On 08/01/2018 17:22, Michael wrote:
> On 08/01/2018 16:07, Michael Felt wrote:
>> Michael Felt  added the comment:
>>
>> Considering that _uuid is now working for AIX issue32399 -

some time differences - this is on POWER6 (10 years old system) - I 
expect POWER8 and POWER9 to be much quicker in exact times.

michael@x071:[/data/prj/python/git/xlc-python3-3.7]./python
Python 3.7.0a3+ (heads/master:9b99747, Jan  8 2018, 15:50:03) [C] on aix6
Type "help", "copyright", "credits" or "license" for more information.
 >>>
michael@x071:[/data/prj/python/git/xlc-python3-3.7]./python -m timeit -n 
100 -r 5 'import uuid; getnode = uuid.getnode()'
100 loops, best of 5: 911 nsec per loop

michael@x071:[/data/prj/python/git/xlc-python3-3.7]python
Python 2.7.12 (default, Sep 29 2016, 12:02:17) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
 >>>
michael@x071:[/data/prj/python/git/xlc-python3-3.7]python -m timeit -n 
100 -r 5 'import uuid; getnode = uuid.getnode()'
100 loops, best of 5: 2.86 usec per loop
michael@x071:[/data/prj/python/git/xlc-python3-3.7]

The second example is a) before the _uuid support was in the code, and 
b) even if in the code would not have been built on AIX5.

The relative difference is: 911/2860 :: 31.85/100 - or roughly 3x faster 
with _uuid.

As far as this issue is concerned - with _uuid active the buggy code I 
mentioned for getnode() is defunct as it does not get called/parsed. 
However, I shall continue with it.

Question: (must have questions!) - the behavior of getnode() without 
_uuid is a 'random' value for getnode() with my current setup BUT using 
the _uuid module it is a 'constant' that is related to (one of) the 
network interface(s). What is the desired behavior, specifically, of 
uuid.getnode() - constant, or 'random'?

>>
>> Does uuid.py (./Lib/uuid.py) call _uuid.py?

--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Christian Heimes]

Change by Christian Heimes :


--
keywords: +patch
pull_requests: +4997
stage:  -> patch review

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Christian Heimes]

Change by Christian Heimes :


--
assignee:  -> christian.heimes
nosy: +christian.heimes

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[STINNER Victor]

STINNER Victor  added the comment:

> The header is located at /usr/include/tirpc/rpc/rpc.h

configure.ac should be modified to detect tirpc is installed. If yes, setup.py 
should add /usr/include/tirpc/ to includes to build the "nis" module.

--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

The header is located at /usr/include/tirpc/rpc/rpc.h

--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Already tried. Unfortunately it doesn't.

--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[STINNER Victor]

STINNER Victor  added the comment:

Do you know if installing libtirpc-devel does install required rpc/rpc.h / 
fixes the issue?

--

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

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

[issue32521] NIS module fails to build due to the removal of interfaces related to Sun RPC from glibc.

[Charalampos Stratakis]

Change by Charalampos Stratakis :


--
title: NIS module fails to build due to the remove of interfaces related to Sun 
RPC from glibc. -> NIS module fails to build due to the removal of interfaces 
related to Sun RPC from glibc.

___
Python tracker 

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

[issue32521] NIS module fails to build due to the remove of interfaces related to Sun RPC from glibc.

[Charalampos Stratakis]

New submission from Charalampos Stratakis :

Currently on the development branch of Fedora (28), an upstream change of glibc 
is being pushed where the Sun RPC support is removed from our downstream glibc 
package in favor of the libtirpc library. More details [0].

As a result, when python is trying to build the nis extension, it will complain 
with:
fatal error: rpc/rpc.h: No such file or directory
#include 
  ^~~
compilation terminated.
 
[0] https://fedoraproject.org/wiki/Changes/SunRPCRemoval

--
components: Extension Modules
messages: 309674
nosy: cstratak
priority: normal
severity: normal
status: open
title: NIS module fails to build due to the remove of interfaces related to Sun 
RPC from glibc.
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt  added the comment:

On 08/01/2018 16:07, Michael Felt wrote:
> Michael Felt  added the comment:
>
> Considering that _uuid is now working for AIX issue32399 - I need to get some 
> things straight (aka some help please).
>
> Does uuid.py (./Lib/uuid.py) call _uuid.py?
>
> If not, I am curious how _uuid.c is used - because ./Lib/test/test_uuid.py 
> does not seem to be successful in finding it:
>
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(10)()
> -> py_uuid = support.import_fresh_module('uuid', blocked=['_uuid'])
> (Pdb) n
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(11)()
> -> c_uuid = support.import_fresh_module('uuid', fresh=['_uuid'])
> (Pdb) n
>> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(14)()
> -> def importable(name):
> (Pdb) py_uuid
> 
> (Pdb) c_uuid
> (Pdb)
>
> So, for now it seems the test is only testing 'uuid.py'. I would like to see 
> the added value of having gotten the _uuid Module to build.
>
> However, if this is 'working as designed' I not worry about it and just go 
> back into the util.py - getnode() etc.

Got this figured out. tested on too many machines - the last version 
built was on AIX5 - which does not have uuid() functions in libc.a.

Running on AIX6 - I get:

(Pdb) py_uuid

(Pdb) c_uuid

(Pdb) import _uuid
(Pdb) _uuid

(Pdb)

However, have a new question - why are py_uuid and c_uuid 'equivalent'. 
(_uuid is shown just to show that it can be imported).

A comment - perhaps a new bpo/issue topic. When trying to run the tests 
from a freshly built version - it still seems to default to looking at 
the installed version first. And that can make debugging very very hard 
(which modules are actually getting loaded?!). In this case, there also 
seem to be a python2 and python3 incompatibility - notice the python2.7 
pdb reference!

michael@x071:[/data/prj/python/git/python3-master]python -m pdb 
./Lib/test/test_uuid.py
Traceback (most recent call last):
   File "/opt/lib/python2.7/pdb.py", line 1314, in main
     pdb._runscript(mainpyfile)
   File "/opt/lib/python2.7/pdb.py", line 1233, in _runscript
     self.run(statement)
   File "/opt/lib/python2.7/bdb.py", line 400, in run
     exec cmd in globals, locals
   File "", line 1, in 
   File "./Lib/test/test_uuid.py", line 520
     print(hex, end=' ')

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

--

___
Python tracker 

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

[issue32520] error writing to file in binary mode - python 3.6.3

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

print() converts all its arguments to string by calling str(). The resulting 
strings are written to the output file.

print(bin_buff, file=fp) is equivalent to

fp.write(str(bin_buff))
fp.write('\n')

If you will run Python with options -b or -bb you will get a warning or an 
error from str(bin_buff) because this operation can be ambiguous. It is better 
to use an explicit repr() for converting bytes to str if you want to get the 
representation of the bytes object as a Python literal, or convert it to a 
string with specifying explicit encoding: str(bin_buff, 'utf-8') or 
bin_buf.decode('utf-8').

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue32174] nonASCII punctuation characters can not display in python363.chm.

[wwq]

wwq  added the comment:

I found the problem was not fixed on python364.chm but it show well on 
python362.chm, maybe the python.org official config was a change to let the 
coding error.

--
nosy: +wwqgtxx

___
Python tracker 

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

[issue31993] pickle.dump allocates unnecessary temporary bytes / str

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'll create a separate PR for the memoroview issue after merging PR 5114.

--

___
Python tracker 

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

[issue32520] error writing to file in binary mode - python 3.6.3

[jeff deifik]

New submission from jeff deifik :

I am running python 3.6.3 on cygwin / windows.

Here is a test program to demonstrate the bug:

#!/usr/bin/env python3

fp = open("bug_out.txt", "ab")
buff = 'Hello world'
print('type of buff is', type(buff))
bin_buff = bytes(buff,  'utf-8')
print('type of bin_buff is', type(bin_buff))
print(bin_buff, file=fp)

Here is the output:
./bug.py
type of buff is 
type of bin_buff is 
Traceback (most recent call last):
  File "./bug.py", line 8, in 
print(bin_buff, file=fp)
TypeError: a bytes-like object is required, not 'str'

The python type system things bin_buff has type bytes, but when I try to print 
it, the print function thinks it is of type str.

--
components: IO
messages: 309669
nosy: lopgok
priority: normal
severity: normal
status: open
title: error writing to file in binary mode - python 3.6.3
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

[issue32517] test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

[STINNER Victor]

Change by STINNER Victor :


--
title: test_read_pty_output() of test_asyncio hangs on x86-64 Sierra 3.6 -> 
test_read_pty_output() of test_asyncio hangs on macOS 10.13.2 (darwin 17.3.0)

___
Python tracker 

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

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

[Michael Felt]

Michael Felt  added the comment:

Considering that _uuid is now working for AIX issue32399 - I need to get some 
things straight (aka some help please).

Does uuid.py (./Lib/uuid.py) call _uuid.py?

If not, I am curious how _uuid.c is used - because ./Lib/test/test_uuid.py does 
not seem to be successful in finding it:

> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(10)()
-> py_uuid = support.import_fresh_module('uuid', blocked=['_uuid'])
(Pdb) n
> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(11)()
-> c_uuid = support.import_fresh_module('uuid', fresh=['_uuid'])
(Pdb) n
> /data/prj/python/git/python3-3.7/Lib/test/test_uuid.py(14)()
-> def importable(name):
(Pdb) py_uuid

(Pdb) c_uuid
(Pdb)

So, for now it seems the test is only testing 'uuid.py'. I would like to see 
the added value of having gotten the _uuid Module to build.

However, if this is 'working as designed' I not worry about it and just go back 
into the util.py - getnode() etc.

--

___
Python tracker 

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

[issue32519] venv API docs - symlinks default incorrect

[Jason R. Coombs]

New submission from Jason R. Coombs :

In the API docs for EnvBuilder.symlinks, it states "Defaults to True on Linux 
and Unix systems, but False on Windows." But in fact, the implementation takes 
the value passed, which always defaults to False. It's only on the command-line 
that the default is inferred from the system. Presumably, the fix is to strike 
that sentence from the docs.

--
components: Library (Lib)
messages: 309667
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: venv API docs - symlinks default incorrect

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

On 08/01/2018 12:47, David Carlier wrote:
> David Carlier  added the comment:
>
> Perfect. That solves in the process OpenBSD uuid module build too.
>
> --
p.s. I did not 'invent' unsigned32 - just took the syntax from the man 
page: 
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.basetrf2/uuid_create.htm
 
- and I just did the grep above to show the type existed AND was 
directly related to unsigned32 - even in AIX include files.
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue32517] test_read_pty_output() of test_asyncio hangs on x86-64 Sierra 3.6

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The darwin version change is likely due to an upgrade from macOS 10.13.1 to 
10.13.2.

The user change can be due to the introduction of a new system user, but I 
don't know when user _timed was introduced and don't have 10.3 VMs other than 
one running 10.13.2.  User _timed does not exist on 10.12.6, and is hence a 
fairly recent addition.

The buildbot operator could verify this by checking the UID for user buildbot, 
this likely conflicts with user _timed. The fix for that would be the give user 
buildbot a new UID and chown all files in the buildbot tree to the new UID.

--

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[R. David Murray]

R. David Murray  added the comment:

Yes, I would say it is.

Note that this isn't going to get "fixed" in 2.7, because 2.7 doesn't get new 
features, and the proposed change to the CLI is a new feature.  As noted in 
that issue discussion we aren't going to change the inheritance hierarchy of 
the classes.  It is up to the library user to make that choice and implement it.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> HTTPServer can't deal with persistent connection properly

___
Python tracker 

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

[issue26959] pickle: respect dispatch for functions again

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[David Carlier]

David Carlier  added the comment:

Perfect. That solves in the process OpenBSD uuid module build too.

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Seems to be in inttypes.h:
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/inttypes.h.htm

--

___
Python tracker 

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

[issue32493] UUID Module - FreeBSD build failure

[Michael Felt]

Michael Felt  added the comment:

On 05/01/2018 13:38, Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
>
> Michael, does AIX have uint32_t?  If so, we could happily drop the unsigned32 
> reference.

Yes, AIX has unit32_t.

michael@x071:[/home/michael]grep unsigned32 /usr/include/*.h 
/usr/include/sys/*.h | grep typed
/usr/include/uuid.h:typedef u_int32_t unsigned32;  /* positive 32 
bit integer */
/usr/include/uuid.h:typedef unsigned32 boolean32;

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

--

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[Martin Panter]

Martin Panter  added the comment:

Perhaps this can be treated as a duplicate of Issue 31639.

--
nosy: +martin.panter

___
Python tracker 

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

[issue32518] HTTPServer can't deal with persistent connection properly

[杨鹏]

New submission from 杨鹏 :

when client is using persistent connection, HTTPServer will hang with that 
connection. As a result, it can't deal with other clients.

--
components: Library (Lib)
messages: 309659
nosy: 杨鹏
priority: normal
pull_requests: 4996
severity: normal
status: open
title: HTTPServer can't deal with persistent connection properly
type: behavior
versions: Python 2.7

___
Python tracker 

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