Re: [Python-Dev] Is explicit registration of Iterators needed?
On 07.10.16 18:08, Guido van Rossum wrote: On Fri, Oct 7, 2016 at 7:47 AM, Serhiy Storchaka wrote: Should we register missed builtin iterators? For example longrange_iterator. I don't feel strongly about this either way. Let sleeping dogs lie, etc. (Is this related to issue 26906?) Not directly. If remove explicit iterator registrations some tests become failing due to the bug 26906. After fixing issue26906 the tests are passed again. Thus the bug 26906 could be found earlier if iterators were not registered. ___ 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] Check dict implementation details
Since dict is ordered in CPython 3.6, it can be used instead of OrderedDict in some places (e.g. for implementing simple limited caches). But since this is implementation detail, it can't be used in the stdlib unconditionally. Needed a way to check whether dict is ordered. Actually there are two levels of "ordering". 1. Dict without deletions is iterated in the order of adding items. Raymond's original compact dict implementation satisfied this claim. 2. In addition the order is preserved after deletion operations. Naoki's implementation satisfies this more strong claim. ___ 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] C99
On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote: > The reason this matters is that the official vendor compiler on RHEL 5 > is gcc 4.1, but there's also a separately-distributed version of gcc > 4.8.2 that can target it. Where can I get that 4.8 for RHEL 5? I'm using Centos 5, which ought to be the same as RHEL 5, and the standard gcc is 4.1, with 4.4 available through yum. If 4.8 is available anywhere, I haven't been able to find it. And as far as I can see, 3.6 won't build under either 4.1 or 4.4 on Centos 5. > If a packager trying to build manylinux > wheels wants a more modern gcc, then it's reasonable to ask them to > get this patched gcc. But for an end-user who's just trying to build > CPython on their machine, you might or might not consider this an > acceptable request -- maybe CPython wants to work on default vendor > compiler to imposing that on users. > > And in practice this almost certainly doesn't matter -- the only > reason people jump through hoops to get gcc 4.8 is for its improved > C++ support. I just tried my c99 test file on CentOS 5's default gcc > 4.1 and it was fine. Can you try building Python 3.6? Because it fails for me, and the discussion here: http://bugs.python.org/issue28092 concluded that 4.1 is not supported and I'm right out of luck until I can upgrade. -- Steve ___ 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] C99
On Sat, Oct 8, 2016 at 9:23 AM, Steven D'Aprano wrote: > On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote: > >> The reason this matters is that the official vendor compiler on RHEL 5 >> is gcc 4.1, but there's also a separately-distributed version of gcc >> 4.8.2 that can target it. > > Where can I get that 4.8 for RHEL 5? > > I'm using Centos 5, which ought to be the same as RHEL 5, and the > standard gcc is 4.1, with 4.4 available through yum. If 4.8 is available > anywhere, I haven't been able to find it. And as far as I can see, 3.6 > won't build under either 4.1 or 4.4 on Centos 5. It's RH's "devtoolset" release. The build scripts for the manylinux docker images demonstrate how to install them: https://github.com/pypa/manylinux/blob/master/docker/build_scripts/build.sh#L38 (Unfortunately this involves installing them from a random CentOS dev's home directory over plain-HTTP, but that's the only way to get them if you don't have the appropriate RHEL subscription -- see https://github.com/pypa/manylinux/issues/46#issuecomment-205054077) >> If a packager trying to build manylinux >> wheels wants a more modern gcc, then it's reasonable to ask them to >> get this patched gcc. But for an end-user who's just trying to build >> CPython on their machine, you might or might not consider this an >> acceptable request -- maybe CPython wants to work on default vendor >> compiler to imposing that on users. >> >> And in practice this almost certainly doesn't matter -- the only >> reason people jump through hoops to get gcc 4.8 is for its improved >> C++ support. I just tried my c99 test file on CentOS 5's default gcc >> 4.1 and it was fine. > > Can you try building Python 3.6? Because it fails for me, and the > discussion here: > > http://bugs.python.org/issue28092 > > concluded that 4.1 is not supported and I'm right out of luck until I > can upgrade. I don't have time to follow up right now, but something like docker run -v $PWD:/io -it --rm quay.io/pypa/manylinux1_x86_64 /bin/bash should drop you into a shell in a temporary centos5 VM where 'gcc' is 4.8.2. >From the bug report it sounds like the issue is that my comments above about 'we only care about static inline' were wrong, or at least, Benjamin disagrees :-). I guess the revised version is - if we insist on full C99 inline support, then that means dropping support for building with vendor gcc on CentOS 5 and OS X (and possibly dropping support for older OS X altogether?) - if we are willing to restrict ourselves to 'static inline' and forgo the other 'inline' variants, then all the other C99 things we care about are fine and we can keep support for vendor gcc on CentOS 5 and OS X. -n -- Nathaniel J. Smith -- https://vorpus.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] Check dict implementation details
> On Oct 8, 2016, at 3:01 AM, Serhiy Storchaka wrote: > > Since dict is ordered in CPython 3.6, it can be used instead of OrderedDict > in some places (e.g. for implementing simple limited caches). But since this > is implementation detail, it can't be used in the stdlib unconditionally. > Needed a way to check whether dict is ordered. I think this is premature and shouldn't be done. Instead, everyone (including us) should follow Guido's directive that for now, the right way to provide an ordered dictionary is to use collections.OrderedDict. In the future, we may reimplement collections.OrderedDict() in terms of the new compact dict and everything that uses OrderedDict will benefit from the change. But for now, I think you should avoid wholesale rewrites of everything in the standard library that uses OrderedDict. It seems to me that "needed a way to check whether dict is ordered" is just an end-run around Guido's decision. Also, from a maintenance standpoint, we don't really want two code paths. It is better to just let the new dict implementation play itself out. There is no reason to rush to change lots of code that is currently working just fine. Raymond ___ 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] Is explicit registration of Iterators needed?
On Fri, Oct 7, 2016 at 3:52 PM, Ivan Levkivskyi wrote: > I have a question about the registration of builtins. Currently, typing.py > contains this line: > > ByteString.register(type(memoryview(b''))) > > But there are two test lines in test_collections.py > > self.assertNotIsInstance(memoryview(b""), ByteString) > self.assertFalse(issubclass(memoryview, ByteString)) > > This looks like a contradiction. Which one is right? > Should these tests be removed or the registration in typing.py? Looks like the registration is in error. The stubs (and hence mypy) don't consider memoryview consistent with ByteString. -- --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/archive%40mail-archive.com
Re: [Python-Dev] Check dict implementation details
On 8 October 2016 at 20:01, Serhiy Storchaka wrote: > Since dict is ordered in CPython 3.6, it can be used instead of OrderedDict > in some places (e.g. for implementing simple limited caches). But since this > is implementation detail, it can't be used in the stdlib unconditionally. > Needed a way to check whether dict is ordered. As Raymond suggests, if order actually matters for a given use case, then use collections.OrderedDict unconditionally without worrying about the behaviour of the default dict implementation. In addition to reducing code churn and improving cross-version and cross-implementation compatibility, doing that also lets the *reader* of the code know that the key iteration order matters. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
