[Python-Dev] A crash during interpreter cleanup when using PyGILState APIs
An extension module I use makes extensive use of the PyGILState API's in callback functions for C APIs. Some of the functions that use the PyGILState APIs are used in the tp_dealloc of methods. This seems cause problems when objects are cleaned up during interpreter shutdown: when an object is deallocated during PyInterpreterState_Clear I get a hard crash because the GILState machinery has been shut down at that time :-( The bug report for this: http://bugs.python.org/issue1402 The report includes a patch, but I know just enough about the python threading infrastructure to be dangerous and am not convinced that the patch is actually correct. Ronald smime.p7s Description: S/MIME cryptographic 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] Should we do away with unbound methods in Py3k?
Guido van Rossum wrote: > Given that the error is of limited value and that otherwise the > unbound method behaves exactly the same as the original function > object, I'd like to see if there are strenuous objections against > dropping unbound method objects altogether (or at least not using them > in this case), so that explicit super calls (via the unbound method) > may go a little faster. Also, it would make it easier to fix this > issue: http://bugs.python.org/issue1109 Assuming the proposal is simply to change function.__get__ to return self when the second argument is None, then +1. The method descriptors for types written in C should continue to return a wrapper which performs the typecheck, as C method implementations tend to assume that the self argument is guaranteed to be of the correct type. Having to perform that check manually would be rather tedious. This does introduce a new discrepancy between types implemented in C and Python classes, but I suspect that the underlying difference in memory layout restrictions is always going to leak through in at least a few places. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] PCbuild9 for the trunk
Just for your information: I've back-ported the PCbuild9 directory from py3k to the trunk. You now can build Python 2.6 and 3.0 with the new Visual Studio 2008. As far as I've heard from other it works with the free Express Edition. MSDN subscribers with the Standard or Professional version can also create PGO builds with the new directory. Preliminary tests are showing that PGO builds are roughly 10% faster than standard builds. Have fun! Christian ___ 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] Tracker summary emails
On 21/11/2007, Paul Moore <[EMAIL PROTECTED]> wrote: > On 21/11/2007, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > Is it only me who thinks that the current daily summaries are a bit > > > frequent? Would it be possible to reduce the frequency to, say, once a > > > week? > > > > Only if the person in charge of it changes the cron job. Feel free to > > submit a bug report at > > > > http://psf.upfronthosting.co.za/roundup/meta > > Done. Issue 168. Thanks for the pointer. That's been fixed now. Paul. ___ 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] (no subject)
Christian, When will the third party library versions be finalized for Py3k? For the time being I am building with: bzip2-1.0.3 db-4.4.20 openssl-0.9.8g sqlite-source-3.3.4 tcl8.4.12 tix-8.4.0 tk8.4.12 I had an slight issue with the PCbuild9 solution with OpenSSL, I will open a bug and submit a patch in a few. I have a few hours before turkey time :-) Good Day! Joseph Armbruster Christian Heimes wrote: > Just for your information: I've back-ported the PCbuild9 directory from > py3k to the trunk. You now can build Python 2.6 and 3.0 with the new > Visual Studio 2008. As far as I've heard from other it works with the > free Express Edition. > > MSDN subscribers with the Standard or Professional version can also > create PGO builds with the new directory. Preliminary tests are showing > that PGO builds are roughly 10% faster than standard builds. > > Have fun! > > Christian > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josepharmbruster%40gmail.com > ___ 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] Update to PEP 366 (Relative imports from the main module)
I've updated PEP 366 with a proposed implementation, as well as a few
changes to the proposed semantics to make the implementation feasible
(the old proposal called for imp.new_module to calculate a value when it
didn't have access to all of the relevant information).
The updated text is below, and should turn up on python.org before too long.
Regards,
Nick.
PEP: 366
Title: Main module explicit relative imports
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 2.6, 3.0
Post-History: 1-May-2007, 4-Jul-2007, 7-Jul-2007, 23-Nov-2007
Abstract
This PEP proposes a backwards compatible mechanism that permits
the use of explicit relative imports from executable modules within
packages. Such imports currently fail due to an awkward interaction
between PEP 328 and PEP 338.
By adding a new module level attribute, this PEP allows relative imports
to work automatically if the module is executed using the ``-m`` switch.
A small amount of boilerplate in the module itself will allow the relative
imports to work when the file is executed by name.
Proposed Change
===
The major proposed change is the introduction of a new module level
attribute, ``__package__``. When it is present, relative imports will
be based on this attribute rather than the module ``__name__``
attribute.
As with the current ``__name__`` attribute, setting ``__package__`` will
be the responsibility of the PEP 302 loader used to import a module.
Loaders which use ``imp.new_module()`` to create the module object will
have the new attribute set automatically to ``None``. When the import
system encounters an explicit relative import in a module without
``__package__`` set (or with it set to ``None``), it will calculate and
store the correct value (``__name__.rpartition('.')[0]`` for normal
modules and ``__name__`` for package initialisation modules). If
``__package__`` has already been set then the import system will use
it in preference to recalculating the package name from the
``__name__`` and ``__path__`` attributes.
The ``runpy`` module will explicitly set the new attribute, basing it off
the name used to locate the module to be executed rather than the name
used to set the module's ``__name__`` attribute. This will allow relative
imports to work correctly from main modules executed with the ``-m``
switch.
When the main module is specified by its filename, then the
``__package__`` attribute will be set to ``None``. To allow
relative imports when the module is executed directly, boilerplate
similar to the following would be needed before the first relative
import statement::
if __name__ == "__main__" and __package__ is None:
__package__ = "expected.package.name"
Note that this boilerplate is sufficient only if the top level package
is already accessible via ``sys.path``. Additional code that manipulates
``sys.path`` would be needed in order for direct execution to work
without the top level package already being importable.
This approach also has the same disadvantage as the use of absolute
imports of sibling modules - if the script is moved to a different
package or subpackage, the boilerplate will need to be updated
manually. It has the advantage that this change need only be made
once per file, regardless of the number of relative imports.
Rationale for Change
The current inability to use explicit relative imports from the main
module is the subject of at least one open SF bug report (#1510172) [1]_,
and has most likely been a factor in at least a few queries on
comp.lang.python (such as Alan Isaac's question in [2]_).
This PEP is intended to provide a solution which permits explicit
relative imports from main modules, without incurring any significant
costs during interpreter startup or normal module import.
The section in PEP 338 on relative imports and the main module provides
further details and background on this problem.
Reference Implementation
Rev 47142 in SVN implemented an early variant of this proposal
which stored the main module's real module name in the
``__module_name__`` attribute. It was reverted due to the fact
that 2.5 was already in beta by that time.
Patch 1487 [4] is the proposed implementation for this PEP.
Alternative Proposals
=
PEP 3122 proposed addressing this problem by changing the way
the main module is identified. That's a significant compatibility cost
to incur to fix something that is a pretty minor bug in the overall
scheme of things, and the PEP was rejected [3]_.
The advantage of the proposal in this PEP is that its only impact on
normal code is the small amount of time needed to set the extra
attribute when importing a module. Relative imports themselves should
be sped up fractionally, as the package name is cached in
Re: [Python-Dev] PCbuild9 for the trunk
Joseph Armbruster wrote: > Christian, > > When will the third party library versions be finalized for Py3k? For the > time > being I am building with: > > bzip2-1.0.3 > db-4.4.20 > openssl-0.9.8g > sqlite-source-3.3.4 > tcl8.4.12 > tix-8.4.0 > tk8.4.12 > > I had an slight issue with the PCbuild9 solution with OpenSSL, I will open a > bug and submit a patch in a few. I have a few hours before turkey time :-) The dependencies are going to be updated shortly before the next release. The owners of the build bots don't want to update the dependencies every time a new version comes out. For now I stick to the versions in our svn repository except of openssl. I had to update it to 0.9.8g because I had some trouble with it. Christian ___ 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] Should we do away with unbound methods in Py3k?
Guido van Rossum wrote: > Not quite. You can evolve an API from an instancemethod into a > staticmethod without changing the call sites. But is there ever any need to do that, rather than leave it as an instance method? Personally it would never have occurred to me to do that. If you want to be able to override it in subclasses, to me that's an indication that it should be an instance method. Also, what happens if you perform such a migration and then some subclasser later finds that he wants access to 'self'? I don't see this as a use case worth supporting. -- Greg ___ 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] Should we do away with unbound methods in Py3k?
It looks like we're in agreement to drop unbound methods and have a reasonable set or arguments around it (e.g. keep staticmethod, no changes to methods of builtin types, etc.). Do we need a PEP? It's essentially a 2-line change in funcobject.c (func_descr_get()) -- plus fixing up half a dozen or so unittests that specifically seem to test the behavior of unbound methods. --Guido On Nov 22, 2007 6:14 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 01:14 PM 11/23/2007 +1300, Greg Ewing wrote: > >Guido van Rossum wrote: > > > Not quite. You can evolve an API from an instancemethod into a > > > staticmethod without changing the call sites. > > > >But is there ever any need to do that, rather than leave > >it as an instance method? > > Yes. :) See below. > > > >Personally it would never have occurred to me to do that. > >If you want to be able to override it in subclasses, to > >me that's an indication that it should be an instance > >method. > > Or a classmethod, or a staticmethod. > > The most common use case for this (in my experience) is when you need > a converter function or some other sort of function that's > configurable per-instance or per-subclass. If you are configuring it > per-class and accessing it per-instance, and reusing an existing > function, you have to make it a staticmethod. > > > >Also, what happens if you perform such a migration and > >then some subclasser later finds that he wants access to > >'self'? > > Then he overrides it with a normal method. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Should we do away with unbound methods in Py3k?
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |Do we need a PEP? In my view, no. And I am a fan of PEPs. I personally saw unbound method wrapping as more of a CPython implementation detail than an essential part of the language definition. This in spite of its mention in the reference manual. In the index, 'method object' has 3 links. I believe all three areas will need at least a word or two changed. If this is a 3.0 change, then it should be listed in the general PEP with a reference to the thread. Otherwise, What's New. tjr ___ 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] Should we do away with unbound methods in Py3k?
At 01:14 PM 11/23/2007 +1300, Greg Ewing wrote: >Guido van Rossum wrote: > > Not quite. You can evolve an API from an instancemethod into a > > staticmethod without changing the call sites. > >But is there ever any need to do that, rather than leave >it as an instance method? Yes. :) See below. >Personally it would never have occurred to me to do that. >If you want to be able to override it in subclasses, to >me that's an indication that it should be an instance >method. Or a classmethod, or a staticmethod. The most common use case for this (in my experience) is when you need a converter function or some other sort of function that's configurable per-instance or per-subclass. If you are configuring it per-class and accessing it per-instance, and reusing an existing function, you have to make it a staticmethod. >Also, what happens if you perform such a migration and >then some subclasser later finds that he wants access to >'self'? Then he overrides it with a normal method. ___ 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] Should we do away with unbound methods in Py3k?
Guido van Rossum wrote: > It looks like we're in agreement to drop unbound methods and have a > reasonable set or arguments around it (e.g. keep staticmethod, no > changes to methods of builtin types, etc.). Do we need a PEP? It's > essentially a 2-line change in funcobject.c (func_descr_get()) -- plus > fixing up half a dozen or so unittests that specifically seem to test > the behavior of unbound methods. I'd like to help but after staring at the code for 10 minutes I still don't get how the descriptor function should be altered. Can you please give an example to a mer mortal? :) Christian ___ 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] Should we do away with unbound methods in Py3k?
Phillip J. Eby wrote: > If you are configuring it per-class and > accessing it per-instance, and reusing an existing function, you have to > make it a staticmethod. I don't understand that. Can you provide an example? > > some subclasser later finds that he wants access to > > 'self'? > > Then he overrides it with a normal method. If that works, I don't see why making the default method a normal method wouldn't work also. -- Greg ___ 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
