Re: [Python-Dev] MinGW And The other Py2.4 issue
On Sun, 12 Dec 2004 23:19:55 +, A.B., Khalid <[EMAIL PROTECTED]> wrote: > [2] Can someone who has the official Python 2.4 download the sample > extension [**] created using the pyMinGW patched & MinGW compiled Python 2.4 > and SWIG? And see if it works? > Sources are in the zip file whose details appears bellow. 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 :-( My current technique for checking an extension is compatible with Python 2.4 is to run objdump -p (from the mingw distribution - use dumpbin /imports from MSVC) and review the import table. If any symbols are referenced from msvcrt.dll, you need to convince yourself that they are used solely by the mingw runtime startup code. For added certainty, add a dummy function to your C code which references these symbols, rebuild and confirm that they are now satisfied from msvcr71. (For total guarantees, you need to get Martin to validate your analysis, as he seems to be the only person here who *really* understands the potential issues :-)) If you want to build extensions compatible with the standard Python 2.4 build, you need to add the -lmsvcr71 flag to the build (link step). Hope this helps, Paul. ___ 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] Deprecated xmllib module
Martin v. Löwis wrote: As for PEP 4: I don't know whether it needs to be listed there. It appears that the PEP is largely unmaintained (I, personally, do not really maintain it). So one option would be to just stop using PEP 4 for recording deprecations, since we now have the warnings module. If we want to keep PEP 4, we need to follow the procedures it requires (or modify them if we don't like them). There is a need for a central place where deprecations are posted. You can't tell people to go hunt the standard lib for uses of the warning module in order for them to catch up with the current state of affairs. One thing that we shouldn't forget is that Python users do not necessarily upgrade to new Python releases every time there's a new release. Production users of Python will often skip a release or two depending on their needs, time frames and audit cycles. It is very important for them to know that module or other technology will be deprecated two releases down the road, so that they can accomodate for these changes today. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2004) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2004-12-06: Released eGenix mx Extensions for Python 2.4 ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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: Re: 2.4 news reaches interesting places
On Mon, 13 Dec 2004, Carlos Ribeiro wrote: > On Sun, 12 Dec 2004 20:36:45 -0500, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > Actually, there's another problem in the corporate world that has > > nothing to do with Python's performance (at least not directly). When a > > manager has to hire 25 programmers for a project they think to > > themselves, "well, Java programmers are a dime a dozen so I'll have no > > problem finding warm bodies if we write it in Java. Can I even /find/ > > 25 Python programmers?" > > You're right, specially for big corporations. But in the end, we're > just running in circles: it's hard to get new programmers to learn > Python, partly because it's in low demand, and partly because the > language has an totally undeserved fame of being slow. The perception-of-speed issue is clearly important but we're definately not running in circles. There are quite a few signs that the Python user base is expanding substantially. 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." http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature Also, there are companies that have hundreds of Python programmers, like some of those that have done success stories: http://www.pythonology.org/success That doesn't mean the perception that you can't hire 25 at once isn't a problem, but clearly some companies know that turning someone into a Python programmer is easy enough to offset the smaller available pool. To counter speed claims, look at articles like this one: http://www.pythonology.org/success&story=suzanne "Python helps AFNIC manage over 10,000 internet domain name registration requests per minute in a landrush for the ".fr" top-level internet domain" Yes it would be nice to have more of these, where performance is mentioned in the summary! Please contact me if you can contribute one. BTW, I can't resist my own favorite speed anecdote: I once wrote a one-off script to process down a couple of gigabytes of variously fragmented web logs into month-by-month files. I thought I was being naive doing f.readline() in a for loop with some date parsing code for each entry. But I was completely astounded how fast it processed -- and it just worked the first time around. - Stephan ___ 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] MinGW And The other Py2.4 issue
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] 7014 70b0 7420 7158 DLL Name: KERNEL32.dll vma: Hint/Ord Member-Name Bound-To 72fc0 AddAtomA 7308 147 FindAtomA 7314 191 GetAtomNameA 7028 70c4 7468 716c 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 703c 7104 7478 71ac DLL Name: msvcrt.dll vma: Hint/Ord Member-Name Bound-To 73bc 510 abort 7050 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 SETUPPY192 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/ ___ 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: Re: 2.4 news reaches interesting places
On Mon, 13 Dec 2004 11:30:45 -0500 (EST), Stephan Deibel <[EMAIL PROTECTED]> wrote: > 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." > > http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature Can we extrapolate from the numbers here to get an estimate of how many Python developers there are? I was asked for that number at workshop a few months ago and I didn't have any idea how to answer. Is there a good answer? Two possibilities come to mind. 1) 14% of developers in the survey work at companies that use Python. How many developers are there? Assume that 14% of them use Python. But what's a good estimate for "number of developers." Pretty rough -- number of survey respondents at company != number of Python programmers at company, and %age companies != %age of programmers. 2) 64% of companies use Java, 4.5 times more than Python. Find out how many Java programmers there are, divide by 4.5. Jeremy ___ 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: Re: 2.4 news reaches interesting places
Title: RE: [Python-Dev] Re: Re: 2.4 news reaches interesting places [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 ___ 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: Re: 2.4 news reaches interesting places
On Mon, 13 Dec 2004, Batista, Facundo wrote: > [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? Not very good, I think. I suspect the vast majority of programmers have never heard of source forge. I'm actually surprised that it's only 4.7% on source forge -- that seems to indicate Python is doing quite a bit better in the non-open source world than on SF. Interesting... wouldn't be surprised if this is because the speed myth has stronger hold among hacker types than business programmer types. If people feel this is getting off-topic for python-dev, there is also the mostly dormant marketing-python list: http://wingware.com/mailman/listinfo/marketing-python (the trolls have been removed) - Stephan ___ 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
Raymond Hettinger wrote: I felt the same way when reading it. Also, it seemed to embody the political outlook that optimization is sinful. The document could be much more positive, fact based, and informative. Also, the wording seems somewhat outdated. A draft for a new entry is included below. Review and feedback are requested. I would add a reference to __slots__, particularly for wrappers of objects. Regards, Nicolas ___ 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: Re: 2.4 news reaches interesting places
On Mon, 13 Dec 2004 13:11:38 -0500 (EST), Stephan Deibel <[EMAIL PROTECTED]> wrote: > On Mon, 13 Dec 2004, Jeremy Hylton wrote: > > Two possibilities come to mind. 1) 14% of developers in the survey > > work at companies that use Python. How many developers are there? > > Assume that 14% of them use Python. But what's a good estimate for > > "number of developers." Pretty rough -- number of survey respondents > > at company != number of Python programmers at company, and %age > > companies != %age of programmers. > > Supposedly there are 5-6 million developers world-wide (by various > estimates; I've no idea whether to believe them). If you just multiply > out naively you get 700K-840K Python programmers. There certainly are > vastly more one person Python projects than large ones, so this may not be > all that far off. > > > 2) 64% of companies use Java, 4.5 > > times more than Python. Find out how many Java programmers there are, > > divide by 4.5. > > I've seen claims of 3-4 million java programmers so that's 666K-888K > Python programmers. Interestingly, this matches up with the above abuse > of statistics. Thanks! I didn't know the numbers from which to guestimate, and it's nice that they are in agreement. This seems like a satisfactory back-of-the-envelope answer. Jeremy ___ 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: Re: 2.4 news reaches interesting places
On Mon, 13 Dec 2004, Jeremy Hylton wrote: > > http://www.infoworld.com/article/04/09/24/39FErrdev_1.html?s=feature > > Can we extrapolate from the numbers here to get an estimate of how > many Python developers there are? I was asked for that number at > workshop a few months ago and I didn't have any idea how to answer. > Is there a good answer? > > Two possibilities come to mind. 1) 14% of developers in the survey > work at companies that use Python. How many developers are there? > Assume that 14% of them use Python. But what's a good estimate for > "number of developers." Pretty rough -- number of survey respondents > at company != number of Python programmers at company, and %age > companies != %age of programmers. Supposedly there are 5-6 million developers world-wide (by various estimates; I've no idea whether to believe them). If you just multiply out naively you get 700K-840K Python programmers. There certainly are vastly more one person Python projects than large ones, so this may not be all that far off. > 2) 64% of companies use Java, 4.5 > times more than Python. Find out how many Java programmers there are, > divide by 4.5. I've seen claims of 3-4 million java programmers so that's 666K-888K Python programmers. Interestingly, this matches up with the above abuse of statistics. Independently by various other techniques of wildly guesstimating over the years, I've come to a current figure of about 350K serious Python projects world-wide. Many are single-person projects so this does mesh w/in an order of magnitude with the above. - Stephan ___ 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] MinGW And The other Py2.4 issue
Thomas Heller wrote: And recently I played with bindings to OpenGL's glut32.dll - glut calls exit() from internal C code. If linked with the wrong CRT, this will do nothing instead of terminating the process. Interesting. Looking at the code of exit(), it is clear that the wrong atexit handlers will be called if you use the wrong CRT (i.e. only one set of atexit handlers will be called, whereas you might have multiple lists of atexit handlers); see atonexit.c. It is not so clear why you could possibly get out of exit() without actually exiting. The only possible code path I see in the msvcr71.dll is when mscoree.dll is in the address space, in which case the CRT will invoke CorExitProcess (!). In all other cases, it will invoke ExitProcess, which, to my understanding, will terminate the process unconditionally. 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
[Python-Dev] Re: The Other Py2.4 issue?
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? ___ 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] MinGW And The other Py2.4 issue
On Mon, 13 Dec 2004 23:17:51 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > I forgot the details of your analysis, but I think you are right. > However, I would feel more comfortable if only a single CRT was used > from an extension module. Agreed. But to some extent I'm equally uncomfortable with the idea that the mingw developers added support for -lmsvcr71 and botched it badly enough for things like this not to work :-) > As for creating a case that crashes if you mix CRTs: Just try > PyRun_SimpleFile in the extension, with a file that you fopen'ed > in the extension. Satisfy this fopen from, say, msvcrt.dll, and > load the extension into Python 2.4. Sorry, I wasn't specific enough. Certainly, if you create a FILE* from one CRT, then pass it to another CRT, this will fail. But my point is, if your extension uses fopen() then the link command generated by distutils will ensure that the symbol is satisfied from msvcr71.dll. So your scenario cannot occur. The only symbols which can be satisfied from msvcrt in a mingw-compiled extension (assuming that distutils is used, or the -lmsvcr71 flag is otherwise added) are those referenced in the mingw startup code, but not in user code. As the startup code will never reference Python APIs, CRT data should never be shared between incompatible CRTs. Your point about atexit (from another email) may be an issue. However, again we have the fact that user C code is *always* satisfied from msvcr71, so any exit handlers added in C or Python will be registered with the msvcr71 CRT, and so, as the main python.exe uses msvcr71, will be executed. I don't see any signs that the mingw runtime for a DLL uses atexit (this by experiment, I haven't time at the moment to review the mingw sources) and so I don't believe that the startup code has issues here, either. 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. Paul. ___ 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] 2.4 news reaches interesting places
On Tue, 14 Dec 2004 01:05:09 -0200, Rodrigo Dias Arruda Senra <[EMAIL PROTECTED]> wrote: > But, but to the joke: I believe Python must strive to run at least as fast as > the crowd -- > Java, Perl, Ruby, Lua, Boo, etc > > Maybe we could visit the language shootout sites, translate Python snipets to > modern > 2.4 idioms and rerun the test suites: Bill Janssen <[EMAIL PROTECTED]> wrote: > In the last couple of months, an acquaintance of mine has been trying > out Python. He likes the language, particularly the support for > character sets, but has (apparently) given up after benchmarking a > typical (for him) task against Perl. The task is to use the "re" > package to heavily modify a file by a sequence of re substitutions. That might be a good idiom to review/translate/test. It's not a particularly natural thing to do in Python (REs are used much less in Python), but it's *very* natural in Perl, and a naive Perl->Python translation will make Python look slower. So a case study showing how you might "really" do a task like this in Python would be a useful resource. Also, it might point to somewhere where there are opportunities for optimisation within Python (for some reason this reminds me of the mutable byte buffer discussions from a while back). Paul ___ 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] 2.4 news reaches interesting places
[ Guido van Rossum <[EMAIL PROTECTED]> ]
---
| 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.
That reminds me of this joke:
"""Couple of guys find themselves being chased by a lion. The first one
starts to strecth out preparing to run, the second one finds that ridicule.
- No way you'll run faster than that lion. While, the other replies:
- I don't need to run faster than the lion, I just need to run faster than you.
"""
I love to see Python getting faster and faster. Eventually (if...when PyPy
succedes)
faster-than-C ! But after over 4 years of making-ends-meet with Python, our
Brazilian
customers never complained of our Python solutions being slow. Perhaps because
they were glad enough with projects delivered 5 to 10 times faster than usual.
But, but to the joke: I believe Python must strive to run at least as fast as
the crowd --
Java, Perl, Ruby, Lua, Boo, etc
Maybe we could visit the language shootout sites, translate Python snipets to
modern 2.4
idioms and rerun the test suites:
http://www.bagley.org/~doug/shootout/ # classic
http://shootout.alioth.debian.org/# modern
My 2 cents.
best regards,
Senra
--
,_
| ) Rodrigo Senra
|(__ ---
_((|__|] GPr Sistemas http://www.gpr.com.br
_ |(|___|] IC - Unicamp http://www.ic.unicamp.br/~921234
___(|__|]
L___(|_|]---
___
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: Re: 2.4 news reaches interesting places
On Sun, Dec 12, 2004 at 03:32:03PM -0200, Carlos Ribeiro wrote: > 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. No one disagrees that Python needs better marketing material. At the last PyCon a group of people sat down in a pydotorg BoF and agreed that yes, we do need a management-friendly marketing site, and that we could put it on a separate hostname (something.python.org) so that the current www.python.org wouldn't have to be changed. However, no one has actually sat down and written such a site, or even outlined it. Let me encourage you to go ahead and do that. You could draft the outline on a Wiki page, and then later figure out an attractive design and organization for a new site. --amk ___ 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] MinGW And The other Py2.4 issue
Paul Moore <[EMAIL PROTECTED]> writes: > 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. There have been problems with the bdist_wininst exe-stub linking to the wrong CRT dll, but I don't remember the exact details. And recently I played with bindings to OpenGL's glut32.dll - glut calls exit() from internal C code. If linked with the wrong CRT, this will do nothing instead of terminating the process. Thomas ___ 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] Rewriting PEP4
Barry Warsaw wrote: On Mon, 2004-12-06 at 16:28, "Martin v. Löwis" wrote: Martin, +1 on everything you wrote, with one minor quibble. Removal === If the module has been deprecated for atleast a year and atleast a version, it can be removed. Removal should move it to old-libs for pure Python modules; a removal procedure for pure C modules has not been defined yet. I wonder if the one year/one version rule is too short. Given that new versions come about every 18 months, I'd probably give it a 2 year/one version limit. +1 I'd make that 2 years / 2 versions, though. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Dec 13 2004) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2004-12-06: Released eGenix mx Extensions for Python 2.4 ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] MinGW And The other Py2.4 issue
On Mon, 13 Dec 2004 16:43:18 +, A.B., Khalid <[EMAIL PROTECTED]> wrote: > So what see ye? :) Does it look good? Looks good to me. The one remaining link to msvcrt, abort, is likely to be due to the startup code using it, and your code not referencing that symbol, so that it doesn't force linking from msvcr71. To check this, you could add a dummy call to abort() somewhere in your code and this last reference should vanish. So this now looks just like an extension built using --compiler=mingw32 with the standard Python 2.4 build, which I guess means that your build can create extensions that are interoperable with both itself and the standard Python 2.4. Paul. ___ 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
Stephan Deibel wrote: > BTW, I can't resist my own favorite speed anecdote: I once wrote a > one-off script to process down a couple of gigabytes of variously > fragmented web logs into month-by-month files. I thought I was being > naive doing f.readline() in a for loop with some date parsing code for > each entry. But I was completely astounded how fast it processed -- and > it just worked the first time around. I was doing the same thing today (well, processing system logs, not web logs) and was completely baffled when I found that a program that just worked the first time around on our development machine, crashed with a MemoryError on the production machine. oh well. ___ 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: Re: 2.4 news reaches interesting places
On Mon, 13 Dec 2004 12:57:07 PST, Bill Janssen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] }
{ http://www.vlo.ids.gda.pl/ | imbaczek at poczta fm | http://www.promode.org }
.. .. .. .. ... ... .. evolve or face extinction .. ... ... .. .. .. ..
___
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] 2.4 news reaches interesting places
On Wed, Dec 08, 2004 at 02:18:48PM -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 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 to fight -- any ideas?
All high level dynamic languages need to fight this. Substitute
python for perl, php, ruby, tcl and the statements in that article
still apply. They'll all have slower execution times (on avg) their
compiled or JITed bretheren.
I suggest reading that article in a different light: The point of
view of the people who are likely to believe what they read in
government computer news is that it just confirmed that python is a
useful languange for getting the job done easily. Not that one
shouldn't use it because "its slow."
--
All new Python 2.4, now with blue crystals!
___
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: Re: 2.4 news reaches interesting places
> That's right - > when I talk to fellow programmers that I'm writing software in Python, > many of them are amazed and ask me, "but isn't it slow?". I've heard > it more than once... I heard it last month. In the last couple of months, an acquaintance of mine has been trying out Python. He likes the language, particularly the support for character sets, but has (apparently) given up after benchmarking a typical (for him) task against Perl. The task is to use the "re" package to heavily modify a file by a sequence of re substitutions. 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. Bill ___ 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] MinGW And The other Py2.4 issue
Paul Moore wrote: My current technique for checking an extension is compatible with Python 2.4 is to run objdump -p (from the mingw distribution - use dumpbin /imports from MSVC) and review the import table. If any symbols are referenced from msvcrt.dll, you need to convince yourself that they are used solely by the mingw runtime startup code. I forgot the details of your analysis, but I think you are right. However, I would feel more comfortable if only a single CRT was used from an extension module. As for creating a case that crashes if you mix CRTs: Just try PyRun_SimpleFile in the extension, with a file that you fopen'ed in the extension. Satisfy this fopen from, say, msvcrt.dll, and load the extension into Python 2.4. 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
