Re: [Python-Dev] C-level duck typing
On 05/18/2012 12:57 AM, Nick Coghlan wrote: I think the main things we'd be looking for would be: - a clear explanation of why a new metaclass is considered too complex a solution - what the implications are for classes that have nothing to do with the SciPy/NumPy ecosystem - how subclassing would behave (both at the class and metaclass level) Yes, defining a new metaclass for fast signature exchange has its challenges - but it means that *our* concerns about maintaining consistent behaviour in the default object model and avoiding adverse effects on code that doesn't need the new behaviour are addressed automatically. Also, I'd consider a functioning reference implementation using a custom metaclass a requirement before we considered modifying type anyway, so I think that's the best thing to pursue next rather than a PEP. It also has the virtue of letting you choose which Python versions to target and iterating at a faster rate than CPython. This seems right on target. I could make a utility code C header for such a metaclass, and then the different libraries can all include it and handshake on which implementation becomes the real one through sys.modules during module initialization. That way an eventual PEP will only be a natural incremental step to make things more polished, whether that happens by making such a metaclass part of the standard library or by extending PyTypeObject. Thanks, Dag ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Remove outdated statements about threading and imports.
I know you fixed the deadlock problem, but the warnings about shutdown misbehaviour are still valid. -- Sent from my phone, thus the relative brevity :) On May 18, 2012 9:59 PM, "antoine.pitrou" wrote: > http://hg.python.org/cpython/rev/565734c9b66d > changeset: 77020:565734c9b66d > parent: 77018:364289cc7891 > user:Antoine Pitrou > date:Fri May 18 13:57:04 2012 +0200 > summary: > Remove outdated statements about threading and imports. > > files: > Doc/library/multiprocessing.rst | 4 +-- > Doc/library/threading.rst | 23 - > 2 files changed, 1 insertions(+), 26 deletions(-) > > > diff --git a/Doc/library/multiprocessing.rst > b/Doc/library/multiprocessing.rst > --- a/Doc/library/multiprocessing.rst > +++ b/Doc/library/multiprocessing.rst > @@ -120,9 +120,7 @@ > print(q.get())# prints "[42, None, 'hello']" > p.join() > > - Queues are thread and process safe, but note that they must never > - be instantiated as a side effect of importing a module: this can lead > - to a deadlock! (see :ref:`threaded-imports`) > + Queues are thread and process safe. > > **Pipes** > > diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst > --- a/Doc/library/threading.rst > +++ b/Doc/library/threading.rst > @@ -996,27 +996,3 @@ > Currently, :class:`Lock`, :class:`RLock`, :class:`Condition`, > :class:`Semaphore`, and :class:`BoundedSemaphore` objects may be used as > :keyword:`with` statement context managers. > - > - > -.. _threaded-imports: > - > -Importing in threaded code > --- > - > -While the import machinery is thread-safe, there are two key restrictions > on > -threaded imports due to inherent limitations in the way that > thread-safety is > -provided: > - > -* Firstly, other than in the main module, an import should not have the > - side effect of spawning a new thread and then waiting for that thread in > - any way. Failing to abide by this restriction can lead to a deadlock if > - the spawned thread directly or indirectly attempts to import a module. > -* Secondly, all import attempts must be completed before the interpreter > - starts shutting itself down. This can be most easily achieved by only > - performing imports from non-daemon threads created through the threading > - module. Daemon threads and threads created directly with the thread > - module will require some other form of synchronization to ensure they do > - not attempt imports after system shutdown has commenced. Failure to > - abide by this restriction will lead to intermittent exceptions and > - crashes during interpreter shutdown (as the late imports attempt to > - access machinery which is no longer in a valid state). > > -- > Repository URL: http://hg.python.org/cpython > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Remove outdated statements about threading and imports.
On Fri, 18 May 2012 23:16:09 +1000 Nick Coghlan wrote: > I know you fixed the deadlock problem, but the warnings about shutdown > misbehaviour are still valid. Do we have a reproducer? It should have been fixed by http://bugs.python.org/issue1856. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-05-11 - 2012-05-18) Python tracker at http://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: open3432 (+14) closed 23196 (+53) total 26628 (+67) Open issues with patches: 1457 Issues opened (52) == #14784: Re-importing _warnings changes warnings.filters http://bugs.python.org/issue14784 opened by brett.cannon #14785: Add sys._debugmallocstats() http://bugs.python.org/issue14785 opened by dmalcolm #14787: pkgutil.walk_packages returns extra modules http://bugs.python.org/issue14787 opened by cjerdonek #14788: Pdb debugs itself after ^C and a breakpoint is set anywhere http://bugs.python.org/issue14788 opened by xdegaye #14789: after continue, Pdb stops at a line without a breakpoint http://bugs.python.org/issue14789 opened by xdegaye #14790: use packaging in setup.py http://bugs.python.org/issue14790 opened by pitrou #14791: setup.py only adds /prefix/lib, not /prefix/lib64 http://bugs.python.org/issue14791 opened by pitrou #14792: setting a bp on current function, Pdb stops at next line altho http://bugs.python.org/issue14792 opened by xdegaye #14794: slice.indices raises OverflowError http://bugs.python.org/issue14794 opened by Paul.Upchurch #14795: Pdb incorrectly handles a method breakpoint when module not im http://bugs.python.org/issue14795 opened by xdegaye #14796: Calendar module test coverage improved http://bugs.python.org/issue14796 opened by Oleg.Plakhotnyuk #14797: Deprecate imp.find_module()/load_module() http://bugs.python.org/issue14797 opened by brett.cannon #14798: pyclbr raises KeyError when the prefix of a dotted name is not http://bugs.python.org/issue14798 opened by xdegaye #14799: Tkinter ttk tests hang on linux http://bugs.python.org/issue14799 opened by asvetlov #14802: Python fails to compile with VC11 ARM configuration http://bugs.python.org/issue14802 opened by Minmin.Gong #14803: Add feature to allow code execution prior to __main__ invocati http://bugs.python.org/issue14803 opened by ncoghlan #14804: Wrong defaults args notation in docs http://bugs.python.org/issue14804 opened by hynek #14805: Support display of both __cause__ and __context__ http://bugs.python.org/issue14805 opened by ncoghlan #14807: Move tarfile.filemode() into stat module http://bugs.python.org/issue14807 opened by giampaolo.rodola #14808: Pdb does not stop at a breakpoint set on the line of a functio http://bugs.python.org/issue14808 opened by xdegaye #14810: Bug in tarfile http://bugs.python.org/issue14810 opened by hwm #14811: decoding_fgets() truncates long lines and fails with a SyntaxE http://bugs.python.org/issue14811 opened by v+python #14812: Change file associations to not be a default installer feature http://bugs.python.org/issue14812 opened by brian.curtin #14813: Can't build under VS2008 anymore http://bugs.python.org/issue14813 opened by pitrou #14814: Implement PEP 3144 (the ipaddress module) http://bugs.python.org/issue14814 opened by ncoghlan #14815: random_seed uses only 32-bits of hash on Win64 http://bugs.python.org/issue14815 opened by loewis #14817: pkgutil.extend_path has no tests http://bugs.python.org/issue14817 opened by eric.smith #14818: C implementation of ElementTree: Some functions should support http://bugs.python.org/issue14818 opened by cmn #14821: Ctypes extension module builds as _ctypes_test.pyd http://bugs.python.org/issue14821 opened by jason.coombs #14822: Build unusable when compiled for Win 64-bit release http://bugs.python.org/issue14822 opened by jason.coombs #14824: reprlib documentation references string module http://bugs.python.org/issue14824 opened by magcius #14826: urllib2.urlopen fails to load URL http://bugs.python.org/issue14826 opened by wichert #14830: pysetup fails on non-ascii filenames http://bugs.python.org/issue14830 opened by tarek #14831: make r argument on itertools.combinations() optional http://bugs.python.org/issue14831 opened by djc #14833: Copyright date in footer of /pypi says 2011 http://bugs.python.org/issue14833 opened by antlong #14834: A list of broken links on the python.org website http://bugs.python.org/issue14834 opened by antlong #14835: plistlib: output empty elements correctly http://bugs.python.org/issue14835 opened by ssm #14836: Add next(iter(o)) to set.pop, dict.popitem entries. http://bugs.python.org/issue14836 opened by terry.reedy #14837: Better SSL errors http://bugs.python.org/issue14837 opened by pitrou #14838: IDLE Will not load on reinstall http://bugs.python.org/issue14838 opened by BugReporter #14840: Tutorial: Add a bit on the difference between tuples and lists http://bugs.python.org/issue14840 opened by zach.ware #14841: os.get_terminal_size() should check stdin as a fallback http://bugs.python.org/issue14841 opened by Arfrever #14842: Link to time.time() in the docs of
[Python-Dev] docs.python.org pointing to Python 3 by default?
At what point should we cut over docs.python.org to point to the Python 3 documentation by default? Wouldn't this be an easy bit to flip in order to promote Python 3 more better? Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] docs.python.org pointing to Python 3 by default?
On May 18, 2012 1:26 PM, "Barry Warsaw" wrote: > > At what point should we cut over docs.python.org to point to the Python 3 > documentation by default? Today sounds good to me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] docs.python.org pointing to Python 3 by default?
2012/5/18 Barry Warsaw : > At what point should we cut over docs.python.org to point to the Python 3 > documentation by default? Wouldn't this be an easy bit to flip in order to > promote Python 3 more better? Perhaps on the occasion on the release on Python 3.3? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] docs.python.org pointing to Python 3 by default?
Hi, > At what point should we cut over docs.python.org to point to the > Python 3 documentation by default? Wouldn't this be an easy bit to > flip in order to promote Python 3 more better? I’d vote for the release of 3.3 instead of a surprise change in the middle of nowhere. Cheers, Hynek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] docs.python.org pointing to Python 3 by default?
On May 18, 2012, at 11:36 AM, Benjamin Peterson wrote: >2012/5/18 Barry Warsaw : >> At what point should we cut over docs.python.org to point to the Python 3 >> documentation by default? Wouldn't this be an easy bit to flip in order to >> promote Python 3 more better? > >Perhaps on the occasion on the release on Python 3.3? Of course, I'm with Brian, JFDI. :) But coordinating with the 3.3 release would also be nice advertisement. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] docs.python.org pointing to Python 3 by default?
On 5/18/2012 2:39 PM, Hynek Schlawack wrote: Hi, At what point should we cut over docs.python.org to point to the Python 3 documentation by default? Wouldn't this be an easy bit to flip in order to promote Python 3 more better? I’d vote for the release of 3.3 instead of a surprise change in the middle of nowhere. I would have done it with 3.2 and thought that was once agreed on. The last 3.2.3 would also have been a good time, but today might seem odd, so I would am willing to wait for 3.3 as long as it is not somehow forgotten about ;-). -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Remove outdated statements about threading and imports.
On May 18, 2012 11:34 PM, "Antoine Pitrou" wrote: > > On Fri, 18 May 2012 23:16:09 +1000 > Nick Coghlan wrote: > > > I know you fixed the deadlock problem, but the warnings about shutdown > > misbehaviour are still valid. > > Do we have a reproducer? It should have been fixed by > http://bugs.python.org/issue1856. > No, I'd simply missed that change when it was made (or had forgotten about it). Cool. Cheers, Nick. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
