Phillip J. Eby wrote:
> Well, for what class-level frame hacking is typically used for, it
> would suffice to have a convenient way to refer to the local
> namespace, e.g. if you could do something like:
>
> implements(@, IExample)
>
> where @ was a shortcut for locals(). The most-used fr
At 10:18 PM 12/3/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > Well, for what class-level frame hacking is typically used for, it
> > would suffice to have a convenient way to refer to the local
> > namespace, e.g. if you could do something like:
> >
> > implements(@, IExample)
>
Nick Coghlan wrote:
> Aren't the metaclass changes in PEP 3115 partially aimed at eliminating
> the need for stack frame hackery to implement these kinds of things?
> (e.g. the metaclass could stuff a closure into the class namespace under
> the name 'implements' to avoid any need for frame hack
At 03:48 PM 12/3/2007 +0100, Christian Heimes wrote:
>Nick Coghlan wrote:
> > Aren't the metaclass changes in PEP 3115 partially aimed at eliminating
> > the need for stack frame hackery to implement these kinds of things?
> > (e.g. the metaclass could stuff a closure into the class namespace under
On 12/3/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 03:48 PM 12/3/2007 +0100, Christian Heimes wrote:
> >Nick Coghlan wrote:
> > > Aren't the metaclass changes in PEP 3115 partially aimed at
> > > eliminating the need for stack frame hackery to implement
> > > these kinds of things?
Yes.
>
On Dec 2, 2007 12:56 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It's only used for sys.maxint. Do we still need sys.maxint and
> > PyInt_GetMax()? IMO PyLong_GetNativeMax() and sys.maxnativelong are
> > better names.
>
> I think they should go entirely. They don't give any interesting
> i
Hi folks,
I think we've made tremendous progress on Py3k recently, and I'd like
to do an official release of version 3.0a2 by the end of this week.
There's really only one issue that I'd like to address (personally)
before claiming it's ready: issue 1400, having to do with incomplete
implementati
> Actually it's still somewhat interesting to be able to tell whether a
> particular Python build uses 64-bit pointer or 32-bit pointers. (I
> realize sys.maxint doesn't quite tell us this, but on Linux at least
> it does.)
Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
ctypes.siz
On Dec 3, 2007 11:34 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Actually it's still somewhat interesting to be able to tell whether a
> > particular Python build uses 64-bit pointer or 32-bit pointers. (I
> > realize sys.maxint doesn't quite tell us this, but on Linux at least
> > it does
On Dec 3, 2007 12:12 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
> >> ctypes.sizeof(ctypes.py_object).
> >
> > Much less intuitive though.
>
> Actually, I find the ctypes version a more direct answer to the
> question "what is
>> Sure. However, you could also use _testcapi.PY_SSIZE_T_MAX, or
>> ctypes.sizeof(ctypes.py_object).
>
> Much less intuitive though.
Actually, I find the ctypes version a more direct answer to the
question "what is the address space?".
>> I'd be in favor of the latter. I never meant the PyInt_C
11 matches
Mail list logo
