E.g. if we need to compile libpython24.a it means we need to
fetch the Python sources themselves first.
Actually, no, you don't need the sources. See:
http://mail.python.org/pipermail/python-dev/2004-January/041676.html
for a script that builds libpython24.a from the python24.lib distributed
wit
Raymond Hettinger wrote:
guidelines for applications that demand peek performance (in terms of memory
Peak performance, perhaps? :) Anyway, it looks pretty good to me, but I have a
few additional ideas.
Add a section of Caveats (we know they exist - might as well be upfront
about it):
Caveats
--
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.
And configure says:
# Generated by GNU Autoconf 2.59
>Raymond:
>
>Acceptance for Py2.4 partially hinges on how quickly third party apps
>have their binaries updated.
>
>I wonder if there is anything we can do to help.
One good way of helping out is to provide an dynamic loading function
that third party modules could access the basic python functio
Hi folks. Is anyone interested in doing an article on Python decorators
for "Doctor Dobb's Journal"? If so, please drop me a line...
Thanks,
Greg
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Phillip J. Eby wrote:
The Python developers who produce the Windows binaries don't use
mingw/cygwin, so this would put a maintenance burden on them.
If this were completely automatic (e.g. part of msi.py), I'd happily
add all utilities needed to integrated this into the build process.
For this to
Armin Rigo wrote:
In other words, if you want 3rd parties to compile Windows binaries for 2.4,
tell them how.
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.
Regards,
Martin
___
> The Wiki entry seems to reinforce the impression that bugged Guido to
> begin with. It provides a bunch of "but ..." explanations about why
> Python's speed isn't that important. Python is slow, but "speed of
> development is far more important."
I felt the same way when reading it. Also, it
On Fri, 10 Dec 2004 20:40:10 +, Paul Moore <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Dec 2004 17:19:21 +, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > Another note: can you report on whether building libpython24.a can be
> > skipped
> > for mingw?
>
> A first attempt seems to almost work. Ther
On Fri, 10 Dec 2004 17:19:21 +, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Another note: can you report on whether building libpython24.a can be skipped
> for mingw?
A first attempt seems to almost work. There is a problem with
structures, however - I get an error about unresolved references to
_
On Fri, 10 Dec 2004 14:01:55 -0500, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 09, 2004 at 05:11:04PM +0300, Oleg Broytmann wrote:
> > some popular areas. Let's add another topic, "Making things fast". Let's
> > even make it the first topic, though I personnaly dont see a need for
> > t
On Fri, Dec 10, 2004 at 02:01:55PM -0500, A.M. Kuchling wrote:
> On Thu, Dec 09, 2004 at 05:11:04PM +0300, Oleg Broytmann wrote:
> > some popular areas. Let's add another topic, "Making things fast". Let's
> > even make it the first topic, though I personnaly dont see a need for
> > this.
>
> The
On Thu, Dec 09, 2004 at 05:11:04PM +0300, Oleg Broytmann wrote:
> some popular areas. Let's add another topic, "Making things fast". Let's
> even make it the first topic, though I personnaly dont see a need for
> this.
The topic guides are migrating into the Wiki, and there's already a Wiki page
a
At 01:12 PM 12/10/04 -0500, Bob Ippolito wrote:
On Dec 10, 2004, at 1:05 PM, Phillip J. Eby wrote:
At 05:19 PM 12/10/04 +, Armin Rigo wrote:
Another note: can you report on whether building libpython24.a can be
skipped
for mingw? I'm thinking about the specific situation where we want on-site
On Dec 10, 2004, at 1:05 PM, Phillip J. Eby wrote:
At 05:19 PM 12/10/04 +, Armin Rigo wrote:
Another note: can you report on whether building libpython24.a can be
skipped
for mingw? I'm thinking about the specific situation where we want
on-site
compilation of extension modules with a minima
At 05:19 PM 12/10/04 +, Armin Rigo wrote:
Another note: can you report on whether building libpython24.a can be skipped
for mingw? I'm thinking about the specific situation where we want on-site
compilation of extension modules with a minimal number of things to install
first. E.g. if we need
Hi,
On Fri, Dec 10, 2004 at 12:06:01PM +, Paul Moore wrote:
> For most C extensions, the best free option is mingw.
Sorry, I was not aware that mingw supports the new VC7.1-type of runtime that
is needed for the extension module to load with the official Python 2.4
distribution.
Note that
Hi Skip,
On Fri, Dec 10, 2004 at 04:49:30AM -0600, Skip Montanaro wrote:
>
> >> The other thing we can do is finish the portable backend for psyco
> >> and make it a standard module. Then Python won't be slow, it will be
> >> compiled, and py2exe will be able to make a single-file ex
At 10:06 AM 12/10/04 +, Armin Rigo wrote:
Hi,
On Wed, Dec 08, 2004 at 11:43:49PM -0500, Raymond Hettinger wrote:
> Acceptance for Py2.4 partially hinges on how quickly third party apps
> have their binaries updated.
>
> I wonder if there is anything we can do to help.
For people like myself, Li
Thomas> I haven't tried it, but using psyco in a script and building an
Thomas> exe from it with py2exe should work right out of the box - but
Thomas> maybe this isn't what you had in mind?
I was thinking of implicitly mixing in psyco, even if the script didn't use
it. Maybe I have t
On Fri, 10 Dec 2004 10:06:59 +, Armin Rigo <[EMAIL PROTECTED]> wrote:
> For people like myself, Linux programmers not developing on Windows every day,
> there is precious little information available about how to compile our
> extension modules for the new Windows distribution. I was actually
Keith Dart <[EMAIL PROTECTED]> writes:
> I did modify the readline module that hooks this and can call back
> to a Python function. There are also methods for installing and
> removing the Python function. I did this for a different reason. I
> need Python signal handlers to run, and they don't ru
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> I agree, although it's not clear to me how much faster it will be in
> the future. Making a *fast* Python based on our own virtual execution
> environment (as opposed to piggybacking a JVM or CLR) is a big
> project. It's not clear than anyone has enou
Skip Montanaro <[EMAIL PROTECTED]> writes:
> >> The other thing we can do is finish the portable backend for psyco
> >> and make it a standard module. Then Python won't be slow, it will be
> >> compiled, and py2exe will be able to make a single-file executable.
>
> Armin> You prob
>> The other thing we can do is finish the portable backend for psyco
>> and make it a standard module. Then Python won't be slow, it will be
>> compiled, and py2exe will be able to make a single-file executable.
Armin> You probably mean that Psyco can dynamically compile Python
Hi,
On Wed, Dec 08, 2004 at 11:43:49PM -0500, Raymond Hettinger wrote:
> Acceptance for Py2.4 partially hinges on how quickly third party apps
> have their binaries updated.
>
> I wonder if there is anything we can do to help.
For people like myself, Linux programmers not developing on Windows e
Hi Andrew,
On Thu, Dec 09, 2004 at 03:32:10PM +1300, Andrew McGregor wrote:
> The other thing we can do is finish the portable backend for psyco and
> make it a standard module. Then Python won't be slow, it will be
> compiled, and py2exe will be able to make a single-file executable.
You pr
27 matches
Mail list logo
