[Python-Dev] OS X buildbots missing
Hello, For the record, we don't have any stable OS X buildbots anymore. If you want to contribute a build slave (I hear we may have Apple employees reading this list), please take a look at http://wiki.python.org/moin/BuildBot Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9141, finalizers and gc module
-Original Message- From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of mar...@v.loewis.de Sent: 18. apríl 2012 07:11 To: python-dev@python.org Subject: Re: [Python-Dev] issue 9141, finalizers and gc module Invoking methods in tp_clear I find fairly harmless, in comparison. My only concern is that errors are silently ignored. However, I don't think this matters in practice, since io objects typically are not part of cycles, anyway. Why not allow it for all objects, then? It's *allowed* for all objects. Why do you think it is not? Oh, because dynamic classes with __del__ methods are deliberately not collected but put in gc.garbage. And the special case of the generator object, etc. etc. iobase.c probably documents its own needs well enough. The fact that I had to raise this question here, though, means that the source code for gcmodule.c doesn't have enough information to explain exactly the problem that it has with calling finalizers. It seems to me that it worries that __del__ methods may not run to completion because of attribute errors, and that it would have to silence such errors to not cause unexpected noise. That is the impression I get from this discussion. Correctness over memory conservation, or something like that. Btw, regarding object resurrection, I was working on a patch to get that to work better, particularly with subclasses. You may want to check out issue 8212, whence this discussion originates. K ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9141, finalizers and gc module
On Fri, Apr 20, 2012 at 3:33 PM, Kristján Valur Jónsson krist...@ccpgames.com wrote: Thanks. I wonder if these semantics might not belong in cPython too, us being consenting adults and all that J I would say it's saner, but it's just my opinion :) Cheers, fijal ** ** K ** ** *From:* python-dev-bounces+kristjan=ccpgames@python.org [mailto: python-dev-bounces+kristjan=ccpgames@python.org] *On Behalf Of *Maciej Fijalkowski *Sent:* 17. apríl 2012 21:29 *To:* Antoine Pitrou *Cc:* python-dev@python.org *Subject:* Re: [Python-Dev] issue 9141, finalizers and gc module ** ** ** ** PyPy breaks cycles randomly. I think a pretty comprehensive description of what happens is here: ** ** http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-2.html ** ** Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] issue 9141, finalizers and gc module
Thanks. I wonder if these semantics might not belong in cPython too, us being consenting adults and all that ☺ K From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Maciej Fijalkowski Sent: 17. apríl 2012 21:29 To: Antoine Pitrou Cc: python-dev@python.org Subject: Re: [Python-Dev] issue 9141, finalizers and gc module PyPy breaks cycles randomly. I think a pretty comprehensive description of what happens is here: http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-1.html http://morepypy.blogspot.com/2008/02/python-finalizers-semantics-part-2.html Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On 04/14/2012 02:12 PM, Brett Cannon wrote: My multi-year project -- started in 2006 according to my blog -- to rewrite import in pure Python and then bootstrap it into CPython as *the* implementation of __import__() is finally over (mostly)! Maybe I'm missing something, but it seems that I need to run importlib._bootstrap._install(sys, _imp) manually in order to make __import__ be importlib's version. Is that not supposed to happen automatically? Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Fri, Apr 20, 2012 at 09:54, Eric V. Smith e...@trueblade.com wrote: On 04/14/2012 02:12 PM, Brett Cannon wrote: My multi-year project -- started in 2006 according to my blog -- to rewrite import in pure Python and then bootstrap it into CPython as *the* implementation of __import__() is finally over (mostly)! Maybe I'm missing something, but it seems that I need to run importlib._bootstrap._install(sys, _imp) manually in order to make __import__ be importlib's version. Is that not supposed to happen automatically? It's happening automatically. If you look in Python/import.c you will notice that the code that __import__() eventually calls is calling out into the Python code. There is still some C code in order to accelerate the case of hitting sys.modules. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Fri, Apr 20, 2012 at 7:54 AM, Eric V. Smith e...@trueblade.com wrote: On 04/14/2012 02:12 PM, Brett Cannon wrote: My multi-year project -- started in 2006 according to my blog -- to rewrite import in pure Python and then bootstrap it into CPython as *the* implementation of __import__() is finally over (mostly)! Maybe I'm missing something, but it seems that I need to run importlib._bootstrap._install(sys, _imp) manually in order to make __import__ be importlib's version. Is that not supposed to happen automatically? In the default tip (3.3a2+), importlib.__import__ is already bootstrapped, so you don't need mess with anything. As well, in any of the 3.x versions you can bind builtins.__import__ to importlib.__import__. If you are making changes to importlib (essentially, changes in Lib/importlib/_bootstrap.py), you must re-build (make) cpython in order for your changes to get pulled into the frozen copy of importlib. Until you do that, the built-in import machinery will be the one that existed before your changes. You could also re-bind builtins.__import__ to try out the changes without having to re-build, but ultimately your changes will have to get frozen (into Python/importlib.h) and will be part of the commit of your changes to importlib. Likely you already know all this, but just in case... :) -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On Fri, Apr 20, 2012 at 11:02, Eric Snow ericsnowcurren...@gmail.comwrote: On Fri, Apr 20, 2012 at 7:54 AM, Eric V. Smith e...@trueblade.com wrote: On 04/14/2012 02:12 PM, Brett Cannon wrote: My multi-year project -- started in 2006 according to my blog -- to rewrite import in pure Python and then bootstrap it into CPython as *the* implementation of __import__() is finally over (mostly)! Maybe I'm missing something, but it seems that I need to run importlib._bootstrap._install(sys, _imp) manually in order to make __import__ be importlib's version. Is that not supposed to happen automatically? In the default tip (3.3a2+), importlib.__import__ is already bootstrapped, so you don't need mess with anything. As well, in any of the 3.x versions you can bind builtins.__import__ to importlib.__import__. If you are making changes to importlib (essentially, changes in Lib/importlib/_bootstrap.py), you must re-build (make) cpython in order for your changes to get pulled into the frozen copy of importlib. Until you do that, the built-in import machinery will be the one that existed before your changes. You could also re-bind builtins.__import__ to try out the changes without having to re-build, but ultimately your changes will have to get frozen (into Python/importlib.h) and will be part of the commit of your changes to importlib. Likely you already know all this, but just in case... :) And if you want to run a test using importlib instead of the frozen code you can use importlib.test.regrtest to handle the injection for you. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib is now bootstrapped (and what that means)
On 04/20/2012 10:59 AM, Brett Cannon wrote: On Fri, Apr 20, 2012 at 09:54, Eric V. Smith e...@trueblade.com mailto:e...@trueblade.com wrote: On 04/14/2012 02:12 PM, Brett Cannon wrote: My multi-year project -- started in 2006 according to my blog -- to rewrite import in pure Python and then bootstrap it into CPython as *the* implementation of __import__() is finally over (mostly)! Maybe I'm missing something, but it seems that I need to run importlib._bootstrap._install(sys, _imp) manually in order to make __import__ be importlib's version. Is that not supposed to happen automatically? It's happening automatically. If you look in Python/import.c you will notice that the code that __import__() eventually calls is calling out into the Python code. There is still some C code in order to accelerate the case of hitting sys.modules. Okay. But I'm running make, and that's succeeding (and it looks like it does the right thing), yet it doesn't appear to be picking up my changes to _bootstrap.py automatically. I'll keep investigating. Eric. ___ Python-Dev mailing list Python-Dev@python.org 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-04-13 - 2012-04-20) 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: open3396 (+19) closed 23015 (+44) total 26411 (+63) Open issues with patches: 1440 Issues opened (45) == #12947: Examples in library/doctest.html lack the flags http://bugs.python.org/issue12947 reopened by eric.araujo #13994: incomplete revert in 2.7 Distutils left two copies of customiz http://bugs.python.org/issue13994 reopened by lemburg #14572: 2.7.3: sqlite module does not build on centos 5 http://bugs.python.org/issue14572 opened by Joakim.Sernbrant #14573: json iterencode can not handle general iterators http://bugs.python.org/issue14573 opened by Aaron.Staley #14574: SocketServer doesn't handle client disconnects properly http://bugs.python.org/issue14574 opened by vdjeric #14576: IDLE cannot connect to subprocess - New solution http://bugs.python.org/issue14576 opened by clikkeb #14578: importlib doesn't check Windows registry for paths http://bugs.python.org/issue14578 opened by brett.cannon #14579: Vulnerability in the utf-16 decoder after error handling http://bugs.python.org/issue14579 opened by storchaka #14580: imp.reload can fail for sub-modules http://bugs.python.org/issue14580 opened by paul_ollis #14581: Support case-insensitive file extensions on Windows in importl http://bugs.python.org/issue14581 opened by brett.cannon #14583: try/except import fails --without-threads http://bugs.python.org/issue14583 opened by skrah #14584: Add gzip support the XMLRPC Server http://bugs.python.org/issue14584 opened by rhettinger #14585: Have test_import run more importlib tests http://bugs.python.org/issue14585 opened by brett.cannon #14586: TypeError: truncate() takes no keyword arguments http://bugs.python.org/issue14586 opened by TheBiggerGuy #14588: PEP 3115 compliant dynamic class creation http://bugs.python.org/issue14588 opened by durban #14590: ConfigParser doesn't strip inline comment when delimiter occur http://bugs.python.org/issue14590 opened by grahamd #14591: Value returned by random.random() out of valid range http://bugs.python.org/issue14591 opened by Dave.Reid #14594: document imp.load_dynamic() http://bugs.python.org/issue14594 opened by scoder #14596: struct.unpack memory leak http://bugs.python.org/issue14596 opened by Robert.Elsner #14597: Cannot unload dll in ctypes until script exits http://bugs.python.org/issue14597 opened by plynch76 #14598: _cursesmodule.c fails with ncurses-5.9 on Linux http://bugs.python.org/issue14598 opened by phaering #14599: Windows test_import failure http://bugs.python.org/issue14599 opened by r.david.murray #14600: Change ImportError reference handling, naming http://bugs.python.org/issue14600 opened by brian.curtin #14604: spurious stat() calls in importlib http://bugs.python.org/issue14604 opened by pitrou #14605: Make import machinery explicit http://bugs.python.org/issue14605 opened by brett.cannon #14606: Memory leak subprocess on Windows http://bugs.python.org/issue14606 opened by rfs #14610: configure script hangs on pthread verification and PTHREAD_SCO http://bugs.python.org/issue14610 opened by Raphael.Cruzeiro #14611: inspect.getargs fails on some anonymous tuples http://bugs.python.org/issue14611 opened by taschini #14613: time.time can return NaN http://bugs.python.org/issue14613 opened by michael.foord #14614: PyTuple_SET_ITEM could check bounds in debug mode http://bugs.python.org/issue14614 opened by pitrou #14616: subprocess docs should mention pipes.quote/shlex.quote http://bugs.python.org/issue14616 opened by eric.araujo #14617: confusing docs with regard to __hash__ http://bugs.python.org/issue14617 opened by stoneleaf #14618: remove modules_reloading from the interpreter state http://bugs.python.org/issue14618 opened by eric.snow #14619: Enhanced variable substitution for databases http://bugs.python.org/issue14619 opened by rhettinger #14620: Fatal Python error: Cannot recover from stack overflow. http://bugs.python.org/issue14620 opened by The-Compiler #14621: Hash function is not randomized properly http://bugs.python.org/issue14621 opened by Vlado.Boza #14624: Faster utf-16 decoder http://bugs.python.org/issue14624 opened by storchaka #14625: Faster utf-32 decoder http://bugs.python.org/issue14625 opened by storchaka #14626: os module: use keyword-only arguments for dir_fd and nofollow http://bugs.python.org/issue14626 opened by larry #14627: Fatal Python Error when Python startup is interrupted by CTRL+ http://bugs.python.org/issue14627 opened by haypo #14628: Clarify import statement documentation regarding what gets bou http://bugs.python.org/issue14628 opened by eric.snow #14630: non-deterministic behavior of int subclass http://bugs.python.org/issue14630 opened by brechtm #14631:
Re: [Python-Dev] OS X buildbots missing
Antoine Pitrou solip...@pitrou.net wrote: For the record, we don't have any stable OS X buildbots anymore. Sigh. That's me again. We are currently installing a virtual private cloud at our workspace, and I'm seeing a lot of intermittent failures in that server room. I need to work out a way in which buildbot restarts automatically either when the machine reboots, or when it hangs up (which happens every couple of weeks). Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 833861CBB0 for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:09 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VZ3GK10QGzN51 for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1334941209; bh=PuPHOLI7fb95kba5/ecLxSLCC9UpM27v8bYaw31epzE=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=ZfbTowau33LvKWnJHYtZ8Fy/cAslebBopL912urudimFDYNg5n7CHpPwxlMLlLTv5 tR2OZmCp3w90e6h937L7R6g7mew3xHaxeRbzP06cEK0JTyOQaekSKHBxivVMuU2hjL AE1J6MRlKrxJoqE8dQMyzP7+wM5o39unn76WD6bE= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 20 Apr 2012 19:00:09 +0200 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:09 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from python-dev@python.org) id 1SLHBo-00063N-NT for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:08 +0200 Date: Fri, 20 Apr 2012 19:00:08 +0200 Message-Id: e1slhbo-00063n...@dinsdale.python.org Content-Type: text/plain; charset=utf8 MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue14633] TmV3IGNoYW5nZXNldCBhMjgxYTY2MjI3MTQgYnkgQnJldHQgQ2Fubm9uIGluIGJyYW5jaCAnZGVm YXVsdCc6Cklzc3VlICMxNDYzMzogU2ltcGxpZnkgaW1wLmZpbmRfbW9kdWUoKSB0ZXN0IGFmdGVy IGZpeGVzIGZyb20gaXNzdWUKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvYTI4MWE2 NjIyNzE0Cg== ___ Python-Dev mailing list Python-Dev@python.org 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: Issue #14581: Windows users are allowed to import modules w/o taking
On 4/20/2012 12:53 PM, brett.cannon wrote:
http://hg.python.org/cpython/rev/a32be109bd86
changeset: 76428:a32be109bd86
user:Brett Cannonbr...@python.org
date:Fri Apr 20 12:53:14 2012 -0400
summary:
Issue #14581: Windows users are allowed to import modules w/o taking
the file suffix's case into account, even when doing a case-sensitive
import.
+name, dot, suffix = item.partition('.')
Should this be .rpartition in case there is more than one . in the name?
tjr
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions
2012/4/15 Victor Stinner victor.stin...@gmail.com:
Here is a simplified version of the first draft of the PEP 418. The
full version can be read online.
http://www.python.org/dev/peps/pep-0418/
FYI there is no time.thread_time() function. It would only be
available on Windows and Linux. It does not use seconds but CPU
cycles. No module or program of the Python source code need such
function, whereas all other functions added by the PEP already have
users in the Python source code, see the Rationale section. For Linux,
CLOCK_THREAD_CPUTIME_ID is already available in Python 3.3. For
Windows, you can get GetThreadTimes() using ctypes or win32process.
Explicit is better than implicit ! I listed the limitations of the
PEP directly in the PEP:
-
Limitations:
* The behaviour of clocks after a system suspend is not defined in the
documentation of new functions. The behaviour depends on the
operating system: see the `Monotonic Clocks`_ section below. Some
recent operating systems provide two clocks, one including time
elapsed during system suspsend, one not including this time. Most
operating systems only provide one kind of clock.
* time.monotonic() and time.perf_counter() may or may not be adjusted.
For example, ``CLOCK_MONOTONIC`` is slewed on Linux, whereas
``GetTickCount()`` is not adjusted on Windows.
``time.get_clock_info('monotonic')['is_adjusted']`` can be used to check
if the monotonic clock is adjusted or not.
* No time.thread_time() function is proposed by this PEP because it is
not needed by Python standard library nor a common asked feature.
Such function would only be available on Windows and Linux. On
Linux, it is possible use use
``time.clock_gettime(CLOCK_THREAD_CPUTIME_ID)``. On Windows, ctypes or
another module can be used to call the ``GetThreadTimes()``
function.
-
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
I'm getting one of these every couple of days. What's the deal? On Apr 21, 2012 1:03 AM, Python tracker roundup-ad...@psf.upfronthosting.co.za wrote: An unexpected error occurred during the processing of your message. The tracker administrator is being notified. Return-Path: python-dev@python.org X-Original-To: rep...@bugs.python.org Delivered-To: roundup+trac...@psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 833861CBB0 for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:09 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3VZ3GK10QGzN51 for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1334941209; bh=PuPHOLI7fb95kba5/ecLxSLCC9UpM27v8bYaw31epzE=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=ZfbTowau33LvKWnJHYtZ8Fy/cAslebBopL912urudimFDYNg5n7CHpPwxlMLlLTv5 tR2OZmCp3w90e6h937L7R6g7mew3xHaxeRbzP06cEK0JTyOQaekSKHBxivVMuU2hjL AE1J6MRlKrxJoqE8dQMyzP7+wM5o39unn76WD6bE= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 20 Apr 2012 19:00:09 +0200 Received: from dinsdale.python.org (svn.python.org[IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:09 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from python-dev@python.org) id 1SLHBo-00063N-NT for rep...@bugs.python.org; Fri, 20 Apr 2012 19:00:08 +0200 Date: Fri, 20 Apr 2012 19:00:08 +0200 Message-Id: e1slhbo-00063n...@dinsdale.python.org Content-Type: text/plain; charset=utf8 MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: python-dev@python.org To: rep...@bugs.python.org Subject: [issue14633] TmV3IGNoYW5nZXNldCBhMjgxYTY2MjI3MTQgYnkgQnJldHQgQ2Fubm9uIGluIGJyYW5jaCAnZGVm YXVsdCc6Cklzc3VlICMxNDYzMzogU2ltcGxpZnkgaW1wLmZpbmRfbW9kdWUoKSB0ZXN0IGFmdGVy IGZpeGVzIGZyb20gaXNzdWUKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvYTI4MWE2 NjIyNzE0Cg== ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Handling deprecations in the face of PEP 384
As I clean up Python/import.c and move much of its functionality into Lib/imp.py, I am about to run into some stuff that was not kept private to the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type which I would like to chop out and move to Lib/imp.py. From my reading of PEP 384 that means I would need to at least deprecate PyImport_getMagicTag(), correct (assuming I follow through with this; I might not bother)? What about NullImporter_Type (it lacks a Py prefix so I am not sure if this is considered public or not)? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling deprecations in the face of PEP 384
On Fri, Apr 20, 2012 at 6:59 PM, Brett Cannon br...@python.org wrote: As I clean up Python/import.c and move much of its functionality into Lib/imp.py, I am about to run into some stuff that was not kept private to the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type which I would like to chop out and move to Lib/imp.py. From my reading of PEP 384 that means I would need to at least deprecate PyImport_getMagicTag(), correct (assuming I follow through with this; I might not bother)? What about NullImporter_Type (it lacks a Py prefix so I am not sure if this is considered public or not)? Yeah, PyImporter_GetMagicTag() looks like a public API, parallel with PyImporter_GetMagicNumber(). Maybe it was accidentally not documented? I'm not sure when it was introduced. Should we even deprecate it? I'd say do the same thing you're doing for GetMagicNumber(). NullImporter_Type looks like it was accidentally not made static, so don't fret about that. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Failed issue tracker submission
On Sat, 21 Apr 2012 08:54:56 +0800, Matt Joiner anacro...@gmail.com wrote: I'm getting one of these every couple of days. What's the deal? On Apr 21, 2012 1:03 AM, Python tracker roundup-ad...@psf.upfronthosting.co.za wrote: There is a bug in the interface between roundup and hg that is new since roundup was switched to using xapian for indexing. When an hg commit mentions more than one issue number, the second (or subsequent, presumably) issue number triggers a write conflict and results in the email doing the second issue update being rejected. Since the email address associated with the hg update email is python-dev, the bounce gets sent here. There are currently only three people who do maintenance work on the tracker (it used to be just one), and none of us have found time to try to figure out a fix yet. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling deprecations in the face of PEP 384
On Sat, Apr 21, 2012 at 12:16 PM, Guido van Rossum gu...@python.org wrote: Yeah, PyImporter_GetMagicTag() looks like a public API, parallel with PyImporter_GetMagicNumber(). Maybe it was accidentally not documented? I'm not sure when it was introduced. Should we even deprecate it? I'd say do the same thing you're doing for GetMagicNumber(). I'd keep it and just make it a convenience wrapper for the call back into the Python code. NullImporter_Type looks like it was accidentally not made static, so don't fret about that. Yeah, the lack of the Py_ prefix suggests this one being visible is just an accident of the implementation, and the name is unusual enough that it never caused a symbol collision for any third parties. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
