Re: [Python-Dev] FreeBSD 7 amd64 and large memory tests
Andrew MacIntyre wrote: I'll take this up with FreeBSD folk, but I'm open to ideas as to how best to deal with the problem in the context of the test suite pending resolution by FreeBSD. The response I got from Jason Evans (author of the new malloc() implementation), along with that of another respondent, indicates that the behaviour on FreeBSD 7.1 and later will (mostly) be restored to that similar to 6.x and earlier through the default use of sbrk() and consequent obedience to the data segment size limit (ulimit -d) - which defaults to 512MB in a standard FreeBSD install in recent times. The residual problem (as of 7.1) is that malloc() defaults to falling back to the mmap() strategy when it can't get more address space via sbrk(). As noted in the tracker item for issue 3862, the only way to control this is the virtual memory size limit (ulimit -v), which unfortunately defaults to "unlimited"... FreeBSD's malloc() can be tuned in several ways, so it is possible to force use of the sbrk() only strategy (as of 7.1) which would exactly match behaviour of the old malloc(). It seems to me that the most practical way forward is to just institute a policy that tests that want to try and test out of memory behaviour must ensure that appropriate resource limits are in place; if they can't (such as because the platform running the tests doesn't support getrlimit()/setrlimit()) the test should be skipped. As Mark Dickinson has suggested a patch for issue 3862 which should worm around the issue with test_array on 64 bit platforms, I think we can move forward for the time being. Cheers, Andrew. -- - 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD 7 amd64 and large memory tests
> It seems to me that the most practical way forward is to just institute a > policy that tests that want to try and test out of memory behaviour must > ensure that appropriate resource limits are in place IMO, there shouldn't be any tests in the test suite that rely on exhaustion of all available memory. The MemoryError tests should all deal with overflow situations only. If stress-testing is desired, it should be done with platform support, i.e. with a malloc implementation that randomly fails. OTOH, I would hope that the static-analysis tools that Python gets run through find failures to properly check for NULL results much better than stress-testing. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ssl module, non-blocking sockets and asyncore integration
Some good news: I finally figured out how to modify asyncore to make it properly handle the non-blocking ssl-handshake. I provided a patch for test_ssl.py in issue 3899. Bill, could you please review it? --- Giampaolo http://code.google.com/p/pyftpdlib/ On 18 Set, 00:49, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote: > Ok, here's some news, in case they can be of some interest. > I managed to write an asyncore disptacher which seems to work. > I used my test suite against it and 70 tests passed and 2 failed. > The tests failed because at a certain point a call to do_handhsake > results in an EOF exception, which is very strange since it is > supposed to raise SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE only. > I'll keep you updated in case I have some news. > > --- Exception --- > > File "C:\python26\lib\ssl.py", line 293, in do_handshake > self._sslobj.do_handshake() > SSLError: [Errno 8] _ssl.c:480: EOF occurred in violation of protocol > > --- SSL dispatcher > > class SSLConnection(asyncore.dispatcher): > > def __init__(self): > self.ssl_handshake_pending = False > > def do_ssl_handshake(self): > try: > self.socket.do_handshake() > except ssl.SSLError, err: > if err.args[0] == ssl.SSL_ERROR_WANT_READ: > self.ssl_handshake_pending = 'read' > elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE: > self.ssl_handshake_pending = 'write' > else: > raise > else: > self.ssl_handshake_pending = False > > def handle_read_event(self): > if self.ssl_handshake_pending == 'read': > self.do_ssl_handshake() > ## if not self.ssl_handshake_pending: > ## asyncore.dispatcher.handle_read_event(self) > else: > asyncore.dispatcher.handle_read_event(self) > > def handle_write_event(self): > if self.ssl_handshake_pending == 'write': > self.do_ssl_handshake() > ## if not self.ssl_handshake_pending: > ## asyncore.dispatcher.handle_write_event(self) > else: > asyncore.dispatcher.handle_write_event(self) > > --- Giampaolohttp://code.google.com/p/pyftpdlib/ > ___ > Python-Dev mailing list > [EMAIL PROTECTED]://mail.python.org/mailman/listinfo/python-dev > Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bsddb tests disabled by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just installing 2.6rc2, I see that bsddb3 testsuite is disabled by default. Current testsuite is far more fast and stable that the old one (entire test: 17 seconds in my machine). I was wondering if it is time to enable bsddb3 testsuite by default. BTW: How is a "resource" enabled by an user, without touching sourcecode?. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSNJktZlgi5GaxT1NAQI7YQP+PwnNpfnJCsd3u/bAgjFQfHaRXMYlS1PN dZPb8lkzMbyanNituTC9VLxI97BXsSPSM7VNnbyO3lBVSvJxvsDaRDmoUynno+VX rw7+dD/mqKdyPujBjLzqYhbvQAoUOxLNac44/pTjvqoGiDa5CeR0AunUDnqnVVJa 4by7SBBxYrs= =sllZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bsddb tests disabled by default
On Sep 18, 2008, at 10:24 AM, Jesus Cea wrote: Current testsuite is far more fast and stable that the old one (entire test: 17 seconds in my machine). I was wondering if it is time to enable bsddb3 testsuite by default. Perhaps so. That certainly improves the chances of finding problems early. BTW: How is a "resource" enabled by an user, without touching sourcecode?. regrtest.py takes a "-u" (for "use") option; take a look at how the value passed to that gets interpreted. (Could use better documentation, if no one's improved it since I added the option umpteen gazillion years ago.) -Fred -- Fred Drake ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
During the past couple of months I have been working on an object-capability subset of Python - in other words, a restricted execution scheme for sandboxing Python code. It has been influenced by other object-capability subset languages, such as Joe-E (a subset of Java [1]), Caja/Cajita (subsets of Javascript [2]) and Caperl (based on Perl [3]). I'm calling it CapPython because the name doesn't seem to have been taken yet. :-) I believe it is now secure, so it seems like a good time to announce it here! The basic idea behind CapPython is to enforce encapsulation by restricting access to private attributes of objects. This is achieved through a combination of static checking and limiting access to unsafe builtins and modules. Private attributes may only be accessed through "self" variables. "Self" variables are defined as being the first arguments of functions defined inside class definitions, with a few restrictions intended to prevent these functions from escaping without being safely wrapped. Private attribute names are those starting with "_". Additionally, "im_self", "im_func" and some other special cases are treated as private attributes. Assignments to attributes are only allowed via "self" variables. For example, the following code is accepted by the static verifier: class Counter(object): def __init__(self): self._count = 0 def get_next(self): self._count += 1 return self._count But the following code reads a private attribute and so it is rejected as violating encapsulation: counter._count -= 1 CapPython consists of three parts: - a static verifier; - a "safe exec" function, which will check code before executing it and can run code in a safe scope; - a module loader which implements a safe __import__ function. Eventually this will be runnable as untrusted CapPython code. I am documenting CapPython via my blog at the moment, with the following posts so far: http://lackingrhoticity.blogspot.com/2008/08/introducing-cappython.html http://lackingrhoticity.blogspot.com/2008/09/dealing-with-modules-and-builtins-in.html http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html The code is available from a Bazaar repository on Launchpad: https://code.launchpad.net/cappython I am currently working on creating a simple example program, which will be a wsgiref-based web server with a form for executing CapPython code. This involves taming some of the standard libraries to pass the verifier. There are some design notes here - http://plash.beasts.org/wiki/CapPython - although these notes are more a list of references and problems CapPython needs to address than an explanation of the current design. There was also a thread about CapPython on the e-lang mailing list: http://www.eros-os.org/pipermail/e-lang/2008-August/012828.html Mark [1] http://code.google.com/p/joe-e/ [2] http://code.google.com/p/google-caja/ [3] http://caperl.links.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bsddb tests disabled by default
On Thu, Sep 18, 2008 at 7:24 AM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Just installing 2.6rc2, I see that bsddb3 testsuite is disabled by default. > > Current testsuite is far more fast and stable that the old one (entire > test: 17 seconds in my machine). I was wondering if it is time to enable > bsddb3 testsuite by default. Well, 'time' says the test takes 16.09 sec user and 16.09 sec system on my MacBook, but a total execution time of almost 8 *minutes*. That is too long to be on by default. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] What's New in 2.6 link wasn't what I expected
>From this page: http://www.python.org/download/releases/2.6/ I clicked the link labelled "What's new in Python 2.6rc2". This didn't take me to the What's New page. Instead it took me to: http://www.python.org/download/releases/2.6/NEWS.txt Seems a bit mislabelled if nothing else. Poking around I see that the 2.5 What's New document is at: http://docs.python.org/dev/whatsnew/whatsnew25.html but http://docs.python.org/dev/whatsnew/whatsnew26.html doesn't exist. Am I missing something? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
Mark Seaborn wrote: During the past couple of months I have been working on an object-capability subset of Python - in other words, a restricted execution scheme for sandboxing Python code. It has been influenced by other object-capability subset languages, such as Joe-E (a subset of Java [1]), Caja/Cajita (subsets of Javascript [2]) and Caperl (based on Perl [3]). I'm calling it CapPython because the name doesn't seem to have been taken yet. :-) No wonder ;-). I like CapPy better, though there is a shareware screen capture program by that name. PyCap is taken. CapThon is not. I believe it is now secure, so it seems like a good time to announce it here! The basic idea behind CapPython is to enforce encapsulation by restricting access to private attributes of objects. This is achieved through a combination of static checking and limiting access to unsafe builtins and modules. Private attributes may only be accessed through "self" variables. "Self" variables are defined as being the first arguments of functions defined inside class definitions, with a few restrictions intended to prevent these functions from escaping without being safely wrapped. What about functions defined outside class definitions and then attached as an attribute. Prevented? Private attribute names are those starting with "_". Additionally, "im_self", "im_func" and some other special cases are treated as private attributes. In 3.0, unbound methods are gone and im_self and im_func are __self__ and __func__ attributes of method objects. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
How about Capt'n Python? :-) Anyway, this is way cool. Looking forward to kicking the tires! On Thu, Sep 18, 2008 at 1:33 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > Mark Seaborn wrote: >> >> During the past couple of months I have been working on an >> object-capability subset of Python - in other words, a restricted >> execution scheme for sandboxing Python code. It has been influenced >> by other object-capability subset languages, such as Joe-E (a subset >> of Java [1]), Caja/Cajita (subsets of Javascript [2]) and Caperl >> (based on Perl [3]). I'm calling it CapPython because the name >> doesn't seem to have been taken yet. :-) > > No wonder ;-). I like CapPy better, though there is a shareware screen > capture program by that name. PyCap is taken. CapThon is not. >> >> I believe it is now secure, so it seems like a good time to announce >> it here! >> >> The basic idea behind CapPython is to enforce encapsulation by >> restricting access to private attributes of objects. This is achieved >> through a combination of static checking and limiting access to unsafe >> builtins and modules. >> >> Private attributes may only be accessed through "self" variables. >> "Self" variables are defined as being the first arguments of functions >> defined inside class definitions, with a few restrictions intended to >> prevent these functions from escaping without being safely wrapped. > > What about functions defined outside class definitions and then attached as > an attribute. Prevented? > >> Private attribute names are those starting with "_". Additionally, >> "im_self", "im_func" and some other special cases are treated as >> private attributes. > > In 3.0, unbound methods are gone and im_self and im_func are __self__ and > __func__ attributes of method objects. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
On Thu, Sep 18, 2008 at 04:33:23PM -0400, Terry Reedy wrote: > Mark Seaborn wrote: > I'm calling it CapPython > > No wonder ;-). I like CapPy better, though there is a shareware screen > capture program by that name. PyCap is taken. CapThon is not. CaPy, and make capybara its mascot. ;) Or may be "captyve" because the goal of the project is to make some code captive. :) Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
Guido van Rossum wrote: How about Capt'n Python? :-) Harr, harr! Geat name :) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
Terry Reedy <[EMAIL PROTECTED]> wrote: > Mark Seaborn wrote: > > Private attributes may only be accessed through "self" variables. > > "Self" variables are defined as being the first arguments of functions > > defined inside class definitions, with a few restrictions intended to > > prevent these functions from escaping without being safely wrapped. > > What about functions defined outside class definitions and then attached > as an attribute. Prevented? Yes, that is prevented: attribute assignment is only allowed on "self" variables, so you can't assign to class attributes. Classes can't be extended that way. That should not be a big problem for expressiveness; defining __getattr__ will still be possible. CapPython has to prevent attribute assignment by default because Python allows it on objects by default. It would be possible to allow attribute assignment by having CapPython rewrite it to a normal method call whose behaviour classes have to opt into, rather than opt out of. Currently CapPython does not do any rewriting. > > Private attribute names are those starting with "_". Additionally, > > "im_self", "im_func" and some other special cases are treated as > > private attributes. > > In 3.0, unbound methods are gone and im_self and im_func are __self__ > and __func__ attributes of method objects. Yes. The renaming of "im_self" and "im_func" is good. The removal of unbound methods is a *big* problem [1]. Regards, Mark [1] http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python
On Thu, Sep 18, 2008 at 2:15 PM, Mark Seaborn <[EMAIL PROTECTED]> wrote: > Terry Reedy <[EMAIL PROTECTED]> wrote: > >> Mark Seaborn wrote: > >> > Private attributes may only be accessed through "self" variables. >> > "Self" variables are defined as being the first arguments of functions >> > defined inside class definitions, with a few restrictions intended to >> > prevent these functions from escaping without being safely wrapped. >> >> What about functions defined outside class definitions and then attached >> as an attribute. Prevented? > > Yes, that is prevented: attribute assignment is only allowed on "self" > variables, so you can't assign to class attributes. Classes can't be > extended that way. That should not be a big problem for > expressiveness; defining __getattr__ will still be possible. > > CapPython has to prevent attribute assignment by default because > Python allows it on objects by default. > > It would be possible to allow attribute assignment by having CapPython > rewrite it to a normal method call whose behaviour classes have to opt > into, rather than opt out of. Currently CapPython does not do any > rewriting. > >> > Private attribute names are those starting with "_". Additionally, >> > "im_self", "im_func" and some other special cases are treated as >> > private attributes. >> >> In 3.0, unbound methods are gone and im_self and im_func are __self__ >> and __func__ attributes of method objects. > > Yes. The renaming of "im_self" and "im_func" is good. The removal of > unbound methods is a *big* problem [1]. > > Regards, > Mark > > [1] > http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html I don't know to what extent you want to modify Python fundamentals, but I think this could be solved simply by adding a metaclass that returns an unbound method object for C.f, couldn't it? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New in 2.6 link wasn't what I expected
> I clicked the link labelled "What's new in Python 2.6rc2". This didn't take > me to the What's New page. Instead it took me to: > > http://www.python.org/download/releases/2.6/NEWS.txt > > Seems a bit mislabelled if nothing else. How so? The first major heading in that file reads "What's New in Python 2.6 release candidate 2?" > Am I missing something? Perhaps reading the file that was linked might have helped. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New in 2.6 link wasn't what I expected
On Fri, Sep 19, 2008 at 12:49:28AM +0200, "Martin v. Löwis" wrote: > > I clicked the link labelled "What's new in Python 2.6rc2". This didn't take > > me to the What's New page. Instead it took me to: > > > > http://www.python.org/download/releases/2.6/NEWS.txt > > > > Seems a bit mislabelled if nothing else. > > How so? The first major heading in that file reads > > "What's New in Python 2.6 release candidate 2?" > > > Am I missing something? > > Perhaps reading the file that was linked might have helped. I ran into this, too (and I did read the file that was linked to). I had expected to find the "What's New" page describing what was new in Python 2.6, and I would have expected a "Release Notes" link to point to the NEWS.txt page. That's how things were in the past, anyway: http://www.python.org/download/releases/2.5.2/#what-s-new It's a minor thing, but I did have to go hunt down the What's New file. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 pgp2b0NCOqYoh.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New in 2.6 link wasn't what I expected
[EMAIL PROTECTED] wrote: >>From this page: > > http://www.python.org/download/releases/2.6/ > > I clicked the link labelled "What's new in Python 2.6rc2". This didn't take > me to the What's New page. Instead it took me to: > > http://www.python.org/download/releases/2.6/NEWS.txt > > Seems a bit mislabelled if nothing else. I agree - as Andrew suggested, it would probably be better if the What's New? list for 2.6 was a bit more like the 2.5 list: http://www.python.org/download/releases/2.5/ > Poking around I see that the 2.5 > What's New document is at: > > http://docs.python.org/dev/whatsnew/whatsnew25.html That actually rewrites the URL to the URL for the current docs (removing the 'dev' part): http://docs.python.org/whatsnew/whatsnew25.html > but > > http://docs.python.org/dev/whatsnew/whatsnew26.html The name was changed in the move to Sphinx for the docs - it's at: http://docs.python.org/dev/whatsnew/2.6.html (Unlike the old What's New directory, or the current library directory and so forth, that directory doesn't have an index entry defined, so simply leaving out the file name detail doesn't currently do the right thing - you get the directory listing instead of the what's new doco) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New in 2.6 link wasn't what I expected
>> http://www.python.org/download/releases/2.6/NEWS.txt >> >> Seems a bit mislabelled if nothing else. Martin> How so? The first major heading in that file reads Seems more like the Misc/NEWS file to me. I was expecting Andrew's What's New document, which I eventually found at http://docs.python.org/dev/whatsnew/2.6.html If you Google for "site:python.org whatsnew" seven of the first eight hits are for various versions of Andrew's 2.x What's New doc. That's what people expect to find. We shouldn't be changing that now. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New in 2.6 link wasn't what I expected
[EMAIL PROTECTED] wrote: > >> http://www.python.org/download/releases/2.6/NEWS.txt > >> > >> Seems a bit mislabelled if nothing else. > > Martin> How so? The first major heading in that file reads > > Seems more like the Misc/NEWS file to me. I was expecting Andrew's What's > New document, which I eventually found at > > http://docs.python.org/dev/whatsnew/2.6.html > > If you Google for "site:python.org whatsnew" seven of the first eight hits > are for various versions of Andrew's 2.x What's New doc. That's what people > expect to find. We shouldn't be changing that now. > +1 -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What's New in 2.6 link wasn't what I expected
> >> http://www.python.org/download/releases/2.6/NEWS.txt > >> > >> Seems a bit mislabelled if nothing else. > > Martin> How so? The first major heading in that file reads > > Seems more like the Misc/NEWS file to me. Correct. > I was expecting Andrew's What's New document Why that? The link deliberately says "What's new in Python 2.6rc2", not "What's new in Python 2.6". > If you Google for "site:python.org whatsnew" seven of the first eight hits > are for various versions of Andrew's 2.x What's New doc. That's what people > expect to find. We shouldn't be changing that now. I admit that the traditional description for that link is "release notes" or "detailed release notes". Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
