Re: [Python-Dev] Supporting Third Party Modules (was The other Py2.4 issue)

["Martin v. Löwis"]

Chui G. Tey wrote:
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functions such as
PyArgParseTuple, PyString_AsString etc regardless of which python the
user is running. This would be similar to the COM approach. You can load
all the function pointers into a struct and then call them. 

Third party modules would link against this DLL independent of which
python is being used. 
I believe this is not implementable: How can the DLL know which Python
DLL to use?
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] removing aclocal.m4

["Martin v. Löwis"]

Neal Norwitz wrote:
Can we remove aclocal.m4?  The last log message states:
fix for bug #811160 - autoconf vs. hp/ux system header files.
also applied to release23-maint.
Note that aclocal.m4 can go away when autoconf 2.58 is out.
It appears to me that 2.59 indeed fixes the HP-UX problem; a diff
with and without aclocal.m4 shows chunks like
 cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
+/* Define $ac_func to an innocuous variant, in case  declares 
$ac_func.
+   For example, HP-UX 11i  declares gettimeofday.  */
+#define $ac_func innocuous_$ac_func
+
 /* System header to define __stub macros and hopefully few prototypes,
 which can conflict with char $ac_func (); below.
 Prefer  to  if __STDC__ is defined, since
- exists even on freestanding compilers.  Under hpux,
-including  includes  and causes problems
-checking for functions defined therein.  */
-#if defined (__STDC__) && !defined (_HPUX_SOURCE)
+ exists even on freestanding compilers.  */
+
+#ifdef __STDC__
 # include 
 #else
 # include 
 #endif
+
+#undef $ac_func
+

So they manage to get limits.h define, say, innoucuous_clock(),
instead of clock(), whereas we currently avoid including limits.h
on HP-UX.
IOW, it seems like it should work, but somebody should test it
on HP-UX to be sure.
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] Supporting Third Party Modules (was The other Py2.4 issue)

[Bob Ippolito]

On Dec 11, 2004, at 3:39 AM, Martin v. Löwis wrote:
Chui G. Tey wrote:
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functions such 
as
PyArgParseTuple, PyString_AsString etc regardless of which python the
user is running. This would be similar to the COM approach. You can 
load
all the function pointers into a struct and then call them. Third 
party modules would link against this DLL independent of which
python is being used.
I believe this is not implementable: How can the DLL know which Python
DLL to use?
Well for py2app on Mac OS X, I wrote an executable stub that chooses a 
Python runtime from an XML file, looks up and binds a few symbols from 
it dynamically, and then starts doing stuff.  Works for 2.3 (as long as 
it's not compiled debug or trace refs) and 2.4 (universally, because it 
has exported functions for incref and decref).

For extension modules, this makes much less sense, but I wanted to be 
able to bootstrap Python programs with a precompiled executable that I 
didn't have to maintain across several versions.

-bob
___
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] Re: 2.4 news reaches interesting places

[Fredrik Lundh]

> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point.

fwiw, IDG's Computer Sweden,  "sweden's leading IT-newspaper" has a
surprisingly big Python article in their most recent issue:

PYTHON FEELS WELL
Better performance biggest news in 2.4

and briefly interviews swedish zope-developer Johan Carlsson and Python-
Ware co-founder Håkan Karlsson.



PS. the heading is a play on the swedish phrase "må pyton", which means
"feel like crap"... 



___
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] Re: 2.4 news reaches interesting places

[Martijn Faassen]

Fredrik Lundh wrote:
[snip]
fwiw, IDG's Computer Sweden,  "sweden's leading IT-newspaper" has a
surprisingly big Python article in their most recent issue:
PYTHON FEELS WELL
Better performance biggest news in 2.4
[snip]
Perhaps the message getting out is actually that Python's performance is 
getting better, so nothing to worry about. The original article that 
Guido cited had a headline along the same lines: "Faster Python grabs 
programmers".

So perhaps there really is nothing to worry about in this department: 
the headlines are saying "Python now faster". That to me sounds like an 
excellent way to combat "Python is slow" memes. :)

Regards,
Martijn
___
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] Re: 2.4 news reaches interesting places

[Oleg Broytmann]

On Sat, Dec 11, 2004 at 08:22:17AM -0800, Guido van Rossum wrote:
> But the perception of Python as
> "slow" does worry managers.

   Much more those managers are worried that Python isn't backed by a
large corporation. For Java there is Sun, for Visual Basic there is the
biggest and most powerful corporation. But who is for Python? Who is
responsible? Whom to blame?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] Re: 2.4 news reaches interesting places

[Phillip J. Eby]

At 08:22 AM 12/11/04 -0800, Guido van Rossum wrote:
BTW I strongly disagree that making easy .EXE binaries available will
address this issue; while not bundled, there are plenty of solutions
for maning .EXEs for those who need them, and this is not something
that typically worries managers. But the perception of Python as
"slow" does worry managers.
The relevant memes are that "compiled == fast", and that ".exe == compiled".
It's not about .exe as a distribution format, but rather that producing an 
.exe is supporting evidence of having a "real" compiler.

IOW, if there exists a compiler, but it doesn't produce .exe's, it won't be 
considered a "real" compiler by many programmers.

___
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] The other Py2.4 issue

[Armin Rigo]

Hi,

On Fri, Dec 10, 2004 at 01:19:10PM -0500, Phillip J. Eby wrote:
> >>http://mail.python.org/pipermail/python-dev/2004-January/041676.html
> >
> >Shouldn't this be distributed with binary distributions of Python, to save 
> >people the trouble?
> 
> The Python developers who produce the Windows binaries don't use 
> mingw/cygwin, so this would put a maintenance burden on them.

This thread started as "how to convince people to build their extension
modules quickly for Python 2.4".  I was just suggesting that taking a bit of
that burden away from us non-Windows-users would be helpful :-)

> >Or, if it can be skipped, the procedure for doing a mingw build with the 
> >.lib should be documented and that'd be the end of it.
> 
> It's actually documented now, in the "Installing Python Modules" manual.  

Oh right...  Well, I didn't notice because, oddly, there is another set of
pages on the same subject (but with different details and up-to-date-ness)  
in "Extending and Embedding the Python Interpreter".

I guess that one of them should be removed and point to the other...


A bientot,

Armin.
___
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] The other Py2.4 issue

[Christian Tismer]

Armin Rigo wrote:
Hi Martin,
On Sat, Dec 11, 2004 at 12:45:01AM +0100, "Martin v. Löwis" wrote:
The straight-forward answer is: Get VC7.1 (aka VS.NET 2003), and invoke
python setup.py bdist_wininst
That's not too hard to do, I think.

Hum, this is getting into a Linux-vs-Windows argument.  I don't want to invest
time and money on Windows tools just to compile my extension module for
Windows users...
Maybe we can set this up as a service?
I have the compiler and could do something like
doing a checkout, build, and upload new binary
for a number of projects.
What is needed is a simple but secure notification
method. Probably I need one windows machine which is
always online.
ciao - chris
--
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
 whom do you want to sponsor today?   http://www.stackless.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] Re: 2.4 news reaches interesting places

[Nick Coghlan]

Raymond Hettinger wrote:
  
Makes sense to me - I look forward to seeing the next version.
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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] PEP 338: Executing modules inside packages with '-m'

[Nick Coghlan]

Python 2.4's -m command line switch only works for modules directly on sys.path.
Trying to use it with modules inside packages will fail with a "Module not
found" error. This PEP aims to fix that for Python 2.5.
Previously, posting of a draft version of the PEP to python-dev and python-list
didn't actually generate any responses. I'm not sure if that's an indication
that people don't see the restriction to top-level modules as a problem (and
hence think the PEP is unecessary), or think the extension to handle packages is
obvious (and hence see no need to comment).
For c.l.p, it could just be a sign that Python 2.4 hasn't been out long enough 
for anyone to care what I'm yabbering on about :)

Anyway, all comments are appreciated (even a simple "Sounds good to me").
Cheers,
Nick.
***
PEP: 338
Title: Executing modules inside packages with '-m'
Version: $Revision: 1.2 $
Last-Modified: $Date: 2004/12/11 20:31:10 $
Author: Nick Coghlan <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 16-Oct-2004
Python-Version: 2.5
Post-History: 8-Nov-2004
Abstract

This PEP defines semantics for executing modules inside packages as
scripts with the ``-m`` command line switch.
The proposed semantics are that the containing package be imported
prior to execution of the script.
Rationale
=
Python 2.4 adds the command line switch ``-m`` to allow modules to be
located using the Python module namespace for execution as scripts.
The motivating examples were standard library modules such as ``pdb``
and ``profile``.
A number of users and developers have requested extension of the
feature to also support running modules located inside packages.  One
example provided is pychecker's ``pychecker.checker`` module.  This
capability was left out of the Python 2.4 implementation because the
appropriate semantics were not entirely clear.
The opinion on python-dev was that it was better to postpone the
extension to Python 2.5, and go through the PEP process to help make
sure we got it right.
Scope of this proposal
==
In Python 2.4, a module located using ``-m`` is executed just as if
its filename had been provided on the command line.  The goal of this
PEP is to get as close as possible to making that statement also hold
true for modules inside packages.
Prior discussions suggest it should be noted that this PEP is **not**
about any of the following:
- changing the idiom for making Python modules also useful as scripts
  (see PEP 299 [1]_).
- lifting the restriction of ``-m`` to modules of type PY_SOURCE or
  PY_COMPILED (i.e. ``.py``, ``.pyc``, ``.pyo``, ``.pyw``).
- addressing the problem of ``-m`` not understanding zip imports or
  Python's sys.metapath.
The issues listed above are considered orthogonal to the specific
feature addressed by this PEP.
Current Behaviour
=
Before describing the new semantics, it's worth covering the existing
semantics for Python 2.4 (as they are currently defined only by the
source code).
When ``-m`` is used on the command line, it immediately terminates the
option list (like ``-c``).  The argument is interpreted as the name of
a top-level Python module (i.e. one which can be found on
``sys.path``).
If the module is found, and is of type ``PY_SOURCE`` or
``PY_COMPILED``, then the command line is effectively reinterpreted
from ``python  -m  `` to ``python 
 ``.  This includes setting ``sys.argv[0]`` correctly
(some scripts rely on this - Python's own ``regrtest.py`` is one
example).
If the module is not found, or is not of the correct type, an error
is printed.
Proposed Semantics
==
The semantics proposed are fairly simple: if ``-m`` is used to execute
a module inside a package as a script, then the containing package is
imported before executing the module in accordance with the semantics
for a top-level module.
This is necessary due to the way Python's import machinery locates
modules inside packages.  A package may modify its own __path__
variable during initialisation.  In addition, paths may affected by
``*.pth`` files.  Accordingly, the only way for Python to reliably
locate the module is by importing the containing package and
inspecting its __path__ variable.
Note that the package is *not* imported into the ``__main__`` module's
namespace.  The effects of these semantics that will be visible to the
executed module are:
- the containing package will be in sys.modules
- any external effects of the package initialisation (e.g. installed
  import hooks, loggers, atexit handlers, etc.)
Reference Implementation

A reference implementation is available on SourceForge [2]_.  In this
implementation, if the ``-m`` switch fails to locate the requested
module at the top level, it effectively reinterprets the command from
``python -m 

Re: [Python-Dev] PEP 338: Executing modules inside packages with '-m'

[Brett C.]

Nick Coghlan wrote:
Python 2.4's -m command line switch only works for modules directly on 
sys.path.
Trying to use it with modules inside packages will fail with a "Module not
found" error. This PEP aims to fix that for Python 2.5.

Previously, posting of a draft version of the PEP to python-dev and 
python-list
didn't actually generate any responses. I'm not sure if that's an 
indication
that people don't see the restriction to top-level modules as a problem 
(and
hence think the PEP is unecessary), or think the extension to handle 
packages is
obvious (and hence see no need to comment).

For c.l.p, it could just be a sign that Python 2.4 hasn't been out long 
enough for anyone to care what I'm yabbering on about :)

Anyway, all comments are appreciated (even a simple "Sounds good to me").
Sounds good to me. =)
+1
-Brett
___
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] python-dev Summary for 2004-10-16 through 2004-10-31 [draft]

[Brett C.]

Winter Break is upon me which means I have time to catch up on the Summaries. 
I will definitely be caught up by the end of the month.

As for this summary, I will send this out around Wednesday.  As always 
corrections are appreciated.  If you feel one of the skipped threads deserves 
coverage please feel free to write up a summary and I will edit it and include it.

--
=
Summary Announcements
=
`Python 2.4`_ final is now out!
As I mentioned in the last summary my school schedule this past quarter has 
been insane.  But now I am on Winter Break and will hopefully be able to catch 
up on my Summary backlog.

.. _Python 2.4: http://www.python.org/2.4/
=
Summaries
=

Specifying main functions and calling packages with '-m'

In my opinion, the new '-m' command line option in Python 2.4 is really handy. 
 But wouldn't it be even handier if you could execute modules in a package? 
That exact question came up.  The reason this kind of thing didn't just go 
directly into 2.4 was that the semantics are not as obvious nor is it as 
simple.  A PEP is on the way, though.  Until then, you can use Nick Coghlan's 
recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307772.

This also brought up the discussion of being able to specify a 'main' function 
to take the place of the good old ``if __name__ == "__main__"`` idiom.  Some 
liked the idea of allowing one to define a function named 'main', others 
'__main__'.  But the discussion never went any farther.  This will require a 
PEP to ever even be seriously considered.

Contributing threads:
  - `python-dev Summary for 2004-09-16 through 2004-09-30 [draft] <>`__
  - `Magic main functions <>`__
  - `Supporting packages on the command line <>`__

ConfigParser shootout begins

As mentioned in the `last summary`_, a desire for a replacement for 
ConfigParser has come into being.  It seems the ideas are being hashed out in 
the wiki at http://www.python.org/moin/ConfigParserShootout .

Contributing threads:
  - `ConfigParser shootout, preliminary entry <>`__
  - `What are the goals for ConfigParser 3000? <>`__

Making pymalloc friendlier to long running processes

Pymalloc, when a small chunk of memory is requested that is less than 256 
bytes, fetches the memory from a pool of previously used memory that is now 
available.  While this speeds up memory allocation since it does not directly 
involve calling the OS to free up the memory, it does cause issues for long 
running processes that have at some point requested a large portion of memory. 
 The example in the OP for this whole topic was an app that needs 1GB for 
about five minutes, but the amount of allocated memory stays at 1 GB since 
pymalloc does not free it to the OS.

This was brought up back in June and is summarized at 
http://www.python.org/dev/summary/2004-06-01_2004-06-15.html#id17 .

No code has been checked in at the moment to change the behavior partially 
thanks to the difficulty of the problem.

Contributing threads:
  - `Changing pymalloc behaviour for long running processes <>`__
  - `Re: Python-Dev Digest, Vol 15, Issue 46 <>`__

How to get a patch looked at

Often times people have a specific patch that they want reviewed/applied to 
solve a specific problem they are having.  Unfortunately the Python developers 
have limited time; we just can't get to every patch there in a timely fashion. 
 This can be a problem who *really* need to get a patch in.

Enter Martin v. LÃwis and his deal to review a specific patch:
1. Review 10 other patches on SF
2. Send an email to python-dev listing the 10 patches that you reviewed and the 
one patch you want to be reviewed
3. Your specific patch gets reviewed by Martin

You can see the exact details of Martin's requirements at 
http://mail.python.org/pipermail/python-dev/2004-October/049495.html and can 
also read http://www.python.org/dev/dev_intro.html for ideas on what to do for 
reviewing.

Contributing threads:
  - `Patches <>`__
--
Discussion of including pysqlite in the stdlib
--
The idea of including pysqlite_ in the stdlib came up once again (not this is 
the wrapper for SQLite_ and not SQLite itself).  The arguments for including 
the module were the SQLite is most likely used more than Sleepycat and thus 
deserved a place in the stdlib if bsddb did.  It also goes along with Python's 
idea of "batteries included".

Arguments against started with the idea of sanctioning pysqlite over other 
SQLite wrappers did not seem proper.  People also thou

Re: [Python-Dev] python-dev Summary for 2004-10-16 through 2004-10-31 [draft]

[Nick Coghlan]

Brett C. wrote:
This also brought up the discussion of being able to specify a 'main' 
function to take the place of the good old ``if __name__ == "__main__"`` 
idiom.  Some liked the idea of allowing one to define a function named 
'main', others '__main__'.  But the discussion never went any farther.  
This will require a PEP to ever even be seriously considered.
There's a PEP already - PEP 299.
The PEP actually describes a reasonable approach, since code using the current 
idiom is unlikely to define a __main__() function. However, it seems more like a 
Py3K idea, since if it's only in 2.5 and later, we'd see code like this to 
support earlier 2.x versions:

==
def __main__(*args):
  ...
if __name__ == "__main__":
  import sys as _sys
  if _sys.version_info < (2, 5):
__main__(_sys.argv)
==
Or, instead (using only the current idiom):
==
def _main(*args):
  ...
if __name__ == "__main__":
  import sys as _sys
  _main(_sys.argv)
==
So, to my mind, the backwards compatibility issue completely defeats the PEP's 
goal of finding a cleaner idiom than the current one.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
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] Re: Supporting Third Party Modules (was The other Py2.4issue)

[Fredrik Lundh]

Martin v. Löwis wrote:

>> Third party modules would link against this DLL independent of which
>> python is being used.
>
> I believe this is not implementable: How can the DLL know which Python
> DLL to use?

the Python interpreter could initialize this DLL, using some suitable mechanism.

alternatively, it could figure out what EXE you used to start the program in the
first place, and figure out what Python DLL that EXE uses.  my ExeMaker tool
can do that, for example:

http://effbot.org/zone/exemaker.htm

(see the #!python.exe entry in the table)

 



___
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] Re: 2.4 news reaches interesting places

[Guido van Rossum]

> fwiw, IDG's Computer Sweden,  "sweden's leading IT-newspaper" has a
> surprisingly big Python article in their most recent issue:
> 
> PYTHON FEELS WELL
> Better performance biggest news in 2.4
> 
> and briefly interviews swedish zope-developer Johan Carlsson and Python-
> Ware co-founder Håkan Karlsson.

Maybe we've done this to ourselves then. I'm sure the interviewer
didn't know what was the biggest news until after Johan and Håkan told
him. And this despite all the functional improvements that are much
more interesting for most Python programmers: generator expressions,
decorators, a ton of new modules...

Ah, but several of those modules are rewrites in C of modules that
were previously written in Python. Maybe we really *should* stop
emphasizing speed so much to ourselves, and focus more on fixing bugs
and adding features instead of looking for speedup opportunities.

I think Python's message ought to be more something like "programming
for the rest of us -- a child can learn Python, but Python's no toy."

BTW I strongly disagree that making easy .EXE binaries available will
address this issue; while not bundled, there are plenty of solutions
for maning .EXEs for those who need them, and this is not something
that typically worries managers. But the perception of Python as
"slow" does worry managers.

(Wish I could add more to this thread but my family is calling...)

-- 
--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] The other Py2.4 issue

[Armin Rigo]

Hi Martin,

On Sat, Dec 11, 2004 at 12:45:01AM +0100, "Martin v. Löwis" wrote:
> The straight-forward answer is: Get VC7.1 (aka VS.NET 2003), and invoke
>
> python setup.py bdist_wininst
> 
> That's not too hard to do, I think.

Hum, this is getting into a Linux-vs-Windows argument.  I don't want to invest
time and money on Windows tools just to compile my extension module for
Windows users...


Armin
___
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] Re: Re: 2.4 news reaches interesting places

[Fredrik Lundh]

Guido van Rossum wrote:

> > fwiw, IDG's Computer Sweden,  "sweden's leading IT-newspaper" has a
> > surprisingly big Python article in their most recent issue:
> >
> > PYTHON FEELS WELL
> > Better performance biggest news in 2.4
> >

(hmm.  I seem to have accidentally deleted a line here...)

> > and briefly interviews swedish zope-developer Johan Carlsson and Python-
> > Ware co-founder Håkan Karlsson.
>
> Maybe we've done this to ourselves then. I'm sure the interviewer
> didn't know what was the biggest news until after Johan and Håkan told
> him. And this despite all the functional improvements that are much
> more interesting for most Python programmers: generator expressions,
> decorators, a ton of new modules...

I don't know Johan, but I'm pretty sure Håkan didn't talk about performance;
he's more interested in *development* speed... (and I don't think he's been
following 2.4 that closely).

Looking again, the article says:

"Among the news in 2.4 is better performance, especially for new
functions that were added in 2.3."

and then mentions integer/long integer unification and the decimal type as 
notable
additions, and continues "and so it continues, with a long list of improved 
details".
The article also points to www.python.org/2.4, where the first link is:

http://www.python.org/2.4/highlights.html

which says:

Here are the (subjective) highlights of what's new in Python 2.4.

* Faster

A number of modules that were added in Python 2.3 (such as sets and heapq)
have been recoded in C.   In addition, there's been a number of other 
speedups
to the interpreter. (See section 8.1, Optimizations, of the "What's New" 
document
for more [this lists a couple of thousand tweaks by Raymond, and Armin's 
string
concatenation hack]).

* New language features

/.../ unification of integers and long integers /.../ decimal - a new 
numeric type
that allows for the accurate representation of floating point numbers /.../

so I don't think you can blame Johan or Håkan...  the writer simply read the
python.org material, and picked a couple of things that he found interesting
(decorators and generator expressions may be a big thing for an experienced
pythoneer, but they are probably a bit too obscure for a general audience...)

> Ah, but several of those modules are rewrites in C of modules that
> were previously written in Python. Maybe we really *should* stop
> emphasizing speed so much to ourselves, and focus more on fixing bugs
> and adding features instead of looking for speedup opportunities.

yes please.

> (Wish I could add more to this thread but my family is calling...)

same here.  more later.

 



___
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