Re: [Python-Dev] NotImplemented reaching top-level
Hi Facundo, On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote: d += 1.2 d NotImplemented The situation appears to be a mess. Some combinations of specific operators fail to convert NotImplemented to a TypeError, depending on old- or new-style-class-ness, although this is clearly a bug (e.g. in an example like yours but using -= instead of +=, we get the correct TypeError.) Obviously, we need to write some comprehensive tests about this. But now I just found out that the old, still-pending SF bug #847024 about A()*5 in new-style classes hasn't been given any attention; my theory is that nobody fully understands the convoluted code paths of abstract.c any more :-( A bientot, Armin ___ 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] NotImplemented reaching top-level
Armin Rigo wrote: Hi Facundo, On Sat, Dec 24, 2005 at 02:31:19PM -0300, Facundo Batista wrote: d += 1.2 d NotImplemented The situation appears to be a mess. Some combinations of specific operators fail to convert NotImplemented to a TypeError, depending on old- or new-style-class-ness, although this is clearly a bug (e.g. in an example like yours but using -= instead of +=, we get the correct TypeError.) Obviously, we need to write some comprehensive tests about this. But now I just found out that the old, still-pending SF bug #847024 about A()*5 in new-style classes hasn't been given any attention; my theory is that nobody fully understands the convoluted code paths of abstract.c any more :-( Time for a rewrite? Reinhold -- Mail address is perfectly valid! ___ 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] deque alternative (was: Linked lists)
Guido van Rossum wrote: Python's philosophy about (built-in) data types, inherited from ABC, is to offer a few powerful clearly distinct choices rather than lots of alternatives with overlapping usages. This reduces the time it takes to choose a data type and reduces the risk of picking the wrong type. (You seem to be indicating that this is indeed what's happening to you in Lisp. :-) Speaking about the new dequeue type, I have the impression that this reasoning applies there a bit, too? Dequeues of course have applications, and I saw them used, especially by newcomers to the language. So I like their functionality. But actually, I'm not so convinced if we need to introduce a new datatype. How about an extension to normal lists that does a little tracking of use-cases and decides about changing its implementation upon the presence of inserts/deletes at the lower end of the list? I'm btw. not sure if this raises an implicit/explicitiness issue. My question is if it is necessary to put the burden about explicitly choosing a specialized two-ended list on the programmer, or if it is simple enough to make lists just do the right thing, if lists are used in a dequeue-style manner. Or is this maybe too much magic happening? merry christmas -- chris -- Christian Tismer :^) mailto:[EMAIL PROTECTED] tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.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] status of development documentation
Brett Cannon wrote: On 12/23/05, Neal Norwitz [EMAIL PROTECTED] wrote: On 12/23/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So for at least the time being they go up nightly (http://www.trentm.com/python). I don't know what Trent did to make that happen, but he did it fairly quickly. I doubt it would be hard to replicate on the docs server. I couldn't let Trent have all the fun. http://docs.python.org/dev/ Cool! Thanks to Trent for sparking Neal, and thanks to Neal for feeling the fire under our arses for getting this done. Indeed - thanks folks. And hopefully of interest to many here: http://docs.python.org/dev/results/ These are the results of svn update, configure, build, test, install and the doc run. Run on the PSFs box and updated every 12 hours. I currently have it send mail to me if there are any test failures. I will probably update that to python-checkins or maybe even python-dev depending on what people think. I'm not likely to be around much for the rest of the year, so I don't want to turn it on just yet. python-checkins seems the most reasonable. But I would have no problem with it going to python-dev. If the message gets sent to python-checkins, then it should be fairly easy to identify candidate culprits (especially if the script is designed to send the email anytime the update actually retrieves new files from the repository, even if the tests all pass). 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] NotImplemented reaching top-level
Hi Reinhold, On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote: that nobody fully understands the convoluted code paths of abstract.c any more :-( Time for a rewrite? Of course, speaking of a rewrite, PyPy does the right thing in these two areas. Won't happen to CPython, though. There are too much backward-compatibility issues with the PyTypeObject structure; I think we're doomed with patching the bugs as they show up. Looking up in the language reference, I see no mention of NotImplemented in the page about __add__, __radd__, etc. I guess it's a documentation bug as well, isn't it? The current code base tries to implement the following behavior: Returning NotImplemented from any of the binary special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if the method was not defined in the first place. If we agree on this, I could propose a doc fix, a test, and appropriate bug fixes. A bientot, Armin ___ 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] status of development documentation
Santa sent me a bad-mood elf overnight, apparently just to motivate me ;-) Since it's 2+ months after the fact, I doubt we'll ever know exactly what went wrong here. In outline: Rev 39758 (the AST merge) left pythoncore.vcproj in an unusable state. That's the VC 7.1 project file that defines what goes into the core Python DLL on Windows, and it was checked in with conflict markers embedded. VC couldn't load the resulting mess, so the Python DLL couldn't be built anymore. In rev 39791, MarkH removed the conflict markers and added parsermodule.c (which had somehow gotten lost during the merge). Python then compiled again under VC7.1. But looks like he didn't run the tests -- or, like me, just assumed that all the test failures he saw were universally-known breakage from the then-still-early days of the AST merge (since most were obviously failures to compile correctly, that was a tempting assumption). It sat there then for two months. As things turn out, rev 39758 also damaged pythoncore.vcproj in other, non-syntactic ways: - It removed tokenizer.c from the core DLL, but that's the correct runtime tokenizer code. - It added pgen.c and tokenizer_pgen.c to the core DLL. The former is useless in the core DLL (I think), and including the latter was just wrong. RaymondH would not have noticed anything wrong because he still runs with VC6, and the AST merge didn't muck with _those_ project files. Anyway, after removing pgen.c and tokenizer_pgen.c, and adding tokenizer.c, test_builtin and test_pep263 pass again. In fact, all the -uall tests pass again (yippee!): 264 tests OK. 38 tests skipped: test__locale test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_commands test_crypt test_curses test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp test_hashlib_speed test_imgfile test_ioctl test_linuxaudiodev test_macfs test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_plistlib test_poll test_posix test_pty test_pwd test_resource test_scriptpackages test_signal test_sunaudiodev test_threadsignals test_timing Those skips are all expected on win32. So, Merry Christmas to all, and there's no longer any reason to deprive yourself of the joy of upgrading to Windows ;-) ___ 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] status of development documentation
Tim So, Merry Christmas to all, and there's no longer any reason to Tim deprive yourself of the joy of upgrading to Windows ;-) Merry Christmas to you as well Tim. Hopefully the bad-mood elf left after seeing how happy you were to have figured out the build problems... Oh, and I'll get right on that Windows thing. Where can I download that again? wink 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] NotImplemented reaching top-level
Armin Rigo wrote: Hi Reinhold, On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote: that nobody fully understands the convoluted code paths of abstract.c any more :-( Time for a rewrite? Of course, speaking of a rewrite, PyPy does the right thing in these two areas. Won't happen to CPython, though. There are too much backward-compatibility issues with the PyTypeObject structure; I think we're doomed with patching the bugs as they show up. Looking up in the language reference, I see no mention of NotImplemented in the page about __add__, __radd__, etc. I guess it's a documentation bug as well, isn't it? The current code base tries to implement the following behavior: Returning NotImplemented from any of the binary special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if the method was not defined in the first place. If we agree on this, I could propose a doc fix, a test, and appropriate bug fixes. That sounds like the right definition to me (I believe this behaviour is what Raymond and Facundo were aiming for with the last round of updates to Decimal). Regards, 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
[Python-Dev] Automated Python testing (was Re: status of development documentation)
Take a look at: http://buildbot.zope.org/ That runs code from: http://buildbot.sourceforge.net/ Someone sets up a buildbot master (that's what the Zope URL points at), and then any number of people can volunteer to set up their boxes as buildbot slaves. From time to time the buildbot master asks the slaves to do the checkout/build/test dance (or any other code dance you like), the slaves report results back to the master, and the master displays the slaves' results. If you look at the 2nd-leftmost column, you can see that the master knows when checkins have been done. Checkins can trigger asking the slaves to run tests, and if the tests fail on some slave the master can send email saying so, including the list of checkins (the blamelist) done since the last time that slave ran tests: The guilty developer can be identified and harassed without human intervention. :-) This really helps at Zope Corp. One downside is that we seem unable to get an in-house Windows buildbot slave to work reliably, and so far don't even know whether that's because of Windows, the buildbot code, or flakiness in our internal network. It seems quite reliable on Linux, though. ___ 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] NotImplemented reaching top-level
On 12/25/05, Armin Rigo [EMAIL PROTECTED] wrote: Hi Reinhold, On Sun, Dec 25, 2005 at 12:37:53PM +0100, Reinhold Birkenfeld wrote: that nobody fully understands the convoluted code paths of abstract.c any more :-( Time for a rewrite? Maybe. Also realize we will have a chance to clean it up when Python 3 comes around since the classic class stuff will be ripped out. That way we might have a chance to streamline the code. Of course, speaking of a rewrite, PyPy does the right thing in these two areas. Won't happen to CPython, though. There are too much backward-compatibility issues with the PyTypeObject structure; I think we're doomed with patching the bugs as they show up. Looking up in the language reference, I see no mention of NotImplemented in the page about __add__, __radd__, etc. I guess it's a documentation bug as well, isn't it? The current code base tries to implement the following behavior: Returning NotImplemented from any of the binary special methods (__xxx__, __rxxx__, __ixxx__) makes Python proceed as if the method was not defined in the first place. This is what I always assumed the behaviour was supposed to be, so I am quite happy to go with that. -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
Re: [Python-Dev] Automated Python testing (was Re: status of development documentation)
On 12/25/05, Tim Peters [EMAIL PROTECTED] wrote: Take a look at: http://buildbot.zope.org/ That runs code from: http://buildbot.sourceforge.net/ Someone sets up a buildbot master (that's what the Zope URL points at), and then any number of people can volunteer to set up their boxes as buildbot slaves. As in some machine I might personally have left on? That would require a static IP which I don't know how common that will be. But then again I am willing to bet that the Python community is big enough that people who do have machines that are idle enough that we should be able to get good coverage. Wonder if we would have to worry about result pollution from someone who thought it was funny to send in false negatives? From time to time the buildbot master asks the slaves to do the checkout/build/test dance (or any other code dance you like), the slaves report results back to the master, and the master displays the slaves' results. If you look at the 2nd-leftmost column, you can see that the master knows when checkins have been done. Checkins can trigger asking the slaves to run tests, and if the tests fail on some slave the master can send email saying so, including the list of checkins (the blamelist) done since the last time that slave ran tests: The guilty developer can be identified and harassed without human intervention. :-) This really helps at Zope Corp. One downside is that we seem unable to get an in-house Windows buildbot slave to work reliably, and so far don't even know whether that's because of Windows, the buildbot code, or flakiness in our internal network. It seems quite reliable on Linux, though. Well, it is written in Python so *someone* here should either be able to fix it or properly blame it on Windows. =) The idea of the PSF paying to have some machines set up to run consistent tests has come up multiple times. I know Neal has said he would be willing to host the machines at his house before (but I think this may have been before his relocation to California). This whole situation of going two months without knowing that a major platform is broken shows that this is a real problem and ignoring it is probably not a good thing. =) If we ask for volunteer machines we could offer to put up company or personal names on the buildbot page of those who have volunteered CPU cycles. I am sure that will help motivate companies and people to install the software on a spare machine. Heck, I would have no problem giving a specific company sole sponsorship kudos if they gave us boxes that covered enough core operating systems. Maybe this is something to bring up at the PSF meeting and to hash out at the sprints? -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
Re: [Python-Dev] Automated Python testing (was Re: status of development documentation)
On Sunday 25 December 2005 15:23, Brett Cannon wrote: As in some machine I might personally have left on? That would require a static IP which I don't know how common that will be. But Only buildbot masters are required to have resolvable names (not necessarily static, though it helps; dynamic DNS is fine if the name propogation to the slaves is fast). The slaves do not need to be reachable from the buildbot master, since the slave is responsible for contacting the master. -Fred -- Fred L. Drake, Jr. fdrake at acm.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] Automated Python testing (was Re: status of development documentation)
[Tim] Take a look at: http://buildbot.zope.org/ That runs code from: http://buildbot.sourceforge.net/ Someone sets up a buildbot master (that's what the Zope URL points at), and then any number of people can volunteer to set up their boxes as buildbot slaves. [Brett] As in some machine I might personally have left on? Slaves have to be powered on to work, yes ;-) That would require a static IP which I don't know how common that will be. Spend a few minutes skimming the buildbot docs -- I'm not an expert, but it's a real system in real use, and they have solutions for the obvious problems. In this case, while the master passes out commands to run and collects status, a slave _initiates_ communication with the master. A static IP for the master is good for that, but I figure the slave can keep participating happily then for just as long as it can keep a socket connection open with the master. If a slave goes away (network problem; powered off; whatever), that's fine too. The master can't talk to it then, and the slave's column in the master's display will say the slave is offline. Or, if it's been so long that all info about the slave has scrolled off the display, the column will just say none above it. You can see a couple examples of that in the http://buildbot.zope.org display today, for some Windows slaves that have gone missing in action. then again I am willing to bet that the Python community is big enough that people who do have machines that are idle enough that we should be able to get good coverage. Wonder if we would have to worry about result pollution from someone who thought it was funny to send in false negatives? I wouldn't worry about it. For one thing, while anyone can volunteer to participate, the buildbot master's admin has to set up config info for each specific slave they want to _allow_ to participate. It's more like a moderated mailing list that way ;-) A slave also needs to know a password (which the master's admin emails (for example) to the slave's admin if the former wants the latter to participate). ... One downside is that we seem unable to get an in-house Windows buildbot slave to work reliably, and so far don't even know whether that's because of Windows, the buildbot code, or flakiness in our internal network. It seems quite reliable on Linux, though. Well, it is written in Python so *someone* here should either be able to fix it or properly blame it on Windows. =) Yup! The idea of the PSF paying to have some machines set up to run consistent tests has come up multiple times. A brilliant part of the buildbot approach is that a sub-community claiming to care about a platform (major or not) can put a bit of resource where their mouth is by offering part-time use of a box to run the checkout/build/test dance. That way platform experts who presumably care about their platform are in charge of all aspects of setting their platform up. No centralized compile farm can work as well, unless it has enough money to buy machines-- and expert caretakers --for umpteen off-the-wall OS variations. I know Neal has said he would be willing to host the machines at his house before (but I think this may have been before his relocation to California). Looks like he's already running automated tests: http://docs.python.org/dev/results/ The various steps there could be defined as buildbot actions, and then run on any number of boxes whenever something changes. This whole situation of going two months without knowing that a major platform is broken shows that this is a real problem and ignoring it is probably not a good thing. =) It's generally true that the sooner you find out something has broken, the easier it is to repair it. For minor platforms, I'd say we have no idea whether the trunk has regressed wrt 2.4.2. There's simply no way to know without trying it. If we ask for volunteer machines we could offer to put up company or personal names on the buildbot page of those who have volunteered CPU cycles. I am sure that will help motivate companies and people to install the software on a spare machine. Finding volunteers has been surprisingly (to me) difficult. Most (but not all) of the machines you see on the Zope page are ZC-internal boxes, and, e.g., a Mac OS box is still missing. Heck, I would have no problem giving a specific company sole sponsorship kudos if they gave us boxes that covered enough core operating systems. Cool too. Maybe this is something to bring up at the PSF meeting and to hash out at the sprints? It primarly takes someone with access to a python.org machine to volunteer to install and play admin for a buildbot master. A committee wouldn't actually help with that ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] status of development documentation
On Sun, Dec 25, 2005, Tim Peters wrote: So, Merry Christmas to all, and there's no longer any reason to deprive yourself of the joy of upgrading to Windows ;-) Much Grass! I already upgraded to Windows, but it's turned off in favor of my Linux box and iBook. Yesterday I decided to try doing an svn checkout for the first time. Has anyone ever tried doing that from the top? There's more than 18GB of stuff, and it never actually completes. (I'm mostly mentioning this as FYI/FYA -- I'm doing it to exercise my new computer.) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck. --USENET schmuck (aka Robert Kern) ___ 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] Automated Python testing (was Re: status of development documentation)
On 12/25/05, Tim Peters [EMAIL PROTECTED] wrote: [Tim] Take a look at: http://buildbot.zope.org/ That runs code from: http://buildbot.sourceforge.net/ Someone sets up a buildbot master (that's what the Zope URL points at), and then any number of people can volunteer to set up their boxes as buildbot slaves. [Brett] As in some machine I might personally have left on? Slaves have to be powered on to work, yes ;-) That would require a static IP which I don't know how common that will be. Spend a few minutes skimming the buildbot docs -- I'm not an expert, but it's a real system in real use, and they have solutions for the obvious problems. In this case, while the master passes out commands to run and collects status, a slave _initiates_ communication with the master. A static IP for the master is good for that, but I figure the slave can keep participating happily then for just as long as it can keep a socket connection open with the master. OK, so it is a pull from the slave side, not a push on the master side. If a slave goes away (network problem; powered off; whatever), that's fine too. The master can't talk to it then, and the slave's column in the master's display will say the slave is offline. Or, if it's been so long that all info about the slave has scrolled off the display, the column will just say none above it. You can see a couple examples of that in the http://buildbot.zope.org display today, for some Windows slaves that have gone missing in action. then again I am willing to bet that the Python community is big enough that people who do have machines that are idle enough that we should be able to get good coverage. Wonder if we would have to worry about result pollution from someone who thought it was funny to send in false negatives? I wouldn't worry about it. For one thing, while anyone can volunteer to participate, the buildbot master's admin has to set up config info for each specific slave they want to _allow_ to participate. It's more like a moderated mailing list that way ;-) A slave also needs to know a password (which the master's admin emails (for example) to the slave's admin if the former wants the latter to participate). ... One downside is that we seem unable to get an in-house Windows buildbot slave to work reliably, and so far don't even know whether that's because of Windows, the buildbot code, or flakiness in our internal network. It seems quite reliable on Linux, though. Well, it is written in Python so *someone* here should either be able to fix it or properly blame it on Windows. =) Yup! The idea of the PSF paying to have some machines set up to run consistent tests has come up multiple times. A brilliant part of the buildbot approach is that a sub-community claiming to care about a platform (major or not) can put a bit of resource where their mouth is by offering part-time use of a box to run the checkout/build/test dance. That way platform experts who presumably care about their platform are in charge of all aspects of setting their platform up. No centralized compile farm can work as well, unless it has enough money to buy machines-- and expert caretakers --for umpteen off-the-wall OS variations. I guess if someone complains about wanting better support for platform X we could then say that we don't have a buildbot slave for it and if they want to help the situation they can get one set up. =) I know Neal has said he would be willing to host the machines at his house before (but I think this may have been before his relocation to California). Looks like he's already running automated tests: http://docs.python.org/dev/results/ The various steps there could be defined as buildbot actions, and then run on any number of boxes whenever something changes. See, that is what threw me; thinking that when the master knows a change happens it pushes out to the slaves. I guess the master notes that there is a reason to do a new run and that is what the slaves are constantly checking with the master about. This whole situation of going two months without knowing that a major platform is broken shows that this is a real problem and ignoring it is probably not a good thing. =) It's generally true that the sooner you find out something has broken, the easier it is to repair it. For minor platforms, I'd say we have no idea whether the trunk has regressed wrt 2.4.2. There's simply no way to know without trying it. Right. Part of the reason AIX, I am sure, keeps breaking. If we ask for volunteer machines we could offer to put up company or personal names on the buildbot page of those who have volunteered CPU cycles. I am sure that will help motivate companies and people to install the software on a spare machine. Finding volunteers has been surprisingly (to me) difficult. Most (but not all) of the
Re: [Python-Dev] deque alternative (was: Linked lists)
On 12/25/05, Christian Tismer [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Python's philosophy about (built-in) data types, inherited from ABC, is to offer a few powerful clearly distinct choices rather than lots of alternatives with overlapping usages. This reduces the time it takes to choose a data type and reduces the risk of picking the wrong type. (You seem to be indicating that this is indeed what's happening to you in Lisp. :-) Speaking about the new dequeue type, I have the impression that this reasoning applies there a bit, too? Dequeues of course have applications, and I saw them used, especially by newcomers to the language. So I like their functionality. But actually, I'm not so convinced if we need to introduce a new datatype. How about an extension to normal lists that does a little tracking of use-cases and decides about changing its implementation upon the presence of inserts/deletes at the lower end of the list? I'm btw. not sure if this raises an implicit/explicitiness issue. My question is if it is necessary to put the burden about explicitly choosing a specialized two-ended list on the programmer, or if it is simple enough to make lists just do the right thing, if lists are used in a dequeue-style manner. Or is this maybe too much magic happening? IMO it's a little bit too much magic. Plus, if you pass these instances around e.g. between libraries, how could you determine with certainty the usage patterns without analysing the entire codebase? I think the user has to be involved. A problem I see now is that there is no way for me to indicate--whether there currently exists or not an appropriate data type with the desired characteristic-- whether I want an array (Python list) or a real list, both of which are really, really basic fundamental kinds of data structures with very different complexity characteristics. The source code I write does not carry this information and therefore if in the future it would become available there won't be an easy way to convert code to take advantage of this. This choice, is being made in the programmer's head, but the distinction blurred in the source code because lists are just not there. I still haven't had time to cook a proper reply to Guido, but one thing I see is that many ppl on the list seem to think that because there aren't many use cases (that they can see), therefore there isn't much use for a list collection type. I would instead argue that because the list type has never been available, people have gotten used not to use them, and therefore settle with arrays and do not see a need for them. When all you have is a hammer, everything seems to be a nail. When you don't have lists, you make do with arrays and you think it's ok (and it pretty much is, in the sense that Python, at least compared to C/LISP, is very slow, so it for the kinds of things you use it for, it does not matter all that much). When you're used to having lists available, you miss being able to express that the data structure you want should have the characteristics of a list, with the intended performance characteristics. Being able to select between a list and an array is like having a bit more vocabulary in natural languages. I would agree with the use case condition if we were talking about a very domain-specific collection type, but we're talking about lists here... it's really fundamental stuff... Also, there is something incredibly elegant and simple and compact about the cons cell, maybe all we need is a good simple cons cell type and a nice interface on it, so you get both single-linked lists and trees at the same time... (more after the xmas thing has passed) ___ 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] deque alternative (was: Linked lists)
At 09:10 PM 12/25/2005 -0500, Martin Blais wrote: I still haven't had time to cook a proper reply to Guido, but one thing I see is that many ppl on the list seem to think that because there aren't many use cases (that they can see), therefore there isn't much use for a list collection type. I would instead argue that because the list type has never been available, people have gotten used not to use them, and therefore settle with arrays and do not see a need for them. Since I routinely use 2-item tuples (twoples?) as cons cells when I actually need a linked list, I think I'm in a good position to say that this isn't true. Certainly it's not true for me. Since Python effectively has single-character operations for both consing and car/cdr (a ',' on the right or left sides of an assignment statement respectively), as well as trivial truth testing for () as a nil, suggests to me that anybody who wants a lispy list can easily have one. For any application where such a structure excels (like shared sublists/trees and recursive traversals), it's so darn easy to use them in Python that I don't think anything special is needed. Honestly, ISTM that the One Obvious Way to do lispy lists in Python is to just use two-tuples, with no special library functions. Sequence packing and unpacking is extremely fast in Python, too, probably faster than any method calls to a more heavyweight builtin type could be. Thus, I'm -1 on creating another cons type. Why do this: foo = cons(bar, None) car_foo = foo.car cdr_foo = foo.cdr when you can just do this: foo = bar, () car_foo, cdr_foo = foo How much simpler can you get? ___ 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] deque alternative (was: Linked lists)
On Sun, Dec 25, 2005, Martin Blais wrote: I still haven't had time to cook a proper reply to Guido, but one thing I see is that many ppl on the list seem to think that because there aren't many use cases (that they can see), therefore there isn't much use for a list collection type. Please take this to comp.lang.python Side note: nobody AFAICT has suggested that you drop this -- only that getting a built-in is extremely unlikely. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck. --USENET schmuck (aka Robert Kern) ___ 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] deque alternative (was: Linked lists)
[Martin Blais] ... Also, there is something incredibly elegant and simple and compact about the cons cell, maybe all we need is a good simple cons cell type and a nice interface on it, so you get both single-linked lists and trees at the same time... The first cons cell C extension for Python I know about was written in 1994: http://www.python.org/search/hypermail/python-1994q2/0110.html There have been others, but the audience for them appears so small that none catch on. Like Phillip Eby, I use 2-tuples for this when I feel the need (usually during a backtracking graph search, to keep track of paths back to the root in a space-efficient way), and am happy with that. ___ 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] Build failure and problem on Windows
[Thomas Heller] Building the svn trunk on Windows fails because Python\pyarena.c is missing in the pythoncore.vcproj file (I'm not yet up to speed with svn, otherwise I would have checked in a fix for this myself). Worse, when running the built exe it segfaults in Py_GetBuildInfo(), because it is picking up somehow a definition of #define BUILD 'b' (from cPickle.c? Could that be?) [also Thomas Heller] I should have known better, but BUILD is defined in the MSVC project file as BUILD=60. [Thomas Heller again] I've committed a fix for both (Hope these comments aren't off-topic nowadays for python-dev). Not at all, according to me. Nobody appears to be paying attention to Python under VC 7.1 these days, but what you did here certainly helped me when I got some time for it this weekend! Thank you. ___ 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] Automated Python testing (was Re: status of development documentation)
On Sun, 25 Dec 2005 16:54:44 -0800, Brett Cannon [EMAIL PROTECTED] wrote: On 12/25/05, Tim Peters [EMAIL PROTECTED] wrote: [Tim] Take a look at: http://buildbot.zope.org/ That runs code from: http://buildbot.sourceforge.net/ Someone sets up a buildbot master (that's what the Zope URL points at), and then any number of people can volunteer to set up their boxes as buildbot slaves. [Brett] As in some machine I might personally have left on? Slaves have to be powered on to work, yes ;-) That would require a static IP which I don't know how common that will be. Spend a few minutes skimming the buildbot docs -- I'm not an expert, but it's a real system in real use, and they have solutions for the obvious problems. In this case, while the master passes out commands to run and collects status, a slave _initiates_ communication with the master. A static IP for the master is good for that, but I figure the slave can keep participating happily then for just as long as it can keep a socket connection open with the master. OK, so it is a pull from the slave side, not a push on the master side. [snip] See, that is what threw me; thinking that when the master knows a change happens it pushes out to the slaves. I guess the master notes that there is a reason to do a new run and that is what the slaves are constantly checking with the master about. The whole world isn't HTTP. There is not necessarily any correlation between the party which initiates the TCP connection and the party which instigates a run. Slaves connect to the master when they come online. The master uses that connection to push commands to the slaves at the appropriate time. Buildbot also supports having multiple slaves perform runs (or builds, in buildbot terminology) for a particular configuration. This means that several people can cooperate to give full coverage for a particular platform, even if none of them can leave a machine on 24/7. You really do want 24/7 coverage for a supported platform, because utility declines rather rapidly as you fall short of this. Developers tend to have an amazing knack for committing broken changes when the slave which would have noticed them is offline :) Jean-Paul ___ 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] file() vs open(), round 7
Guido sez in http://mail.python.org/pipermail/python-dev/2004-July/045921.html that it is not correct to recommend using ``file()`` instead of ``open()``. However, because ``open()`` currently *is* an alias to ``file()``, we end up with the following problem (verified in current HEAD) where doing ``help(open)`` brings up the docs for ``file()``: help(open) Help on class file in module __builtin__: class file(object) | file(name[, mode[, buffering]]) - file object | | Open a file. The mode can be 'r', 'w' or 'a' for reading (default), [...] | Note: open() is an alias for file(). This is confusing. I suggest that we make ``open()`` a factory function right now. (I'll submit a bug report (and possibly a patch) after I get agreement.) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Don't listen to schmucks on USENET when making legal decisions. Hire yourself a competent schmuck. --USENET schmuck (aka Robert Kern) ___ 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] deque alternative (was: Linked lists)
Tim Peters [EMAIL PROTECTED] wrote: Like Phillip Eby, I use 2-tuples for this when I feel the need (usually during a backtracking graph search, to keep track of paths back to the root in a space-efficient way), and am happy with that. Then there's the whole Python list with append() and pop(). It takes a method resolution and function call, but at least in Python 2.3, it is a hair faster... - Josiah if 1: ... t = time.time() ... a = tuple() ... for i in xrange(100): ... a = (i, a) ... for i in xrange(100): ... i,a = a ... print time.time()-t ... 3.2858583 if 1: ... t = time.time() ... a = [] ... for i in xrange(100): ... a.append(i) ... for i in xrange(100): ... i = a.pop() ... print time.time()-t ... 3.0232943 ___ 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] Automated Python testing (was Re: status of development documentation)
Brett As in some machine I might personally have left on? That would Brett require a static IP which I don't know how common that will be. Nah, just use dyndns.org. 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
