On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote:
> For those who believe that a non-profit project should not do any
> marketing, a reminder. If the perception about Python is one of a slow
> language, it's much more difficult to find places where you can use
> Python. In the long run, many of u
On Sun, 12 Dec 2004 20:36:45 -0500, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote:
>
> > For those who believe that a non-profit project should not do any
> > marketing, a reminder. If the perception about Python is one of a slow
> > language, it's muc
Adam Bark wrote:
> Now this might sound a bit stupid but I've only been programming in
> python for about 6 months and before that about the same on VB. Anyway
> here goes, as python is built in C & C++ surely every piece of python
> code has a corresponding piece of C/C++ albeit more complex. So
Martin v. Löwis wrote:
That's good to know, but somewhat unrelated to the issue under
discussion. While it is clear from your message that you can build
python, as well as python extensions with MingW, it is not that
clear whether extensions build with mingw will work in the standard
2.4 distributi
Now this might sound a bit stupid but I've only been programming in
python for about 6 months and before that about the same on VB. Anyway
here goes, as python is built in C & C++ surely every piece of python
code has a corresponding piece of C/C++ albeit more complex. So would
it be possible to so
At 11:07 PM 12/12/04 +0100, Martin v. Löwis wrote:
it is not that
clear whether extensions build with mingw will work in the standard
2.4 distribution, or whether you can use the standard 2.4 distribution
to build extensions with mingw.
I thought that it was clarified some time ago, with my success
A.B., Khalid wrote:
I am following this thread with interest too, because I can certainly
report that it is now indeed possible and quite easy to compile not only
Python's 2.4 extensions but also Python itself in MinGW with the help of
pyMinGW[1]. Indeed there is no need to buy or even download
Bob Ippolito wrote:
I was talking about PYTHON_API_VERSION, hence "forced" in quotes.
Nobody likes to see an ugly error message.
Ah, that... If PYTHON_API_VERSION changes, it is because there is
a real incompatibility, somewhere. It is not automatically bumped
with each release. So it is safe to
Bob Ippolito wrote:
Yes, of course, I was talking about the executable, not extensions. On
Mac OS X 10.3+, the linker flag -undefined dynamic_lookup allows
extensions to link to no Python whatsoever.
It's the same on SysV ELF shared libraries, and in most other unices.
The extensions will just
Nick Craig-Wood wrote:
I'm following this thread with interest because we are considering
embedding Python into this project, and I'm wondering whether we can
cross compile python using mingw (almost certainly by the sound of
it), but probably harder would be to make python module build and
install
On Dec 12, 2004, at 1:09 PM, Martin v. Löwis wrote:
Bob Ippolito wrote:
Yes, of course, I was talking about the executable, not extensions.
On Mac OS X 10.3+, the linker flag -undefined dynamic_lookup allows
extensions to link to no Python whatsoever.
It's the same on SysV ELF shared libraries,
On Sun, Dec 12, 2004 at 04:40:22PM +0100, "Martin v. L?wis" wrote:
> Armin Rigo wrote:
> >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...
>
> If you don't have Windows at a
Carlos Ribeiro wrote:
If none of your users volunteers to do the build for you, I would stop
worrying about the Windows users.
Sorry, Martin. I understand your point, but I think you are not being
realistic. I for myself took the decision to use only free tools for
my own development, but I still
> . Multiple assignment is slower than individual assignment. For
> example "x,y=a,b" is slower than "x=a; y=b". However, multiple
> assignment is faster for variable swaps. For example, "x,y=y,x" is
> faster than "t=x; x=y; y=t".
marginally faster in 2.4, a lot slower in earlier versions. may
On Sun, 12 Dec 2004 16:40:22 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> If none of your users volunteers to do the build for you, I would stop
> worrying about the Windows users.
Sorry, Martin. I understand your point, but I think you are not being
realistic. I for myself took the decisio
On Dec 12, 2004, at 11:02 AM, Martin v. Löwis wrote:
Bob Ippolito wrote:
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
fro
Hello all,
Just to complement my previous remarks, I would like to point out how
do a competing language defines itself in its own website. The
perl.org website has a simple faq that is a good piece of marketing.
What follows are direct quotes, just to point out how ot handle the
market perception
On Sat, 11 Dec 2004 19:57:55 +0100, Christian Tismer
<[EMAIL PROTECTED]> wrote:
> Armin Rigo wrote:
> > 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...
First of all
On Sun, 12 Dec 2004 17:10:58 +0100, Erik Heneryd <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh 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 b
On Sat, 11 Dec 2004 19:17:28 -0800, Brett C. <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > Anyway, all comments are appreciated (even a simple "Sounds good to me").
> >
>
> Sounds good to me. =)
And me :-)
+1
Paul.
___
Python-Dev mailing lis
Fredrik Lundh wrote:
the Python interpreter could initialize this DLL, using some suitable mechanism.
What suitable mechanism could that be? Suppose the Python script imports
foo.pyd, which in turn is linked with pythonany.dll, which in turn is
supposed to find the right Python DLL.
Now, python24.d
Fredrik Lundh 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
and briefly interviews swedish zope-developer Johan Carlsson and Python-
Ware co-found
Bob Ippolito wrote:
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.
While
Christian Tismer wrote:
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.
I don't think this needs to be too automated.
Offering this service is a good thing, and if somebody
volunteers, I
John J Lee wrote:
> the idea spreads that Python-built .exe's are so big because they're just
> an interpreter plus a script.
that's why exemaker is so great, of course: all EXE files are 4 kilobytes.
as for the PYC files, hide them in a ZIP archive named DAT, HLP, OCX,
or even DLL, and you're d
Armin Rigo wrote:
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...
If you don't have Windows at all, you cannot create Windows installers
for your users, anyway.
If you do have Win
On Wed, 8 Dec 2004, Phillip J. Eby wrote:
> At 02:18 PM 12/8/04 -0800, Guido van Rossum wrote:
> >I was pleasantly surprised to find a pointer to this article in a news
> >digest that the ACM emails me regularly (ACM TechNews).
> >
> >http://gcn.com/vol1_no1/daily-updates/28026-1.html
> >
> >One t
On Wed, 8 Dec 2004, Raymond Hettinger wrote:
> > 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. This is
> > a PR issue that Python needs
Phillip J. Eby wrote:
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 wor
29 matches
Mail list logo
