[issue34711] Lib/http/server.py: Return HTTPStatus.NOT_FOUND if path.endswith(/) and not a directory

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +14034
pull_request: https://github.com/python/cpython/pull/14197

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

[issue35704] On AIX, test_unpack_archive_xztar fails with default MAXDATA settings

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +14031
pull_request: https://github.com/python/cpython/pull/14194

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Need some help searching github to determine the blast radius of the proposed 
changes. How does one look for instances of argparse.REMAINDER that are used 
with a default value?

--

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

Re: How control a GUI for an unrelated application from a Python script?

[Michael Torrie]

On 06/13/2019 05:49 PM, Christian Seberino wrote:
> I have a third party GUI that manages some hardware.
> 
> I want to control the hardware from a Python script.
> 
> This seems to mean I need to somehow have Python code
>   that imitates a human doing the necessary
> actions on the GUI (selecting menu options, pressing buttons, etc.)
> 
> Is this possible

Maybe.

> / easy 
No.

> doable?

Maybe.

It's kind of the old "if you have to ask" sort of question.

There are ways of programatically driving other applications' user
interfaces.  You haven't said what OS you are using.  We used to use an
application called AutoIt to drive GUI programs.  You can send clicks,
keystrokes, and work with certain controls (read values, set values,
etc), at least if they are standard win32 widgets.  More and more
applications draw their own controls these days rather than use win32
widgets, which wouldn't be usable for that kind of modification.

As far as modifying a running GUI to add functionality, the answer to
that is probably "very difficult" to "impossible."  If the GUI itself is
just a frontend for command-line tools or even libraries that interact
with the hardware, then you probably could develop your own GUI from
scratch.

This is one reason why free and open source software wins. It's just
that much more flexible to manipulate and make to do cool new things.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue19645] decouple unittest assertions from the TestCase class

[Michael Foord]

Michael Foord  added the comment:

Or even making the assert methods into custom descriptors.

--

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

[issue19645] decouple unittest assertions from the TestCase class

[Michael Foord]

Michael Foord  added the comment:

Hmm, it could be done by __init_subclass__ potentially.

--

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

[issue19645] decouple unittest assertions from the TestCase class

[Michael Foord]

Michael Foord  added the comment:

Suppose failureException is set to TypeError on that TestCase class, how would 
your assertEquals signal failure to the test runner?

--

___
Python tracker 
<https://bugs.python.org/issue19645>
___
___
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() needs refresh

[Michael Felt]

Michael Felt  added the comment:

p.s. - changed the title: way back when I first started on this I was mainly 
concerned that the _netstat_getnode() routine was broken for AIX. During the 
research and follow-up discussions it has become clear that it is more than 
just an AIX issue. There are multiple aspects that need attention.

Footnote: For most platforms, most of the data accessed via Lib/uuid is 
actually retrieved via Modules/_uuid. The majority of issues with Lib/uuid 
occur during testing: ./python -m test test_uuid

At least two PR (8672 - fix bug for AIX), (12777 - make "_getters" lists 
platform specific when possible). FYI: the first PR (5183) was when I was 
trying to patch multiple issues.

--
title: core logic of uuid.getnode() is broken for netstat -> core logic of 
uuid.getnode() needs refresh

___
Python tracker 
<https://bugs.python.org/issue28009>
___
___
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 netstat

[Michael Felt]

Change by Michael Felt :


--
versions: +Python 3.9

___
Python tracker 
<https://bugs.python.org/issue28009>
___
___
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 netstat

[Michael Felt]

Michael Felt  added the comment:

I have modified -

_NODE_GETTERS_WIN32 = [_windll_getnode, _netbios_getnode, _ipconfig_getnode]

_NODE_GETTERS_UNIX = [_unix_getnode, _ifconfig_getnode, _ip_getnode,
  _arp_getnode, _lanscan_getnode, _netstat_getnode]

to:

  +683  # _OS_GETTERS, when known, are targetted for a specific OS or platform.
  +684  # The order is by 'common practice' on the specified platform.
  +685  # Note: 'posix' and 'windows' _OS_GETTERS are prefixed by a 
dll/dlload() method
  +686  # which, when successful, means none of these "external" methods are 
called.
  +687  # _GETTERS is (also) used by test_uuid.py to SkipUnless(), e.g.,
  +688  # @unittest.skipUnless(_uuid._ifconfig_getnode in _uuid._GETTERS, 
...)
  +689  if _LINUX:
  +690  _OS_GETTERS = [_ip_getnode, _ifconfig_getnode]
  +691  elif _DARWIN:
  +692  _OS_GETTERS = [_ifconfig_getnode, _arp_getnode, _netstat_getnode]
  +693  elif _WINDOWS:
  +694  _OS_GETTERS = [_netbios_getnode, _ipconfig_getnode]
  +695  elif _AIX:
  +696  _OS_GETTERS = [_netstat_getnode]
  +697  else:
  +698  _OS_GETTERS = [_ifconfig_getnode, _ip_getnode, _arp_getnode,
  +699 _netstat_getnode, _lanscan_getnode]
  +700  if os.name == 'posix':
  +701  _GETTERS = [_unix_getnode] + _OS_GETTERS
  +702  elif os.name == 'nt':
  +703  _GETTERS = [_windll_getnode] + _OS_GETTERS
  +704  else:
  +705  _GETTERS = _OS_GETTERS

The shortened list, and in particular the move of _ip_getnode before 
_ifconfig_getnode is my experience that the "old" programs such as ifconfig, 
arp, and netstat are (occasionally) not available - with "ip" being the 
replacement for all.

Further, re: linux, on the two distros I could test (centos and debian) neither 
arp nor netstat return a (useable) MACADDR aka "node" value.

Requesting verification from people with other platforms.

Also, would like to know specifics for other platforms (e.g., OpenBSD, HPUX, 
Solaris). 

More generally speaking - if os.name is "posix" or "windows" - this  lists are 
almost irrelevant because the "DLL" _uuid module should provide the needed 
value.

The "plus" is that on systems that audit such things, there are fewer calls to 
non-existent programs and/or negative side-effects from calling programs that 
can/do not provide any useful data.

--

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

[issue19645] decouple unittest assertions from the TestCase class

[Michael Foord]

Michael Foord  added the comment:

Has anyone seen any real world use cases for failureException? It's a real 
hindrance to a whole bunch of changes sounds decoupling. 

On the other hand something like assertThat could catch a custom exception from 
the matchers (subclass of AssertionError) and raise failureException

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +13875
pull_request: https://github.com/python/cpython/pull/14011

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

[issue37243] test_sendfile in asyncio crashes when os.sendfile() is not supported

[Michael Felt]

Change by Michael Felt :


--
keywords: +patch
pull_requests: +13874
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14010

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

[issue37243] test_sendfile in asyncio crashes when os.sendfile() is not supported

[Michael Felt]

New submission from Michael Felt :

issue34655 added sendfile support to asyncio. However, the `test_sendfile` 
fails when called if there is no os.sendfile support.

This patch will skip the test when 

@unittest.skipUnless(hasattr(os, 'sendfile'), 'test needs os.sendfile()')

--
messages: 345314
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_sendfile in asyncio crashes when os.sendfile() is not supported

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

[issue37087] Adding native id support for openbsd

[Michael Felt]

Change by Michael Felt :


--
pull_requests: +13872
pull_request: https://github.com/python/cpython/pull/13624

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

Re: FDs will be closed after exception automatically in python2.7?

[Michael Torrie]

On 06/10/2019 04:18 AM, lampahome wrote:
> as title,
> 
> I confused will fd will be close after exception automatically?
> Like:
> try:
> fd=open("file","w+")
> fd.get() //any useless function of fd
> except Exception:
> print 'hi'

No.  What if you want to work with the fd object after dealing with the
exception?

Probably you should be using Python 3, which uses a print() function.
But even in Python 2.7, the recommended way to do this is like this:

fd = open("file","w+")
with fd:
fd.get()

After the "with" block exits, the fd object is automatically closed.
This happens regardless of whether an exception occurred within the with
block or not.  You may use try and except within the with block.
Normally I wouldn't bother, though.

Be careful about catching exceptions.  In most cases, it is not
appropriate in my opinion to "except Exception" which will catch *all*
exceptions including syntax errors in your code.

Only catch exceptions that your code is specifically equipped to deal
with (expecting).  For example, if a user provides a file name, and you
open it, you may want to catch the FileNotFound exception, in order to
inform the user and prompt for a new file name.

Exceptions that your code is not expecting and cannot handle should be
left alone to bubble up and be caught somewhere else, or crash the
program with a traceback, which will aid in debugging.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

[Michael Felt]

Michael Felt  added the comment:

I started a reply on the python-mentoring maillist - and promised to come back 
here.

a) imho - the discussion about an "attacker" is only misleading for the general 
case. For active attacks - where an attacker has active acces to the system is 
not something that is the responsibility of "stdlib". On POSIX, one of the 
first things I would consider is adding the "STX" bit so that only root and the 
file owner can remove an existing "link" to an inode (a symbolic link is a 
"special" file whose contents is the PATH to yet another filesystem "name" 
regardless of it's type.) For reference, a hard-link "merely" increases the 
number of links to an inode - and so only works for non-directory objects 
within the same filesystem). Puf!

b) the "real", again imho, security issue is one of system integrity. Compare 
this "race" condition with a multi-user database (think of directories as the 
"index" to a data-record. A user that trusts the file-system index to refer to 
the correct file-system object (file, directory, other special file) - 
especially when there is no way for the user to verify the accuracy of the 
symbolic link. Any application, especially if it runs as "root" needs to be 
extremely cautious with "overwriting" existing "records". It is asif as 
database admin just changes where one database record references - as is, I 
cannot change the data it references - so I just change what it goes to - where 
I can change the data. -- As I think about it - an application that is 
dependent on symbolic links has an inherent weakness.

In short - I would be against this - if security is the primary argument for 
developing it. I would rather be notified that there is an existing symbolic 
link - where there should not be - and consider later action.

a) an application, running as root, can override any security measure I can 
come up with. The is the core "weakness" of UNIX/POSIX access control. When not 
running as root - there are mechanisms that can block the removal of any 
directory entry (the unlink() call).

b) so, if you want to consider adding a "user-friendly" force option, just as 
POSIX ln does (whether for hard or soft links) - then that is, imho - a 
different discussion. I would tend to be "against" making it too easy, because 
an application coded with "Force=true" would never get the feedback that 
something already exists. If the currect implementation returns the a "fatal" 
error - that needs to be fixed.

In short, I do not think it is the task of Python to rewrite the behavior of 
the system calls being used - and/because I fear lazy programmers (being there, 
done that!).

"ls -sf xxx yyy" and/or "ln -f xxx yyy" is a convenience. Using it as a default 
is "bad-practice" (imho) - and I fear programmers would use this new "feature" 
and move to "bad practice"

Michael

--

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

[issue36656] Please add race-free os.link and os.symlink wrapper / helper

[Michael Felt]

Change by Michael Felt :


--
nosy: +Michael.Felt

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

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 06/06/2019 19:08, Steve Dower wrote:
> Steve Dower  added the comment:
>
> Changing our policy here (from "no policy" to "here's a recommendation") 
> probably deserves a python-dev discussion first.
I can rejoin the list - to follow the discussion, should one start.
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36624>
> ___
>

--

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

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 06/06/2019 14:14, Tal Einat wrote:
> Tal Einat  added the comment:
>
> Steve's suggestion sounds reasonable.
>
> Should we just add this to the devguide, then?

Well, as I said before - it was never about THIS being the solution.
While that would have been nice (for my ego). Would it be worthwhile,
assuming this moves to "devguide" status - for me to work through the
tests - looking for the tests that do not follow these guidelines and
"patch" those?

Probably minor, but it is something I could do. Think of it as
"self-documentation" rather than .rst files.

>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36624>
> ___
>

--

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

[issue37166] inspect.findsource doesn't handle shortened files gracefully

[Michael Bejda]

Change by Michael Bejda :


--
keywords: +patch
pull_requests: +13727
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13850

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

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 05/06/2019 07:07, Tal Einat wrote:
> Tal Einat  added the comment:
>
> Michael, your willingness to help, and the work on this issue and PR, are 
> greatly appreciated!
>
> Reading through the discussion here again, and the one referenced by Ned, I 
> tend to agree with the point that having *yet another* spelling for OS 
> checking is perhaps not a good idea.  The point that needing to see exactly 
> which check is done in certain edge-cases is another good point against 
> adding such new constants.  Moreover, regardless of my opinion, there isn't a 
> consensus and at this point I don't think there will be.
>
> Considering the above, perhaps it would be better to use only a single, 
> "canonical" idiom throughout the tests, or at least from this point forward 
> (to avoid a codebase-wide change)? Steve Dower said he would "prefer 
> sys.platform to be canonical".
>
> I do suffer from having all of os.name, sys.platform and platform.system() 
> used in various places, and it not being clear when one should be used 
> instead of another.

>From experience, for AIX, and I think also for windows, not sure about
darwin, oops - macos (or is that macOS) the confusion I faced was that
sys.platform returns the value the system was built on, not what it is
running on. If I was an application developer I would be more interested
in the platform it is running on. "Lucky me!" - starting with Python3.8
sys.platform will say "aix" rather than aixX. Likely there could have
been differences between aix3 and aix4 (e.g., the kernel changed from
"static" to "dynamic" driver extensions) that might have influenced
Python - but not since AIX5 - and AIX "binary compatibility" assurances
when using shared libraries (from IBM, e.g. libc).

More to the point - we all suffer - and some kind of direction is
needed. Beyond my pay grade - so I'll accept whatever is decided (even
if that is indecesion). As I said before - "lucky me", the core is
"resolved" for AIX (platform.system() == 'AIX', and sys.platform ==
'aix') - just as it is for "linux". This remains 'not resolved' for many
other platforms.

Further, imho - having it defined as a "constant" is not "yet another
spelling". Instead, it moves us towards a "canonical" idiom.

I have said before, and I'll say again - I am willing to do the manual
backport, learn more about git as I do so (;P) - and I'll even
"maintain" this, should this be any additional "help" is working towards
a canonical/uniform (or should I say PEP) to establish the RUNNING platform.

Regards,

Michael

> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36624>
> ___
>

--

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

Re: Checking refusal of a network connection

[Michael Torrie]

On 06/01/2019 11:15 AM, Markus Elfring wrote:
>>> connect(3, {sa_family=AF_INET, sin_port=htons(37351), 
>>> sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
>>
>>  Without seeing the code, I'd be suspicious of that difference.
> 
> I would expect that the IPv4 address from such a connection attempt
> would be automatically converted to a IPv6 loopback address.

How would this conversion take place?  Localhost is 127.0.0.1.
Localhost6 is ::1.  They are different and you cannot route between the two.

What I can see is that your server binds to localhost6 and your client
is trying to connect to localhost.

> Unfortunately, the direct specification “… socket-send_json_data.py 
> --server_id ::1 …”
> does not work at the moment because of the error message “socket.gaierror: 
> [Errno -9]
> Address family for hostname not supported”.

No idea on that one.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue36721] Add pkg-config python-3.8-embed and --embed to python3.8-config

[Michael Haubenwallner]

Change by Michael Haubenwallner :


--
pull_requests: +13592
pull_request: https://github.com/python/cpython/pull/737

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Michael Felt]

Michael Felt  added the comment:

hmm - i had just synced with master. must have just missed something since 
there is a strike-out through GH-13251. If so, please ignore. BBL.

--

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

[issue36889] Merge StreamWriter and StreamReader into just asyncio.Stream

[Michael Felt]

Michael Felt  added the comment:

FYI: since:
commit 23b4b697e5b6cc897696f9c0288c187d2d24bff2
Author: Andrew Svetlov 
Date:   Mon May 27 22:56:22 2019 +0300

bpo-36889: Merge asyncio streams (GH-13251)



https://bugs.python.org/issue36889

AIX bot 'hangs' during 
test_sendfile (test.test_asyncio.test_streams.StreamTests)

ctrl-c gives this (in case useful)
Warning -- 'test_asyncio' left behind file '@test_7012552_tmp'
Warning -- asyncio.events._event_loop_policy was modified by test_asyncio
  Before: None
  After:  


== Tests result: INTERRUPTED ==
Test suite interrupted by signal SIGINT.

1 test omitted:
test_asyncio

Total duration: 13 min 36 sec
Tests result: INTERRUPTED
/data/prj/python/git/python3-3.8/Lib/asyncio/base_events.py:646: 
ResourceWarning: unclosed event loop <_UnixSelectorEventLoop running=False 
closed=False debug=False>
  _warn(f"unclosed event loop {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
Exception ignored in: .test 
at 0x30576ed0>
Traceback (most recent call last):
  File 
"/data/prj/python/git/python3-3.8/Lib/test/test_asyncio/test_streams.py", line 
1643, in test
await do_connect(*srv.sockets[0].getsockname())
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py", line 314, in 
__aexit__
await self.close()
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py", line 292, in 
close
await tasks.wait([stream.close() for stream in streams])
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py", line 292, in 

await tasks.wait([stream.close() for stream in streams])
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py", line 1382, in 
close
self._transport.close()
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/selector_events.py", line 
680, in close
self._loop.call_soon(self._call_connection_lost, None)
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/base_events.py", line 711, 
in call_soon
self._check_closed()
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/base_events.py", line 504, 
in _check_closed
raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed
/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py:352: ResourceWarning: 
unclosed stream server 
  _warn(f"unclosed stream server {self!r}",
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/data/prj/python/git/python3-3.8/Lib/asyncio/selector_events.py:684: 
ResourceWarning: unclosed transport <_SelectorSocketTransport fd=7>
  _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/data/prj/python/git/python3-3.8/Lib/asyncio/selector_events.py:684: 
ResourceWarning: unclosed transport <_SelectorSocketTransport closing fd=8>
  _warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
ResourceWarning: Enable tracemalloc to get the object allocation traceback

--
nosy: +Michael.Felt

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

On 30/05/2019 23:11, Andrew Svetlov wrote:
> Andrew Svetlov  added the comment:
>
> Guys, thank you for investigation.
> If there is AIX "idiosyncrasy" -- please feel free to skip failed tests on 
> AIX.
>
> If you have access to AIX box it would be much easier for you. I can only 
> look at Python buildbot statuses.
OK. I'll setup a skip test - but also try to get more info from IBM
and/or discover the root cause myself.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue35545>
> ___
>

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

On 30/05/2019 10:27, Erwan Le Pape wrote:
> Erwan Le Pape  added the comment:
>
> Assuming similar configuration to the one in msg343430, a simple native 
> getaddrinfo test to check whether any scope ID is returned.

The 'expanded' program ... main():

int main() {
/* local addresses */
    test("fe80::221:5eff:fea3:c746%0");
    test("fe80::221:5eff:fea3:c746%en0");
    test("fe80::f8d1:8cff:fe32:8305%2");
    test("fe80::f8d1:8cff:fe32:8305%en1");
/* remote addresses */
    test("fe80::f8d1:81ff:fe81:ac05%2");
    test("fe80::f8d1:81ff:fe81:ac05%en1");

    return 0;
}

The conclusion seems to be that the scopeid returned is always 0 - when
it is working;
The status is always "8", when it fails.

This seems to be:
#define EAI_NONAME  8   /* hostname nor servname not provided,
or not known */

So, %enX is not recognized - only a numerical scope.

+++ Details +++

On the first server - added two addresses - they are local to platform.

root@x066:[/data/prj/aixtools/tests/tcpip/socket]cc -g ex03.c -o ex03
root@x066:[/data/prj/aixtools/tests/tcpip/socket]./ex03
getaddrinfo(fe80::221:5eff:fea3:c746%en0) returned 8
getaddrinfo(fe80::f8d1:8cff:fe32:8305%en1) returned 8
getaddrinfo(fe80::f8d1:81ff:fe81:ac05%en1) returned 8
root@x066:[/data/prj/aixtools/tests/tcpip/socket]netstat -ni
Name  Mtu   Network Address    Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2  0.21.5e.a3.c7.46  1496455 0  1214300 0 0
en0   1500  192.168.129 192.168.129.66    1496455 0  1214300 0 0
en0   1500  fe80::221:5eff:fea3:c746  1496455 0  1214300 0 0
en1   65390 link#3  fa.d1.8c.32.83.5 4041 0   34 0 0
en1   65390 fe80::f8d1:8cff:fe32:8305%2  4041 0   34 0 0
lo0   16896 link#1 160253 0   160252 0 0
lo0   16896 127 127.0.0.1  160253 0   160252 0 0
lo0   16896 ::1%1  160253 0   160252 0 0
root@x066:[/data/prj/aixtools/tests/tcpip/socket]oslevel -s
6100-07-07-1316
+++ Note +++ the 5th field says below (-), equal (=), or exceeded (+)
 - so on this server they are equal, on the AIX 7.1 TL4 - exceeded.
root@x066:[/data/prj/aixtools/tests/tcpip/socket]instfix -ciqk IV52116
IV52116:bos.64bit:6.1.7.21:6.1.7.21:=:GETADDRINFO AND INET_PTON CANNOT
HANDLE IPV6 SCOPE/ZONE
IV52116:bos.rte.control:6.1.7.21:6.1.7.21:=:GETADDRINFO AND INET_PTON
CANNOT HANDLE IPV6 SCOPE/ZONE
IV52116:bos.rte.libc:6.1.7.21:6.1.7.21:=:GETADDRINFO AND INET_PTON
CANNOT HANDLE IPV6 SCOPE/ZONE
IV52116:bos.rte.shell:6.1.7.22:6.1.7.22:=:GETADDRINFO AND INET_PTON
CANNOT HANDLE IPV6 SCOPE/ZONE
IV52116:mcr.rte:6.1.7.21:6.1.7.21:=:GETADDRINFO AND INET_PTON CANNOT
HANDLE IPV6 SCOPE/ZONE

On a second server (all addresses are 'remote now')
root@x064:[/data/prj/aixtools/tests/tcpip/socket]netstat -ni
Name  Mtu   Network Address    Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2  0.21.5e.a3.c7.44   765518 0   792062 0 0
en0   1500  192.168.129 192.168.129.64 765518 0   792062 0 0
en0   1500  fe80::221:5eff:fea3:c744   765518 0   792062 0 0
en1   1500  link#3  fa.d1.81.81.ac.5   773516 0   422335 0 0
en1   1500  192.168.2   192.168.2.64   773516 0   422335 0 0
en1   1500  fe80::f8d1:81ff:fe81:ac05%2    773516 0   422335 0 0
lo0   16896 link#1 410599 0   410596 0 0
lo0   16896 127 127.0.0.1  410599 0   410596 0 0
lo0   16896 ::1%1  410599 0   410596 0 0

root@x064:[/data/prj/aixtools/tests/tcpip/socket]./ex03
getaddrinfo(fe80::221:5eff:fea3:c746%en0) returned 8
gai_strerror:Hostname and service name not provided or found
getaddrinfo(fe80::f8d1:8cff:fe32:8305%en1) returned 8
gai_strerror:Hostname and service name not provided or found
getaddrinfo(fe80::f8d1:81ff:fe81:ac05%en1) returned 8
gai_strerror:Hostname and service name not provided or found

root@x064:[/data/prj/aixtools/tests/tcpip/socket]oslevel -s
7100-04-06-1806
root@x064:[/data/prj/aixtools/tests/tcpip/socket]instfix -ciqk IV53671
IV53671:bos.64bit:7.1.3.15:7.1.4.33:+:getaddrinfo cannot handle IPv6
scope/zone
IV53671:bos.rte.control:7.1.3.15:7.1.4.33:+:getaddrinfo cannot handle
IPv6 scope/zone
IV53671:bos.rte.libc:7.1.3.15:7.1.4.33:+:getaddrinfo cannot handle IPv6
scope/zone
IV53671:bos.rte.shell:7.1.3.15:7.1.4.33:+:getaddrinfo cannot handle IPv6
scope/zone
IV53671:mcr.rte:7.1.3.15:7.1.4.33:+:getaddrinfo cannot handle IPv6
scope/zone

And a server with the bug - i.e., not fixed:
root@x065:[/data/prj/aixtools/tests/tcpip/socket]./ex03
getaddrinfo(fe80::221:5eff:fea3:c746%0) returned 8
getaddrinfo(fe80::221:5eff:fea3:c746%en0) returned 8
getaddrinfo(fe80::f8d1:8cff:fe32:8305%2) returned 8
getaddrinfo

[issue36624] cleanup the stdlib and tests with regard to sys.platform usage

[Michael Felt]

Michael Felt  added the comment:

On 29/05/2019 16:36, Ned Deily wrote:
> Ned Deily  added the comment:
>
> FWIW, my opinion on making this kind of wholesale change has not changed: see 
> the discussion in PR 7800. 

I had actually read through that before I started on this. Your closing
comments are here:
https://github.com/python/cpython/pull/7800#issuecomment-400182213

As someone who does not work 100% of the time with python - it is
extremely confusing and frustrating because there is no clear way of
doing something. From afar it appears as if platform.system() and
sys.platform evolved at different moments. I saw them as equivalent, and
only learned much later than one is build and the other is run-time.
And, there are very specific strings - that no longer match the current
situation.

Why, I ask myself, is it sometimes "darwin" (or is it "Darwin" - oh yes,
different test). And, I also ask myself - why did sys.platform "win"?
People did not like a function call (e.g., more resource intensive?) -
or was sys.platform "first" and platform.system() just never caught on?

I (think I) understand your concerns. While I would consider going
through the code to bring them in-line - that may be, for many reasons -
going too far.

I had hoped to: a) improve consistency and set a good example; as well
as b) be more than 'two constants' and in so-doing, provide a basis for
a grounded discussion.

As we stand now I still have a concern/question - is there any
willingness to work towards a solution - that can be (a basis of) a
clear definition of what "should" be. In a word - I consider the current
situation 'confusing'.

What is presented here does not have to be the solution. I hope everyone
will remember that this concern continues to popup. Saying no over and
over again does not solve anything - will not make it go away. Saying
no, repeatedly, may silence people.

All I can offer is my willingness to help.

Thank you for your time spent reading!

>  I think the changes made there were not an improvement for all the reasons 
> stated, primarily because this now requires people reading the code base to 
> learn *two* different ways of doing the same thing since these changes only 
> affect the tests and not the platform-conditional code in the standard 
> library modules themselves (which are not and should not be changed). Also, 
> this means that backports of fixes from 3.8 will be complicated.  Note there 
> ware already some "translation" errors detected and fixed in the PR re-spin; 
> how many others remain?
>
> --
> nosy: +ned.deily
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36624>
> ___
>

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

On 25/05/2019 00:19, Erwan Le Pape wrote:
> Erwan Le Pape  added the comment:
>
> Thanks for testing that. It's good that you used an actual address because 
> that eliminates the possibility that AIX doesn't handle addresses it doesn't 
> really know about.
>
> On the other hand, even when properly specified to a real scoped IPv6 
> address, `getaddrinfo` doesn't seem to get the necessary scope ID from the 
> underlying C call which socket.getaddrinfo > _socket.getaddrinfo is pretty 
> much mapped to.
>
> I'm looking at cpython/master for the socketmodule implementation:
> https://github.com/python/cpython/blob/6dbbe748e101a173b4cff8aada41e9313e287e0f/Modules/socketmodule.c#L6400
>  is `getaddrinfo`
> https://github.com/python/cpython/blob/master/Modules/socketmodule.c#L1294 is 
> `makesockaddr` which actually creates the 4-tuple returned as the last 
> element of the `getaddrinfo` tuples.
> The fourth element (ie. the scope ID) is clearly `a->sin6_scope_id` which 
> should contain the scope ID.
>
> At this stage, I don't know if this is a bug from the socketmodule which I 
> doubt or if the AIX `getaddrinfo` simply just doesn't handle scoped IP 
> addresses properly.

I also doubt a bug in the socketmodule - my assumption is that AIX may
be wrong - although I prefer different, i.e., has idiosyncrasies.

++ If we "accept" or "conclude" that AIX's getaddrinfo() routine is not
working as needed for this test - would "you" (Python-core) accept a
@SkipIf for this test - as is already done re: IPv6 re:

bpo-34490 Fix test_asyncio for AIX - do not call 
transport.get_extra_info('sockname')

++ Further, I have a start on "send/receive" stubs in C and am trying
out different ideas - learn as I go. "netstat" clearly shows, as does
ifconfig -a

root@x066:[/]ifconfig -a
en0:
flags=1e080863,c0
    inet 192.168.129.66 netmask 0xff00 broadcast 192.168.129.255
    inet6 fe80::221:5eff:fea3:c746/64
 tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 0
en1:
flags=1e080863,480
    inet6 fe80::f8d1:8cff:fe32:8305%2/64
lo0:
flags=e08084b,c0
    inet 127.0.0.1 netmask 0xff00 broadcast 127.255.255.255
    inet6 ::1%1/128
 tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1

Sadly, I have a lot to learn re: IPv6 - and I expect how "host-based
routing" is concerned*, so movement forward will be slow going.

* from years ago, I recall a discussion where one of the improvements in
IPv6 compared to IPv4 is that the "work" of routing would be shared by
all end-points, rather than focused in router(-hubs) whose performance
basically determine the performance limits of a connection (or connections).

>
> If you're still okay to proxy tests for AIX, I'll try and come up with either 
> a simple C snippet to see what's in the returned structure or ctype the AIX 
> `libc` `getaddrinfo`.
Repeating - always willing.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue35545>
> ___
>

--

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

[issue37077] Threading: add builtin TID attribute to Thread objects for AIX

[Michael Felt]

Change by Michael Felt :


--
keywords: +patch
pull_requests: +13523
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13624

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

[issue37077] Threading: add builtin TID attribute to Thread objects for AIX

[Michael Felt]

New submission from Michael Felt :

As issue36084 is already closed - opening a new issue for the PR to add this 
support for AIX.

--
messages: 343765
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Threading: add builtin TID attribute to Thread objects for AIX
versions: Python 3.8

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

[issue17250] argparse: Issue 15906 patch; positional with nargs='*' and string default

[Michael Blahay]

Michael Blahay  added the comment:

Also see https://bugs.python.org/issue35495

--
nosy: +mblahay

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

[issue36913] Missing documentation for decorators

[Michael Blahay]

Michael Blahay  added the comment:

The PEP is not the first place I go looking for information on Python topics, 
just my two cents.

--
nosy: +mblahay

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Ryan, last chance, do you have any feedback?

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

Thank you Mark. Everything for this one is complete. The issue may be closed.

--

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

[issue36084] Threading: add builtin TID attribute to Thread objects

[Michael Felt]

Michael Felt  added the comment:

On 23/05/2019 18:16, Jake Tesler wrote:
> Jake Tesler  added the comment:
>
> Michael Felt -
> If you would like some help with adding/building AIX support for this 
> functionality, tag me, I'd be glad to help out! :)
>
> --
Thanks - I'll try to look at this early next week.
> ___
> Python tracker 
> <https://bugs.python.org/issue36084>
> ___
>

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

No problem with trying out your tests. 

Sent from my iPhone

> On 25 May 2019, at 00:19, Erwan Le Pape  wrote:
> 
> 
> Erwan Le Pape  added the comment:
> 
> Thanks for testing that. It's good that you used an actual address because 
> that eliminates the possibility that AIX doesn't handle addresses it doesn't 
> really know about.
> 
> On the other hand, even when properly specified to a real scoped IPv6 
> address, `getaddrinfo` doesn't seem to get the necessary scope ID from the 
> underlying C call which socket.getaddrinfo > _socket.getaddrinfo is pretty 
> much mapped to.
> 
> I'm looking at cpython/master for the socketmodule implementation:
> https://github.com/python/cpython/blob/6dbbe748e101a173b4cff8aada41e9313e287e0f/Modules/socketmodule.c#L6400
>  is `getaddrinfo`
> https://github.com/python/cpython/blob/master/Modules/socketmodule.c#L1294 is 
> `makesockaddr` which actually creates the 4-tuple returned as the last 
> element of the `getaddrinfo` tuples.
> The fourth element (ie. the scope ID) is clearly `a->sin6_scope_id` which 
> should contain the scope ID.
> 
> At this stage, I don't know if this is a bug from the socketmodule which I 
> doubt or if the AIX `getaddrinfo` simply just doesn't handle scoped IP 
> addresses properly.
> 
> If you're still okay to proxy tests for AIX, I'll try and come up with either 
> a simple C snippet to see what's in the returned structure or ctype the AIX 
> `libc` `getaddrinfo`.
> 
> --
> 
> ___
> Python tracker 
> <https://bugs.python.org/issue35545>
> ___
>

--

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

Re: PEP 594 cgi & cgitb removal

[Michael Torrie]

On 05/24/2019 04:27 AM, Jon Ribbens via Python-list wrote:
> On 2019-05-23, Gunnar Þór Magnússon  wrote:
>>> nginx is the current hotness. CGI has not been hotness since the
>>> mid 90s.
>>
>> Serverless is the new hotness, and serverless is CGI. Technology is
>> cyclical.
> 
> Sorry, in what sense do you mean "Serverless is CGI"?
> 
> As far as I can tell, it's just a script to automatically upload
> bits of code into various cloud providers, none of which use CGI.

Not really.  Serverless just means stateless web-based remote procedure
calls.  This is by definition what CGI is.  Only now you can click a
button and put your cgi script on any cloud provider you want and get
billed by how much cpu and network bandwidth your little cgi script
uses.  So basically the cool kids have reinvented CGI.  And instead of
calling them scripts, they call them functions.

Serverless is an unfortunate name.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

PR 13203 is still waiting for merge

--

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

Re: PEP 594 cgi & cgitb removal

[Michael Torrie]

On 05/24/2019 01:24 PM, Marko Rauhamaa wrote:
> There's a programming language arms race. Python wants to beat Java, C#
> and go in the everything-for-everybody game. Python developers seem to
> take the popularity of the language as proof of success. Pride goes
> before the fall.

I don't see this at all.  Python is useful.  Period.  And it may be
popular too.  I don't actually think the core devs are focused much at
all on winning a popularity contest.  Besides, who cares about C# or
Java.  It's not a zero sum game.  Features are being added that people
who use Python require, or that the core devs think are useful or cool.
Other languages are also evolving similar features.  Async stuff is not
simply to compete with C#.  It's seen as a necessary feature for certain
types of development that are popular (needed?) right now.

The only thing that worries me is that open source and free software
projects in general seem to be in decline as their core developers age
out and generally get tired or change their priorities.  We don't seem
to be attracting replacement talent.  Perhaps the next generations are
less idealistic, or more likely they have less money and thus less time
to donate.  I could maybe fall into that category.  I'm older now than
when I was first exposed to Linux, and I have a lot less time.

Corporate open source software seems to be a growing phenomenon.  While
I welcome companies being open and liberal with their source code and
projects, it does worry me just a bit.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

On 24/05/2019 19:59, Erwan Le Pape wrote:
> python3 -c 'import socket; print(socket.getaddrinfo("fe80::1%1", 80))'`

root@x067:[/home/root]python3 -c 'import socket;
print(socket.getaddrinfo("fe80::1%1", 80))'
[(, , 17, '',
('fe80::1', 80, 0, 0))]

I have not yet checked if the patches mentioned are installed.

This is a system I am testing PyInstaller, and the python3 version is 3.6.8.

OS-Level is: 7100-03-05-1524, but it was built on a different version of
AIX.

+++

This is the system I have the buildbot on:

buildbot@x064:[/home/buildbot/aixtools-master]./python
Python 3.8.0a4+ (heads/bpo-37009-thread-safe-dirty:b489efab81, May 22
2019, 15:13:31)
[GCC 4.7.4] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>>
buildbot@x064:[/home/buildbot/aixtools-master]oslevel -s
7100-04-06-1806
buildbot@x064:[/home/buildbot/aixtools-master]

buildbot@x064:[/home/buildbot/aixtools-master]./python -c 'import
socket; print(socket.getaddrinfo("fe80::1%1", 80))'
[(, , 17, '',
('fe80::1', 80, 0, 0))]

+

re the patches mentioned.

a) not applicable for the systems above - both are AIX 7.1.

b) the AIX 6.1 TL7 I build with says:

root@x066:[/]instfix -i | grep IV52116
    All filesets for IV52116 were found.

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

On 24/05/2019 19:59, Erwan Le Pape wrote:
> python3 -c 'import socket; print(socket.getaddrinfo("fe80::1%1", 80))'`

p.s. I used an actual address:

buildbot@x064:[/home/buildbot/aixtools-master]netstat -ni
Name  Mtu   Network Address    Ipkts Ierrs    Opkts Oerrs  Coll
en0   1500  link#2  0.21.5e.a3.c7.44   191897 0   171570 0 0
en0   1500  192.168.129 192.168.129.64 191897 0   171570 0 0
en0   1500  fe80::221:5eff:fea3:c744   191897 0   171570 0 0
en1   1500  link#3  fa.d1.81.81.ac.5   147474 0    80440 0 0
en1   1500  192.168.2   192.168.2.64   147474 0    80440 0 0
en1   1500  fe80::f8d1:81ff:fe81:ac05%2    147474 0    80440 0 0
lo0   16896 link#1 184523 0   184521 0 0
lo0   16896 127 127.0.0.1  184523 0   184521 0 0
lo0   16896 ::1%1  184523 0   184521 0 0
buildbot@x064:[/home/buildbot/aixtools-master]./python -c 'import
socket; print(socket.getaddrinfo("fe80::f8d1:81ff:fe81:ac05%2", 80))'
[(, , 17, '',
('fe80::f8d1:81ff:fe81:ac05', 80, 0, 0))]

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

In hindsight, maybe the message could have been better,

BUT - is it relevant?

commit 413118ebf3162418639a5c4af14b02d26571a02c
Author: Michael Felt 
Date:   Fri Sep 14 01:35:56 2018 +0200

Fix test_asyncio for AIX - do not call transport.get_extra_info('sockname') 
(#8907)

FYI:
I have a server where "netstat -in" (aka ip a) does show an address with a 
scope component. Not figured out how to query that in C or python yet. (not my 
favorite thing - messing with socket() :p@me)

Re: the example below - I would have thought the scopeid would be showing on 
en1, not en2 - and I am also wondering, if the scopeid is "%1" AIX ignores it. 
(also, I masked my global ipv6 address).
Maybe en0 has a scopeid BECAUSE there is a global address (where en1 does not).

michael@x071:[/home/michael]netstat -ni
Name  Mtu   Network Address   Ipkts IerrsOpkts Oerrs  Coll
en0   1500  link#2  fa.d1.8c.f7.62.4  3103849 0  1085261 0 0
en0   1500  192.168.129 192.168.129.713103849 0  1085261 0 0
en0   1500  192.168.90  192.168.90.71 3103849 0  1085261 0 0
en0   1500  MASK::1:f8d1:8cff:fef7:6204   3103849 0  1085261 0 0
en0   1500  fe80::f8d1:8cff:fef7:6204%2   3103849 0  1085261 0 0
en1   1500  link#3  fa.d1.8c.f7.62.512704 0 9323 0 0
en1   1500  192.168.2   192.168.2.1 12704 0 9323 0 0
en1   1500  fe80::f8d1:8cff:fef7:6205   12704 0 9323 0 0
lo0   16896 link#1   3908 0 3908 0 0
lo0   16896 127 127.0.0.13908 0 3908 0 0
lo0   16896 ::1%13908 0 3908 0 0

So, I looked at another server with two interfaces - here only one has a IPv6 
address

root@x064:[/home/root]netstat -in
Name  Mtu   Network AddressIpkts IerrsOpkts Oerrs  Coll
en0   1500  link#2  0.21.5e.a3.c7.44   119801 084874 0 0
en0   1500  192.168.129 192.168.129.64 119801 084874 0 0
en0   1500  fe80::221:5eff:fea3:c744   119801 084874 0 0
en1   1500  link#3  fa.d1.81.81.ac.589362 048409 0 0
en1   1500  192.168.2   192.168.2.6489362 048409 0 0
lo0   16896 link#1 139882 0   139881 0 0
lo0   16896 127 127.0.0.1  139882 0   139881 0 0
lo0   16896 ::1%1  139882 0   139881 0 0
root@x064:[/home/root]

And, after I activate IPv6 on the second interface - I see a scopeid-like 
representation:

Name  Mtu   Network AddressIpkts IerrsOpkts Oerrs  Coll
en0   1500  link#2  0.21.5e.a3.c7.44   120043 085045 0 0
en0   1500  192.168.129 192.168.129.64 120043 085045 0 0
en0   1500  fe80::221:5eff:fea3:c744   120043 085045 0 0
en1   1500  link#3  fa.d1.81.81.ac.589370 048420 0 0
en1   1500  192.168.2   192.168.2.6489370 048420 0 0
en1   1500  fe80::f8d1:81ff:fe81:ac05%2 89370 048420 0 0
lo0   16896 link#1 139923 0   139922 0 0
lo0   16896 127 127.0.0.1  139923 0   139922 0 0
lo0   16896 ::1%1  139923 0   139922 0 0

I would have to guess at this point, but to simplify, it seems that AIX 
resolves addresses differently (rather than say 'not correctly') and maybe 
requires specific conditions.

If relevant - I can provide the output from Debian on POWER. But it seems AIX 
is only using a "ADDRv6%scopeid" when there at least two interfaces defined.

+
What the bot is not showing is this re: the "mock" connections 'failing':

root@x066:[/data/prj/python/python3-3.8]./python -m test test_asyncio
Run tests sequentially
0:00:00 [1/1] test_asyncio
/data/prj/python/git/python3-3.8/Lib/test/support/__init__.py:1627: 
RuntimeWarning: coroutine 'AsyncMockMixin._mock_call' was never awaited
  gc.collect()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
Future exception was never retrieved
future: 
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/subprocess.py", line 162, 
in _feed_stdin
await self.stdin.drain()
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py", line 443, in 
drain
await self._protocol._drain_helper()
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/streams.py", line 200, in 
_drain_helper
await waiter
  File "/data/prj/python/git/python3-3.8/Lib/asyncio/unix_events.py", line 661, 
in _write_ready
n = os.write(self._fileno, self._buffer)
BrokenPipeError: [Errno 32] Broken pipe
Future exception was never retrieved
future: 
Traceba

[issue37017] Use LOAD_METHOD optimization in CallMethod C API functions

[Michael J. Sullivan]

Michael J. Sullivan  added the comment:

I believe that this is orthogonal to PEP 590.

PyObject_CallMethodObjArgs and friends take varargs which need to be copied 
into an array one way or another. It is easy (and efficient) to prepend the 
base while copying the function arguments into the array (see the attached PR). 
I don't think that vector call will change anything about this.

--

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

[issue37017] Use LOAD_METHOD optimization in CallMethod C API functions

[Michael J. Sullivan]

Change by Michael J. Sullivan :


--
nosy: +brett.cannon, serhiy.storchaka, vstinner, yselivanov

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

[issue37017] Use LOAD_METHOD optimization in CallMethod C API functions

[Michael J. Sullivan]

Change by Michael J. Sullivan :


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

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

[issue37017] Use LOAD_METHOD optimization in CallMethod C API functions

[Michael J. Sullivan]

New submission from Michael J. Sullivan :

The different varieties of PyObject_CallMethod* routines all operate by doing a 
PyObject_GetAttr to fetch an object to call. It seems likely to be worthwhile 
to take advantage of the LOAD_METHOD optimization that avoids creating a bound 
method object when calling a method.

--
components: Extension Modules
messages: 343259
nosy: msullivan
priority: normal
severity: normal
status: open
title: Use LOAD_METHOD optimization in CallMethod C API functions
versions: Python 3.8

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

[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore

[Michael J. Sullivan]

Michael J. Sullivan  added the comment:

I think this is done!

--

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

[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore

[Michael J. Sullivan]

Change by Michael J. Sullivan :


--
pull_requests: +13419

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

[issue36084] Threading: add builtin TID attribute to Thread objects

[Michael Felt]

Michael Felt  added the comment:

On 22/05/2019 18:08, STINNER Victor wrote:
> STINNER Victor  added the comment:
>
> Michael Felt: it's annoying when you ignore Antoine's comment and my comment.
> * https://github.com/python/cpython/pull/13463#issuecomment-494797084
> * https://bugs.python.org/issue36084#msg343159
>
> The AIX case is very special and required a separated issue. Please open a 
> separated if you want to discuss/implement get_native_id() on AIX.

My apologies. I was not ignoring anyone. I am sorry you had that impression.

I had already taken it as a given that it would not be in this PR (re:
https://bugs.python.org/issue36084#msg343159)

And, I had expressed my hope - it would not be too complex in
https://bugs.python.org/issue36084#msg343168. Which also made me realize
that an 'issue' around the "define" described in the "pthread"
documentation (so in hindsight, not applicable to an implementation of
"get_native_id()".

And, while I am sorry you feel I have ignored you - it is hardly the
case. Everyone's comments have given me a reason to look further. And it
grieves me that my intentions are misunderstood.

Thank you for your honesty!

>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36084>
> ___
>

--

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

[issue36084] Threading: add builtin TID attribute to Thread objects

[Michael Felt]

Michael Felt  added the comment:

On 22/05/2019 15:15, Jake Tesler wrote:
> Jake Tesler  added the comment:
>
> I will look into whether adding thread_self() for AIX would be simple enough 
> for this PR.
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue36084>
> ___
>
Blush. Maybe I should have read further (to chapter T)

Here is a bare bones example - showing the pthread_self() is not the
right value, but thread_self is.

michael@x071:[/data/prj/aixtools/tests/posix]cat thread*.c
#include 
#include 
#include 

main()
{
    pid_t pid;
    tid_t tid;
    pthread_t ptid;

    pid = getpid();
    tid = thread_self();
    ptid = pthread_self();

    fprintf(stderr,"thread_self: pid:%d tid:%d ptid:%d\n", pid, tid,
ptid);
    sleep(300); /* give time to run ps -mo THREAD */
}

michael@x071:[/data/prj/aixtools/tests/posix]./thread_self
thread_self: pid:*4129010 *tid:*23724099 *ptid:1

michael@x071:[/data/prj/aixtools/tests/posix]ps -mo THREAD
    USER PID    PPID   TID S  CP PRI SC    WCHAN    F TT
BND COMMAND
 michael 3408006 7012502 - A   3  61  1    -   21 
pts/0  -1 ps -mo THREAD
   -   -   -  22282455 R   3  61  1    -   40 
-  -1 -
 michael *4129010 *7012502 - A   0  60  1 f1000a03e16533b0 
8200011  pts/0  -1 ./thread_self
   -   -   -  *23724099 *S   0  60  1 f1000a03e16533b0  
410400  -  -1 -

--

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

[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore

[Michael Sullivan]

Michael Sullivan  added the comment:

I think there will be one more PR to disallow non-ASCII characters immediately 
after a `# type: ignore`, but otherwise I think this is done

--

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

[issue37009] Threading and THREAD_SAFE for AIX

[Michael Felt]

New submission from Michael Felt :

For years Python includes the file /usr/include/pthread.h. The AIX 
documentation states that this needs to be the first include file included OR 
the define _THREAD_SAFE needs to be defined.

As this may have been true, might still be true, or might have never been true 
- this patch assures that the define is added to BASECFLAGS for AIX - and will 
not be forgotten during builds.

It may be advisable to include this in backports. This "conditional 
requirement" has been accurate for over 20 years.

--
components: Build
messages: 343184
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Threading and THREAD_SAFE for AIX
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

[issue36084] Threading: add builtin TID attribute to Thread objects

[Michael Felt]

Michael Felt  added the comment:

On 22/05/2019 12:22, Michael Felt wrote:
> All the other "assurances" are just things that need to be assured. Adding a 
> -D_XXX to CFLAGS is not all that complex either. Perhaps getting the need for 
> the flag documented is 'complex'.

Now that I think about it, perhaps I should make a separate PR just for
the -D_THREAD_SAFE definition. Python does reference the AIX "threading"
include files and documentation has always indicated they should be
first, or have this define. If it is already there, please excuse the
noise; if not, imho - it should be there.

--

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

[issue36084] Threading: add builtin TID attribute to Thread objects

[Michael Felt]

Michael Felt  added the comment:

I do not know if it is that much mode complex. Unless I missed something it 
seems to be that this bit - needs three lines added after the FREEBSD block - 
per below: 
All the other "assurances" are just things that need to be assured. Adding a 
-D_XXX to CFLAGS is not all that complex either. Perhaps getting the need for 
the flag documented is 'complex'.

#ifdef PY_HAVE_THREAD_NATIVE_ID
unsigned long
PyThread_get_thread_native_id(void)
{
if (!initialized)
PyThread_init_thread();
#ifdef __APPLE__
uint64_t native_id;
(void) pthread_threadid_np(NULL, _id);
#elif defined(__linux__)
pid_t native_id;
native_id = syscall(SYS_gettid);
#elif defined(__FreeBSD__)
int native_id;
native_id = pthread_getthreadid_np();
#elif defined(_AIX)
pthread_t native_id;
native_id = pthread_self()


More may be needed, but I expect it the include file mentioned is already 
included - but perhaps without the assurance that AIX says it wants/needs for 
real thread safe builds. And fixing that is just a bonus!

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

On 22/05/2019 10:43, Michael Felt wrote:
> 'fe80::1%1' <> 'fe80::1' - ... I am not 'experienced' with IPv6 and scope.

>From what I have just read (again) - scope seems to be a way to indicate
the interface used (e.g., eth0, or enp0s25) as a "number".

Further, getsockname() (and getpeername()) seem to be more for after a
fork(), or perhaps after a pthread_create(). What remains unclear is why
would I ever care what the scopeid is.  Is it because it is "shiney",
does it add security (if so, how)?

And, as this has been added - what breaks in Python when "scopeid" is
not available?

I am thinking, if adding a scopeid is a way to assign an IPv6 address to
an interface - what is to prevent abuse? Why would I even want the same
(link-local IP address on eth0 and eth1 at the same time? Assuming that
it what it is making possible - the same IPv6/64 address on multiple
interfaces and use scope ID to be more selective/aware. It this an
alternative way to multiplex interfaces - now in the IP layer rather
than in the LAN layer?

If I understand why this is needed I may be able to come up with a way
to "get it working" for the Python model of interfaces - although,
probably not "fast".

Regards,

Michael

--

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

[issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses

[Michael Felt]

Michael Felt  added the comment:

from below:

In case of 3.7 first call to _ensure_resolved returns
('fe80::1', 12345, 0, 1)
then second call returns
('fe80::1', 12345, 0, 0)
Notice that scope is now completely lost and is set to 0, thus actual call to 
socket.connect is wrong

In case of 3.6 both first and second call to _ensure_resolved return
('fe80::1%lo', 12345, 0, 1)
because in 3.6 case scope info is preserved in address and second call can 
derive correct address tuple

I'll have to locate the PR I made to resolve the test issue AIX was having - 
but it seems the address format ::1%lo is not supported everywhere. FYI: I do 
not believe the PR was backported into 3.6.

** Found it:
commit 413118ebf3162418639a5c4af14b02d26571a02c
Author: Michael Felt 
Date:   Fri Sep 14 01:35:56 2018 +0200

Fix test_asyncio for AIX - do not call transport.get_extra_info('sockname') 
(#8907)

and
[3.7] bpo-34490: Fix test_asyncio for AIX - do not call 
transport.get_extra_info('sockname') (GH-8907) #9286


Since in the first call - a scope of 1 is being returned - the initial "open" 
seems to be working as expected.

Some "help" to be sure I do exactly the same tests.

 Reading through the bpo text, my change was only to skip the test because 
quote: On AIX with AF_UNIX family sockets getsockname() does not provide 
'sockname'

and, from memory, the information being looked for is the bit after the '%' - 
aka scope.

On the one hand - the test is working - the information being returned does not 
match:

==
FAIL: test_create_connection_ipv6_scope 
(test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests)
--
Traceback (most recent call last):
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/mock.py", 
line 1226, in patched
return func(*args, **keywargs)
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_asyncio/test_base_events.py",
 line 1316, in test_create_connection_ipv6_scope
sock.connect.assert_called_with(('fe80::1', 80, 0, 1))
  File 
"/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/unittest/mock.py", 
line 838, in assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: expected call not found.
Expected: connect(('fe80::1', 80, 0, 1))
Actual: connect(('fe80::1', 80, 0, 0))
--

What is not clear from the test is that what "expected" says, is not the same 
as the first address in the code:


coro = self.loop.create_connection(asyncio.Protocol, 'fe80::1%1', 80)
t, p = self.loop.run_until_complete(coro)
try:
sock.connect.assert_called_with(('fe80::1', 80, 0, 1))
_, kwargs = m_socket.socket.call_args
self.assertEqual(kwargs['family'], m_socket.AF_INET6)
self.assertEqual(kwargs['type'], m_socket.SOCK_STREAM)
finally:
t.close()
test_utils.run_briefly(self.loop)  # allow transport to close

'fe80::1%1' <> 'fe80::1' - and maybe, on AIX - the initial connection failed. 
(or maybe it has to have succeeded, or the failure message would look 
different). I am not 'experienced' with IPv6 and scope.

--
nosy: +Michael.Felt

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

[issue36084] Threading: add builtin TID attribute to Thread objects

[Michael Felt]

Michael Felt  added the comment:

Repeating a bot of what I added to PR13463

AIX has native support for thread-id since at least AIX 4.1 (1994-1995) where 
every process has an initial TID (PID are even numbers and "own" the resources, 
TID are odd and are the "workers" - very simply put). Hence, by default, an AIX 
process is "mono-threaded".

The key concern - when calling thread related issues, is to ensure that all 
compiled code uses the same definitions in include files - namely, with 
_THREAD_SAFE defined.

There are couple of ways to accomplish this:
a) ensure that #include  is first (everywhere!)
b) use cc_r, xlc_r, etc_r (with IBM compiler)
c) -D_THREAD_SAFE

As a) seems unpractical to ensure all the time; b) is also unpractical (no idea 
how/if gcc, e.g., has a way to 'signal' the need to be thread_safe - so a 
change in configure.ac, and maybe in setup.py, and thinking further yet - in 
the CFLAGS that get passed to extrnal modules and extensions - adding 
-D_THREAD_SAFE seems the most complete (aka safe) approach.

And, of course, for this specific function a call to

Syntax
#include 
pthread_t pthread_self (void);

Description
The pthread_self subroutine returns the calling thread's ID.

--
nosy: +Michael.Felt

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

[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore

[Michael Sullivan]

Change by Michael Sullivan :


--
pull_requests: +13391

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

[issue36816] self-signed.pythontest.net TLS certificate key is too weak

[Michael Felt]

Michael Felt  added the comment:

On 21/05/2019 12:08, Michael Felt wrote:
> Michael Felt  added the comment:
>
> p.s. On Centos I could not even get a python3 (at least not easily).
>
> On debian (on POWER) I get the same error (message) as on AIX - although the 
> line number did change.
>
> ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
> verify failed: self signed certificate (_ssl.c:1056)
>
> so, not a message about "key too small error" - pure, this is self-signed, so 
> error.
>
> --
p.s. blush: seems I was testing against the wrong fork - seems to be
cleared in 'master'. My apologies for the noise.
> ___
> Python tracker 
> <https://bugs.python.org/issue36816>
> ___
>

--

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

[issue36990] test_asyncio.test_create_connection_ipv6_scope fails(in mock test?)

[Michael Felt]

New submission from Michael Felt :

==
test_create_connection_ipv6_scope 
(test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests)
--
Traceback (most recent call last):
  File "/home/buildbot/python-master/Lib/unittest/mock.py", line 1226, in 
patched
return func(*args, **keywargs)
  File 
"/home/buildbot/python-master/Lib/test/test_asyncio/test_base_events.py", line 
1316, in test_create_connection_ipv6_scope
sock.connect.assert_called_with(('fe80::1', 80, 0, 1))
  File "/home/buildbot/python-master/Lib/unittest/mock.py", line 838, in 
assert_called_with
raise AssertionError(_error_message()) from cause
AssertionError: expected call not found.
Expected: connect(('fe80::1', 80, 0, 1))
Actual: connect(('fe80::1', 80, 0, 0))


More details:
buildbot@x064:[/home/buildbot/python-master]nohup ./python -m test -v 
test_asyncio | egrep -v "ok$" | grep -v " ... skipped "
== CPython 3.8.0a4+ (heads/master:4fb1502189, May 21 2019, 11:08:13) [GCC 4.7.4]
== AIX-1-00C291F54C00-powerpc-32bit big-endian
== cwd: /home/buildbot/python-master/build/test_python_17694732
== CPU count: 4
== encodings: locale=ISO8859-1, FS=iso8859-1
Run tests sequentially
0:00:00 [1/1] test_asyncio
test_create_connection_ipv6_scope 
(test.test_asyncio.test_base_events.BaseEventLoopWithSelectorTests) ... FAIL
test_communicate_ignore_broken_pipe 
(test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... 
/home/buildbot/python-master/Lib/inspect.py:2819: RuntimeWarning: coroutine 
'AsyncMockMixin._mock_call' was never awaited
  params = OrderedDict(((param.name, param)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
Future exception was never retrieved
future: 
Traceback (most recent call last):
  File "/home/buildbot/python-master/Lib/asyncio/subprocess.py", line 162, in 
_feed_stdin
await self.stdin.drain()
  File "/home/buildbot/python-master/Lib/asyncio/streams.py", line 443, in drain
await self._protocol._drain_helper()
  File "/home/buildbot/python-master/Lib/asyncio/streams.py", line 200, in 
_drain_helper
await waiter
  File "/home/buildbot/python-master/Lib/asyncio/unix_events.py", line 661, in 
_write_ready
n = os.write(self._fileno, self._buffer)
BrokenPipeError: [Errno 32] Broken pipe
test_communicate_ignore_broken_pipe 
(test.test_asyncio.test_subprocess.SubprocessSafeWatcherTests) ... Future 
exception was never retrieved
future: 
Traceback (most recent call last):
  File "/home/buildbot/python-master/Lib/asyncio/subprocess.py", line 162, in 
_feed_stdin
await self.stdin.drain()
  File "/home/buildbot/python-master/Lib/asyncio/streams.py", line 443, in drain
await self._protocol._drain_helper()
  File "/home/buildbot/python-master/Lib/asyncio/streams.py", line 200, in 
_drain_helper
await waiter
  File "/home/buildbot/python-master/Lib/asyncio/unix_events.py", line 661, in 
_write_ready
n = os.write(self._fileno, self._buffer)
BrokenPipeError: [Errno 32] Broken pipe
test_cancel_at_end (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
test_cancel_gather_1 (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
test_cancel_at_end (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
test_cancel_gather_1 (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
test_cancel_at_end (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
test_cancel_gather_1 (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.CTask_CFuture_Tests)
test_cancel_at_end (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
test_cancel_gather_1 (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
test_cancel_at_end (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
test_cancel_gather_1 (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
test_cancel_at_end (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
test_cancel_gather_1 (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
test_cancel_at_end (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
test_cancel_gather_1 
(test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
test_return_coroutine_from_coroutine 
(test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
test_cancel_at

[issue36989] test_thread fails because symbol is (no longer) exported

[Michael Felt]

New submission from Michael Felt :

On AIX, with commit 4fb15021890d327023aefd95f5a84ac33b037d19 (HEAD -> master, 
origin/master, origin/HEAD)

test_thread is failing.

The three sub_tests that exit as ERROR are:
ERROR: test_threads_join_2 (test.test_threading.SubinterpThreadingTests)
ERROR: test_frame_tstate_tracing (test.test_threading.ThreadTests)

These two have in common:
Traceback (most recent call last):
...
ImportError:0509-130 Symbol resolution failed for 
/home/buildbot/python-master/build/lib.aix-7.1-3.8-pydebug/_testcapi.so because:
0509-136   Symbol _PyMem_GetAllocatorsName (number 191) is not exported 
from
   dependent module python.
0509-192 Examine .loader section symbols with the
 'dump -Tv' command.

FAIL: test_daemon_threads_fatal_error 
(test.test_threading.SubinterpThreadingTests)

I am guessing that:

==
FAIL: test_daemon_threads_fatal_error 
(test.test_threading.SubinterpThreadingTests)
--
Traceback (most recent call last):
  File "/home/buildbot/python-master/Lib/test/test_threading.py", line 942, in 
test_daemon_threads_fatal_error
self.assertIn("Fatal Python error: Py_EndInterpreter: "
AssertionError: 'Fatal Python error: Py_EndInterpreter: not the last thread' 
not found in 'Traceback (most recent call last):\n  File "", line 2, in 
\nImportError: \t0509-130 Symbol resolution failed for 
/home/buildbot/python-master/build/lib.aix-7.1-3.8-pydebug/_testcapi.so 
because:\n\t0509-136   Symbol _PyMem_GetAllocatorsName (number 191) is not 
exported from\n\t\t   dependent module python.\n\t0509-192 Examine .loader 
section symbols with the\n\t\t \'dump -Tv\' command.'

--
is caused by the earlier failures.

--
components: Build, Tests
messages: 343016
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_thread fails because symbol is (no longer) exported
versions: Python 3.8

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

[issue36273] test_thread leaks a core dump on PPC64 AIX 3.x

[Michael Felt]

Michael Felt  added the comment:

Again - how can I get the core (dump) mentioned in the error message. When I 
force this situation I have several core dumps - not "the one".

--

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

[issue36752] test multiprocessing: test_rapid_restart() crash on AIX

[Michael Felt]

Michael Felt  added the comment:

I believe (or hope) this is related to issue35828.

This is, as far as I can tell, a compiler issue.

It appears "always" in the bot situation (not building as root) when using 
xlc-v11, but not when using gcc-4.7.4.

So, when the test failure "disappears" on the bot - it is because I have 
switched CC=clr_r to CC=gcc

I am quite willing to continue searching (I just removed over three GBytes of 
core dumps I had collected previously).

As to analysis: it appears the "server" side core-dumps, and the the 
client-side is refused a connection (obviously).

--
nosy: +Michael.Felt

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

[issue36816] self-signed.pythontest.net TLS certificate key is too weak

[Michael Felt]

Michael Felt  added the comment:

p.s. On Centos I could not even get a python3 (at least not easily).

On debian (on POWER) I get the same error (message) as on AIX - although the 
line number did change.

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed: self signed certificate (_ssl.c:1056)

so, not a message about "key too small error" - pure, this is self-signed, so 
error.

--

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

[issue36816] self-signed.pythontest.net TLS certificate key is too weak

[Michael Felt]

Michael Felt  added the comment:

I am not an OpenSSL expert - and I am conscious of OpenSSL changes with regard 
to 'acceptance' of anything self-signed.

And, what it looks like you are trying to do with an updated 'signing" .pem is 
to remove the 'self-signed' charasteric.

On AIX - atm - I get, as did Chih-Hsuan Yen (yan12125),

==
ERROR: test_networked_good_cert (test.test_httplib.HTTPSTest)
--
Traceback (most recent call last):
  File "/home/buildbot/python-master/Lib/test/test_httplib.py", line 1632, in 
test_networked_good_cert
h.request('GET', '/')
  File "/home/buildbot/python-master/Lib/http/client.py", line 1221, in request
self._send_request(method, url, body, headers, encode_chunked)
  File "/home/buildbot/python-master/Lib/http/client.py", line 1267, in 
_send_request
self.endheaders(body, encode_chunked=encode_chunked)
  File "/home/buildbot/python-master/Lib/http/client.py", line 1216, in 
endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
  File "/home/buildbot/python-master/Lib/http/client.py", line 1004, in 
_send_output
self.send(msg)
  File "/home/buildbot/python-master/Lib/http/client.py", line 944, in send
self.connect()
  File "/home/buildbot/python-master/Lib/http/client.py", line 1383, in connect
self.sock = self._context.wrap_socket(self.sock,
  File "/home/buildbot/python-master/Lib/ssl.py", line 405, in wrap_socket
return self.sslsocket_class._create(
  File "/home/buildbot/python-master/Lib/ssl.py", line 853, in _create
self.do_handshake()
  File "/home/buildbot/python-master/Lib/ssl.py", line 1117, in do_handshake
self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate 
verify failed: self signed certificate (_ssl.c:1055)

And I see why now:
test_networked_good_cert (test.test_httplib.HTTPSTest) ... skipped "Use of the 
'network' resource not enabled"

Digging a bit:

buildbot@x064:[/home/buildbot/python-master]openssl s_client -connect 
self-signed.pythontest.net:443
CONNECTED(0003)
depth=0 C = XY, ST = Castle Anthrax, L = Argument Clinic, O = Python Software 
Foundation, CN = self-signed.pythontest.net
verify error:num=18:self signed certificate
verify return:1
depth=0 C = XY, ST = Castle Anthrax, L = Argument Clinic, O = Python Software 
Foundation, CN = self-signed.pythontest.net
verify return:1
---
Certificate chain
 0 s:/C=XY/ST=Castle Anthrax/L=Argument Clinic/O=Python Software 
Foundation/CN=self-signed.pythontest.net

   i:/C=XY/ST=Castle Anthrax/L=Argument Clinic/O=Python Software 
Foundation/CN=self-signed.pythontest.net

And while this:
How to know if it has been fixed?  Monitor the test_networked_good_cert test on 
any "Debian buster" builtbot(s) such as 
https://buildbot.python.org/all/#/workers/23 to make sure it is not skipped.  
(the test _currently_ fails, I am going to have it be _skipped_ on this 
specific key too small error for the time being to get that stable buildbot 
green again)

is nice for some, it is not nice for all!

Perhaps the test should be switched to 'warn' on failure, rather than error on 
failure, until fixed!

--
nosy: +Michael.Felt

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

Re: Why Python has no equivalent of JDBC of Java?

[Michael Torrie]

On 05/20/2019 04:23 PM, Andrew Z wrote:
> What does 249 specification mention about drivers?

Nothing that I can see.

But it stands to reason that at some point the Python code is going to
have to interface with the SQL database server's API. And when the
database in question is proprietary, the original poster should probably
not be surprised that a special driver install is required. I assume
it's also required for JDBC also, but since Java is owned by Oracle,
they probably install such things automatically.

> 
> On Mon, May 20, 2019, 17:39 Marco Sulla via Python-list <
> python-list@python.org> wrote:
> 
>> On Mon, 20 May 2019 at 17:32, Thomas Jollans  wrote:
>>
>>> Python has a the "Python Database API" (DB API 2.0)
>>> https://www.python.org/dev/peps/pep-0249/
>>>
>>
>> So why Oracle need instantclient for using cx_Oracle? They say they use
>> DB-API:
>>
>>> *cx_Oracle* is a Python extension module that enables access to Oracle
>>> Database. It conforms to the Python database API 2.0 specification
>>  with
>>> a considerable number of additions and a couple of exclusions.
>>
>> https://oracle.github.io/python-cx_Oracle/
>>
>>
>> On Sun, 19 May 2019 at 23:47, Chris Angelico  wrote:
>>
>>> I've no idea what the hassles are with Oracle, as it's a database
>>> engine that I don't use. But with PostgreSQL, which I *do* use, I can
>>> assure you that it's much easier
>>>
>>
>> I use Postgres if I can choose, but companies uses Oracle unluckily. Oracle
>> and MSSQL. And I must say that surprisingly, being a Microsoft product, I
>> find MSSQL more simple to install than Oracle, like Postregres, and has an
>> easier SQL syntax.  Like Postgres.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

PR 13203 is still waiting for merge

--

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

Re: Error Opening Python for Windows Download

[Michael Torrie]

On 05/12/2019 04:42 PM, Alexandra Mistak wrote:
> Hi Python,
> 
> I have unsuccessfully downloaded Python Windows x86-64 executable installer
>  multiple
> times.
> 
> After installation, when I go to launch the program it tells me to "repair
> or modify" the app. I click "repair," I try opening it again, and it
> continues on in a vicious cycle. :(((

How are you running Python? Are you sure you're not running the
installer again?

Remember that Python is a command-line interpreter, and as such it
should be invoked from a command prompt, which will drop you into the
read-eval-print-loop interface (control-Z or Control-D to exit depending
on operating system).  Alternatively .py files can be associated with
the python launcher to let them run with a double click from the Windows
explorer. But Python itself really doesn't have much of a user
interface. Normally you create programs in a text editor that are then
run with the python interpreter. If you are looking for some sort of
IDE, you might look into IDLE, which may have installed with Python.
IDLE is an editor that also lets you run and debug python programs with
within it.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32509] doctest syntax ambiguity between continuation line and ellipsis

[Michael Blahay]

Michael Blahay  added the comment:

At the end of msg309603 it was stated that this issue is being changed to an 
enhancement. Later on, Tim Peters changed it Type back to behavior, but didn't 
provide any detail about why. Should this issue still be considered an 
enhancement?

--
nosy: +mblahay

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Ryan, What say you? Will you be satisfied with the addition of a note in the 
documentation?

--

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

[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore

[Michael Sullivan]

Change by Michael Sullivan :


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

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

PR 13203 has finally made it through all checks successfully and is now 
awaiting merging. Please someone pick it up and merge it. Thank you

--

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

[issue36878] ast.parse with type_comments=True should allow extra text after # type: ignore

[Michael Sullivan]

New submission from Michael Sullivan :

Per discussion during the typing summit at PyCon, it would be a good idea to 
allow extra information to be included in `# type: ignore` comments, in order 
to allow behavior such as suppressing individual errors (for example, with 
syntax like `# type: ignore[E1000]`, to suppress error 1000).

My proposal, then, is to generalize the definition of type: ignore comments to 
be `# type: ignore followed by a non-alphanumeric character. Then `# type: 
ignore[E1000]` and `# type: ignore E1000` would be valid type ignore comments 
while `# type: ignoreE1000` would not be.

Now that ast.parse can parse type_comments, this needs to make it into 3.8, 
basically, if we want to do this and be able to use the ast type_comment 
feature.

Ideally, the text of the type ignore would be actually included in the produced 
AST. As a bare minimum first step, we need to recognize type ignores with extra 
information and report them (and, critically, not detect them as regular type 
comments and produce errors when they appear in unexpected places).

I'll put up a PR to do the second part shortly.

--
components: Interpreter Core
messages: 342130
nosy: gvanrossum, levkivskyi, msullivan
priority: normal
severity: normal
status: open
title: ast.parse with type_comments=True should allow extra text after # type: 
ignore
type: enhancement
versions: Python 3.8

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Much detail has been provided regarding why the default is ignored when user 
the REMAINDER option. The desire to add an exception has not. Is there anyone 
that can provide guidance on whether the combination of:
1. Positional Argument 
2. nargs=REMAINDER
3. default=something  
should raise an exception upon execution of the add_argument method?

--

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

With the optional arguments, the determination about whether to use the default 
value is made based on whether the flag is present or not. When positional 
arguments are involved, the need for the defaults seems to in part be 
determined based on whether the argument exists. The fact that * and REMAINDER 
are zero-to-many in nature add some ambiguity into the situation. For the *, it 
seems that the positional argument only exists if there is at least one actual 
argument value that it can consume.

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
#parser.add_argument('bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.add_argument('baz', nargs='*', default=['nada'])
parser.parse_args('a b'.split())

Out[25]: Namespace(baz=['b'], foo=['a'])

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
#parser.add_argument('bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.add_argument('baz', nargs='*', default=['nada'])
parser.parse_args('a'.split())

Out[26]: Namespace(baz=['nada'], foo=['a'])

Mean while, the REMAINDER option makes the argument act as if it exists 
regardless of whether an actual argument value exists.

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
parser.add_argument('bar', nargs=argparse.REMAINDER,default=['nothing'])
#parser.add_argument('baz', nargs='*', default=['nada'])
parser.parse_args('a b'.split())

Out[27]: Namespace(bar=['b'], foo=['a'])

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
parser.add_argument('bar', nargs=argparse.REMAINDER,default=['nothing'])
#parser.add_argument('baz', nargs='*', default=['nada'])
parser.parse_args('a'.split())

Out[28]: Namespace(bar=[], foo=['a'])

To conclude, * and REMAINDER perform similar, but different, roles when used 
with positional arguments. With edge cases like the ones laid out above, it can 
be hard to conceptualize what the exact behavior should be. I will recommend 
that the documentation be updated to convey the following message: "When used 
with positional arguments, REMAINDER will never use the designated default 
value list. It will instead return an empty list if there are no values for the 
argument to consume. If the use of default values is desired, then * must be 
used."

--

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Here is another take on the issue, this time illustrated through the lens of 
optional arguments.

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs=1,default=['none'])
parser.add_argument('--baz', nargs='*', default=['nada'])
parser.add_argument('--bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.parse_args('--foo a --bar b --baz c'.split())

Out[9]: Namespace(bar=['b', '--baz', 'c'], baz=['nada'], foo=['a'])

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs=1,default=['none'])
parser.add_argument('--baz', nargs='*', default=['nada'])
parser.add_argument('--bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.parse_args('--foo a --baz b --bar c'.split())

Out[10]: Namespace(bar=['c'], baz=['b'], foo=['a'])

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs=1,default=['none'])
parser.add_argument('--baz', nargs='*', default=['nada'])
parser.add_argument('--bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.parse_args([])

Out[11]: Namespace(bar=['nothing'], baz=['nada'], foo=['none'])

It is important to note that when an optional argument is not present then the 
default is always used, including for one using nargs=argparse.REMAINDER. In 
all three tests, bar is the argument using REMAIDER. In the first test, one can 
see that when bar isn't the last argument then anything else, including other 
arguments, are swept up as being arguments of bar. This greedy behavior for 
REMAINDER is something that * does not share (test 2).

--

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

For the purpose of facilitating continuing conversation, here are two tests 
that contrast the use of * versus REMAINDER

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
parser.add_argument('bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.add_argument('baz', nargs='*', default=['nada'])
parser.parse_args('a b c'.split())

Out[7]: Namespace(bar=['b', 'c'], baz=['nada'], foo=['a'])

import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
parser.add_argument('baz', nargs='*', default=['nada'])
parser.add_argument('bar', nargs=argparse.REMAINDER,default=['nothing'])
parser.parse_args('a b c'.split())

Out[8]: Namespace(bar=[], baz=['b', 'c'], foo=['a'])

You can see that * and REMAINDER do differ in functionality when they are the 
last defined argument.

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

For those that are wondering what is going on with PR 13181 and PR 13203, those 
are both for back porting the change to 3.7. The auto generated PR 13181 failed 
for an unknown reason and then the bot deleted the branch so the PR could not 
be taken any further. PR 13203 is a manual attempt at the backport which is 
moving along much for successfully.

--

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Ryan, I have reviewed the documentation at 
https://docs.python.org/3/library/argparse.html#nargs and must admit that there 
is not a definitive answer that I can see regarding the defined behavior should 
there be no command line arguments that are in fact remaining. One could 
certainly argue that the empty list is the expression of the fact that no 
remaining arguments could be found. One can also argue that when seeking the 
remaining arguments, a list that may be zero to many elements in size, that by 
definition there cannot be a default.

Can you cite any documentation that would support your claim?

--

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Okay, so the expected output after running parse.parse_args([]) is 
Namespace(['nothing'])

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

PR 13150, the recreation of PR 4981, was noticed just after I created PR 13169. 
It was decided to continue forward with PR 13169 since PR 13150 contained 
changes that were out of scope for BPO-27639 for which it was suspected might 
have been the cause of the non-merging of PR 4981. Thank for identifying 
Dmitry; I did my best to give credit where credit was due.

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Change by Michael Blahay :


--
pull_requests: +13114

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

[issue36849] Native libcurses on HP-UX not properly detected

[Michael Osipov]

Change by Michael Osipov <1983-01...@gmx.net>:


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

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

[issue36849] Native libcurses on HP-UX not properly detected

[Michael Osipov]

New submission from Michael Osipov <1983-01...@gmx.net>:

The module _curses fails to build because curses cannot be found on HP-UX. In 
this case, it has an unorthodox location:

> $ ll /usr/lib/hpux32/libcurses.so
lr-xr-xr-x 1 bin bin 17 2018-09-07 15:29 /usr/lib/hpux32/libcurses.so -> 
./libxcurses.so.1*

A PR is in preparation

--
components: Build
messages: 341856
nosy: michael-o
priority: normal
severity: normal
status: open
title: Native libcurses on HP-UX not properly detected
type: compile error
versions: Python 3.8

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

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

[Michael Blahay]

Michael Blahay  added the comment:

Ryan, what are the exact steps to reproduce the problem? This is what I get 
when I run the code you included:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('things', nargs=argparse.REMAINDER, default=['nothing'])
_StoreAction(option_strings=[], dest='things', nargs='...', const=None, 
default=['nothing'], type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args([])
Namespace(things=[])
>>> Namespace(things=[])
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'Namespace' is not defined

--
nosy: +mblahay

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

Let it be known that the author of PR 4981 is known as vaultah. He/she 
personally closed the pull request this morning stating a lack of need to be 
recognized for the work. Per his/her instructions I am reviewing the changes 
and incorporating in our solution as needed. Thank you vaultah!

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

Please note that I am working with Erick Cervantes at PyCon2019 on this issue.

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

Thank you for bringing up that PR. My team will review and try to find out why 
it was closed without a merge.

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

Results from a quick unit test on the proposed changes were positive:

>>> from collections import UserList
>>> UserList([0,1,2,3,4,5])[0:2].__class__


If you compare this result with the one a couple comments above, you can see 
that the result is no longer a list, but rather of type UserList.

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

It is also worth noting that the definition of UserList moved from 
Lib/UserList.py in 2.7 to Lib/collections/__init__.py in 3.x

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

The root cause of this issue seems to be the failure to implement type usage in 
__getitem__ when the deprecated __getslice__ was removed. This is why slicing 
worked correctly in 2.7, but not the 3.x versions.

In 3.8, the __getitem__ method is used to create the slice, but here we can see 
that all it does is pass the task to data, which is of type list and then fails 
to convert the result to the correct type.

  def __getitem__(self, i): return self.data[i]

Using other methods as examples, the fix should look like this:

  def __getitem__(self, i): return self.__class__(self.data[i])

--

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

[issue27639] UserList.__getitem__ doesn't account for slices

[Michael Blahay]

Michael Blahay  added the comment:

Here is a test that more explicitly shows the problem. 

>>> from collections import UserList
>>> UserList([0,1,2,3,4,5])[0:2].__class__

>>> 

It can clearly be seen here that the return type of the slicing operator is 
list when it should, in this case, be UserList (or whatever class one is using 
that is derived from UserList).

--
nosy: +mblahay

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

[issue11698] Improve repr for structseq objects to show named, but unindexed fields

[MICHAEL BLAHAY]

MICHAEL BLAHAY  added the comment:

I have been advised to avoid enhancements like this one, so I am setting this 
back down. Also, this should be relabeled as easy(c).

--

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

[issue36582] collections.UserString encode method returns a string

[MICHAEL BLAHAY]

MICHAEL BLAHAY  added the comment:

My mistake, dfortunov is already working on this one.

--

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

[issue36582] collections.UserString encode method returns a string

[MICHAEL BLAHAY]

MICHAEL BLAHAY  added the comment:

I will pick this on up

--
nosy: +MICHAEL BLAHAY

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

[issue11698] Improve repr for structseq objects to show named, but unindexed fields

[MICHAEL BLAHAY]

MICHAEL BLAHAY  added the comment:

I will work on this

--
nosy: +MICHAEL BLAHAY

___
Python tracker 
<https://bugs.python.org/issue11698>
___
___
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

[MICHAEL BLAHAY]

MICHAEL BLAHAY  added the comment:

Ah ha, so there is. I'm glad this one will get closed out. Sorry for noob 
mistake.

--

___
Python tracker 
<https://bugs.python.org/issue27497>
___
___
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

[MICHAEL BLAHAY]

MICHAEL BLAHAY  added the comment:

I would like to drive this to conclusion since it appears this issue has not 
had any real activity in a while. First thing that needs to be determined is 
whether this enhancement is still desirable. Who can answer this?

--
nosy: +MICHAEL BLAHAY

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