Re: [Python-Dev] RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11
[Raymond, says test_glob and test_urllib fail on WinME now] [Andrew MacIntyre] >> I don't see any possible way for those checkins to affect any platform >> other than OS/2. >> >> 2 of the files are platform specific files (PC/os2emx/getpath.c, >> PC/os2vacpp/getpath.c), and the checkin to Modules/posixmodule.c is >> contained within a platform specific #if/#endif: [Brett] > Perhaps, but if you look at line 3299 you will notice that a comment is > started > but not closed off before the next comment on line 3304. How is that comment > supposed to be closed off? That's obviously a bug, and was introduced by the patch. Andrew wanted /* setup the pipe */ not /* setup the pipe But we don't get there unless PYOS_OS2 and PYCC_VACPP are defined, so that can't explain Raymond's problem. FWIW, the tests at issue pass on WinXP for me today w/ current CVS. ___ 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 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?
I think that right now there is a promising ongoing happening that
may be useful for this PR problem and Python perception in general,
which is the Chandler project, because it's a piece of software that may
end up in front of lot of people. It is both an opportunity and a risk.
A not great success of Chandler especially if imputed to Python
shortcomings would be bad.
I think that people with long-time Python experience that feel like to
contribute should try.
A successful, responsive Chandler, I think, would be a good thing for
Python.
___
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: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11
On Sat, 18 Dec 2004, Tim Peters wrote: > [Raymond, says test_glob and test_urllib fail on WinME now] > > [Andrew MacIntyre] > >> I don't see any possible way for those checkins to affect any platform > >> other than OS/2. > >> > >> 2 of the files are platform specific files (PC/os2emx/getpath.c, > >> PC/os2vacpp/getpath.c), and the checkin to Modules/posixmodule.c is > >> contained within a platform specific #if/#endif: > > [Brett] > > Perhaps, but if you look at line 3299 you will notice that a comment is > > started > > but not closed off before the next comment on line 3304. How is that > > comment > > supposed to be closed off? > > That's obviously a bug, and was introduced by the patch. Andrew wanted > > /* setup the pipe */ > > not > > /* setup the pipe Fair cop guv. Long exposure to a language with comments of the latter form has been a PITA at times. :-( > But we don't get there unless PYOS_OS2 and PYCC_VACPP are defined, so > that can't explain Raymond's problem. > > FWIW, the tests at issue pass on WinXP for me today w/ current CVS. Good, though Raymond's report appeared to be focussed on the 2.3 branch. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ 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: [Python-checkins] python/dist/src/Modulesposixmodule.c, 2.300.8.10, 2.300.8.11
> > FWIW, the tests at issue pass on WinXP for me today w/ current CVS. Tests pass here too. Raymond ___ 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: 2.4 news reaches interesting places
On Fri, 17 Dec 2004 09:20:18 -0200, Carlos Ribeiro <[EMAIL PROTECTED]> wrote: > One possible marketing strategy is to use the adjective "fast" in a > broader sense. The Python slogan could be something like: "Programming > has never been any faster" -- this changes the playing ground, from > raw performance to *programming* performance. And sure, nothing beats > Python (the overall package) in this respect. It can deliver fast code > in a short time. Othere languages are faster to run, but take longer > to code... Parabens, Carlos, boa ideia! Carlos has said it well, Python has the edge in overall performance. Evidence seems to indicate a 3-4 times edge over development in Java, and this is a powerful argument. cheers, -- Stewart Midwinter [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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 Wed, 15 Dec 2004 22:57:00 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote: > Paul Moore wrote: > > For a starter, what steps do you actually take to build a release? I > > assume that the first step is to build Python, by clicking on "build" > > in VS.NET. > > Yes. You can skip this step by just putting all the .pyds, dlls, and > .exes into the PCbuild directory. The packaging will try to pick them > up from there (and proceed if some are missing, like Tcl likely will). > > > Once you have that, is there a single script you run? > > Yes. Invoke Tools\msi\msi.py, using a Python that has pythonwin (i.e. > COM interopability). The only tricky part is that you need cabarc.exe, > which is included in VC, and in the platform SDK. OK, I've got a copy of the Python sources, and had a look. The change needed to msi.py to include libpythonXX.a in the installer looks simple. But I'm less sure as to where to build the file. It seems to me that msi.py is not the right place - that's focused on building the installer, not building the files to be installed. On the other hand, including it in the build process is a nuisance, as well, as it would add a dependency on mingw (or cygwin) to the MSVC build process. My feeling is that building libpythonXX.a should be a separate step, handled by a dedicated script, which gets run before msi.py. What do others (particularly Martin) think? Should I keep the steps separate, and focused on one task each, or should I incorporate the build of libpythonXX.a into msi.py, so that the installer build still requires just one step? 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] mmap feature or bug?
Quick questions: Is mmap's inability to be subclassed a feature or bug? Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and others) a feature or bug? I would imagine they are bugs, but I just wanted to make sure and post the report/request in the proper location. Thank you, - Josiah ___ 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: OK, I've got a copy of the Python sources, and had a look. The change needed to msi.py to include libpythonXX.a in the installer looks simple. But I'm less sure as to where to build the file. It seems to me that msi.py is not the right place - that's focused on building the installer, not building the files to be installed. Don't worry about this: there is already quite some building going on in msi.py. If you look at the CVS copy of Tools/msi, you find that it now has a nmake makefile to build msisupport.dll, which replaces the VB scripts. It also extracts msvcr71.dll from the merge module (.msm) each time it is invoked. So having yet another build process would be just fine; adding it to the makefile would have the added advantage that nmake will compare time stamps for us (if it is easier to do in Python than in nmake, that would be a reason not to use nmake, though). On the other hand, including it in the build process is a nuisance, as well, as it would add a dependency on mingw (or cygwin) to the MSVC build process. That is definitely undesirable. Lots of people build Python using the project files, and only few need the packaging to work. My feeling is that building libpythonXX.a should be a separate step, handled by a dedicated script, which gets run before msi.py. Making it separate is fine, as long as msi.py invokes/calls it. What do others (particularly Martin) think? Should I keep the steps separate, and focused on one task each, or should I incorporate the build of libpythonXX.a into msi.py, so that the installer build still requires just one step? Having the entire process involve as few manual steps as possible is definitely an important goal. Keeping it modular (in terms of splitting it into several files) is also a good idea, and one which does not conflict at all with the "fully automatic" goal. msi.py supports a config.py which allows to add customization. Putting cygwin_dir = r"C:\cygwin" into msi.py might be appropriate, with an option to set cygwin_dir to None, to indicate that cygwin should not be used in the build process. (similar to the way have_tcl already works). 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
Re: [Python-Dev] mmap feature or bug?
Josiah Carlson wrote: Is mmap's inability to be subclassed a feature or bug? No. It's a missing feature: it's not a bug, because nobody says this should work, and anybody trying will find out that it doesn't work, so nobody is tricked into believing it should work. The mmap type is not even documented; mmap.mmap is a function. It's not a feature, because (atleast IMO) there would be nothing wrong with making mmap.mmap a subclassable type. Is one's inability to use a = mmapinstance.__setslice__;a(1,2,'a') (and others) a feature or bug? That is a bug. Slice assignments are supported, and so should __setslice__. 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
