Python-Dev November 2016

python-dev@python.org

47 participants
35 discussions

congrats on 3.5! Alas, windows 7 users are having problems installing it

by Laura Creighton

webmaster has already heard from 4 people who cannot install it. I sent them to the bug tracker or to python-list but they seem not to have gone either place. Is there some guide I should be sending them to, 'how to debug installation problems'? Laura

9 months, 4 weeks

OpenIndiana and Solaris support

by Victor Stinner

Hi, My question is simple: do we officially support Solaris and/or OpenIndiana? Jesus Cea runs an OpenIndiana buildbot slave: http://buildbot.python.org/all/buildslaves/cea-indiana-x86 "Open Indiana 32 bits" The platform module of Python says "Solaris-2.11", I don't know the exact OpenIndiana version. A lot of unit tests fail on this buildbot with MemoryError. I guess that it's related to Solaris which doesn't allow overcommit (allocating more memory than available memory on the system), or more simply because the slave has not enough memory. There is now an issue which seems specific to OpenIndiana: http://bugs.python.org/issue27847 It might impact Solaris as well, but the Solaris buildbot is offline since "684 builds". Five years ago, I reported a bug because the curses module of Python 3 doesn't build on Solaris nor OpenIndiana anymore. It seems like the bug was not fixed, and the issue is still open: http://bugs.python.org/issue13552 So my question is if we officially support Solaris and/or OpenIndiana. If yes, how can we fix issues when we only have buildbot slave which has memory errors, and no SSH access to this server? Solaris doesn't seem to be officially supported in Python, so I suggest to drop the OpenIndiana buildbot (which is failing since at least 2 years) and close all Solaris issues as "WONTFIX". Victor

3 years, 3 months

Default formatting

by Serhiy Storchaka

Classes that doesn't define the __format__ method for custom PEP 3101 formatting inherits it from parents. Originally the object.__format__ method was designed as [1]: def __format__(self, format_spec): return format(str(self), format_spec) An instance is converted to string and resulting string is formatted according to format specifier. Later this design was reconsidered [2], and now object.__format__ is equivalent to: def __format__(self, format_spec): assert format_spec == '' return format(str(self), '') Non-empty format specifier is rejected. But why call format() on resulting string? Why not return resulting string as is? object.__format__ could be simpler (not just implementation, but for understanding): def __format__(self, format_spec): assert format_spec == '' return str(self) This can change the behaviour in corner case. str(self) can return not exact string, but string subclass with overloaded __format__. But I think we can ignore such subtle difference. [1] https://www.python.org/dev/peps/pep-3101/ [2] http://bugs.python.org/issue7994

3 years, 5 months

Is there any remaining reason why weakref callbacks shouldn't be able to access the referenced object?

by Nathaniel Smith

Hi all, It's an old feature of the weakref API that you can define an arbitrary callback to be invoked when the referenced object dies, and that when this callback is invoked, it gets handed the weakref wrapper object -- BUT, only after it's been cleared, so that the callback can't access the originally referenced object. (I.e., this callback will never raise: def callback(ref): assert ref() is None.) AFAICT the original motivation for this seems was that if the weakref callback could get at the object, then the weakref callback would effectively be another finalizer like __del__, and finalizers and reference cycles don't mix, so weakref callbacks can't be finalizers. There's a long document from the 2.4 days about all the terrible things that could happen if arbitrary code like callbacks could get unfettered access to cyclic isolates at weakref cleanup time [1]. But that was 2.4. In the mean time, of course, PEP 442 fixed it so that finalizers and weakrefs mix just fine. In fact, weakref callbacks are now run *before* __del__ methods [2], so clearly it's now okay for arbitrary code to touch the objects during that phase of the GC -- at least in principle. So what I'm wondering is, would anything terrible happen if we started passing still-live weakrefs into weakref callbacks, and then clearing them afterwards? (i.e. making step 1 of the PEP 442 cleanup order be "run callbacks and then clear weakrefs", instead of the current "clear weakrefs and then run callbacks"). I skimmed through the PEP 442 discussion, and AFAICT the rationale for keeping the old weakref behavior was just that no-one could be bothered to mess with it [3]. [The motivation for my question is partly curiosity, and partly that in the discussion about how to handle GC for async objects, it occurred to me that it might be very nice if arbitrary classes that needed access to the event loop during cleanup could do something like def __init__(self, ...): loop = asyncio.get_event_loop() loop.gc_register(self) # automatically called by the loop when I am GC'ed; async equivalent of __del__ async def aclose(self): ... Right now something *sort* of like this is possible but it requires a much more cumbersome API, where every class would have to implement logic to fetch a cleanup callback from the loop, store it, and then call it from its __del__ method -- like how PEP 525 does it. Delaying weakref clearing would make this simpler API possible.] -n [1] https://github.com/python/cpython/blob/master/Modules/gc_weakref.txt [2] https://www.python.org/dev/peps/pep-0442/#id7 [3] https://mail.python.org/pipermail/python-dev/2013-May/126592.html -- Nathaniel J. Smith -- https://vorpus.org

3 years, 5 months

Python 2.7.13 release dates

by Benjamin Peterson

I've have just updated PEP 373 to say that Python 2.7.13 release candidate 1 will be released on December 3. The final will follow two weeks later on December 17. If there are delays in the process, the final will likely to pushed into January. Servus, Benjamin

3 years, 7 months

Re: [Python-Dev] cpython: Uniformize argument names of "call" functions

by Serhiy Storchaka

On 29.11.16 19:58, victor.stinner wrote: > https://hg.python.org/cpython/rev/7efddbf1aa70 > changeset: 105395:7efddbf1aa70 > user: Victor Stinner <victor.stinner(a)gmail.com> > date: Tue Nov 29 18:47:56 2016 +0100 > summary: > Uniformize argument names of "call" functions > > * Callable object: callable, o, callable_object => func > * Object for method calls: o => obj > * Method name: name or nameid => method This change looks wrong to me. "callable" and "callable_object" are better names for functions like PyObject_Call(), since it supports not just functions, but any callables. "name" is appropriate name of the parameter that denotes a method name, not a method object.

3 years, 7 months

Python private and protected variables and methods

by Annapoornima Koppad

Dear All, While teaching Python protected variables, I figured out the oddity about Python. I am using Python 2.7.12+ for my teaching. There is not really a concept of protected variables in Python, is it? For a more detailed explanation of what I am trying to do, please read this article, http://radek.io/2011/07/21/private-protected-and-public-in-python/ It that is the case, Python is not suitable for companies that require secure transactions such as Banking softwares. What solution are possible to overcome data masquerading attempts that might result because of this? Thanks and regards, Annapoornima www.pyladies.co.in

3 years, 7 months

Tests breakage with latest openssl (issue28689)

by Charalampos Stratakis

Hello, Escalating here an issue that seems that it should be tagged as blocker. Currently the latest version of openssl-1.1.0c breaks Python's test suite. The problematic commit was identified [0] and reverted [1] at openssl's upstream, however when running the test suite on a Fedora Rawhide machine, which includes the fix, the tests currently hang (not just failing like before). The issue, with some more details, is tracked here: https://bugs.python.org/issue28689 [0] https://github.com/openssl/openssl/issues/1903 [1] https://github.com/openssl/openssl/commit/beacb0f0c1ae7b0542fe053b95307f515… Regards, Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat

3 years, 7 months

Last call for the Call For Proposals of PythonFOSDEM 2017

by Stephane Wirtel

Because the deadline is imminent and because we have only received some proposals, we will extend the current deadline. The new submission deadline is 2016-12-18. Call For Proposals ================== This is the official call for sessions for the Python devroom at FOSDEM 2017. FOSDEM is the Free and Open source Software Developers' European Meeting, a free and non-commercial two-day week-end that offers open source contributors a place to meet, share ideas and collaborate. It's the biggest event in Europe with +5000 hackers, +400 speakers. For this edition, Python will be represented by its Community. If you want to discuss with a lot of Python Users, it's the place to be! Important dates =============== * Submission deadlines: 2016-12-18 * Acceptance notifications: 2016-12-23 Practical ========= * The duration for talks will be 30 minutes, including presentations and questions and answers. * Presentation can be recorded and streamed, sending your proposal implies giving permission to be recorded. * A mailing list for the Python devroom is available for discussions about devroom organisation. You can register at this address: https://lists.fosdem.org/listinfo/python-devroom How to submit ============= All submissions are made in the Pentabarf event planning tool at https://penta.fosdem.org/submission/FOSDEM17 When submitting your talk in Pentabarf, make sure to select the Python devroom as the Track. Of course, if you already have a user account, please reuse it. Questions ========= Any questions, please send an email to info AT python-fosdem DOT org Thank you for submitting your sessions and see you soon in Brussels to talk about Python. If you want to keep informed for this edition, you can follow our twitter account @PythonFOSDEM. * FOSDEM 2017: https://fosdem.org/2017 * Python Devroom: http://python-fosdem.org * Twitter: https://twitter.com/PythonFOSDEM Stephane -- Stéphane Wirtel - http://wirtel.be - @matrixise

3 years, 7 months

Does anyone use CALL_PROFILE special build?

by Victor Stinner

Hi, I proposed a patch to drop the CALL_PROFILE special build to simplify Python/ceval.c: http://bugs.python.org/issue28799 I modified ceval.c for fast calls in Python 3.6, and I'm not sure that the feature still works correctly. The feature is not well documented and not tested at all. For fast calls, I moved some code, so it's more complex to update call statistics since statistics are implemented in ceval.c. I would like to completely remove the feature to be able to implement further optimizations. Victor

3 years, 7 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev November 2016