Re: [Python-Dev] re: 2.4 news reaches interesting places
On Thu, 16 Dec 2004 06:13:41 -0700, Stewart Midwinter <[EMAIL PROTECTED]> wrote: > A number of people commented on the article in GCN, at > http://gcn.com/vol1_no1/daily-updates/28026-1.html, and wondered if > more could not be done to address the perception of speed. The point > is made that although people mention all of the benefits of Python, > like ease of use, flexibility, they always come back to making > references to its speed. And the question is raised, "what can we do > to counter this perception?". I think the answer lies in a quote by a > user in that same article: "At first, Doak was worried a Python-based > program would not run simulations quickly enough, however he found > performance to be acceptable. > > Let's turn this around. Forget about trying to create a perception > that Python is fast. Compiled languages will always be faster, at > least for large applications. Or at least they'll be perceived that > way. So let's acknowledge that upfront, but say "Python is fast > enough for most uses", but then go on to say "and in addition to its > acceptable speed, it offers many advantages like ease-of-use, > flexibility, easy code maintenance (since the code is still > understandable 6 months later!) etc. > > Marketers of other products have used this same technique > successfully. For example, at one time there was a perception that > Kellogg's Corn Flakes were old and boring. Sales were slipping. > Rather than refute that, marketers turned the issue on its head by > emphasizing that the product had been around a long time because it > was good, and good for you. Hence was born the slogan "taste them > again, for the first time". > > Possible slogan for Python: "Fast enough, and better in many ways". 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... BTW, I would move away from the "fast enough" when talking about performance. It's difficult to qualify what is "enough" in marketing terms; also, a selling/winning message can't be seen as taking excuses for any reason. On the other hand, Python never claims to be the fastest language on raw execution performance, but only to be fast; but in this sense, being "fast enough" is the same as being "fast". So, I would never say, "Python allows you to write fast enough code in a short time"; I would say "Python allows you to write fast code in a short time". Leave the "fast enough" out of this, please. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [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
[Python-Dev] RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11
The Dec 12th check-ins break tests on WinME:
test_glob.py
Traceback (most recent call last):
File "test_glob.py", line 78, in test_glob_one_directory
eq(self.glob('a*'), map(self.norm, ['a', 'aab', 'aaa']))
File "test_glob.py", line 67, in assertSequencesEqual_noorder
self.assertEqual(set(l1), set(l2))
AssertionError: set(['/[EMAIL PROTECTED]', '/[EMAIL PROTECTED]',
'/[EMAIL PROTECTED]
t_dir\\a']) != set(['[EMAIL PROTECTED]', '[EMAIL PROTECTED]',
'[EMAIL PROTECTED]
est_dir\\a'])
test_urllib.py
--
FAIL: test_basic (__main__.urlretrieve_FileTests)
--
Traceback (most recent call last):
File "test_urllib.py", line 142, in test_basic
self.assertEqual(result[0], test_support.TESTFN)
AssertionError: '[EMAIL PROTECTED]' != '/[EMAIL PROTECTED]'
Please fix,
Raymond
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:python-checkins-
> [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
> Sent: Sunday, December 12, 2004 3:37 AM
> To: [EMAIL PROTECTED]
> Subject: [Python-checkins] python/dist/src/Modules posixmodule.c,
> 2.300.8.10, 2.300.8.11
>
> Update of /cvsroot/python/python/dist/src/Modules
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12893
>
> Modified Files:
> Tag: release23-maint
> posixmodule.c
> Log Message:
> OS/2 specific fixes related to SF bug # 1003471.
>
> Also revise a related function to minimise file handle/pipe leakage
> and improve reliability.
>
> Backported from -HEAD.
___
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
Keith Dart <[EMAIL PROTECTED]> writes: > A.M. Kuchling wrote: >> 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. > > > Whatever it looks like, it should probably run on Zope plus Plone. 8-) > You know... eat your own dog food. 8-) This is SO not the problem that needs discussion... > The kind folks over at Zettai! have provided some space for > me. Perhaps they will be glad to host the main Python site, as well? Neither is this! Cheers, mwh -- Just point your web browser at http://www.python.org/search/ and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed.-- Tim Peters, on python-help, 16 Jun 1998 ___ 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
Carlos Riberio writes: > 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. I think Carlos is onto something here. Guido's original question was how to fight this meme... in other words, people think of Python as slow, whether they have measured it or not. Just like they think of Java as being more portable. Talking about "fast enough" is just another way of reminding people that we're really quite slow (even if that's not true). So how about a slogan like "Code it Fast, with Python", or "Python: Code Fast" -- one which emphasizes the (easily defended) claim that development time is shorter with Python, but which at the same time manages to associate the word "fast" with "Python". -- Michael Chermside ___ 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
> So how about a slogan like "Code it Fast, with Python", or "Python: Code > Fast" -- one which emphasizes the (easily defended) claim that development > time is shorter with Python, but which at the same time manages to > associate the word "fast" with "Python". I always liked: "Python, the language that wraps tightly around a problem and swallows it whole." 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
Title: RE: [Python-Dev] re: 2.4 news reaches interesting places [Raymond Hettinger] #- > So how about a slogan like "Code it Fast, with Python", or "Python: #- Code #- > Fast" -- one which emphasizes the (easily defended) claim that #- development #- > time is shorter with Python, but which at the same time manages to #- > associate the word "fast" with "Python". #- #- I always liked: "Python, the language that wraps tightly around a #- problem and swallows it whole." Yes, but the point is that, even if it swallows the problem not-as-fast as C, it wraps around the problem very quickly! . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. ___ 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 08:24:11 -0800, Michael Chermside <[EMAIL PROTECTED]> wrote: > Carlos Riberio writes: > > 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. > > I think Carlos is onto something here. Guido's original question was > how to fight this meme... in other words, people think of Python as > slow, whether they have measured it or not. Just like they think of > Java as being more portable. Talking about "fast enough" is just another > way of reminding people that we're really quite slow (even if that's not > true). > > So how about a slogan like "Code it Fast, with Python", or "Python: Code > Fast" -- one which emphasizes the (easily defended) claim that development > time is shorter with Python, but which at the same time manages to > associate the word "fast" with "Python". Whatever the slogan is, the most important point is: Python (and Pythonistas in general) should not be ashamed about Python's speed. I've checked most of the links that popped up as this thread progressed, and followed other similar links. In many cases, Python advocates are quoted as saying that speed improvements were due to recoding in C. That's definitely *not* the way we're going to sell the perception of speed. It is an unnecessary apology, and it sells the wrong idea. It says "we know it's slow, but we're moving to a faster language to improve performance". Not exactly reassuring. As far as the slogan is concerned - I still stand for my proposal, but I don't know if anyone has registered it first... I fear it is, it sounds strangely familiar. But I hope not. p.s. Can someone imagine a Microsoft senior executive saying that "C# is now faster because we rewrote the critical parts in C?" Or the same for Sun & Java? ;-) -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [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] re: 2.4 news reaches interesting places
Title: RE: [Python-Dev] re: 2.4 news reaches interesting places [Carlos Ribeiro] #- As far as the slogan is concerned - I still stand for my #- proposal, but #- I don't know if anyone has registered it first... I fear it is, it #- sounds strangely familiar. But I hope not. Well, Google didn't return any match to the exact phrase "Programming has never been any faster" (but this is not legal to affirm prior invention (yet)). I like your proposal (and slogan) a LOT! . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. ___ 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, 2004-12-17 at 09:20 -0200, Carlos Ribeiro wrote: > BTW, I would move away from the "fast enough" when talking about > performance. It's difficult to qualify what is "enough" in marketing > terms; also, a selling/winning message can't be seen as taking excuses > for any reason. On the other hand, Python never claims to be the > fastest language on raw execution performance, but only to be fast; > but in this sense, being "fast enough" is the same as being "fast". > So, I would never say, "Python allows you to write fast enough code in > a short time"; I would say "Python allows you to write fast code in a > short time". Leave the "fast enough" out of this, please. I totally agree. Personally, the first thing I think of when I see "enough" is "640k aught to be enough for anybody" (quote from you-know-who), like you are defining the needs of the user. Promote the strong sides, don't excuse the weak ones. "Fast enough" is not a positive marketing term, it's an excuse for a problem which I fail to see in Python. Hardware cost is way lower than programmer cost - I am convinced that in most cases the total expence is lower for a Python solution compared to an equal performing C, C++, C# or Java solution. -- Eirik Mikkelsen <[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
[Python-Dev] RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11
On Fri, 17 Dec 2004, Raymond Hettinger wrote:
> The Dec 12th check-ins break tests on WinME:
>
>
> test_glob.py
>
> Traceback (most recent call last):
> File "test_glob.py", line 78, in test_glob_one_directory
> eq(self.glob('a*'), map(self.norm, ['a', 'aab', 'aaa']))
> File "test_glob.py", line 67, in assertSequencesEqual_noorder
> self.assertEqual(set(l1), set(l2))
> AssertionError: set(['/[EMAIL PROTECTED]', '/[EMAIL PROTECTED]',
> '/[EMAIL PROTECTED]
> t_dir\\a']) != set(['[EMAIL PROTECTED]', '[EMAIL PROTECTED]',
> '[EMAIL PROTECTED]
> est_dir\\a'])
>
>
> test_urllib.py
> --
> FAIL: test_basic (__main__.urlretrieve_FileTests)
> --
> Traceback (most recent call last):
> File "test_urllib.py", line 142, in test_basic
> self.assertEqual(result[0], test_support.TESTFN)
> AssertionError: '[EMAIL PROTECTED]' != '/[EMAIL PROTECTED]'
>
>
>
> Please fix,
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:
...
#ifdef HAVE_POPEN<<<-- line 3241
...
#if defined(PYOS_OS2)
#if defined(PYCC_VACPP)
... <<<-- changes here
#elif defined(PYCC_GCC)
...
#endif /* PYCC_??? */
#elif defined(MS_WINDOWS)
...
#else /* which OS? */
...
#endif /* PYOS_??? */
#endif /* HAVE_POPEN */
...
Note that the posixmodule change affects popen().
The matching PC/getpath.c changes that apply to Windows were checked in by
Tim Peters back in August.
I don't have any Windows development environment, so can't cross check
your report :-(
If you have verified the cause of failure by backing out v2.300.8.11, then
there's a deeper problem about the Windows build picking up explicitly
non-Windows components - which I find hard to believe.
In the absence of more evidence, not guilty your honour.
-
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: 2.4 news reaches interesting places
On Fri, 17 Dec 2004, Raymond Hettinger wrote: > > So how about a slogan like "Code it Fast, with Python", or "Python: > Code > > Fast" -- one which emphasizes the (easily defended) claim that > development > > time is shorter with Python, but which at the same time manages to > > associate the word "fast" with "Python". > > I always liked: "Python, the language that wraps tightly around a > problem and swallows it whole." The only problem here is the association with the reptilian python, which is not perceived as being rapid - though it is highly effective as you describe. Whereas cobras... I somewhat suspect a subliminal association linking the reptile and the language, colouring perceptions without factual basis... :-( - 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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 259 open ( +0) / 2707 closed ( +2) / 2966 total ( +2) Bugs: 822 open (+22) / 4685 closed (+23) / 5507 total (+45) RFE : 160 open ( +0) / 139 closed ( +2) / 299 total ( +2) New / Reopened Patches __ repair typo (2004-12-08) CLOSED http://python.org/sf/1080684 opened by George Yoshida Description of message_set and command option to store() (2004-12-13) http://python.org/sf/1084092 opened by Sean Reifschneider Patches Closed __ repair typo (2004-12-07) http://python.org/sf/1080684 closed by jlgijsbers fix inspect.getsource breaking with line-continuation & more (2004-08-19) http://python.org/sf/1011890 closed by jlgijsbers New / Reopened Bugs ___ Inplace set merge produces wrong results (2004-12-07) CLOSED http://python.org/sf/1080424 opened by Matthias Klose float issue for NaN type in .pyc file (2004-12-07) http://python.org/sf/1080440 opened by Dileep Nirala Python Icon in system Tray (2004-12-07) CLOSED http://python.org/sf/1080634 opened by Dileep Nirala thread.error: release unlocked lock on Queue put (2004-12-07) CLOSED http://python.org/sf/1080660 opened by John Speno os.ttyname() accepts wrong arguments (2004-12-07) http://python.org/sf/1080713 opened by Christian Höltje full test with all unicode text files (2004-12-07) CLOSED http://python.org/sf/1080811 opened by Grzegorz Makarewicz locale.py doesn't recognize valid locale setting (2004-12-07) CLOSED http://python.org/sf/1080864 opened by stas Z readline module doesn't build on MacOSX (2004-12-07) http://python.org/sf/1081045 opened by Skip Montanaro Bad reference in whrandom docs (2004-12-08) CLOSED http://python.org/sf/1081370 opened by Lars Marius Garshol LDAP search segfaults on RedHat FC3 (2004-12-08) CLOSED http://python.org/sf/1081633 opened by Tessa Lau Rewrite of docs for compiler.visitor (2004-12-09) http://python.org/sf/1081824 opened by Kent Johnson Pydoc can't find browser (bug+solution!) (2004-12-08) http://python.org/sf/1081879 opened by Stewart Midwinter PyString_AsString() segfaults when passed a unicode string (2004-12-09) CLOSED http://python.org/sf/1082085 opened by Andreas Jung Documentation for PyUnicode_TailMatch incorrrectly says it r (2004-12-10) CLOSED http://python.org/sf/1082944 opened by Jim Fulton truncated gzip file triggers zlibmodule segfault (2004-12-10) http://python.org/sf/1083110 opened by Sam Rushing Change in signal function in the signal module (2004-12-10) http://python.org/sf/1083177 opened by Gary H. Loechelt Unable to see Python binary (2004-12-10) http://python.org/sf/1082874 opened by Prabal Rakshit UnboundLocalError raised by atexit module (2004-12-10) CLOSED http://python.org/sf/1083202 opened by Gary H. Loechelt Distutils doesn't pick up all the files it should. (2004-12-10) http://python.org/sf/1083299 opened by Mike Meyer font lock keyword regular expressions (2004-12-09) http://python.org/sf/1082487 opened by Robert Brown Tests fail instead of skip (2004-12-12) http://python.org/sf/1083645 opened by Detlef Vollmann Python 2.4 crashes (2004-12-12) http://python.org/sf/1083793 opened by Axel Kaiser functions replaced should point to its docs (2004-12-12) http://python.org/sf/1083895 opened by Johannes Gijsbers status of small floats in xml-rpc ? (2004-12-13) CLOSED http://python.org/sf/1084279 opened by Antoine Pitrou ossaudiodev no longer undocumented (2004-12-13) CLOSED http://python.org/sf/1084457 opened by Gregory H. Ball sys.stdin segfaults on invalid stdin (2004-12-13) http://python.org/sf/1084766 opened by Mihai Ibanescu list initialization bug (2004-12-14) CLOSED http://python.org/sf/1084906 opened by py_py gethostbyaddr on redhat for multiple hostnames (2004-12-14) http://python.org/sf/1085069 opened by Dave Kirby Fix stale link in PEP (2004-12-14) CLOSED http://python.org/sf/1085096 opened by Michael Chermside Uninstaller unclear about the app it's uninstalling (2004-12-14) CLOSED http://python.org/sf/1085168 opened by Giles Antonio Radford Uninstaller should restore file associations if possible (2004-12-14) http://python.org/sf/1085172 opened by Giles Antonio Radford Installation ends prematurely (2004-12-14) http://python.org/sf/1085208 opened by anamh0001 binascii.b2a_qp oddities (2004-12-14) http://python.org/sf/1085283 opened by DSM Mac Library Modules 1.1.1 Bad Info (2004-12-14) http://python.org/sf/1085300 opened by Walrus Make array.array pickle-able (2004-12-14) CLOSED http://python.org/sf/1085304 opened by Nicolas Fleury Bad interaction between PySequence_Fast and itertools (2004-12-15) CLOSED http://python.org/sf/1085744 opened by Nick Coghlan subp
[Python-Dev] python-dev Summary for 2004-11-01 through 2004-11-15 [draft]
Now I am only a month behind. Won't send this out any earlier than Monday night, but probably won't be until Tuesday. = Summary Announcements = I am hoping to be caught up with my summary backlog by the end of the month. Hear is to hoping. = Summaries = 2.4 released `Python 2.4`_ has been released! Read the `What's New`_ for 2.4 to see what the major changes are since 2.3 . .. _Python 2.4: http://www.python.org/2.4/ .. _What's New: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html Contributed threads: - `TRUNK FROZEN for 2.4b2 release from UTC 3rd November (tomorrrow) <>`__ - `RELEASED Python 2.4, beta 2 <>`__ - `TRUNK UNFROZEN <>`__ - Code coverage of the regression tests - Walter DÃrwald has a code coverage tool that runs once a month on Python's regression test at http://coverage.livinglogic.de/ . There was some issue with the 'trace' module having partially broken in 2.4 . The coverage was then run using ``Lib/test/regrtest.py -T`` to get more accurate numbers. Contributing threads: - `Code coverage tool updated <>`__ Garbage collecting weakref callbacks Tim Peters discovered that in 2.4 if a weakref's callback is still reachable but the referent and weakref itself are unreachable (Tim's example had an instance that contained a weakref to itself) that the callback is not called during garbage collection. This seemed inconsistent since if the weakref in Tim's example was replaced with an instance that contained a __del__ method that the method would have been called. Tim would like to clean this up so as to be able to ditch __del__ methods in Python 3000. The idea is that one would register a weakref with a callback for an object in itself that would be called when it is garbage collected. This would also negate the need for gc.garbage . Contributing threads: - `weakref gc semantics <>`__ - `patch-finalizer vs Zope3 <>`__ - PEP Watch - `PEP 336`_ introduces the idea of having None be a callable object. The result that calling None would return None itself. .. _PEP 336: http://www.python.org/peps/pep-0336.html Contributing threads: - `PEP 336, "Make None Callable", by Andrew McClelland <>`__ -- Discussion of including pysqlite in the stdlib -- The idea of including pysqlite_ in the stdlib came up once again (not this is the wrapper for SQLite_ and not SQLite itself). The arguments for including the module were the SQLite is most likely used more than Sleepycat and thus deserved a place in the stdlib if bsddb did. It also goes along with Python's idea of "batteries included". Arguments against started with the idea of sanctioning pysqlite over other SQLite wrappers did not seem proper. People also thought that including bsddb might not be correct anymore and thus should not be used as a basis for including pysqlite. This all then led into a discussion about package management and how to simplify extending what can be installed at compile-time. The idea of pushing PyPI_ came up as well as revising `PEP 206`_. .. _pysqlite: http://pysqlite.org/ .. _SQLite: http://www.sqlite.org/ .. _PyPI: http://www.python.org/pypi .. _PEP 206: http://www.python.org/peps/pep-0206.html Contributing threads: - `SQLite module for Python 2.5 <>`__ 2.3 maintenance coming to an end With Python 2.4 out, maintaining 2.3 is no longer a priority. Anthony Baxter, our beloved release manager, has said that 2.3.5 will be most likely coming out in January. After that, though, don't count on another 2.3 release since 2.4 will take its place as the version to maintain. All of this came about by the fact that Facundo Batista asked if closing 2.1 bugs was okay. As long as they have been fixed in the earliest version being maintained, closing them is fine. This goes for 2.2 as well. And as soon as 2.3.5 is out the door will most likely apply to 2.3 bugs. Contributing threads: - `Policy about old Python versions <>`__ - Sync/async servers in the stdlib and whether they should be there - There are multiple servers in the core for handling communications in both a synchronous and asynchronous manner. The idea came up of developing an API that all servers could follow in the core. While the discussion went back and forth with multiple mentions of PEAK, Twisted, and greenlets_, in the end the trend of the discussion suggested doing this well would be very difficult and not worth the effort. asyncore and a
Re: [Python-Dev] RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11
Andrew MacIntyre wrote: 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: 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? -Brett ___ 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
