Mailman 3 December 2004 - Python-Dev

RE: [Python-Dev] MinGW And The other Py2.4 issue
by Delaney, Timothy C (Timothy) 14 Dec '04

14 Dec '04

"Martin v. Löwis" wrote: > Not at all. I'm talking about the release process, and prerequisites > required in that process. This is worth mentioning because the list > of prerequisites you need to perform a Python release is already quite > long: Ah - sorry - misinterpreted. What is the size of the generated libpython24.a? Unfortunately, I don't happen to have binutils installed in my work cygwin (pulling it down now, but it's very slow ...) so I can't check myself (I've built the 2.3 one at home before ...). Tim Delaney

1 0

RE: [Python-Dev] MinGW And The other Py2.4 issue
by Delaney, Timothy C (Timothy) 14 Dec '04

14 Dec '04

"Martin v. Löwis" wrote: > Paul Moore wrote: >> Thanks for your comments. Your support for the viability of building >> extensions using mingw is important to me, so if you still have any >> concerns, let me know and I will do my best to address them. > > I understand that one still needs to build libpython24.a in order to > use this process. As I have said, I'd happily ship that file with the > 2.4.1 MSI, unless the release manager tells me that this would an > unacceptable new feature, and as long as somebody provides a fully > automatic build process integrated into msi.py; for that build > process, > it is ok to assume that a cygwin installation is in c:\cygwin. I think we should aim to support MSYS as well as Cygwin, but perhaps not for the first version where this goes in. OTOH, is it really necessary to have either MSYS or Cygwin? MinGW32 works standalone - distutils should be able to just invoke it. Tim Delaney

2 1

httplib timeout patch
by ZhangYue张岳 14 Dec '04

14 Dec '04

Hi, Here is a patch for httplib. I added a timeout value for httplib.HTTPConnection, please check. (diff - CVS 1.94) Zhang Yue 2004-12-14 Index: httplib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/httplib.py,v retrieving revision 1.94 diff -r1.94 httplib.py 575c575 < def __init__(self, host, port=None, strict=None): --- > def __init__(self, host, port=None, strict=None, timeout=None): 580a581 > self.timeout = timeout 613a615,616 > if self.timeout: > self.sock.settimeout(self.timeout)

3 2

Re: The Other Py2.4 issue?
by Adam Bark 13 Dec '04

13 Dec '04

Even though there would be no significant speed-up I would still be interested in a proper compiler just to make smaller exe's so I can give out my programs. I used Py2EXE for my last program that was tiny but with Tkinter and all the Tcl/Tk gubbins it was over 5Mb. Also would it perhaps be possible to have some sort of psyco program that can optimize the compiled code on the fly?

1 0

Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places
by Marek "Baczek" Baczyński 13 Dec '04

13 Dec '04

On Mon, 13 Dec 2004 12:57:07 PST, Bill Janssen <janssen(a)parc.com> wrote: > Apparently the Python program, which applies the same re substitutions > in the same order as the Perl program, takes 3 times as long to run. > He thinks it's because of mutable strings in Perl -- that is, he > thinks the string being modified (which is long, a whole file full of > text) is modified in place in Perl, but has to be re-consed in Python. Did he use re.compile? -- { Marek Baczyński :: UIN 57114871 :: GG 161671 :: JID imbaczek(a)jabber.gda.pl } { http://www.vlo.ids.gda.pl/ | imbaczek at poczta fm | http://www.promode.org } .. .. .. .. ... ... ...... evolve or face extinction ...... ... ... .. .. .. ..

1 0

RE: [Python-Dev] Re: Re: 2.4 news reaches interesting places
by Batista, Facundo 13 Dec '04

13 Dec '04

[Stephan Deibel] #- For example, a September article in InfoWorld said "But the #- big winner #- this time around is the object-oriented scripting language #- Python, which #- saw a 6 percent gain in popularity, almost doubling last #- year's results." How big are the chances that SourceForge numbers actually could be extrapolated to the rest of the universe? According to them (check software map, and look by programming language), and showing everything with a "developers choice for their project" share >= 2%: C++ 18.5 C 18.1 Java 17.5 PHP 12.9 Perl 7.2 Python 4.7 Visual Basic 2.6 C# 2.6 JavaScript 2.6 Delphi/Kylix 2.1 Unix Shell 2.0 It also would nice to see a graph showing tendencies here. . Facundo

2 1

MinGW And The other Py2.4 issue
by A.B., Khalid 13 Dec '04

13 Dec '04

Paul Moore wrote: >I tried this out, and from some basic uses, it seems to work OK. >However, the PYD file references msvcrt.dll, which suggests that there >will be issues in more complex cases. The biggest problem with CRT >compatibility issues is that (AFAIK) no-one has actually been able to >trigger a *real* error, all of the problems are still theoretical. I >have done some fairly extensive analysis of what could go wrong, and I >suspect that there are very few genuine cases where data from one CRT >could end up being manipulated by another - but this doesn't mean that >the problems aren't real, just VERY hard to locate :-( First of all, thank you for your input. It is greatly appreciated. And yes if Martin, for whom I have much respect, can help here, then that would be awesome. Okay. This is partly my own fault. I am not using a standard MinGW distribution. This is why there is no release date in the sys.version information of the Python I compiled. I am using GCC RC 3.4.1 but the linking is still done by the 2002 MinGW 3.2, which is most probably hard- wired to use msvcrt.dll. Having said that, however, let me quickly add that it is almost a certainity that the newer standard MinGW distributions link with the latest libraries. Nevertheless, I updated pyMinGW's cygwinccompiler.py to always link in with libmsvcr71, and rebuit the sample pymingw extension[1]. Now according to objdump we get the following: [CUT] 00007014 000070b0 00000000 00000000 00007420 00007158 DLL Name: KERNEL32.dll vma: Hint/Ord Member-Name Bound-To 72fc 0 AddAtomA 7308 147 FindAtomA 7314 191 GetAtomNameA 00007028 000070c4 00000000 00000000 00007468 0000716c DLL Name: msvcr71.dll vma: Hint/Ord Member-Name Bound-To 7324 56 __dllonexit 7334 189 _errno 7340 610 ctime 7348 619 fflush 7354 630 fputs 735c 634 free 7364 642 fwrite 7370 685 malloc 737c 701 puts 7384 724 strcmp 7390 726 strcpy 739c 730 strlen 73a8 733 strncpy 73b4 748 time 0000703c 00007104 00000000 00000000 00007478 000071ac DLL Name: msvcrt.dll vma: Hint/Ord Member-Name Bound-To 73bc 510 abort 00007050 00000000 00000000 00000000 00000000 00000000 There is an export table in .edata at 0x6000 [CUT] So what see ye? :) Does it look good? Best wishes Khalid [1] pymingw-01.zip (5.37 KB): Location: http://jove.prohosting.com/iwave/misc/pymingw-01.zip MD5: 63b486093b344b0299538c952dea4ce1 -------------------------- Contents in KB: -------------------------- PYMINGW PY 1.115 13/12/04 16:12 pymingw.py PYMINGW I 278 13/12/04 1:00 pymingw.i EXAMPLE C 848 13/12/04 0:23 example.c SETUP PY 192 13/12/04 0:59 setup.py _PYMINGW PYD 9.216 13/12/04 16:12 _pymingw.pyd _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

2 1

Deprecated xmllib module
by Raymond Hettinger 13 Dec '04

13 Dec '04

Hmph. The xmllib module has been deprecated since Py2.0 but is not listed in PEP 4. Question: Do we have to keep it for another two years because of that omission? It seems somewhat silly to keep an obsolete, supplanted module that doesnt full support XML 1.0. Raymond

17 39

RE: [Python-Dev] Re: The Other Py2.4 issue?
by Delaney, Timothy C (Timothy) 12 Dec '04

12 Dec '04

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 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. Yes. And it would run at about the same speed as CPython. The only way to significantly improve this is to remove much of the dynamism of Python. As an example, I've been playing around with Raymond's constant binding - making it do more aggressive binding (I'll give an example later). By binding constants, I'm able to reduce the runtimes for psyco-compiled versions of friendly code (lots of things that can be converted into constant references) from around 2 seconds to less than 0.001 seconds. That's a very significant speedup. Unfortunately, it doesn't translate as well into real-world code - or even benchmarks (parrotbench for example gets a slight speedup but it's not overly significant). As a quick example if the changes I'm playing with, def func() docutils.parsers.rst.states.struct.__init__ Raymond's generates: JUMP_FORWARD 0 LOAD_CONST (docutils) LOAD_ATTR (parsers) LOAD_ATTR (rst) LOAD_ATTR (states) LOAD_ATTR (struct) LOAD_ATTR (__init__) Mine generates 0 JUMP_ABSOLUTE 15 3 NOP 4 NOP 5 NOP 6 NOP 7 NOP 8 NOP 9 NOP 10 NOP 11 NOP 12 NOP 13 NOP 14 NOP 15 LOAD_CONST (<unbound method Struct.__init__) I've also been doing some peephole optimisations - the above actually ends up being an immediate jump to the return bytecode, but that's fairly useless. Using JUMP_ABSOLUTE instead of JUMP_FORWARD simplifies doing this. Once I've got the code into a fit state I'll send it to you if you're interested Raymond ... Tim Delaney

1 0

Re: The Other Py2.4 issue?
by Adam Bark 12 Dec '04

12 Dec '04

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(a)python.org <python-dev-request(a)python.org> wrote: > Send Python-Dev mailing list submissions to > python-dev(a)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(a)python.org > > You can reach the person managing the list at > python-dev-owner(a)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(a)gmail.com> > To: Erik Heneryd <erik(a)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(a)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(a)gmail.com > mail: carribeiro(a)yahoo.com > > > > ---------- Forwarded message ---------- > From: Paul Moore <p.f.moore(a)gmail.com> > To: Christian Tismer <tismer(a)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(a)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(a)gmail.com> > To: "python-dev(a)python.org" <python-dev(a)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(a)gmail.com > mail: carribeiro(a)yahoo.com > > > > ---------- Forwarded message ---------- > From: Bob Ippolito <bob(a)redivi.com> > To: "Martin v. Löwis" <martin(a)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(a)gmail.com> > To: Martin v. Löwis <martin(a)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(a)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(a)gmail.com > mail: carribeiro(a)yahoo.com > > > > ---------- Forwarded message ---------- > From: "Fredrik Lundh" <fredrik(a)pythonware.com> > To: python-dev(a)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(a)v.loewis.de> > To: Carlos Ribeiro <carribeiro(a)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(a)v.loewis.de> > To: Bob Ippolito <bob(a)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(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > > >

1 0