Re: The Other Py2.4 issue?
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 somehow make a program to convert the Python to C & C++ which can then be compiled with a C/C++ compiler. Adam On Sun, 12 Dec 2004 19:09:27 +0100 (CET), python-dev-request@python.org <python-dev-request@python.org> wrote:
Send Python-Dev mailing list submissions to python-dev@python.org
To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request@python.org
You can reach the person managing the list at python-dev-owner@python.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..."
Today's Topics:
1. Re: Re: Re: 2.4 news reaches interesting places (Carlos Ribeiro) 2. Re: The other Py2.4 issue (Paul Moore) 3. Re: Re: Re: 2.4 news reaches interesting places (Carlos Ribeiro) 4. Re: Supporting Third Party Modules (was The other Py2.4 issue) (Bob Ippolito) 5. Re: The other Py2.4 issue (Carlos Ribeiro) 6. Re: Re: 2.4 news reaches interesting places (Fredrik Lundh) 7. Re: The other Py2.4 issue (Martin v. L?wis) 8. Re: Supporting Third Party Modules (was The other Py2.4 issue) (Martin v. L?wis)
---------- Forwarded message ---------- From: Carlos Ribeiro <carribeiro@gmail.com> To: Erik Heneryd <erik@heneryd.com> Date: Sun, 12 Dec 2004 15:14:09 -0200 Subject: Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places On Sun, 12 Dec 2004 17:10:58 +0100, Erik Heneryd <erik@heneryd.com> 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 biggest news in 2.4
and briefly interviews swedish zope-developer Johan Carlsson and Python- Ware co-founder Håkan Karlsson.
...
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...)
I'm a bit puzzled by the last paragraph, where Python is grouped together with PHP and Perl - names starting with p, being popular on Linux and not having big, commercial backers. The article then concludes "Since Python is copyrighted, it's not truly open. However, it can be freely used and redistributed, even commercially."
Huh? Where did THAT come from? You might argue the merits of Python being associated with Perl/PHP, but it's a fact that it is. But when it is, it's seen as less free?
The author was probably referring to the old (and as AFAIK already solved) CRNI copyright issue that ocurred into the 1.x to 2.x series transition. It's amazing how old memes from Python keep being remembered and repeated, even years after the fact. It also illustrates something very important - the community is not doing a good job at spreading the news; perhaps we talk too much between ourselves, and too little with the outside market. IMHO the website is a great part of this, its message being more important to "sell" Python than the standard library or native .exes.
About the website, a note from my own experience: when I search for documentation on Python, I'm usually directed to some of the mirror of the main python.org site. To find it inside the main site, I have to use "site:python.org", or even "site:docs.python.org". Usually Google does a good job at ranking pages, and if it doesn't rank the main Python website very highly, it's because they're not being referred to. A campaign to ask people to put links back to the canonical documentation at the Python website would be nice.
-- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
---------- Forwarded message ---------- From: Paul Moore <p.f.moore@gmail.com> To: Christian Tismer <tismer@stackless.com> Date: Sun, 12 Dec 2004 17:26:49 +0000 Subject: Re: [Python-Dev] The other Py2.4 issue On Sat, 11 Dec 2004 19:57:55 +0100, Christian Tismer <tismer@stackless.com> 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, I'm assuming this is a timing issue. If I understood your initial posting, your concern was that people wanted Windows build of your extension *now*, and it was going to take you time to make it available.
That's a different issue from you not having the facilities to build the Windows installers at all, where you rely on 3rd parties making builds available.
As Martin points out, ultimately the provision of Windows binaries is an issue for the extension project - is the demand high enough to justify the effort, can you find tools and/or a helper, etc etc.
But the former issue (how quickly you can provide binaries, assuming that you will do so ultimately) is more relevant for python-dev. Specifically, because lack of binary extensions can be a barrier to take-up of the new version. Certainly, in the past, you could pretty much guarantee that there would be very few Windows users testing beta releases, because pywin32 binaries weren't available. With 2.4, I have at least one system I'd upgrade *now* but for the lack of a critical extension in binary form (I haven't yet had the time to try to adapt the build process to mingw for myself).
Maybe we can set this up as a service?
That sounds like a good idea. What I'd suggest is needed is a website where the following can take place:
1. People have a way of posting rquests for particular modules. 2. Installers can be uploaded to satisfy those requests. 3. There is somewhere to put step-by-step "build it yourself" instructions, using free components, so that people *without* access to VS.NET can make progress themselves. Obviously, if a particular extension can't be built with free compilers, then binaries or access to VS.NET are the only options.
The installers should be clearly noted as having no warranty or support implied, to encourage people to offer binaries they have built without feeling that they are taking on a support burden. Conversely, as soon as "official" binaries are available from the extension project, the binaries available here should be removed (and replaced with a link to the official site) to reinforce the "unofficial" nature of the binaries provided here.
The biggest potential issue with such a site is clearly validation. I've no idea how to make something like this work without it being a major virus risk. Which may, sadly, be enough to kill the idea :-(
Paul.
---------- Forwarded message ---------- From: Carlos Ribeiro <carribeiro@gmail.com> To: "python-dev@python.org" <python-dev@python.org> Date: Sun, 12 Dec 2004 15:32:03 -0200 Subject: Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places 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 about their quality & speed.
-- "Perl takes the best features from other languages, such as C, awk, sed, sh, and BASIC, among others."
(A claim can't possibly be any more generic than this. Strangely enough, it mentions only older languages -- not Java, C++, or even Python (!). This is possibly a sign of an old quote, but anyway: it has a good marketing effect, specially for non-techies.)
-- "Perl can be embedded into web servers to speed up processing by as much as 2000%."
(BTW, this quote is embarrassing misleading -- it probably means that Perl is 20x slower when started on a request basis by the web server, and that embedding it will accelerate response by a huge factor. I'm sure non-techies will read it as "Perl is able to accelerate my server 20x!")
Of course, the point here is not Perl-bashing. The point here is that we should be able to "sell" Python better than we do now, even without the need to resort to such poor measures. I'm sure the Python community does have good & creative people that can write a good "selling" FAQ for Python, emphasizing the main points of the language.
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 us may be forced to work with other languages & tools, just because that's where the money is. I personally take it a matter of personal interest, because I know how hard it is to "sell" Python to companies here in Brazil.
-- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
---------- Forwarded message ---------- From: Bob Ippolito <bob@redivi.com> To: "Martin v. Löwis" <martin@v.loewis.de> Date: Sun, 12 Dec 2004 12:46:18 -0500 Subject: Re: [Python-Dev] Supporting Third Party Modules (was The other Py2.4 issue)
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 from it dynamically, and then starts doing stuff.
While that would work, I think this is inappropriate for this specific issue: we want to write extension modules which are independent of the Python version, and might even be used with multiple Python installations on the same system. In that case, adding configuration files won't work, as each usage of the extension might require a different Python DLL.
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. The extensions will just find the symbols it needs from some other image already loaded into the process at runtime. If it weren't for the "forced" ABI incompatibility, we'd already have extensions that work cross-Python-major-version (assuming they used a safe subset of functions and structures).
-bob
---------- Forwarded message ---------- From: Carlos Ribeiro <carribeiro@gmail.com> To: Martin v. Löwis <martin@v.loewis.de> Date: Sun, 12 Dec 2004 15:53:10 -0200 Subject: Re: [Python-Dev] The other Py2.4 issue On Sun, 12 Dec 2004 16:40:22 +0100, Martin v. Löwis <martin@v.loewis.de> 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 have to suport my Windows customers. I can't force them to change to Linux. I don't own a copy of MSVC. Also, one of the reasons to choose a third part module is to save time. The moment I am required to recompile everything myself I'm losing this convenience. This of course impacts my ability to focus on my own work, and so the story goes.
I'm not saying that module authors should work for free just to save me some time & hassle. It's fair if an author decides to release a Linux-only module. But again -- this is not realistic. The world has a lot of Windows users, and I depend on them for my own income. If I can't find a good set of Python tools for my projects, what should I do? Picking another language is not a choice, mind you :-)
All in all, I sincerely hope that this discussion end up in a high note. I'm not qualified to talk about the particulars of C compilers & development environments, but as a Python user, I have hope that a good solution will be found to make the process of building Python extensions for Windows more convenient. The dream scenario is not to require recompiling, at least inside the same major release (2.4 to 2.5, for example). That would be really great.
-- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: carribeiro@gmail.com mail: carribeiro@yahoo.com
---------- Forwarded message ---------- From: "Fredrik Lundh" <fredrik@pythonware.com> To: python-dev@python.org Date: Sun, 12 Dec 2004 18:53:27 +0100 Subject: [Python-Dev] Re: Re: 2.4 news reaches interesting places
. 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. maybe you should mark sections that rely on 2.4-specific optimizations, so that people who use earlier versions don't end up slowing their programs down...
</F>
---------- Forwarded message ---------- From: "Martin v. Löwis" <martin@v.loewis.de> To: Carlos Ribeiro <carribeiro@gmail.com> Date: Sun, 12 Dec 2004 19:06:44 +0100 Subject: Re: [Python-Dev] The other Py2.4 issue 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 have to suport my Windows customers. I can't force them to change to Linux. I don't own a copy of MSVC. Also, one of the reasons to choose a third part module is to save time. The moment I am required to recompile everything myself I'm losing this convenience. This of course impacts my ability to focus on my own work, and so the story goes.
I did not suggest that *all* your Windows users should recompile your module - just a single one would be sufficient.
I'm not saying that module authors should work for free just to save me some time & hassle. It's fair if an author decides to release a Linux-only module. But again -- this is not realistic. The world has a lot of Windows users, and I depend on them for my own income. If I can't find a good set of Python tools for my projects, what should I do? Picking another language is not a choice, mind you :-)
As I said: Find a volunteer that has the necessary build infrastructure, and have that volunteer build the extension for you.
The dream scenario is not to require recompiling, at least inside the same major release (2.4 to 2.5, for example). That would be really great.
That is guaranteed. Extensions built for 2.4 will certainly continue to work in 2.4.1, and later 2.4.x. They will stop working with 2.5 (as they are linked with python24.dll).
Regards, Martin
---------- Forwarded message ---------- From: "Martin v. Löwis" <martin@v.loewis.de> To: Bob Ippolito <bob@redivi.com> Date: Sun, 12 Dec 2004 19:09:05 +0100 Subject: Re: [Python-Dev] Supporting Third Party Modules (was The other Py2.4 issue) 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 find the symbols it needs from some other image already loaded into the process at runtime. If it weren't for the "forced" ABI incompatibility, we'd already have extensions that work cross-Python-major-version (assuming they used a safe subset of functions and structures).
Are you talking about a forced ABI incompatibility, beyond the Windows issue of linking with a specific pythonxy.dll?
On Unix, you certainly can have extensions across Python major versions.
Regards, Martin
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
participants (1)
-
Adam Bark