[Python-Dev] Reminder: Less than 24 hours until 3.4 feature freeze
I hope to tag 3.4 in less than 24 hours from now. Last call, folks. Here's hoping the buildbots all get green soon, //arry/ ___ Python-Dev mailing list [email protected] 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 454 - tracemalloc - accepted
Hi, 2013/11/21 Charles-François Natali : > I'm happy to officially accept PEP 454 aka tracemalloc. > The API has substantially improved over the past weeks, and is now > both easy to use and suitable as a fundation for high-level tools for > memory-profiling. I pushed the implementation of he PEP 454 (tracemalloc): http://hg.python.org/cpython/rev/6e2089dbc5ad Just after that, I pushed a change in the API to fix a bug: http://hg.python.org/cpython/rev/66db0c66a6ee "Issue #18874: Remove tracemalloc.set_traceback_limit()" Changing the traceback limit while tracemalloc is tracing can leads to bugs or weird behaviour. So I added an option nframe parameter to start instead. I'm sorry, there are pending comments in the issue. I got many reviews the last days, I didn't have time to address them yet. I prefer to push the code before the beta1 because this version marks the feature freeze and I expect more feedback if the module is included in the release. I consider that the comments doesn't change the public API (except the removal of set_tracemalloc_limit which is already done) and so can be addressed later. http://bugs.python.org/issue18874 Anyway, thanks to everyone who helped me to build a better tracemalloc module! And don't hesitate to continue to review the code and test the module. I will try to write an article for the Python Insider blog to show some examples of usage of the tracemalloc module. It would be nice to have similar articles for the other PEPs implemented in Python 3.4, before the release of Python 3.4! http://blog.python.org/ Victor ___ Python-Dev mailing list [email protected] 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 428 (pathlib) now committed
22.11.13 18:44, Antoine Pitrou написав(ла): I've pushed pathlib to the repository. I'm hopeful there won't be new buildbot failures because of it, but still, there may be some platform-specific issues I'm unaware of. Congratuate Antoine! Does it means that issues #11344 (Add os.path.splitpath(path) function) [1] and #13968 (Support recursive globs) [2] have no chance? Both are ready for commit and waits for reviews almost a year. Are the os.path and glob modules deprecated now? [1] http://bugs.python.org/issue11344 [2] http://bugs.python.org/issue13968 ___ Python-Dev mailing list [email protected] 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 428 (pathlib) now committed
I'd vote for a different perspective on path handling. For me the pathlib is not the good way to go. Especially with copying ill behaviour of old os.path functions. We definitely need a "task force page" dedicated to "working with paths in Python" to collaborate. ML + PEP with privileged write access is ineffective. While I like the problem decomposition what I see in pathlib, I don't think it supports the greatest power of Python that it allows you not to think about cross-platform differences - http://clanmills.com/files/dist/doc/cross_platform.html#python-batteries-included I've got the impression that while using pathlib you should care about those. I am +1 for iterating few more times to research best compromise between the most simple possible and most user friendly interface (wart-free). But every iteration should be historically accessible like in blog report, not like in Mercurial PEP diff. There is still problem to dedicate time though. -- anatoly t. On Sat, Nov 23, 2013 at 4:32 PM, Serhiy Storchaka wrote: > 22.11.13 18:44, Antoine Pitrou написав(ла): > >> I've pushed pathlib to the repository. I'm hopeful there won't be >> new buildbot failures because of it, but still, there may be some >> platform-specific issues I'm unaware of. > > > Congratuate Antoine! > > Does it means that issues #11344 (Add os.path.splitpath(path) function) [1] > and #13968 (Support recursive globs) [2] have no chance? Both are ready for > commit and waits for reviews almost a year. Are the os.path and glob modules > deprecated now? > > [1] http://bugs.python.org/issue11344 > [2] http://bugs.python.org/issue13968 > > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com ___ Python-Dev mailing list [email protected] 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 428 (pathlib) now committed
On Sat, 23 Nov 2013 15:32:58 +0200 Serhiy Storchaka wrote: > 22.11.13 18:44, Antoine Pitrou написав(ла): > > I've pushed pathlib to the repository. I'm hopeful there won't be > > new buildbot failures because of it, but still, there may be some > > platform-specific issues I'm unaware of. > > Congratuate Antoine! > > Does it means that issues #11344 (Add os.path.splitpath(path) function) > [1] and #13968 (Support recursive globs) [2] have no chance? Both are > ready for commit and waits for reviews almost a year. Are the os.path > and glob modules deprecated now? They are not deprecated, no. I am not terribly interested in reviewing those patches, personally, but other people may be :-) Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Accepting PEP 3154 for 3.4?
Hello, I've now pushed Alexandre's implementation, and the PEP is marked final. Regards Antoine. On Sat, 16 Nov 2013 19:15:26 +0100 Antoine Pitrou wrote: > > Hello, > > Alexandre Vassalotti (thanks a lot!) has recently finalized his work on > the PEP 3154 implementation - pickle protocol 4. > > I think it would be good to get the PEP and the implementation accepted > for 3.4. As far as I can say, this has been a low-controvery proposal, > and it brings fairly obvious improvements to the table (which table?). > I still need some kind of BDFL or BDFL delegate to do that, though -- > unless I am allowed to mark my own PEP accepted :-) > > (I've asked Tim, specifically, for comments, since he contributed a lot > to previous versions of the pickle protocol.) > > The PEP is at http://www.python.org/dev/peps/pep-3154/ (should be > rebuilt soon by the server, I'd say) > > Alexandre's implementation is tracked at > http://bugs.python.org/issue17810 > > Regards > > Antoine. > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] can someone create a buildbot slave name & password for me?
I've got a nice ARM box to add to the pool (it should be a lot faster and more reliable than warsaw-ubuntu-arm; hopefully making its way to stable). proposed slave name: gps-ubuntu-exynos5-armv7l description: Ubuntu ARM - Dual Cortex A15 2GiB (ie: a repurposed samsung ARM chromebook) thanks, -gps ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] can someone create a buildbot slave name & password for me?
On Nov 23, 2013, at 10:34 AM, Gregory P. Smith wrote: >I've got a nice ARM box to add to the pool (it should be a lot faster and >more reliable than warsaw-ubuntu-arm; hopefully making its way to stable). Once that's up, let me know. I'd like to eventually retire this box. It's unsupported hardware and barely limping along. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: asyncio: Change bounded semaphore into a subclass, like
[guido]
> http://hg.python.org/cpython/rev/6bee0fdcba39
> changeset: 87468:6bee0fdcba39
> user:Guido van Rossum
> date:Sat Nov 23 15:09:16 2013 -0800
> summary:
> asyncio: Change bounded semaphore into a subclass, like
> threading.[Bounded]Semaphore.
>
> files:
> Lib/asyncio/locks.py| 36
> Lib/test/test_asyncio/test_locks.py | 2 +-
> 2 files changed, 20 insertions(+), 18 deletions(-)
>
>
> diff --git a/Lib/asyncio/locks.py b/Lib/asyncio/locks.py
> --- a/Lib/asyncio/locks.py
> +++ b/Lib/asyncio/locks.py
> @@ -336,22 +336,15 @@
...
> +class BoundedSemaphore(Semaphore):
...
> +def release(self):
> +if self._value >= self._bound_value:
> +raise ValueError('BoundedSemaphore released too many times')
> +super().release()
If there's a lock and parallelism involved, this release()
implementation is vulnerable to races: any number of threads can see
"self._value < self._bound_value" before one of them manages to call
the superclass release(), and so self._value can become arbitrarily
larger than self._bound_value. I fixed the same bug in threading's
similar bounded semaphore class a few weeks ago.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] can someone create a buildbot slave name & password for me?
On Sat, Nov 23, 2013 at 12:31 PM, Barry Warsaw wrote: > On Nov 23, 2013, at 10:34 AM, Gregory P. Smith wrote: > > >I've got a nice ARM box to add to the pool (it should be a lot faster and > >more reliable than warsaw-ubuntu-arm; hopefully making its way to stable). > > Once that's up, let me know. I'd like to eventually retire this box. It's > unsupported hardware and barely limping along. > It's up and running: http://buildbot.python.org/all/buildslaves/gps-ubuntu-exynos5-armv7l ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbot's are needlessly compiling -O0
our buildbots are setup to configure --with-pydebug which also unfortunately causes them to compile with -O0... this results in a python binary that is excruciatingly slow and makes the entire test suite run take a long time. given that nobody is ever going to run a gdb or another debugger on the buildbot generated transient binaries themselves how about we speed all of the buildbot's up by adding CFLAGS=-O2 to the configure command line? Sure, the compile step will take a bit longer but that is dwarfed by the test time as it is: http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3224 http://buildbot.python.org/all/builders/ARMv7%203.x/builds/7 http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/639 It should dramatically decrease the turnaround latency for buildbot results. -gps ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
