date:20120219

Re: [Python-Dev] Status of PEP 397 - Python launcher for Windows

2012-02-19 Thread martin

The launcher was slightly controversial when the pep was initially  
written 12 months ago.


So what were the objections?


Assuming you are proposing some future action for CPython,
I'm opposed to the notion that the implementation of the
launcher is the specification. The specification needs to be
in the PEP. It may leave room, in which case the remaining
details need to be specified in the documentation.


I'm really not sure what you are trying to say here.


Let me try again: I dislike the phrase "written in C, which defines
the detailed implementation". That means that in order to find out
what the launcher does, you have to read its source code. I also
dislike the phrase "but instead to offer guidelines the launcher
should adhere to"; the PEP should not just be guidelines, but a
clear, prescriptive specification.

I admit that I had difficulties to find the places in the PEP
where it specifies things, as opposed to explaining things. It
seems that all of the sections
- An overview of the launcher.
- Guidelines for a Python launcher.
- Shebang line parsing
- Virtual commands in shebang lines:
- Customized Commands:
- Python Version Qualifiers
- Command-line handling
- Process Launching
are specification, so it may help to group them as subsections of
a top-level heading "Specification".

OTOH, "Process Launching" has 4 paragraphs of discussion, then
two sentences of specification, then 1,5 sentences of discussion.
I wish it was easier to find out what the PEP actually says.

That the PEP should remove all references to an implementation  
specification, or that the PEP simply should be withdrawn?


Having references to the implementation is fine; saying that you
have to read the code to understand what it does, and that the
code takes precedence over the PEP is not.


If it comes with the Python distribution,
how get multiple copies of the launcher coordinated?


This may not be specified as well as it could, but: "Future versions  
of the launcher should remain backwards compatible with older  
versions, so later versions of Python can install an updated version  
of the launcher without impacting how the previously installed  
version of the launcher is used."


That's not really my concern. I didn't originally find the place where
it said that the launcher goes into the Windows directory. Now that I
see it: how do you prevent deinstallation of py.exe when some version
of Python is uninstalled, but other versions remain?

Regards,
Martin


___
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] Status of PEP 397 - Python launcher for Windows

2012-02-19 Thread Paul Moore

On 19 February 2012 03:09, Mark Hammond  wrote:
> Thanks for the note Paul, but did you also mean to CC python-dev?

Yes, I did, sorry.

>
> On 18/02/2012 9:15 PM, Paul Moore wrote:
>>
>> On 18 February 2012 05:24, Mark Hammond  wrote:
>>>
>>> I'm wondering what thoughts are on PEP 397, the Python launcher for
>>> Windows.
>>>  I've been using the implementation for a number of months now and I find
>>> it
>>> incredibly useful.
>>
>>
>> I use it all the time. It's extremely useful, and I wouldn't be without
>> it.
>>
>> [OT: One interesting property I find useful - if you put an alias
>> "vpython=python.exe" in the ini file (no path to Python) then
>> #!vpython picks up whatever Python is on PATH - this can be very
>> useful if you use virtualenvs a lot and want to run a script with the
>> current virtualenv]
>>
>>> Thoughts or comments?
>>
>>
>> IIRC, one question was how to manage multiple installs - if I install
>> Python 3.3 and 3.4, both of which install py.exe, and then uninstall
>> one, what happens to py.exe. What if I then uninstall the second?
>> Reference count the launcher?
>>
>> If it were possible to package up the launcher installer with the
>> Python installer, but then install it as a separate item, that might
>> be best (it's what MS products seem to do a lot - install one, get ten
>> extra - I don't like the way MS do it, but it seems appropriate here).
>> This would also allow python.org to host a standalone version of the
>> installer which could be installed seamlessly for older versions.
>>
>> 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

Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)

2012-02-19 Thread Ned Deily

In article <[email protected]>,
 "Martin v. Lowis"  wrote:

> > There are two issues that I know of for OS X.  One is just getting a 
> > python2 symlink into the bin directory of a framework build.  That's 
> > easy.
> 
> Where exactly in the Makefile is that reflected? ISTM that the current
> patch already covers that, since the framwork* targets are not concerned
> with the bin directory.

When a framework build is enabled in configure, several additional 
targets from Mac/Makefile are called from the main Makefile.  The 
creating of the links in the framework bin directory and in $prefix/bin 
(/usr/local/bin) are handled there.  (See the checked in patch for 2.7 
for gory details: http://hg.python.org/cpython/rev/499796937b7a)

> > The other is managing symlinks (python, python2, and python3) 
> > across framework bin directories; currently there's no infrastructure 
> > for that.  That part will probably have to wait until PyCon.
> 
> What is the "framework bin directory"? The links are proposed for
> /usr/local/bin resp. /usr/bin. The proposed patch already manages
> these links across releases (the most recent install wins).

The framework bin directory is a bin directory within a framework.  The 
default location for 2.7 is:

/Library/Frameworks/Python.framework/Versions/2.7/bin

This is where the python executable, aux programs like idle, 2to3, 
pydoc, python-config, as well as all Distutils-installed scripts go.  
Mac/Makefile and the Mac installer each optionally create symlinks from 
/usr/local/bin (default) to the items in the framework bin directory at 
build or install time for the standard items but not for subsequent 
Distutils-installed scripts.  Normally, the /usr/local/bin links are not 
needed with framework builds as the framework bin directory is added to 
the user's $PATH during installation.

> If you are concerned about multiple feature releases: this is not an
> issue, since the links are just proposed for Python 2.7 (distributions
> may also add them for 2.6 and earlier, but we are not going to make
> a release in that direction).

It is more of an issue for multiple Python 3 versions.  But the whole 
mechanism of managing multiple framework versions (2 and/or 3) is messy 
right now.  But that's a separate topic that I plan to address later.  
As for now, I believe all that is needed for PEP 394 is now checked-in.

-- 
 Ned Deily,
 [email protected]

___
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] compiling cpython in visual studio 2010

2012-02-19 Thread Antoine Pitrou


Hello,

> I am trying to work on Python bugs following the tutorial given in the
> python website.
> I have installed Tortoise svn and visual studio 2010, I cloned a copy
> of cpython as it is advised in the website using, however I am having
> some problem in compiling it using visual studio 2010.

Which tutorial have you been reading?
I'm not sure it's a typo in your e-mail, but you should be installing
TortoiseHg, not TortoiseSVN.

There's more information about that in the devguide:
http://docs.python.org/devguide/index.html

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

Re: [Python-Dev] cpython: allow arbitrary attributes on classmethod and staticmethod (closes #14051)

2012-02-19 Thread Antoine Pitrou


Hi,

> +static PyObject *
> +cm_get___dict__(classmethod *cm, void *closure)
> +{
> +Py_INCREF(cm->cm_dict);
> +return cm->cm_dict;
> +}

>>> def f(): pass
... 
>>> cm = classmethod(f)
>>> cm.__dict__
Erreur de segmentation


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

Re: [Python-Dev] cpython: allow arbitrary attributes on classmethod and staticmethod (closes #14051)

2012-02-19 Thread Antoine Pitrou



That's answering to Benjamin's f46deae68e34, by the way.

Regards

Antoine.



On Sun, 19 Feb 2012 13:11:22 +0100
Antoine Pitrou  wrote:
> 
> Hi,
> 
> > +static PyObject *
> > +cm_get___dict__(classmethod *cm, void *closure)
> > +{
> > +Py_INCREF(cm->cm_dict);
> > +return cm->cm_dict;
> > +}
> 
> >>> def f(): pass
> ... 
> >>> cm = classmethod(f)
> >>> cm.__dict__
> Erreur de segmentation
> 
> 
> 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] C-API functions for reading/writing tstate->exc_* ?

2012-02-19 Thread Stefan Behnel

Hi,

the Cython and PyPy projects are currently working on getting Cython
implemented extensions to build and run in PyPy, interfacing at the C-API
level for now.

One problem we encountered was that there is currently no "abstract" way to
access tstate->exc_type and friends, i.e. the last exception that was
caught, aka. sys.exc_info(). Apparently, PyPy stores them at a frame level,
whereas CPython makes them available in thread local storage as bare struct
fields. Even if PyPy put them there on request, any changes to these fields
would pass unnoticed. And Cython needs to set them in order to properly
implement the semantics of a try-except statement (and in some other places
where exception state is scoped).

When compiling for PyPy, Cython therefore needs a way to tell PyPy about
any changes. For the tstate->curexc_* fields, there are the two functions
PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official"
functions for the exc_* fields? Maybe PyErr_FetchLast() and
PyErr_RestoreLast()?

Note that Cython would not have a reason to actually use them in CPython,
and it should be uncommon for non-Cython extension modules to care about
the exc_* fields at all. So these functions won't be of much use if
actually implemented in CPython (although I wouldn't mind doing that). The
question is just if we could have two officially named functions that PyPy
(and maybe other Pythons) could implement in order to access the last
raised exception in a way that does not depend on implementation details.

Stefan

___
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] C-API functions for reading/writing tstate->exc_* ?

2012-02-19 Thread Paul Moore

On 19 February 2012 13:04, Stefan Behnel  wrote:
> When compiling for PyPy, Cython therefore needs a way to tell PyPy about
> any changes. For the tstate->curexc_* fields, there are the two functions
> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official"
> functions for the exc_* fields? Maybe PyErr_FetchLast() and
> PyErr_RestoreLast()?

It sounds reasonable to simply write a patch implementing and
documenting these functions, put it in the tracker, and ask for it to
be applied - I can't see an obvious reason not to do so. (There may be
reasons not to put them in the "stable API", but that's not so
relevant here).

> Note that Cython would not have a reason to actually use them in CPython,
> and it should be uncommon for non-Cython extension modules to care about
> the exc_* fields at all. So these functions won't be of much use if
> actually implemented in CPython (although I wouldn't mind doing that). The
> question is just if we could have two officially named functions that PyPy
> (and maybe other Pythons) could implement in order to access the last
> raised exception in a way that does not depend on implementation details.

You're probably worrying too much here. Get them added to Python 3.3,
and then you're fine (if PyPy need to implement them for earlier
versions, that's no problem for CPython, presumably PyPy don't have
quite so stringent backward compatibility requirements yet, and the
fact that they exist in 3.3 gives you the standardisation you need).
Certainly "to have a standard API for getting at this information,
even though it's probably not necessary for CPython extensions" isn't
the best justification, but it's not the worst I've seen either :-)

Of course, you could always go through the Python API, getting the sys
module, extracting the relevant functions and calling them using the
abstract API. That's what I'd recommend if this were purely a CPython
question. But I assume that (for some reason) that's not appropriate
for PyPy.

Of course, my opinion doesn't carry a lot of weight here, so don't
read too much into this :-)
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

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

2012-02-19 Thread Nick Coghlan

On Mon, Feb 20, 2012 at 12:18 AM, Paul Moore  wrote:
> Of course, you could always go through the Python API, getting the sys
> module, extracting the relevant functions and calling them using the
> abstract API. That's what I'd recommend if this were purely a CPython
> question. But I assume that (for some reason) that's not appropriate
> for PyPy.

I had the same thought, but it actually only works cleanly for the
"fetch" half of the equation. You'd have to muck around with actually
raising an exception to handle *setting* those fields, which is
*really* relying on implementation details). That said, it may be
worth further exploring the idea of invoking appropriate snippets of
Python code to get the desired effect.

My other question would be whether there's an existing *private* C API
with the desired behaviour that could be made public, or if this would
be a genuinely new addition to the API.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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] PEP 394 accepted

2012-02-19 Thread Kerrick Staley

Thanks Nick, Ned, and everyone else who worked on implementing this! If any
further work on the text of the PEP or on the Makefile patch is needed,
please shoot me an email (I have GMail set to archive messages to
python-dev unless they explicitly CC me).

-Kerrick Staley

On Fri, Feb 17, 2012 at 6:44 AM, Nick Coghlan  wrote:

> On Fri, Feb 17, 2012 at 10:27 PM, Nick Coghlan  wrote:
> > Unfortunately, dinsdale appears to have fallen over again, so I can't
> > push the change right now :(
>
> It appears that was a temporary glitch - the 2.7 change is now in
> Mercurial.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/mail%40kerrickstaley.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

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

2012-02-19 Thread Stefan Behnel

Nick Coghlan, 19.02.2012 15:31:
> On Mon, Feb 20, 2012 at 12:18 AM, Paul Moore wrote:
>> Of course, you could always go through the Python API, getting the sys
>> module, extracting the relevant functions and calling them using the
>> abstract API. That's what I'd recommend if this were purely a CPython
>> question. But I assume that (for some reason) that's not appropriate
>> for PyPy.
> 
> I had the same thought, but it actually only works cleanly for the
> "fetch" half of the equation. You'd have to muck around with actually
> raising an exception to handle *setting* those fields, which is
> *really* relying on implementation details). That said, it may be
> worth further exploring the idea of invoking appropriate snippets of
> Python code to get the desired effect.

Actually, we currently inline the straight C code for this in CPython for
performance reasons, so, no, going through Python code isn't going to be a
good idea.


> My other question would be whether there's an existing *private* C API
> with the desired behaviour that could be made public, or if this would
> be a genuinely new addition to the API.

I'm not aware of any. The code in CPython (especially in ceval.c) always
uses direct field access.

Stefan

___
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] C-API functions for reading/writing tstate->exc_* ?

2012-02-19 Thread Martin v. Löwis

> When compiling for PyPy, Cython therefore needs a way to tell PyPy about
> any changes. For the tstate->curexc_* fields, there are the two functions
> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official"
> functions for the exc_* fields? Maybe PyErr_FetchLast() and
> PyErr_RestoreLast()?

I wouldn't call the functions *Last, as this may cause confusion with
sys.last_*. I'm also unsure why the current API uses this Fetch/Restore
pair of functions where Fetch clears the variables. A Get/Set pair of
functions would be more natural, IMO (where Get returns "new"
references). This would give PyErr_GetExcInfo/PyErr_SetExcInfo.

Regards,
Martin
___
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] PEP 410, 3rd revision, Decimal timestamp

2012-02-19 Thread Martin v. Löwis

>>  * Ruby (1.9.3), the `Time class `_
>>   supports picosecond (10\ :sup:`-12`)
> 
> We must do better than Ruby: support arbritrary precision! :-D

Seriously, I do consider that a necessary requirement for the PEP (which
the Decimal type actually meets). I don't want to deal with
this issue *again* in my lifetime (now being the second time),
so it's either arbitrary-precision, or highest-possible precision.
When I was in school, attoseconds (as) where the shortest named
second fraction. Today, it seems we should go for yoctoseconds (ys).
There is an absolute boundary, though: it seems there is no point in
going shorter than the Planck time (5.4 * 10**-44).

Regards,
Martin
___
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] folding cElementTree behind ElementTree in 3.3

2012-02-19 Thread Martin v. Löwis

> The change of backing ElementTree by cElementTree has already been
> implemented in the default branch (3.3) by Florent Xicluna with careful
> review from me and others. etree has an extensive (albeit a bit clumsy)
> set of tests which keep passing successfully after the change. 

I just noticed an incompatible change: xml.etree.ElementTree.Element
used to be a type, but is now a function.

> In the past couple of years Florent has been the de-facto maintainer of
> etree in the standard library, although I don't think he ever
> "committed" to keep maintaining it for years to come. Neither can I make
> this commitment, however I do declare that I will do my best to keep the
> library functional, and I also plan to work on improving its
> documentation and cleaning up some of the accumulated cruft in its
> implementation. I also have all the intentions to take the blame if
> something breaks. 

Would you mind adding yourself to

http://docs.python.org/devguide/experts.html

Regards,
Martin
___
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] PEP for new dictionary implementation

2012-02-19 Thread Martin v. Löwis

>> Ah, now I understand; you do need a single ssize_t either on the dict
>> or at the head of the values array to indicate how many slots it has
>> actually allocated.  It *may* also be worthwhile to add a second
>> ssize_t to indicate how many are currently in use, for faster results
>> in case of len.  But the dict is guaranteed to have at least one free
>> slot, so that extra index will never make the allocation larger than
>> the current code.
> 
> The dict already has a field indicating how many items are in use,
> the ma_used field.

So what do you think about Jim's proposal to make the values indexed
not by hash value, but by an index that is stored in the shared keys?

Since the load will be < 2/3, this should save 1/3 of the value storage
(typically more than that, if you initialize the values array always to
the current number of shared keys).

Regards,
Martin
___
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] Links to last binary builds to download pages

2012-02-19 Thread Michael Foord

Hey folks,

When we do security only releases of Python we regularly get emails to 
[email protected] asking where to find binary builds. If you want to find 
the most recent binary builds of Python 2.5 & 2.6, it used to involve clicking 
through quite a few links.

I've added links to the latest binary releases to the 2.6.7, 2.5.6 and 2.5.5 
security release download pages. These are primarily for the benefit of Windows 
and Mac OS X users who wouldn't normally compile their own builds from source.

It would be helpful if release managers for security, source only, releases 
could include similar links in future.

All the best,

Michael

--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
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: Fix a failing importlib test under Windows.

2012-02-19 Thread Nick Coghlan

On Mon, Feb 20, 2012 at 10:36 AM, brett.cannon
 wrote:
> -    if sys_module.platform in CASE_INSENSITIVE_PLATFORMS:
> +    if any(sys_module.platform.startswith(x)
> +            for x in CASE_INSENSITIVE_PLATFORMS):

Since C_I_P is a tuple, that condition can be written as:
"sys_module.platform.startswith(CASE_INSENSITIVE_PLATFORMS)"

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

2012-02-19 Thread Nick Coghlan

On Mon, Feb 20, 2012 at 10:55 AM, antoine.pitrou
 wrote:
> +def _relax_case():
> +    """True if filenames must be checked case-insensitively."""
> +    if any(map(sys.platform.startswith, CASE_INSENSITIVE_PLATFORMS)):
> +        def _relax_case():
> +            return b'PYTHONCASEOK' in _os.environ
>     else:
> -        return True

Wow, that's horrendously confusing. Please change the name of the
factory function to "_make_relax_case" (or something, anything that
isn't "_relax_case" would be an improvement).

Also, the docstring should be on the created functions, not the
factory function.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

2012-02-19 Thread Nick Coghlan

However, "very cool" on adding the caching in the default importers :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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: add generic implementation of a dict descriptor for C types

2012-02-19 Thread Georg Brandl

Am 20.02.2012 02:04, schrieb benjamin.peterson:
> http://hg.python.org/cpython/rev/78f93eb7dd75
> changeset:   75050:78f93eb7dd75
> user:Benjamin Peterson 
> date:Sun Feb 19 19:59:10 2012 -0500
> summary:
>   add generic implementation of a __dict__ descriptor for C types
> 
> files:
>   Doc/c-api/object.rst |  12 +
>   Doc/c-api/type.rst   |   1 -
>   Include/object.h |   2 +
>   Misc/NEWS|   4 +++
>   Objects/object.c |  42 
>   Objects/typeobject.c |  22 +++-
>   6 files changed, 64 insertions(+), 19 deletions(-)
> 
> 
> diff --git a/Doc/c-api/object.rst b/Doc/c-api/object.rst
> --- a/Doc/c-api/object.rst
> +++ b/Doc/c-api/object.rst
> @@ -101,6 +101,18 @@
> This is the equivalent of the Python statement ``del o.attr_name``.
>  
>  
> +.. c:function:: PyObject* PyType_GenericGetDict(PyObject *o, void *context)
> +
> +   A generic implementation for the getter of a ``__dict__`` descriptor. It
> +   creates the dictionary if necessary.
> +
> +
> +.. c:function:: int PyType_GenericSetDict(PyObject *o, void *context)
> +
> +   A generic implementation for the setter of a ``__dict__`` descriptor. This
> +   implementation does not allow the dictionary to be deleted.
> +
> +
>  .. c:function:: PyObject* PyObject_RichCompare(PyObject *o1, PyObject *o2, 
> int opid)


versionadded, please?

Georg

___
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] Status of PEP 397 - Python launcher for Windows

Re: [Python-Dev] Status of PEP 397 - Python launcher for Windows

Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)

Re: [Python-Dev] compiling cpython in visual studio 2010

Re: [Python-Dev] cpython: allow arbitrary attributes on classmethod and staticmethod (closes #14051)

Re: [Python-Dev] cpython: allow arbitrary attributes on classmethod and staticmethod (closes #14051)

[Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Re: [Python-Dev] PEP 394 accepted

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Re: [Python-Dev] PEP 410, 3rd revision, Decimal timestamp

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Re: [Python-Dev] PEP for new dictionary implementation

[Python-Dev] Links to last binary builds to download pages

Re: [Python-Dev] [Python-checkins] cpython: Fix a failing importlib test under Windows.

Re: [Python-Dev] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

Re: [Python-Dev] [Python-checkins] cpython: Issue #14043: Speed up importlib's _FileFinder by at least 8x, and add a new

Re: [Python-Dev] cpython: add generic implementation of a dict descriptor for C types

20 matches

Site Navigation

Mail list logo

Footer information