2009/5/20 Stephen J. Turnbull :
> Benjamin Peterson writes:
> > 2009/5/20 :
> >
> > > I suspect it's not really germane to this discussion but if the
> > > incref/decref functions were defined as inline would that effectively be
> > > like using the macro versions vis a vis ABI compatibility?
On May 20, 2009, at 4:07 PM, Nick Coghlan wrote:
Forcing developers to choose between the speed of the INCREF/DECREF
macros and the proposed ABI compatibility mode for the benefit of an
as
yet hypothetical GIL-less CPython API implementation seems more like a
way to kill adoption of the ABI co
Benjamin Peterson writes:
> 2009/5/20 :
>
> > I suspect it's not really germane to this discussion but if the
> > incref/decref functions were defined as inline would that effectively be
> > like using the macro versions vis a vis ABI compatibility?
>
> The code would be inlined into appl
2009/5/20 :
> I suspect it's not really germane to this discussion but if the
> incref/decref functions were defined as inline would that effectively be
> like using the macro versions vis a vis ABI compatibility?
The code would be inlined into applications defeating the point of
being able to c
Nick> Jeffrey Yasskin wrote:
>> To decrease the annoyance of having to change source code, we could
>> have Py_INCREF(x) expand to Py_IncRef(x) in ABI-compatibility mode.
Nick> Forcing developers to choose between the speed of the
Nick> INCREF/DECREF macros and the proposed AB
Hi Sven
can you add an issue with your patch in http://bugs.python.org/
Thanks in advance
Tarek
On Wed, May 20, 2009 at 2:31 PM, Sven Schrader wrote:
> Hi,
>
> since our python installation is located on a symlink'ed directory,
> our variables "sys.exec_prefix" and "sys.executable" can have dif
Martin v. Löwis wrote:
> Functions and function-like Macros
> --
>
> All functions starting with _Py are not available to applications.
> Also, all functions that expect parameter types that are unavailable
> to applications are excluded from the ABI, such as PyAST_
Jeffrey Yasskin wrote:
> Yes, that's my intention. (Well, not the annoying part, but making
> them use Py_IncRef instead for ABI compatibility is, I think, a good
> thing.) If they don't want ABI compatibility, they shouldn't ask for
> it. Giving them something else useful to ask for is why I menti
On Wed, May 20, 2009, Sven Schrader wrote:
>
> since our python installation is located on a symlink'ed directory,
> our variables "sys.exec_prefix" and "sys.executable" can have
> different paths. Therefore, the respective test in build_ext.py fails
> (line 202) and a wrong library directory is o
On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou wrote:
> Jeffrey Yasskin gmail.com> writes:
>>
>> Sorry, I didn't mean to get into a GIL debate. All I'm saying is that
>> I don't think changing the definition of Py_INCREF and Py_DECREF
>> justifies going to Python 4.0, so I don't think their def
Jeffrey Yasskin gmail.com> writes:
>
> Sorry, I didn't mean to get into a GIL debate. All I'm saying is that
> I don't think changing the definition of Py_INCREF and Py_DECREF
> justifies going to Python 4.0, so I don't think their definitions
> should be part of the ABI. If that's not what the A
On Wed, May 20, 2009 at 10:14 AM, Antoine Pitrou wrote:
> Jeffrey Yasskin gmail.com> writes:
>>
>> Over an 8-year lifetime for Python 3, Moore's law predicts that
>> desktop systems will have up to 64 cores, at which point even the
>> simplest GIL-removal strategy of making refcounts atomic will
Jeffrey Yasskin gmail.com> writes:
>
> Over an 8-year lifetime for Python 3, Moore's law predicts that
> desktop systems will have up to 64 cores, at which point even the
> simplest GIL-removal strategy of making refcounts atomic will be a
> win, despite the 2x performance loss for a single threa
Chris Plasun schrieb:
> Thanks for your reply.
>
> Ulrich Eckhardt wrote:
>> On Wednesday 20 May 2009, Chris Plasun wrote:
>>> I'm to develop console apps on a Linux embedded PowerPC board (Freescale
>>> MPC8313).
>>>
>>> Is there a Python release for the PowerPC platform?
>>
>> This has pretty l
On Tue, May 19, 2009 at 2:09 AM, William Reade
wrote:
> (for example, all(?) PyCxx modules use PyCode_New and
> PyFrame_New to get nicer tracebacks)
Specifically for this, I think it'd be nice to expose a function to do
this directly. I recently added PyCode_NewEmpty
(http://svn.python.org/view?v
ad? (Where ### could be an ISO date like
20090520.) That would put "ABI" in the macro name and make it easier
to define new versions later if necessary. (New versions would help
people compile against a new version of Python and be confident they
had something that would run against old versio
Thanks for your reply.
Ulrich Eckhardt wrote:
On Wednesday 20 May 2009, Chris Plasun wrote:
I'm to develop console apps on a Linux embedded PowerPC board (Freescale
MPC8313).
Is there a Python release for the PowerPC platform?
This has pretty little to do with the development of the Python l
Hi all.
I've got a patch to add some documentation for lnotab and its use in
tracing at http://bugs.python.org/issue6042. I think it's correct, but
it's complicated so I'm looking for someone who was around when it was
designed to check. I'm also proposing a change to the semantics of
PyCode_Check
On Wednesday 20 May 2009 13:54:56 David Stanek wrote:
> On Wed, May 20, 2009 at 7:13 AM, Doug Hellmann
wrote:
> > On May 19, 2009, at 10:21 PM, David Stanek wrote:
> >> It seems that using a technique similar to dependency injection could
> >> provide some value. DI allows implementations conform
Hi,
since our python installation is located on a symlink'ed directory,
our variables "sys.exec_prefix" and "sys.executable" can have different
paths. Therefore, the respective test in build_ext.py fails (line 202)
and a wrong
library directory is obtained.
To fix this issue, I have attached a pa
On Wed, May 20, 2009 at 7:13 AM, Doug Hellmann wrote:
>
> On May 19, 2009, at 10:21 PM, David Stanek wrote:
>
>>
>> It seems that using a technique similar to dependency injection could
>> provide some value. DI allows implementations conforming to some
>> interface to be injected into a running a
On Wednesday 20 May 2009, Chris Plasun wrote:
> I'm to develop console apps on a Linux embedded PowerPC board (Freescale
> MPC8313).
>
> Is there a Python release for the PowerPC platform?
This has pretty little to do with the development of the Python language
itself, so it is rather off topic h
On May 20, 2009, at 3:31 AM, Chris Plasun wrote:
Hi,
I'm to develop console apps on a Linux embedded PowerPC board
(Freescale MPC8313).
Is there a Python release for the PowerPC platform?
We used to run a version of the interpreter on PPC for a
microcontroller board we had, but we buil
On May 19, 2009, at 10:21 PM, David Stanek wrote:
On Tue, May 19, 2009 at 9:26 PM, Benjamin Peterson > wrote:
2009/5/19 Michael Foord :
I have IronPython specific versions of several of these functions
which use
.NET reflection and inspect could fallback to if sys.platform ==
'cli'.
Would i
On Tue, May 19, 2009 at 10:36 PM, P.J. Eby wrote:
>
> Now, about the APIs...
>
> I think it would be simpler to have explicit object types representing
> things like a directory, a collection of directories, and individual
> projects, and these object types should be part of the API.
>
> Any funct
Hi,
I'm to develop console apps on a Linux embedded PowerPC board (Freescale
MPC8313).
Is there a Python release for the PowerPC platform?
Thanks,
Chris Plasun
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
26 matches
Mail list logo
