Re: [Python-Dev] AIX to stable, what does that take?
Hi Michael,
being on a similar road with Gentoo Prefix, I really do appreciate
your AIX related work!
However, for two (not so minor) topics I've got a little different
experience, which I think should be mentioned here for completion:
On 10/04/2018 11:13 AM, Michael Felt wrote:
> On 10/4/2018 10:30 AM, INADA Naoki wrote:
>> Hello,
>>
>> First of all, congratulations on passing all test on AIX.
>> As a one of core developer, I don't know anything about AIX.
>> If my change breaks AIX build, I can't investigate what's happened.
>>
>> So I think we need following in devguide:
>>
>> * Brief description about AIX, from developer's point of view.
> This I might be able to do. Bullet form:
> ... I build everything myself, using xlc
> (gcc introduces the need for a GNU RTE, e.g., glibc).
Using gcc does *not* require to use glibc or even GNU binutils at all.
Except for gcc's own runtime libraries, there's no need for a GNU RTE.
In fact, in Gentoo Prefix I do use gcc as the compiler, configured to
use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE.
> * finally, a bit deeper: while the AIX linker loader supports svr4
> shared libraries (it is the data, not the file name) it also supports
> having multiple shared libraries in a classic archive. So, rather that
> .../lib/libxxx.so and .../lib64/libxxx.so AIX prefers .../lib/libxxx.a
> with two so-called members, with same or different names. The one found
> is not it's name, but the symbol name and size of the ABI (32-bit or 64-bit)
While this all is true, having multiple *versions* of one shared library in
one single file is a PITA for package managers - both human or software.
But fortunately, the AIX linker does support so called "Import Files",
allowing for *filename based* shared library versioning like on Linux,
while still allowing for both ABIs in a single library archive file.
For example, libtool provides the --with-aix-soname={aix|svr4|both}
configure flag since libtool-2.4.4. Although the default will stay
at 'aix' here, in Gentoo Prefix I do use 'svr4' only. This actually
is a package manager's decision, ideally for all depending packages.
As gcc does use libtool, for more information please refer to
https://gcc.gnu.org/install/configure.html#WithAixSoname
But note that "Import Files" should work with xlc as well.
Thanks!
/haubi/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2018-09-28 - 2018-10-05) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open6813 (+32) closed 39845 (+42) total 46658 (+74) Open issues with patches: 2722 Issues opened (53) == #18291: codecs.open interprets FS, RS, GS as line ends https://bugs.python.org/issue18291 reopened by serhiy.storchaka #31310: semaphore tracker isn't protected against crashes https://bugs.python.org/issue31310 reopened by serhiy.storchaka #32117: Tuple unpacking in return and yield statements https://bugs.python.org/issue32117 reopened by serhiy.storchaka #34811: test_gdb fails with latest gdb https://bugs.python.org/issue34811 reopened by vstinner #34834: test_ssl.test_options does not correctly account for built-in https://bugs.python.org/issue34834 opened by xnox #34836: test_ssl.test_default_ecdh_curve needs no tls1.3 flag in 2.7, https://bugs.python.org/issue34836 opened by xnox #34837: Multiprocessing.pool API Extension - Pass Data to Workers w/o https://bugs.python.org/issue34837 opened by seanharr11 #34838: Improve arg clinic code generation for cases with type checkin https://bugs.python.org/issue34838 opened by rhettinger #34839: doctest: Change example under warnings section https://bugs.python.org/issue34839 opened by cheryl.sabella #34840: dlopen() error with no error message from dlerror() https://bugs.python.org/issue34840 opened by shuoz #34841: Scriptâs directory not in sys.path with embeddable Windows d https://bugs.python.org/issue34841 opened by ssapin #34844: logging.Formatter enhancement - Checking on style and fmt fiel https://bugs.python.org/issue34844 opened by BNMetrics #34846: Runtime failure with Failed to import site module https://bugs.python.org/issue34846 opened by sat@gmail.com #34847: asyncio: Add PHA for TLS 1.3 https://bugs.python.org/issue34847 opened by fantix #34848: range.index only takes one argument when it's documented as ta https://bugs.python.org/issue34848 opened by bup #34849: Drop logging when asyncio waits in selector.select() https://bugs.python.org/issue34849 opened by asvetlov #34850: Emit a syntax warning for "is" with a literal https://bugs.python.org/issue34850 opened by serhiy.storchaka #34852: Counter-intuitive behavior of Server.close() / wait_closed() https://bugs.python.org/issue34852 opened by aymeric.augustin #34855: batch file variables https://bugs.python.org/issue34855 opened by lindblad #34856: Make the repr of lambda containing the signature and body expr https://bugs.python.org/issue34856 opened by serhiy.storchaka #34857: IDLE: SyntaxWarning not handled properly https://bugs.python.org/issue34857 opened by terry.reedy #34858: MappingProxy objects should JSON serialize just like a diction https://bugs.python.org/issue34858 opened by Michael Smith2 #34861: Improve cProfile standard output https://bugs.python.org/issue34861 opened by Anders.Hovmöller #34864: In Idle, Mac tabs make editor status line disappear. https://bugs.python.org/issue34864 opened by andyharrington #34866: CGI DOS vulnerability via long post list https://bugs.python.org/issue34866 opened by Matthew Belisle #34867: Add mode to disable small integer and interned string caches https://bugs.python.org/issue34867 opened by steven.daprano #34870: Core dump when Python VSCode debugger is attached https://bugs.python.org/issue34870 opened by Per Lundberg #34872: investigate task/future cancellation in asynciomodule.c https://bugs.python.org/issue34872 opened by yselivanov #34876: Python3.8 changes how decorators are traced https://bugs.python.org/issue34876 opened by nedbat #34877: Inconsistent Behavior Of futures.ProcessPoolExecutor https://bugs.python.org/issue34877 opened by TensorTom #34880: About the "assert" bytecode https://bugs.python.org/issue34880 opened by vtheno athena #34881: unnecessary encoded-words usage breaks DKIM signatures https://bugs.python.org/issue34881 opened by bryced #34882: f(a=1, *args) should be a SyntaxError https://bugs.python.org/issue34882 opened by metaxm #34883: test_lzma: Multiple test failures when liblzma is built withou https://bugs.python.org/issue34883 opened by mgorny #34884: Python loads incorrect libraries https://bugs.python.org/issue34884 opened by Tim Hutt #34885: asyncio documention has lost its paragraph about cancellation https://bugs.python.org/issue34885 opened by abki #34886: subprocess.run throws exception when input and stdin are passe https://bugs.python.org/issue34886 opened by aecant #34888: Python3.8 optimizes away a "while" line https://bugs.python.org/issue34888 opened by nedbat #34890: Support functools.partial in inspect.is*function() checks https://bugs.python.org/issue34890 opened by asvetlov #34891: Multi-processing example inaccurate warning https://bugs.python.org/issue34
Re: [Python-Dev] AIX to stable, what does that take?
On 10/5/18, 10:33 AM, "Python-Dev on behalf of Michael Haubenwallner" wrote: > >... I build everything myself, using xlc >(gcc introduces the need for a GNU RTE, e.g., glibc). Using gcc does *not* require to use glibc or even GNU binutils at all. Except for gcc's own runtime libraries, there's no need for a GNU RTE. In fact, in Gentoo Prefix I do use gcc as the compiler, configured to use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE. I think the author was referring to the dependency on libgcc_s when using gcc. It's typical for native UNIX package builders to use gcc only when necessary because the correct runtime is always installed (if the os running it is newer) and therefore won't clash when something else in the process space is using a different version of libgcc_s (I'm not sure what the ABI guarantees are with libgcc_s specifically, and neither are UNIX packagers - not necessarily anyway) It also eliminates the need to ship a version of libgcc_s as a shared library. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AIX to stable, what does that take?
On 05/10/2018 16:15, Michael Haubenwallner wrote:
> Hi Michael,
>
> being on a similar road with Gentoo Prefix, I really do appreciate
> your AIX related work!
>
> However, for two (not so minor) topics I've got a little different
> experience, which I think should be mentioned here for completion:
Always.
>
> On 10/04/2018 11:13 AM, Michael Felt wrote:
>> On 10/4/2018 10:30 AM, INADA Naoki wrote:
>>> Hello,
>>>
>>> First of all, congratulations on passing all test on AIX.
>>> As a one of core developer, I don't know anything about AIX.
>>> If my change breaks AIX build, I can't investigate what's happened.
>>>
>>> So I think we need following in devguide:
>>>
>>> * Brief description about AIX, from developer's point of view.
>> This I might be able to do. Bullet form:
>> ... I build everything myself, using xlc
>> (gcc introduces the need for a GNU RTE, e.g., glibc).
> Using gcc does *not* require to use glibc or even GNU binutils at all.
> Except for gcc's own runtime libraries, there's no need for a GNU RTE.
> In fact, in Gentoo Prefix I do use gcc as the compiler, configured to
> use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE.
Well, this is something I learned - second hand - from someone who
worked hard to make much more OSS available than I. Probably wrong then
- in how I came to my conclusion - but the few things I tried to compile
"asis" to shared libraries would not work without also a lot of the gcc
compiler libraries. While I could have bitten the bullet and just found
a way to add those I was warned that different versions of gcc need
different level of supporting files.
>> * finally, a bit deeper: while the AIX linker loader supports svr4
>> shared libraries (it is the data, not the file name) it also supports
>> having multiple shared libraries in a classic archive. So, rather that
>> .../lib/libxxx.so and .../lib64/libxxx.so AIX prefers .../lib/libxxx.a
>> with two so-called members, with same or different names. The one found
>> is not it's name, but the symbol name and size of the ABI (32-bit or 64-bit)
> While this all is true, having multiple *versions* of one shared library in
> one single file is a PITA for package managers - both human or software.
Yes, it is a necessary pain. My secret is a) do not touch /usr/lib -
leave what is as it is, and in the few situations where it must be in
/usr/lib I add/replace named archive members with my new ones - and all
the other ones get extracted, modify a flag in their respective header -
so that the linker knows they are only to be used for applications that
expect them - not for new applications.
> But fortunately, the AIX linker does support so called "Import Files",
> allowing for *filename based* shared library versioning like on Linux,
> while still allowing for both ABIs in a single library archive file.
>
> For example, libtool provides the --with-aix-soname={aix|svr4|both}
> configure flag since libtool-2.4.4. Although the default will stay
> at 'aix' here, in Gentoo Prefix I do use 'svr4' only. This actually
> is a package manager's decision, ideally for all depending packages.
> As gcc does use libtool, for more information please refer to
> https://gcc.gnu.org/install/configure.html#WithAixSoname
> But note that "Import Files" should work with xlc as well.
Actually, more detail than I really want to know. I recall the day when
a library was a collection of "static" .o files, and ranlib was nearly
always needed - Or you told the linker to link against that library
multiple times. And I recall going to my first conference where "RPC"
was the next greatest thing, and shared libraries were going to be such
a space savior - both on disk and in memory. And I was always more of a
bsd fan having schooled myself on UNIX v7, then bsd (2.9 iirc) and bsd
4.1, 4.2 (in comes tcpip) and 4.3. But I diverge :p
To return briefly to the question of what is AIX for the developer -
very flexible. You can choose your architecture and it generally, just
works. I wrote some scripts as a front-end for packaging and most
packages are a one-liner - that runs configure, make, makeinstall (using
DESTDIR) and then packaging the DESTDIR.
As far as python development and AIX goes I am open to helping others.
Been doing that for more years than I care to count. :)
>
> Thanks!
> /haubi/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AIX to stable, what does that take?
On 05/10/2018 22:01, Rob Boehne wrote: > On 10/5/18, 10:33 AM, "Python-Dev on behalf of Michael Haubenwallner" > michael.haubenwall...@ssi-schaefer.com> wrote: > > > > >... I build everything myself, using xlc > >(gcc introduces the need for a GNU RTE, e.g., glibc). > > Using gcc does *not* require to use glibc or even GNU binutils at all. > Except for gcc's own runtime libraries, there's no need for a GNU RTE. > In fact, in Gentoo Prefix I do use gcc as the compiler, configured to > use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE. > > I think the author was referring to the dependency on libgcc_s when using gcc. > It's typical for native UNIX package builders to use gcc only when necessary > because the correct runtime is always installed (if the os running it is > newer) and therefore won't clash when something else in the process space is > using a different version of libgcc_s (I'm not sure what the ABI guarantees > are with libgcc_s specifically, and neither are UNIX packagers - not > necessarily anyway) Thank you Rob. My core mistake is calling it glibc (that is the gnome libc not that I think back), and libgcc* are something else entirely. In any case, I need to get my facts more accurate. > It also eliminates the need to ship a version of libgcc_s as a shared library. That would make life easier. Would probably have to package gcc on my own to get it work that way though. > > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 544 status (forked off "Petr Viktorin as BDFL-Delegate for PEP 580")
I think whatever governance we end up with would have named you BDFL-delegate anyway, Guido, so I think you're just taking the time machine for a spin again. ;) On Wed, 3 Oct 2018 at 09:40, Guido van Rossum wrote: > The process for PEP 544 is off-topic for that thread so I'm starting a new > one. > > I have promised its author to approve it after certain minor changes (that > we both agree on) have been made. It's not an example of how PEP acceptance > in general will works until governance is sorted out though -- PEP 544 is a > very unique special case. (For one, it's uncontroversial -- the reason it's > not been accepted yet is that its author is busy with other things.) > > On Wed, Oct 3, 2018 at 9:12 AM Jeroen Demeyer wrote: > >> On 2018-10-03 17:06, Łukasz Langa wrote: >> > That's the only >> > reason why PEP 544 is not yet accepted for example. >> >> Did you actually try to get PEP 544 accepted or to appoint a >> BDFL-Delegate? I don't find any discussions about PEP 544 after the >> stepping down of the BDFL. >> > > -- > --Guido van Rossum (python.org/~guido) > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs
I'm also fine with saying that keys in **kwargs that are not proper
identifiers is an implementation detail.
On Thu, 4 Oct 2018 at 02:20, Serhiy Storchaka wrote:
> 04.10.18 11:56, Steven D'Aprano пише:
> > While keyword arguments have to be identifiers, using **kwargs allows
> > arbitrary strings which aren't identifiers:
> >
> > py> def spam(**kwargs):
> > print(kwargs)
> >
> > py> spam(**{"something arbitrary": 1, '\n': 2})
> > {'something arbitrary': 1, '\n': 2}
> >
> >
> > There is some discussion on Python-Ideas on whether or not that
> > behaviour ought to be considered a language feature, an accident of
> > implementation, or a bug.
> >
> > Can we get some guidence on this please?
>
> This is an implementation detail. Currently CPython doesn't ensure that
> keyword argument names are identifiers for performance reasons. But this
> can be changed in future versions or in other implementations.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?
On Wed, 3 Oct 2018 at 19:39, Benjamin Peterson wrote: > > > On Wed, Oct 3, 2018, at 08:59, Steven D'Aprano wrote: > > On the bug tracker, there's a discussion about the current behaviour of > > the assert statement, where shadowing AssertionError will change the > > behaviour of the assertion. > > > > https://bugs.python.org/issue34880 > > > > Currently, assert does a LOAD_GLOBAL on AssertionError, which means if > > you shadow the name, you get a different exception. This behaviour goes > > back to Python 1.5. > > > > I'm looking for guidance here, is this the intended behaviour, or an > > accident? Should it be changed to better match other builtins? > > The behavior certainly has been relied on historically by py.test. By > replacing builtins.AssertionError, you can improve the error message of the > AssertionError by, e.g., inspecting the failing frame. py.test's code to do > this was deleted in 2016, but other code bases may still be relying on this > hack. It's probably okay to change the behavior in 3.8 with the > understanding that a revert may be necessary if some clever hack surfaces. > I like Guido's reasoning that syntax probably shouldn't be affected by overloads unless otherwise documented as so, and Benjamin's approach to solving it for 3.8 and then potentially reverting if it breaks too much. -Brett > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
