[Python-Dev] Python on PowerPC?

[Chris Plasun]

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/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 376 : Changing the .egg-info structure

[Tarek Ziadé]

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 function-oriented API should just be exposed as the methods of a default
> singleton.  Other Python modules follow this pattern -- and it's what I
> copied for the pkg_resources design.  It gives a nice tradeoff between
> keeping the simple things simple, and complex things possible, as well as
> keeping mechanism and policy separate.
>
> Right now, the API design you're trying to do is being burdened by using
> strings and tuples to represent things that could just as easily be objects
> with their own methods, instead of things you have to pass back into other
> APIs.  This also makes caching more complex, because you can't just have one
> main object with stuff hanging off; you've got to have a bunch of
> dictionaries, tuples, lists, sets, etc.

I don't know how other people work on building APIs in PEPs, but at
this stage I am unable
to work them on the paper, without having a prototype to try things out.

So I guess I'll start this prototype in bitbucket and come back with
it for feedback
in Distutils-SIG, for a new PEP 376 round.

Tarek

-- 
Tarek Ziadé | http://ziade.org
___
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] IronPython specific code in inspect module

[Doug Hellmann]

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 it be ok for me to add these to the inspect module?  
Obviously the
tests would only run on IronPython... The behaviour for CPython  
would be

unaffected.


[...]


However that still leaves the question of how to handle putting code
like this in. Should we ask that all code be
implementation-independent as much as possible from the original
authors? Do all all changes against the stdlib have to be run against
several implementations? Should we sprinkle if switches all over the
codebase for different implementations, or should new support files  
be

added?



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 application without the messy
construction logic. The simple construction-by-hand pattern is to
create the dependencies and pass them into the dependent objects.
Frameworks build on top of this to allow the dependencies to be wired
together without having any construction logic in code, like switch
statements, to do the wiring.

I think a similar pattern could be used in the standard library. When
the interpreter goes through its normal bootstrapping process in can
just execute a module provided by the vendor that specifies the
platform specific implementations. Some defaults can be provided since
Python already has a bunch of platform specific implementations.

An over simplified design to make this happen may look like:
1. Create a simple configuration that allows a mapping of interfaces
to implementations. This is where the vendor would say when using
inspect you really should be using cli.inspect.


That sounds like a plugin and the "strategy" pattern.  Tarek is doing  
some work on providing a standard plugin mechanism as part of the work  
he's doing on distutils, isn't he?



2. Add executing this new configuration to the bootstrapping process.


Maybe I misunderstand, but wouldn't it make more sense to initialize  
the platform-specific parts of a module when it is imported rather  
than bring in everything at startup?


Are we only worried about interpreter-implementation-level  
dependencies, or should there be a way for all platform-specific  
features to be treated in the same way?   There are quite a few checks  
for Windows that could be moved into the platform-specific modules if  
there was an easy/standard way to do it.


Doug


3. Add generic hooks into the library where needed to load the
dependency instead of platform specific if statements.
4. Rip out the platform specific code that is hidden in the if
statements and use that as the basis for the sane injected defaults.
5. Document the interfaces for each component that can be changed by
the vendor.

--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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/doug.hellmann%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

Re: [Python-Dev] Python on PowerPC?

[Doug Hellmann]

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 built it ourselves.  Have you  
tried building from source?  It might Just Work.


Doug

___
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 on PowerPC?

[Ulrich Eckhardt]

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 here.

That said, Linux systems are barely thinkable without Python, even when 
running on PPC, so yes, Python runs on PPC, too, and is included in probably 
every Linux distro, e.g. Debian.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

___
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] IronPython specific code in inspect module

[David Stanek]

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 application without the messy
>> construction logic. The simple construction-by-hand pattern is to
>> create the dependencies and pass them into the dependent objects.
>> Frameworks build on top of this to allow the dependencies to be wired
>> together without having any construction logic in code, like switch
>> statements, to do the wiring.
>>
>> I think a similar pattern could be used in the standard library. When
>> the interpreter goes through its normal bootstrapping process in can
>> just execute a module provided by the vendor that specifies the
>> platform specific implementations. Some defaults can be provided since
>> Python already has a bunch of platform specific implementations.
>>
>> An over simplified design to make this happen may look like:
>> 1. Create a simple configuration that allows a mapping of interfaces
>> to implementations. This is where the vendor would say when using
>> inspect you really should be using cli.inspect.
>
> That sounds like a plugin and the "strategy" pattern.  Tarek is doing some
> work on providing a standard plugin mechanism as part of the work he's doing
> on distutils, isn't he?
>

Basically yes. What I proposed is more like a service locator with a
pinch of DI. Where can I learn more about what Tarek is working on? Is
there a branch somewhere?

>> 2. Add executing this new configuration to the bootstrapping process.
>
> Maybe I misunderstand, but wouldn't it make more sense to initialize the
> platform-specific parts of a module when it is imported rather than bring in
> everything at startup?
>

By executing I mean figure out the mappings and necessarily create
them. This enables errors to happen early if the dependencies are not
met. This is really useful if the technique is used for more than just
the platform specific code.

> Are we only worried about interpreter-implementation-level dependencies, or
> should there be a way for all platform-specific features to be treated in
> the same way?   There are quite a few checks for Windows that could be moved
> into the platform-specific modules if there was an easy/standard way to do
> it.
>

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
___
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] distutils.build_ext path comparison - python 2.5.2

[Sven Schrader]

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 patch that uses "os.path.samefile"
instead,
to see whether two files are identical irrespective of its path.


Greetings

Sven Schrader



ps: please CC answers to me, I'm not on the list :-)
pps: I hope the attachment isn't inline...
Fixed path comparison in cases where symlinks to python executables are used.

Signed-off-by: Sven Schrader 
Signed-off-by: Sven Rebhan 
Signed-off-by: Jochen Eppler 

--- distutils/command/build_ext.py	2009-05-20 14:02:07.039240200 +0200
+++ distutils/command/build_ext.py.new	2009-05-20 14:06:55.491335213 +0200
@@ -186,7 +186,7 @@
 # for extensions under Cygwin and AtheOS Python's library directory must be
 # appended to library_dirs
 if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos':
-if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
+if os.path.samefile(os.path.join(sys.exec_prefix, "bin"), os.path.dirname(sys.executable)):
 # building third party extensions
 self.library_dirs.append(os.path.join(sys.prefix, "lib",
   "python" + get_python_version(),
@@ -199,7 +199,7 @@
 # Python's library directory must be appended to library_dirs
 if (sys.platform.startswith('linux') or sys.platform.startswith('gnu')) \
 and sysconfig.get_config_var('Py_ENABLE_SHARED'):
-if sys.executable.startswith(os.path.join(sys.exec_prefix, "bin")):
+if os.path.samefile(os.path.join(sys.exec_prefix, "bin"), os.path.dirname(sys.executable)):
 # building third party extensions
 self.library_dirs.append(sysconfig.get_config_var('LIBDIR'))
 else:
___
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] IronPython specific code in inspect module

[Sebastien Binet]

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 conforming to some
> >> interface to be injected into a running application without the messy
> >> construction logic. The simple construction-by-hand pattern is to
> >> create the dependencies and pass them into the dependent objects.
> >> Frameworks build on top of this to allow the dependencies to be wired
> >> together without having any construction logic in code, like switch
> >> statements, to do the wiring.
> >>
> >> I think a similar pattern could be used in the standard library. When
> >> the interpreter goes through its normal bootstrapping process in can
> >> just execute a module provided by the vendor that specifies the
> >> platform specific implementations. Some defaults can be provided since
> >> Python already has a bunch of platform specific implementations.
> >>
> >> An over simplified design to make this happen may look like:
> >> 1. Create a simple configuration that allows a mapping of interfaces
> >> to implementations. This is where the vendor would say when using
> >> inspect you really should be using cli.inspect.
> >
> > That sounds like a plugin and the "strategy" pattern.  Tarek is doing
> > some work on providing a standard plugin mechanism as part of the work
> > he's doing on distutils, isn't he?
>
> Basically yes. What I proposed is more like a service locator with a
> pinch of DI. Where can I learn more about what Tarek is working on? Is
> there a branch somewhere?

it is here:
 http://wiki.python.org/moin/Distutils/PluginSystem
and there:
 http://pypi.python.org/pypi/extensions

cheers,
sebastien.
-- 
#
# Dr. Sebastien Binet
# Laboratoire de l'Accelerateur Lineaire
# Universite Paris-Sud XI
# Batiment 200
# 91898 Orsay
#

___
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 on PowerPC?

[Thomas Heller]

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 little to do with the development of the Python language 
>> itself, so it is rather off topic here.
> 
> This group appeared to be relevant.
> 
>> That said, Linux systems are barely thinkable without Python, even when 
>> running on PPC, so yes, Python runs on PPC, too, and is included in probably 
>> every Linux distro, e.g. Debian.
> 
> hmmm, hopefully I can find something to run in an embedded box.

If you need to cross-compile, I have a build script and working patches
to cross-build Python 2.6.2 for an ARM embedded system.  Contact me by private 
mail
if you want them.

-- 
Thanks,
Thomas

___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Jeffrey Yasskin]

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 definitions
>> should be part of the ABI. If that's not what the ABI means, that's ok
>> too.
>
> Consider, though, that if Py_INCREF and Py_DECREF are not part of the ABI,
> enabling the ABI-specific preprocessor symbol will hide them, which might (or
> might not!) annoy a lot of extension writers.

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 mentioned an
API compatibility mode.

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.
___
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 on PowerPC?

[Chris Plasun]

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 language 
itself, so it is rather off topic here.


This group appeared to be relevant.

That said, Linux systems are barely thinkable without Python, even when 
running on PPC, so yes, Python runs on PPC, too, and is included in probably 
every Linux distro, e.g. Debian.


hmmm, hopefully I can find something to run in an embedded box.

Thanks,
Chris
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Jeffrey Yasskin]

A couple thoughts:

I'm with the people who think the refcount should be accessed through
functions by apps that want ABI compatibility. In particular,
GIL-removal efforts are guaranteed to change how the refcount is
modified, but there's a good chance they wouldn't have to change the
API. (We have some ideas for how to maintain source compatibility in
the absence of a GIL:
http://code.google.com/p/unladen-swallow/wiki/ExtensionModules#Reference_Counting)
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 thread. I wouldn't
want an ABI to rule that out.

I do think the refcounting macros should remain present in the API
(not ABI) for apps that only need source compatibility and want the
extra speed.

I wonder if it makes sense to specify an API compatibility mode in
this PEP too.

"Py_LIMITED_API" may not be the right macro name—it didn't imply
anything about an ABI when I first saw it. Might it make sense to use
Py_ABI_COMPATIBILITY=### instead? (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 versions.) If we never define
a new version, defining it to a number instead of just anything
doesn't really hurt.

It's probably worth pointing out in the PEP that the fact that
PyVarObject.ob_size is part of the ABI means that PyObject cannot
change size, even by adding fields at the end.

Right now, the globals representing types are defined like
"PyAPI_DATA(PyTypeObject) PyList_Type;". To allow the core to use the
new type creation functions, it might be useful to make the ABI type
objects PyTypeObject* constants instead.

In general, this looks really good. Thanks!

Jeffrey

On Sun, May 17, 2009 at 1:54 PM, "Martin v. Löwis"  wrote:
>
> Thomas Wouters reminded me of a long-standing idea; I finally
> found the time to write it down.
>
> Please comment!
>
> Regards,
> Martin
>
> PEP: 384
> Title: Defining a Stable ABI
> Version: $Revision: 72754 $
> Last-Modified: $Date: 2009-05-17 21:14:52 +0200 (So, 17. Mai 2009) $
> Author: Martin v. Löwis 
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 17-May-2009
> Python-Version: 3.2
> Post-History:
>
> Abstract
> 
>
> Currently, each feature release introduces a new name for the
> Python DLL on Windows, and may cause incompatibilities for extension
> modules on Unix. This PEP proposes to define a stable set of API
> functions which are guaranteed to be available for the lifetime
> of Python 3, and which will also remain binary-compatible across
> versions. Extension modules and applications embedding Python
> can work with different feature releases as long as they restrict
> themselves to this stable ABI.
>
> Rationale
> =
>
> The primary source of ABI incompatibility are changes to the lay-out
> of in-memory structures. For example, the way in which string interning
> works, or the data type used to represent the size of an object, have
> changed during the life of Python 2.x. As a consequence, extension
> modules making direct access to fields of strings, lists, or tuples,
> would break if their code is loaded into a newer version of the
> interpreter without recompilation: offsets of other fields may have
> changed, making the extension modules access the wrong data.
>
> In some cases, the incompatibilities only affect internal objects of
> the interpreter, such as frame or code objects. For example, the way
> line numbers are represented has changed in the 2.x lifetime, as has
> the way in which local variables are stored (due to the introduction
> of closures). Even though most applications probably never used these
> objects, changing them had required to change the PYTHON_API_VERSION.
>
> On Linux, changes to the ABI are often not much of a problem: the
> system will provide a default Python installation, and many extension
> modules are already provided pre-compiled for that version. If additional
> modules are needed, or additional Python versions, users can typically
> compile them themselves on the system, resulting in modules that use
> the right ABI.
>
> On Windows, multiple simultaneous installations of different Python
> versions are common, and extension modules are compiled by their
> authors, not by end users. To reduce the risk of ABI incompatibilities,
> Python currently introduces a new DLL name pythonXY.dll f

[Python-Dev] Documenting lnotab

[Jeffrey Yasskin]

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_CheckLineNumber and want to know whether I should consider it
public.

Thanks to anyone who takes a look!
Jeffrey
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Jeffrey Yasskin]

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 be a
>> win, despite the 2x performance loss for a single thread.
>
> That's only if you think all workloads parallelize easily (and with little 
> work
> from the average programmer), which sounds a bit presumptuous. When you have a
> GUI application and the perceived performance is driven by UI responsivity,
> spawning dozens of threads can little to improve the picture ("GUI 
> application"
> here can mean a feature-rich Web application, too).
>
> As for desktop systems having 64 cores, that's unless the available die space
> gets used for something else instead, e.g. an integrated GPU. Or unless the
> desktop dies in favor of something else (e.g. laptops with small tightly
> integrated chips). The former is already in AMD's and Intel's plans. The 
> latter
> could be happening right now.
>
> And we're not even talking about embedded platforms, or virtual machines 
> where a
> 64-core server is partitioned into 64 "single-core" systems.
>
> (and then there's the whole threading vs processing debate ;-))
>
> Endly, removing the GIL means you have to make all base types (especially
> containers) thread-safe without sacrificing their performance. I don't think
> it's just about reference-counting.
>
>
> That said, the Py_Incref() and Py_Decref() functions already exist. Perhaps 
> they
> should be advertised a bit more in the documentation. The day a hypothetical
> Python implementation gets rid of reference-counting while remaining binary
> compatible with the rest of the API (which rules out PyPy), and gets much 
> faster
> in the process, I think people will happily suffer a small recompile.

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 ABI means, that's ok
too.
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Antoine Pitrou]

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 thread.

That's only if you think all workloads parallelize easily (and with little work
from the average programmer), which sounds a bit presumptuous. When you have a
GUI application and the perceived performance is driven by UI responsivity,
spawning dozens of threads can little to improve the picture ("GUI application"
here can mean a feature-rich Web application, too).

As for desktop systems having 64 cores, that's unless the available die space
gets used for something else instead, e.g. an integrated GPU. Or unless the
desktop dies in favor of something else (e.g. laptops with small tightly
integrated chips). The former is already in AMD's and Intel's plans. The latter
could be happening right now.

And we're not even talking about embedded platforms, or virtual machines where a
64-core server is partitioned into 64 "single-core" systems.

(and then there's the whole threading vs processing debate ;-))

Endly, removing the GIL means you have to make all base types (especially
containers) thread-safe without sacrificing their performance. I don't think
it's just about reference-counting.


That said, the Py_Incref() and Py_Decref() functions already exist. Perhaps they
should be advertised a bit more in the documentation. The day a hypothetical
Python implementation gets rid of reference-counting while remaining binary
compatible with the rest of the API (which rules out PyPy), and gets much faster
in the process, I think people will happily suffer a small recompile.

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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Antoine Pitrou]

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 ABI means, that's ok
> too.

Consider, though, that if Py_INCREF and Py_DECREF are not part of the ABI,
enabling the ABI-specific preprocessor symbol will hide them, which might (or
might not!) annoy a lot of extension writers.

(I don't know if there are extensions out there having reference count
increments and decrements in their critical paths)

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] [Fwd: Re: PEP 384: Defining a Stable ABI]

[Jeffrey Yasskin]

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?view=rev&revision=72487) to go part of the
way here. I didn't go farther because I didn't have a big enough
picture. If most uses of PyFrame_New are really just to call into
Python with a nice traceback, I think it'd be a good idea to add such
a function to ceval.h next to PyEval_Call*(). We can only credibly
tell people to use only the ABI functions when we have an ABI
replacement for the (sane uses of) non-ABI calls.
___
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] distutils.build_ext path comparison - python 2.5.2

[Aahz]

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 obtained.
>
> To fix this issue, I have attached a patch that uses
> "os.path.samefile" instead, to see whether two files are identical
> irrespective of its path.

Please post this patch to bugs.python.org so it can be tracked.

Note that Python 2.5 is now accepting only security patches, so please
check whether 2.6 and trunk need it.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"A foolish consistency is the hobgoblin of little minds, adored by little
statesmen and philosophers and divines."  --Ralph Waldo Emerson
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Nick Coghlan]

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 mentioned an
> API compatibility mode.
> 
> 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.

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 compatibility mode rather than a way to
encourage the use of the IncRef/Decref functions.

The idea of allow an extension to explicitly version the stable ABI
they're using with a macro like Py_ABI_VERSION is a good one though. I'd
suggest using the Python version in hex (e.g. 0x020700 and 0x030200)
rather than an ISO date though. That way an extension developer that
wanted to ensure there code worked with a particular Python version and
later could just define the right Py_ABI_VERSION rather than have to
specifically compile against that earliest version.

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

Re: [Python-Dev] PEP 384: Defining a Stable ABI

[Nick Coghlan]

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_FromNode
> (which expects a ``node*``).
> 
> All other functions are available, unless excluded below.
> 
> Function-like macros (in particular, field access macros) remain
> available to applications, but get replaced by function calls
> (unless their definition only refers to features of the ABI, such
> as the various _Check macros)
> 
> ABI function declarations will not change their parameters or return
> types. If a change to the signature becomes necessary, a new function
> will be introduced. If the new function is source-compatible (e.g. if
> just the return type changes), an alias macro may get added to
> redirect calls to the new function when the applications is
> recompiled.
> 
> If continued provision of the old function is not possible, it may get
> deprecated, then removed, in accordance with PEP 7, causing
> applications that use that function to break.

Something I haven't seen explicitly mentioned as yet (in the PEP or the
python-dev list discussion) are the memory management APIs and the FILE*
APIs which can cause the MSVCRT versioning issues on Windows.

Those would either need to be excluded from the stable ABI or else
changed to use opaque pointers.

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

Re: [Python-Dev] distutils.build_ext path comparison - python 2.5.2

[Tarek Ziadé]

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 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 patch that uses "os.path.samefile"
> instead,
> to see whether two files are identical irrespective of its path.
>
>
> Greetings
>
> Sven Schrader
>
>
>
> ps: please CC answers to me, I'm not on the list :-)
> pps: I hope the attachment isn't inline...
>
> ___
> 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/ziade.tarek%40gmail.com
>
>



-- 
Tarek Ziadé | http://ziade.org
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[skip]

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 ABI compatibility mode for
Nick> the benefit of an as yet hypothetical GIL-less CPython API
Nick> implementation seems more like a way to kill adoption of the ABI
Nick> compatibility mode rather than a way to encourage the use of the
Nick> IncRef/Decref functions.

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?

Skip
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Benjamin Peterson]

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 change the implementation. :)



-- 
Regards,
Benjamin
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[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?
 > 
 > The code would be inlined into applications defeating the point of
 > being able to change the implementation. :)

Hang on, are you sure Skip isn't on to something?  If the A*P*Is are
defined in such way that by making them *function calls* they preserve
A*B*I compatibility, while making them inline gives performance, then
the user (in this case, I really mean the vendor of an application
that contains C modules, I guess) can choose which route to go, right?

I suppose that Python itself could be built with inlined code
internally, but also provide the ABI (at a cost in size, of course).

I don't know if this complexity is manageable or worth trying to
manage, but isn't it conceivable that it could work?

I guess that's for the advocates of extending the promise of ABI
compatibility to these APIs to show, though.  I don't need it myself.
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[James Y Knight]

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 compatibility mode rather than a way  
to

encourage the use of the IncRef/Decref functions.


Indeed, and if the promise of "no-ABI-breakages-till-4.0" is removed,  
this would be a non-issue. Keep Py_INCREF macros in the current ABI,  
and then break the ABI when someone wants to remove the GIL someday.  
That's certainly going to be a big enough change to justify changing  
the ABI.


James
___
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] [unladen-swallow] PEP 384: Defining a Stable ABI

[Benjamin Peterson]

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?
>  >
>  > The code would be inlined into applications defeating the point of
>  > being able to change the implementation. :)
>
> Hang on, are you sure Skip isn't on to something?  If the A*P*Is are
> defined in such way that by making them *function calls* they preserve
> A*B*I compatibility, while making them inline gives performance, then
> the user (in this case, I really mean the vendor of an application
> that contains C modules, I guess) can choose which route to go, right?

In that case, they might as well be macros because changing would
require recompiling.



-- 
Regards,
Benjamin
___
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