Re: [Python-Dev] doc for new restricted execution design for Python
I wrote: Bob writes: Ack - sorry about that - the HTML mail confused me :) It was Brett, of course. Mark ___ 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] xturtle.py
[EMAIL PROTECTED] wrote: One other thought -- at PyCon, I talked with a group of educators. While they needed some minor tweaks to the Turtle module, there were no requests for an extensive rewrite or a fatter API. The name of the game was to have a single module with a minimal toolset supporting a few simple programs, just rich enough to inspire, but small enough to fit into tiny slots in the curriculum (one sixth grade class gets is allocated three 55 minute sessions to learn programming). which makes RUR-PLE a much better choice than turtles, really. /F ___ 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] PEP 328 and PEP 338, redux
Guido van Rossum wrote: On 6/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: The workaround to replace __name__ with __module_name__ in order to enable relative imports turned out to be pretty ugly, so I also worked up a patch to import.c to get it to treat __module_name__ as an override for __name__ when __name__ == '__main__'. Ah, clever. +1. In that case, I'll check it straight in. It was actually surprisingly easy to do, given how finicky import.c can get (this particular change was able to be handled entirely inside get_parent()). So given a test_foo.py that started like this: import unittest import ..foo Um, that's not legal syntax last I looked. Leading dots can only be used in from ... import. Did you change that too? I really hope you didn't! It's OK - I just spelt it wrong in the example. It should have said from .. import foo. 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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
On 6/28/06, Gregor Lingl [EMAIL PROTECTED] wrote: I made xturtle.py and that was a big effort. And I offer it to replace turtle.py. I do this because I'm a Python enthusiast and I want a better Python. (And I know very well that my contribution is rather marginal). We all, I think, have this motive. And of course it was my fault to submit it too late. I am certainly interested in your module, and will have a look at it in due course (to use it, not as a review for inclusion in Python). So, if you can't accept that offer - now, or even ever - , because it contradicts your rules, that's o.k. But it's not 'my cause'. I concieve it to be the community's cause. It's purely a timing issue. You offered the module just before the Python 2.5 feature freeze. At that point in time, a brand new module intended to replace an existing one is almost certainly going to be rejected, simply from time constraints. I see no reason at all why you can't offer the module for Python 2.6, however. The only point is, that it leaves Python's turtle.py an (imho) unsatisfactory solution. Please be aware that *someone* will need to champion your module for inclusion into Python 2.6 As Martin points out, review will require some effort - and particularly if the proposal is to replace turtle.py rather than sitting alongside it. It will be necessary to persuade one of the core developers to care enough to spend time on this. They are all doing this in their spare time, and have their own interests which will come first. I know from experience that getting developer time is hard. It's possible that it would help to leave the module as an external project for a while, until enough other people in the Python community have acknowledged its usefulness, and can testify that it gives them no issues. At that point, the job of a reviewer becomes much easier (there's a user base confirming most of the things a reviewer has to consider) and so it is more likely that your module will be accepted. 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
Re: [Python-Dev] PEP 328 and PEP 338, redux
Giovanni Bajo wrote: Guido van Rossum wrote: This is where I wonder why the def __main__() PEP was rejected in the first place. It would have solved this problem as well. Could this be reconsidered for Py3k? You have a point. AFAICT, there's nothing preventing it from being added in 2.6. It won't break existing code with the if name == main paradigm. Writing modules that use the approach but want to work with both 2.5 and 2.6 becomes a little more annoying - such modules have to finish with the coda: if __name__ == '__main__': from sys import version_info, argv if version_info (2, 6): sys.exit(__main__(argv)) The interpreter would also have to be careful to ensure that a __main__ variable in the globals isn't the result of a module doing import __main__. The above two reasons are what got PEP 299 killed the first time (the thread is even linked from the PEP ;). Another downside I've discovered recently is that calling sys.exit() prevents the use of a post-mortem debugging session triggered by -i or PYTHONINSPECT. sys.exit() crashes out of the entire process, so the post-mortem interactive session never even gets started. The only real upside I can see to PEP 299 is that main is a function is more familiar to people coming from languages like C where you can't have run-time code at the top level of a module. Python's a scripting language though, and having run-time logic at the top level of a script is perfectly normal! 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] RFC: trunk checkins between now and 2.5 final
Anthony Baxter wrote: Anyway, this is the current thinking. Am I being too dogmatic here? Comments solicited. Seems like a fair policy to me. As far as people to sign off on things, Neal, myself or Guido should be the ones to do it. Course, Guido will probably decide he doesn't want this dubious honour wink. I consider the proposed import change (looking for __module_name__ in the main module) a bug fix for the interaction between PEP 338 and 328, but I'll hold off on committing it until I get the OK from yourself or Neal (and put the patch on SF in the meantime). 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] RFC: trunk checkins between now and 2.5 final
Nick Coghlan wrote: I consider the proposed import change (looking for __module_name__ in the main module) a bug fix for the interaction between PEP 338 and 328, but I'll hold off on committing it until I get the OK from yourself or Neal (and put the patch on SF in the meantime). Or maybe not, since SF is still broken :( You can find the diff here instead: http://members.iinet.net.au/~ncoghlan/main_relative_imports.diff The patch includes updates to import.c so that relative imports from a main module executed with -m will work automatically, some additional tests in test_runpy to make sure this all works as intended, and a couple of paragraphs in the tutorial about using explicit relative imports instead of implicit ones. The changes to make runpy set '__module_name__' as well as '__name__' (and the associated doc and test changes) have already been committed. 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] PEP 3103: A Switch/Case Statement
Greg Ewing wrote: Nick Coghlan wrote: By 'current namespace' I really do mean locals() - the cell objects themselves would be local variables from the point of view of the currently executing code. This is wrong. Cells are *parameters* implicitly passed in by the calling function. They may temporarily be referenced from the current scope, but their home has to be in an outer scope, otherwise they won't survive between calls. As far as I'm aware, the cell objects get kept alive by the references to them from the closure attribute of the inner function. The actual execution frame of the outer function still goes away. The cell values persist because the function object persists between calls - it's only the execution frame that gets reinitialised every time. However, I'm now clearer on the fact that Guido's main interest is in true once-per-process semantics for case expressions, which changes the design goals I was working towards. So I think I'll try to take a break from this discussion, and let ideas percolate in the back of my head for a while :) 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] PEP 328 and PEP 338, redux
Nick Coghlan wrote: Writing modules that use the approach but want to work with both 2.5 and 2.6 becomes a little more annoying - such modules have to finish with the coda: if __name__ == '__main__': from sys import version_info, argv if version_info (2, 6): sys.exit(__main__(argv)) Actually, this should be enough: if __name__ == '__main__': sys.exit(__main__(argv)) and it will still work for the python -mpackage.module case which we're discussing about. The if suite can be dropped when you won't need pre-2.6 compatibility anymore. The interpreter would also have to be careful to ensure that a __main__ variable in the globals isn't the result of a module doing import __main__. Real-world usage case for import __main__? Otherwise, I say screw it :) Another downside I've discovered recently is that calling sys.exit() prevents the use of a post-mortem debugging session triggered by -i or PYTHONINSPECT. sys.exit() crashes out of the entire process, so the post-mortem interactive session never even gets started. In fact, this is an *upside* of implementing the __main__ PEP, because the call to sys.exit() is not needed in that case. All of my Python programs right now need a sys.exit() *because* the __main__ PEP was not implemented. The only real upside I can see to PEP 299 is that main is a function is more familiar to people coming from languages like C where you can't have run-time code at the top level of a module. Python's a scripting language though, and having run-time logic at the top level of a script is perfectly normal! My personal argument is that if __name__ == '__main__' is totally counter-intuitve and unpythonic. It also proves my memory: after many years, I still have to think a couple of seconds before rememebering whether I should use __file__, __name__ or __main__ and where to put the damn quotes. The fact that you're comparing a variable name and a string literal which seems very similar (both with the double underscore syntax) is totally confusing at best. Also, try teaching it to a beginner and he will go huh wtf. To fully understand it, you must understand how import exactly works (that is, the fact that importing a module equals evaluating all of its statement one by one). A function called __main__ which is magically invoked by the python itself is much much easier to grasp. A different, clearer spelling for the if condition (like: if not __imported__) would help as well. -- Giovanni Bajo ___ 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] PEP 3103: A Switch/Case Statement
Eric Sumner wrote: Forget subroutines for a moment - the main point of the thread was the idea that the dispatch table was built explicitly rather than automatically - that instead of arguing over first-use vs. function-definition, we let the user decide. I'm sure that my specific proposal isn't the only way that this could be done. But anything that makes the build explicit is going to be so much more ugly. And I still think you're trying to solve the wrong problem. Only if the programmer has to see it. The dispatch table need not include the behaviors of each of the cases; it only needs to define what the cases are. In most of the use cases I've seen, switch is used to define behavior for different values of an enumeration. The dispatch table for an enumeration can be built wherever the values for the enumeration are defined (such as in a module). Programmers don't need to bother with making a dispatch table unless they are defining enumeration values themselves. You mean something like this?: switch x in colours: case RED: # whatever case GREEN: # whatever case BLUE: # whatever I think Guido's right. It doesn't solve the underlying problem because the compiler still has to figure out how to build a dispatch table from the possible values in colours to the actual bytecode offsets of the cases. 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] [Python-checkins] r47142 - in python/trunk: Doc/lib/librunpy.tex Lib/runpy.py Lib/test/test_runpy.py
Anthony Baxter wrote: On Wednesday 28 June 2006 20:41, nick.coghlan wrote: Author: nick.coghlan Date: Wed Jun 28 12:41:47 2006 New Revision: 47142 Modified: python/trunk/Doc/lib/librunpy.tex python/trunk/Lib/runpy.py python/trunk/Lib/test/test_runpy.py Log: Make full module name available as __module_name__ even when __name__ is set to something else (like '__main__') Er. Um. Feature freeze? Sorry about that - I was trying to deal with a conflict between PEP 328 and 338 (bug 1510172) and didn't even think about the fact that this counted as a new feature. See my response to your RFC about tightening up control of the trunk - I'd really like to make these two PEPs play nicely together before beta 2. 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] once [was: Simple Switch statementZ]
Guido van Rossum wrote: So we have what seems to be an impasse. Some people would really like once-expressions to be captured at def-time rather than at the first execution per def; this is the only way to use it so solve the outer loop variable reference problem. Others would really hate it if a once could be hidden in unreachable code but still execute, possibly with a side effect. I'm not sure that the possibility of writing obfuscated code should kill a useful feature. What do others think? It's basically impossible to prevent obfuscated code and we've had this argument before: preventing bad code is not the goal of the language; encouraging good code is. I'm coming around to liking the idea of Fredrik's static expressions. def-time really is a clean way to define when something happens, it provides a nice readable solution to the early-vs-late binding question, and the only ways I've managed to break it are by deliberately writing code that's altogether too clever for its own good. It should be possible to find some reasonable way to handle module level code, and pychecker and the like can warn about static expressions in unreachable code. I even worked out how to rewrite my side-effect-free-but-still-too-clever-for-its-own-good example so it worked under Option 3: def outer(cases=None): if cases is None: # Use unmatchable cases cases = [() for x in range(3)] def inner(option, force_default=False): if not force_default: switch option: case in cases[0]: # case 0 handling case in cases[1]: # case 1 handling case in cases[2]: # case 2 handling # Default handling return inner I'm happy I've made the best case I can for Option 2, and it's left even me thinking that Option 3 is a cleaner, more useful way to go :) 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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: So, if you can't accept that offer - now, or even ever - , because it contradicts your rules, that's o.k. But it's not 'my cause'. I concieve it to be the community's cause. All we said is that we cannot integrate it now, as a policy matter. Nobody said it can't be integrated for 2.6; I am in favour of doing that. However, I do think that a number of changes need to be made still; I'll post my first review on the SF tracker item when SF comes back. I, for my part, can and will use xturtle.py, knowing and having the experience, that it is far superior to turtle.py. So I have no problem. And I'll offer it for download from the xturtle-webpage or from wherever you suggest. So it will be freely available. (Perhaps a sourceforge project would be appropriate. Give me your advice, please) You should add it into the Cheeshop: python.org/pypi Notice that the Cheeseshop already knows about turtle2.py by Mark Summerfield. The only point is, that it leaves Python's turtle.py an (imho) unsatisfactory solution. Looking at the feature list on #1513695, I think none of the new feature really make turtle.py look unsatisfactory: - better animation of turtle movements: yes, this is a good thing to have, but not absolutely necessary. The current turtle already displays the orientation after it has turned. - different turtle shapes. It's probably fun to play with these, but (IMO) a distraction from the module's primary purpose (although fun certainly also is a purpose of the module). OTOH, perhaps the original Logo turtle icon should be the default? - fine control over turtle movement (in particular speed) Why are these needed? - Aliases for the most common functions. I guess it's useful, but if it was unsatisfactory not to have them, somebody would have contributed a patch for turtle.py already. - scrollable canvas. I had a hard time to figure out what method to use to resize the canvas (and am still uncertain whether rescaling is supported or not) - background color and image. Again, this looks like a distraction to me, but I see that Logo tutorials use this (along with turtle shapes like C64 sprites), so I guess there is a point to them, also. The only respect in which I would consider turtle.py unsatisfactory is the true bugs. At the moment, I can only see one open turtle.py bug reported, namely #1047540 (where the submitter later says it might be an IDLE bug). 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
[Python-Dev] msvccompiler.py: some remarks
I am testing/working on some Python code on Windows. During this I encounter some issues where I am being told I don't have the .Net SDK installed. So I started investigating this issue and came to http://www.vrplumber.com/programming/mstoolkit/index.html I also checked the latest repository version of msvccompiler.py and I noticed a few potential issues: 1) If MSSdk is set it does not automatically mean that cl.exe and the rest are available. With the latest SDKs, Windows 2003 R2 at least, the bin directory contains no compilers, linkers or the like. On the other hand, it is perfectly valid to set MSSdk to your Platform SDK installation directory. So this is unfortunately a problematic solution as introduced in revision 42515. 2) As far as I have been able to determine .Net 2.0 uses sdkInstallRootv2.0. Also it installs by default under C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\ 3) The Windows 2003 R2 Platform SDK uses HKLM\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDKs\D2FF9F89-8AA2-4373-8A31-C838BF4DBBE1, which in turn has a entry for 'Install Dir' which lists the installation directory for the Platform SDK. 4) One line has p = rSoftware\Microsoft\NET Framework Setup\Product, however, there's no subkey at all under my NET Framework Setup entry, only NDP, which in itself has two subkeys, namely: v1.1.4322 and v2.0.50727. The NET Framework Setup\Product seems to be limited to the old 1.0 setup which used a subkey like: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\Product\Microsoft .NET Framework Full v1.0.3705 (1033) This is what my 1.1 and 2.0 give: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v1.1.4322 and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727 So effectively on newer installations (and 1.0 is more or less deprecate in favour of 1.1) this piece of code is rendered unusable. So basically a bunch of logic needs to be rewritten for newer version support and I will investigate this. Are there any other people working on this so that I can throw back/forth some ideas to make sure things keep working for various versions? -- Jeroen Ruigrok van der Werven ___ 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] once [was: Simple Switch statementZ]
I haven't followed the complete discussion about once, but I would assume it would be used as such: once name = expression that is, always an assignment, with the value stored as a cellvar, perhaps, on first execution 0f the code. Typically I would use it as: def function(a): once pathjoin = os.path.join etc ___ 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] PEP 3103: A Switch/Case Statement
On 6/29/06, Nick Coghlan [EMAIL PROTECTED] wrote: You mean something like this?: switch x in colours: case RED: # whatever case GREEN: # whatever case BLUE: # whatever I think Guido's right. It doesn't solve the underlying problem because the compiler still has to figure out how to build a dispatch table from the possible values in colours to the actual bytecode offsets of the cases. To implement this, you actually need two lookup tables: one particular to the switch that maps labels to bytecode offsets, and one in the dispatch table to map values to labels. The former is built when the switch is compiled, and the latter is built wherever the dispatch table is defined. Each lookup is still O(1), so the whole operation remains O(1). It is O(n) or worse to check that all of the cases in the switch are defined in the dispatch table, but that only has to be done once per dispatch table/switch statement pair, and can then be stred in one or the other (probably the dispatch table, as that will be a proper object). -- Eric Sumner ___ 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] PEP 3103: A Switch/Case Statement
Eric Sumner wrote: You mean something like this?: switch x in colours: case RED: # whatever case GREEN: # whatever case BLUE: # whatever I think Guido's right. It doesn't solve the underlying problem because the compiler still has to figure out how to build a dispatch table from the possible values in colours to the actual bytecode offsets of the cases. To implement this, you actually need two lookup tables: one particular to the switch that maps labels to bytecode offsets, and one in the dispatch table to map values to labels. The former is built when the switch is compiled, and the latter is built wherever the dispatch table is defined. Each lookup is still O(1), so the whole operation remains O(1). what's a label ? /F ___ 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] PEP 328 and PEP 338, redux
On Thursday 29 June 2006 20:56, Nick Coghlan wrote: Guido van Rossum wrote: On 6/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: The workaround to replace __name__ with __module_name__ in order to enable relative imports turned out to be pretty ugly, so I also worked up a patch to import.c to get it to treat __module_name__ as an override for __name__ when __name__ == '__main__'. Ah, clever. +1. In that case, I'll check it straight in. It was actually surprisingly easy to do, given how finicky import.c can get (this particular change was able to be handled entirely inside get_parent()). Please, please DON'T. At this point in the release cycle, making a change like this without review (particularly to something as diabolically hairy as import.c) is going to make me _unbelievably_ cranky. I'll try to make time to review the patch you posted tomorrow. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] PEP 3103: A Switch/Case Statement
You mean something like this?: switch x in colours: case RED: # whatever case GREEN: # whatever case BLUE: # whatever I think Guido's right. It doesn't solve the underlying problem because the compiler still has to figure out how to build a dispatch table from the possible values in colours to the actual bytecode offsets of the cases. To implement this, you actually need two lookup tables: one particular to the switch that maps labels to bytecode offsets, and one in the dispatch table to map values to labels. The former is built when the switch is compiled, and the latter is built wherever the dispatch table is defined. Each lookup is still O(1), so the whole operation remains O(1). what's a label ? In your example, RED, GREEN, and BLUE. colours provides a mapping from values to labels/cases, and the switch statement provides a mapping from labels/cases to code. Sorry about introducing a new term without saying anything about it. -- Eric Sumner ___ 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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Martin v. Löwis schrieb: Gregor Lingl wrote: ... (Who reviewed it? This is a _newly_added_ function - did nobody try it out yet? Incredible!!) Apparently not. Thanks for pointing that out; Georg (who committed the patch originally) just fixed it in r47151. This illustrates the main point: Even small changes need careful review. Much more so large changes. I understand that now. [turtle does not just fill the shape, but the entire boundary polygon] What a shame!! An immanent bug, persistent for years now! If the bug had existed for years, somebody could have contributed a patch. I've 2 remarks on this point: (i) apparingly turtle.py isn't used that much, that things like these come out necessarily (ii) I had a discussion with Vern Ceder about exactly this point (on edupython list). He had the opinion, that this couldn't be fixed. Somebody else promised to fix it anyway, but he didn't. ... It's not only about finding bugs. It's also about studying the consistency of the new API, and so on. That's right and very important. I would be very happy to have somebody to discuss questions like these. It was not so easy to make all those decisions, and I know, of course, others necessarily would have decided differently in some points. One question in this respect - how important do you consider backward compatibility. When designing a new module the requirement backward copmpatibility can have a big impact on the code although it may in some parts be questionable. As an example let me mention the radians() function. As for reliable proofs: An automatic test suite for turtle.py would be a good thing to have. Yes,, and I have some ideas in this respect, but mainly a prioncipal question. I read about using doctest and unittest, but how does one devise automatic test suites for graphical output. In the end it depends on how it looks like. That was one reason, why I made my example scripts. I use them for (not automatic) testing and I can _see_ if things go wrong. Example: how do you test automatically if a shape is filled correctly or not (as in the above mentioned bug)? A more courageous and less bureaucratic approach to the problem would be appropriate. Perhaps combined with some fantasy. ... The approach used in xturtle (i.e. represent circles as polylines) could also be used for turtle.py, no? Yes. I've done that patch right now, and I'll put it (as a suggestion) on the path manger, along with a test script, when it's online again. It works as expected. See if you like it. Believe it or not, when testing this patch I discovered (within half an hour) three more bugs of turte.py: I did the following interactive session: from turtle import * circle(100,90) radians() circle(100, pi/2) two bugs occured: (i) after calling radians() the turtle moves a wrong path (I assume because of misinterpretation of its heading, which doesn't know of the change of units) (as it does when executing e. g. forward(50) (ii) it doesn't draw the arc(!) (if as up() were given - I don't know why) restoring degrees() it draws again. In the meantime I had put the drawing window away from the center to be better able to use the Shell window. When I constructed a new Pen: p = Pen() (ii) the graphcis window jumped into the screencenter again (and it does so with every newly constructed Pen). Apparently one shouldn't have setup() called in Pen's __init__() method. This again seems to be a newly introduced bug. I'll put them on the bug manager, when it's online again. Regards, Gregor 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] PEP 3103: A Switch/Case Statement
Eric Sumner wrote: what's a label ? In your example, RED, GREEN, and BLUE. colours provides a mapping from values to labels/cases, and the switch statement provides a mapping from labels/cases to code. Sorry about introducing a new term without saying anything about it. yeah, but what are they? integers? strings? names without an associated value? how do you create new labels? where are they stored? who keeps track of them? /F ___ 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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: One question in this respect - how important do you consider backward compatibility. When designing a new module the requirement backward copmpatibility can have a big impact on the code although it may in some parts be questionable. As an example let me mention the radians() function. It's fairly important. Text books have been written that refer to the turtle module; the examples in these text books must continue to work. As we don't know what features these examples use, we must rather err on the conservative side, breaking the API only for a very good reason. Yes,, and I have some ideas in this respect, but mainly a prioncipal question. I read about using doctest and unittest, but how does one devise automatic test suites for graphical output. It might be ok not to verify the output. OTOH, this is a canvas widget, so it should be possible to get all items on the screen at any point with primitive canvas methods. These could then be compared to precompiled lists. In the end it depends on how it looks like. That was one reason, why I made my example scripts. I use them for (not automatic) testing and I can _see_ if things go wrong. Example: how do you test automatically if a shape is filled correctly or not (as in the above mentioned bug)? You could check whether there is a polygon with the right shape, where right is specified by a series of coordinates. This is regression testing, and perhaps also coverage: we want to know whether changes to the module effect the current behaviour. When we test discovers a behaviour change, somebody manually will have to determine whether the test is wrong or the new code, and update the test if it is the former. Thanks your investigations about the current turtle.py. 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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: Yes,, and I have some ideas in this respect, but mainly a prioncipal question. I read about using doctest and unittest, but how does one devise automatic test suites for graphical output. In the end it depends on how it looks like. There are a few options here.. Two that come to mind are: - Check the output -- e.g., run a demo, and then use Tkinter.Canvas to write its output to postscript, and then check the contents of that postscript file against a known correct file. - Monkey-patching -- replace specific classes (e.g., ScrolledCanvas?) with new testing classes that simply intercept drawing primitives, rather than displaying graphics. Then check that the right drawing primitives (lines, circles, etc) are generated in the right order. The former may be more robust, but requires that you have a display surface available. With the former approach, you may also run into some problems with different postscript files being generated on different systems (esp. with respect to font sizes -- I seem to remember that using negative font sizes might help there?). -Edward ___ 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] PEP 3103: A Switch/Case Statement
yeah, but what are they? integers? strings? names without an associated value? how do you create new labels? where are they stored? who keeps track of them? In this scheme, dispatch tables can be considered to be reverse-lookup namespaces. Where a regular namespace is used to look up a value given its name, a dispatch table is used to look up a name given its value. The switch statement then lets you actually do something based on which name is returned. -- Eric Sumner ___ 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] Joke: Rush Limbaugh (a joke in and of himself)
Rush Limbaugh was detained and questioned for transporting a possible illegal Viagra prescription into the country. Well... a least we know his back is feeling better. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] PEP 328 and PEP 338, redux
On 6/29/06, Giovanni Bajo [EMAIL PROTECTED] wrote: Real-world usage case for import __main__? Otherwise, I say screw it :) [...] My personal argument is that if __name__ == '__main__' is totally counter-intuitve and unpythonic. It also proves my memory: after many years, I still have to think a couple of seconds before rememebering whether I should use __file__, __name__ or __main__ and where to put the damn quotes. The fact that you're comparing a variable name and a string literal which seems very similar (both with the double underscore syntax) is totally confusing at best. Also, try teaching it to a beginner and he will go huh wtf. To fully understand it, you must understand how import exactly works (that is, the fact that importing a module equals evaluating all of its statement one by one). A function called __main__ which is magically invoked by the python itself is much much easier to grasp. A different, clearer spelling for the if condition (like: if not __imported__) would help as well. You need to watch your attitude, and try to present better arguments than I don't like 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
[Python-Dev] document @property?
In followup to a clpy discussion, should the docs contain a note that property can be used as a decorator for creating read-only properties? Georg ___ 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] Joke: Rush Limbaugh (a joke in and of himself)
On Thu, Jun 29, 2006, Scott David Daniels wrote: Rush Limbaugh was detained and questioned for transporting a possible illegal Viagra prescription into the country. Well... a least we know his back is feeling better. I'm hoping this was a typo of an e-mail address for sending, because this is not appropriate for python-dev. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes ___ 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] Proposal to eliminate PySet_Fini
Fredrik Lundh fredrik at pythonware.com writes: given that CPython has about a dozen Fini functions, what exactly is it that makes PySet_Fini so problematic ? I have not been bitten by the other _Fini yet. ;-) I was bitten by PySet_Fini when I tried to replace the interned dict with a set. Since setobject is finalized before stringobject, interpretor crashed when cleaning interned. I feel that set is a more basic object than dict, but dictobject module is never finalized (is this a bug or a feature?), so dict api functions are always safe. For example, I can use dict API in atexit callbacks, but not set API. ___ 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] PEP 328 and PEP 338, redux
Guido van Rossum wrote: Real-world usage case for import __main__? Otherwise, I say screw it :) [...] My personal argument is that if __name__ == '__main__' is totally counter-intuitve and unpythonic. It also proves my memory: after many years, I still have to think a couple of seconds before rememebering whether I should use __file__, __name__ or __main__ and where to put the damn quotes. The fact that you're comparing a variable name and a string literal which seems very similar (both with the double underscore syntax) is totally confusing at best. Also, try teaching it to a beginner and he will go huh wtf. To fully understand it, you must understand how import exactly works (that is, the fact that importing a module equals evaluating all of its statement one by one). A function called __main__ which is magically invoked by the python itself is much much easier to grasp. A different, clearer spelling for the if condition (like: if not __imported__) would help as well. You need to watch your attitude, and try to present better arguments than I don't like it. Sorry for the attitude. I though I brought arguments against if __name__: - Harder to learn for beginners (requires deeper understanding of import workings) - Harder to remember (a string literal compared to a name with the same naming convention) - Often requires explicit sys.exit() which breaks python -i - Broken by -mpkg.mod, and we ended up with another __magic_name__ just because of this. - (new) Defining a main() function is already the preferred style for reusability, so __main__ would encourage the preferred style. If you believe that these arguments collapse to I don't like it, then no, I don't have any arguments. -- Giovanni Bajo ___ 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] document @property?
On Thursday 29 June 2006 14:31, Georg Brandl wrote: In followup to a clpy discussion, should the docs contain a note that property can be used as a decorator for creating read-only properties? I certainly wouldn't object. This is a very handy feature of property that I use frequently. -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] document @property?
Georg Brandl wrote: In followup to a clpy discussion, should the docs contain a note that property can be used as a decorator for creating read-only properties? feel free to steal the extended example and the read-only example from the pyref wiki: http://pyref.infogami.com/property /F ___ 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] doc for new restricted execution design for Python
On 6/28/06, Mark Hammond [EMAIL PROTECTED] wrote: Bob writes: I don't know how _javascript_ is doing it yet.The critical thing for me for this month was trying to come up with a security model.I don't fully understand how JS does it either, certainly not in any detail. I know that it uses the concept of a principal (the IDL file can be seenat http://lxr.mozilla.org/seamonkey/source/caps/idl/nsIPrincipal.idl ) and Ithink that the absence of any principals == trusted code.I believe theprincipals are obtained either from the JS stack, or from the event sourceand a few other obscure exceptions.There is also lots of C code littered with explicit is this code trusted calls that makes implicit and explicit_javascript_ assumptions - not particularly deep assumptions, but they exist.Yeah. Luckily I am interning at Google this summer and so I have access to some Mozilla people internally to get help in pointing me in the right direction. =) Cross-language calls will also need consideration.JS will be able toimplicitly or explicitly call Python functions, which again will implicitly or explicitly call JS functions.Some of those frames will always beunrestricted (ie, they are components - often written in C++, they can do*anything*), but some will not.We have managed to punt on that given that Python is currently always unrestricted.How to work with JS will need to be dealt with eventually. In the early stages though, Mozilla is happy to have Python enabled only fortrusted sources - that means it is limited to Mozilla extensions, or even acompletely new app using the Mozilla framework.From a practical viewpoint, that helps mozilla the platform more than it helps firebox the browseretc.This sandboxing would help the browser, which is great!Yep! Also, to help with the contribution to the field part of my dissertation I hope to help develop ways to make developing web apps with Python easier and better than with JS. So the goal is to just make it a no-brainer to dev with Python on the web. I'm confident that when the time comes we will get the ear of Brendan Eich to help steer us forward.Cool.Mark, can you email me (publically or privately, don't care) links and stuff about pyXPCOM so that when I start working on stuff I know where you are at and such with integration? Obviously I want to keep you in the loop overall on this whole endeavour. -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] once [was: Simple Switch statementZ]
Christos Georgiou wrote: I haven't followed the complete discussion about once, but I would assume it would be used as such: once name = expression that is, always an assignment, with the value stored as a cellvar, perhaps, on first execution 0f the code. Typically I would use it as: def function(a): once pathjoin = os.path.join etc In the name = (once expr) form I gave, the property of a constant name that can't be rebound or that of a value that persists across function call invocations isn't needed. I was trying to separate the different behaviors cleanly and clearly. # once as constant assignment and skipped line later. for n in range(x, 10): once startcube x**3 # assigns constant value, skips later print startcube startcube += 1 # give an exception So this is the same as const startcube x**3, except it's ignored if it is executed again instead of giving an excepton. Here the constantness property isn't needed. # once as calc once, use result many times expression. for n in range(x, 10): startcube = (once x**3) # calculated once used many print startcube startcube += 1 # Ok to do this I wasn't suggesting which behavior (or combination of) is correct. That would depend on what problem is meant to solved. A fourth property of external has been touched on in these threads where some of the suggestions require doing a calculation on a yet to be known value. That's usually handled by linkers in other languages and probably isn't something desired in a dynamic language like Python. Cheers, Ron * I may not be able to reply, do to leaving on a trip. Already should be gone. ;-) ___ 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] Joke: Rush Limbaugh (a joke in and of himself)
Aahz wrote: On Thu, Jun 29, 2006, Scott David Daniels wrote: a quoted joke. I'm hoping this was a typo of an e-mail address for sending, because this is not appropriate for python-dev. This absolutely was a matter of clicking the wrong spot. I completely agree it would be inappropriate for this forum. I retracted it as soon as I could, and I apologize to the group. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] For sandboxing: alternative to crippling file()
I have gotten some questions from people about why cripple 'file' (and probably 'socket' if they cared), asking whey I didn't just remove the 'file' built-in from built-ins. Problem is that I still want to provide some protection for files. So an option I have been thinking of is making sure 'file' does not end up in built-ins by just not inserting it into tstate-interp-builtins (see Include/pystate.h to see what other fields there are; also will answer Trent's question about how heavy, roughly, interpreters are). Then, there can be a file delegator class that can, at the C level, store a reference to the actual 'file' object that is open. Finally, handling whether a path is legal or not can be handled by open(). And the open() thing is the key here. Guido always talks about how open() should be treated more like a factory function that could some day return the proper object based on its argument. Well, perhaps we should start doing that and add support for HTTP addresses and IP addresses. Then the file and networking settings can be viewed more as global settings to be followed for file handling instead of specific restrictions placed on the 'file' and socket types. My worry, as has been from the start, is containing 'file'. The ``del __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff from the built-in namespace. And knowing how easy it tends to be to get at objects and types in Python in general makes me worry even more about hiding objects and types properly from people (within reason, of course; if you want to allow blatent 'file' access we should be able to give it to you somehow). But perhaps removing 'file' from the builtin dict in the PyInterpreterState state is enough to hide the type. So, my question to python-dev, is:1) Is removing 'file' from the builtins dict in PyInterpreterState (and maybe some other things) going to be safe enough to sufficiently hide 'file' confidently (short of someone being stupid in their C extension module and exposing 'file' directly)? 2) Changing open() to return C-implemented delegate objects for files (and thus won't type check, but this is Python so I am not worried about that too much) and delegate socket objects for IP and URL addresses. Basically, do people think doing this instead of modifying the 'file' object directly and crippling is better and safer in terms of possible security breach issues from implementing this?-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] For sandboxing: alternative to crippling file()
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote: My worry, as has been from the start, is containing 'file'. The ``del __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff from the built-in namespace. And knowing how easy it tends to be to get at objects and types in Python in general makes me worry even more about hiding objects and types properly from people (within reason, of course; if you Random, only tangentially-related thought: what if each interpreter had a blacklist of objects that should never be made available to untrusted code? You could then put __builtins__, file, and anything else on this list. Then, using some #ifdef'ery in ceval.c, check if an object is on this blacklist before pushing it onto the evaluation stack; if it's a blacklisted object, replace it with None (or raise an exception). This entails a performance hit and makes it impossible to support Bastion-like functionality, where untrusted code could call code that would be treated as trusted, but it also means that, even if you find some type(foo).__dict__['blah'].co_magic incantation that lets you get to a dangerous type object or module, it wouldn't matter because the dangerous value is silently substituted, and the untrusted code has no way of breaking out of this. (Could you fool a C extension into doing stuff with a dangerous object? Don't know...) This thought was sparked by the piece on failure-oblivious computing in today's Linux Weekly News about this paper: http://www.usenix.org/events/osdi04/tech/rinard.html. The authors tried continuing to run after a memory error instead of segfaulting: out-of-bounds writes were ignored, and OOB reads returned generated values. See the LWN discussion for more (subscribers only). --amk ___ 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] For sandboxing: alternative to crippling file()
On 6/29/06, A.M. Kuchling [EMAIL PROTECTED] wrote: On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote: My worry, as has been from the start, is containing 'file'.The ``del __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff from the built-in namespace.And knowing how easy it tends to be to get at objects and types in Python in general makes me worry even more about hiding objects and types properly from people (within reason, of course; if you Random, only tangentially-related thought: what if each interpreterhad a blacklist of objects that should never be made available tountrusted code?You could then put __builtins__, file, and anythingelse on this list.Then, using some #ifdef'ery in ceval.c, check ifan object is on this blacklist before pushing it onto the evaluationstack; if it's a blacklisted object, replace it with None (or raise anexception).Huh. Interesting idea. I would go with the exception position (pushing None feels very Lua/_javascript_-like), This entails a performance hit and makes it impossible to supportBastion-like functionality, where untrusted code could call code that would be treated as trusted, but it also means that, even if you findsome type(foo).__dict__['blah'].co_magic incantation that lets you getto a dangerous type object or module, it wouldn't matter because the dangerous value is silently substituted, and the untrusted code has noway of breaking out of this.(Could you fool a C extension into doingstuff with a dangerous object?Don't know...)Yeah, that would definitely help with the issue. And I am not even thinking of Bastion functionality. If you want something like that, write a delegate in C. And this could be extended so that a list of objects that should be banned could be added to and checked as needed. Performance would drop, but I don't know by how much. This thought was sparked by the piece on failure-oblivious computingin today's Linux Weekly News about this paper:http://www.usenix.org/events/osdi04/tech/rinard.html .The authorstried continuing to run after a memory error instead of segfaulting:out-of-bounds writes were ignored, and OOB reads returned generatedvalues.See the LWN discussion for more (subscribers only). Thanks for the link, Andrew!-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] msvccompiler.py: some remarks
Jeroen Ruigrok van der Werven wrote: I am testing/working on some Python code on Windows. During this I encounter some issues where I am being told I don't have the .Net SDK installed. So I started investigating this issue and came to http://www.vrplumber.com/programming/mstoolkit/index.html We should remove/change this comment. It is utterly misleading. 1) If MSSdk is set it does not automatically mean that cl.exe and the rest are available. With the latest SDKs, Windows 2003 R2 at least, the bin directory contains no compilers, linkers or the like. On the other hand, it is perfectly valid to set MSSdk to your Platform SDK installation directory. So this is unfortunately a problematic solution as introduced in revision 42515. I meant to leave this as a per-shell choice. If you set MSSdk, you indicate that the environment you created is right, and distutils should not second-guess you. This is problematic if the user did register environment variables when installing the SDK, so I plan to change this to look for a different environment variable (in addition) 2) As far as I have been able to determine .Net 2.0 uses sdkInstallRootv2.0. Also it installs by default under C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\ Forget about Visual Studio 8 and .NET 2.0. It won't help here. 3) The Windows 2003 R2 Platform SDK uses HKLM\SOFTWARE\Microsoft\MicrosoftSDK\InstalledSDKs\D2FF9F89-8AA2-4373-8A31-C838BF4DBBE1, which in turn has a entry for 'Install Dir' which lists the installation directory for the Platform SDK. Correct. This helps for Itanium and AMD64 extension modules. So basically a bunch of logic needs to be rewritten for newer version support and I will investigate this. No. The checks are all fine. 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] For sandboxing: alternative to crippling file()
A.M. Kuchling wrote: This thought was sparked by the piece on failure-oblivious computing in today's Linux Weekly News about this paper: http://www.usenix.org/events/osdi04/tech/rinard.html. The paper is also available from one of the authors at http://www.cag.lcs.mit.edu/~rinard/paper/osdi04.pdf -- Benji York ___ 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] Proposal to eliminate PySet_Fini
Alexander Belopolsky wrote: I feel that set is a more basic object than dict I don't feel that way; dict is more basic, set is just a special case of dict for performance reasons. Also, dict is used to define and implement the language itself, set is just a predefined type. but dictobject module is never finalized (is this a bug or a feature?) I guess it's a feature. What should PyDict_Fini do? Release the dummy object? That can't work, and won't help. For example, I can use dict API in atexit callbacks, but not set API. Right. It is by design that you can use the dict API everywhere, since dict is part of the language itself. set wasn't designed with such a goal (the same is true for many other types, I would guess). 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] Proposal to eliminate PySet_Fini
On 6/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote: ... dict is more basic, set is just a special case of dict for performance reasons. Also, dict is used to define and implement the language itself, set is just a predefined type. I guess it can be seen either way, just as a chicken and an egg. Does python-3000 still plan to integrate sets and dicts so that a set is a view of a dict? That would support the view that a set is more basic (dict code will depend on set code but not the other way around). If set has better performance than dict (which I have not noticed so far), it will be appropriate to use it in the language implementation where it can replace a dict. The prime example is the interned dict. What should PyDict_Fini do? Release the dummy object? That and a list of free dicts. That can't work, and won't help. Probably, but I am not arguing that PyDict_Fini is needed. Dict dummy should be static as well and free dicts list is probably not needed in the presence of pymalloc. ... It is by design that you can use the dict API everywhere, since dict is part of the language itself. set wasn't designed with such a goal (the same is true for many other types, I would guess). That's probably the hart of my proposal. I would like to see sets usable as a part of the language, or an application that embeds the language everywhere where dicts can be used today. ___ 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] PEP 328 and PEP 338, redux
Real-world usage case for import __main__? Typically for inter-module communication. A standard name (such as lobby, or __settings__) would work as well, but __main__ is what we have, for backwards compatibility. -jJ ___ 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] xturtle.py a replacement for turtle.py(!?)
Martin v. Löwis wrote: Greg Ewing wrote: BTW, I'm not sure if 'xturtle' is such a good name. There's a tradition of X Windows executables having names starting with 'x', whereas this is presumably platform-independent. Maybe 'turtleplus' or something? When it goes into Python, it will be 'turtle'. Perhaps in the meantime (if xturtle is not loved), you could go with turtle_ as in like the standard turtle, but my definition. -- -- Scott David Daniels [EMAIL PROTECTED] ___ 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] Proposal to eliminate PySet_Fini
Alexander Belopolsky [EMAIL PROTECTED] wrote: On 6/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote: ... dict is more basic, set is just a special case of dict for performance reasons. Also, dict is used to define and implement the language itself, set is just a predefined type. I guess it can be seen either way, just as a chicken and an egg. Does python-3000 still plan to integrate sets and dicts so that a set is a view of a dict? That would support the view that a set is more basic (dict code will depend on set code but not the other way around). I don't think that makes sense. I see a basic structure as one that can be used to implement other structures. A dict can emulate a set, but a set cannot emulate a dict. Thus, a set is a specialization of a dict with fewer features than the regular dict. If set has better performance than dict (which I have not noticed so far), it will be appropriate to use it in the language implementation where it can replace a dict. The prime example is the interned dict. The performance, I believe, is based on a Python 2.5 optimization that reduces memory consuption per entry from 12 to 8 bytes per entry. ... It is by design that you can use the dict API everywhere, since dict is part of the language itself. set wasn't designed with such a goal (the same is true for many other types, I would guess). That's probably the hart of my proposal. I would like to see sets usable as a part of the language, or an application that embeds the language everywhere where dicts can be used today. I disagree. You can get everything you need with a dict, and making sets a part of the language (besides being a builtin type), would necessarily add more overhead and maintenance to the language for little gain. If you need set-like functionality, and you need it to not be finalized, use a dict; it is available today, can do all the same things, and you don't need to wait at least 1.5 years until Python 2.6 is out. - Josiah ___ 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] Proposal to eliminate PySet_Fini
On 6/29/06, Josiah Carlson [EMAIL PROTECTED] wrote: I disagree. You can get everything you need with a dict, and making sets a part of the language (besides being a builtin type), would necessarily add more overhead and maintenance to the language for little gain. If you need set-like functionality, and you need it to not be finalized, use a dict; it is available today, can do all the same things, and you don't need to wait at least 1.5 years until Python 2.6 is out. That was a purely altruistic proposal. I've already discovered that sets are finalized and that some code that works with dict emulating a set may not work with a set. It will not make much difference for me if my proposal will be implemented in 2.6 or even in 3.0, but the sooner it will happen the fewer people will stumble on the same problem that I did. I also feel that dummy allocated on the heap and the free set list are complicating the code with no gain. Given negaive feedback, I will probably not try to make a patch, but such patch would mostly consist of removed lines. ___ 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] Pickle implementation questions
In developing a cPickle module for IronPython that's as compatible as possible with CPython, these questions have come up: - Where are object.__reduce__ and object.__reduce_ex__ defined, and how does copy_reg._reduce_ex fit into the picture? PEP 307 states that the default __reduce__ implementation for new-style classes implemented in Python is copy_reg._reduce. However, in Python 2.4.3 dir(copy_reg) indicates that it has no _reduce method. (Tangentially, is there a way to inspect a method_descriptor object to determine the function it's bound to?) - When the optional constructor argument is passed to copy_reg.pickle, where is it stored and how is it used by pickle? - What does copy_reg.constructor() do? Thanks! --Bruce ___ 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] Pickle implementation questions
Bruce Christensen wrote: In developing a cPickle module for IronPython that's as compatible as possible with CPython, these questions have come up: [I wish you were allowed to read the source code of Python] - Where are object.__reduce__ and object.__reduce_ex__ defined, and how does copy_reg._reduce_ex fit into the picture? See http://docs.python.org/lib/node69.html PEP 307 states that the default __reduce__ implementation for new-style classes implemented in Python is copy_reg._reduce. However, in Python 2.4.3 dir(copy_reg) indicates that it has no _reduce method. Yes, it calls copy_reg._reduce_ex now (which also expects the protocol version) - When the optional constructor argument is passed to copy_reg.pickle, where is it stored and how is it used by pickle? It's not used anymore. A comment says # The constructor_ob function is a vestige of safe for unpickling. # There is no reason for the caller to pass it anymore. - What does copy_reg.constructor() do? It does this: def constructor(object): if not callable(object): raise TypeError(constructors must be callable) 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] msvccompiler.py: some remarks
Hi Martin, On 6/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote: We should remove/change this comment. It is utterly misleading. To a warning/error stating that you miss a compiler? I meant to leave this as a per-shell choice. If you set MSSdk, you indicate that the environment you created is right, and distutils should not second-guess you. This is problematic if the user did register environment variables when installing the SDK, so I plan to change this to look for a different environment variable (in addition) OK, that makes sense. 2) As far as I have been able to determine .Net 2.0 uses sdkInstallRootv2.0. Also it installs by default under C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\ Forget about Visual Studio 8 and .NET 2.0. It won't help here. I only have .NET 1.1 and 2.0 and Visual Studio 2005 (8) installed. Why should I forget about it? Is Python compiled with much older compilers and thus unable to work together in a nice way or? So basically a bunch of logic needs to be rewritten for newer version support and I will investigate this. No. The checks are all fine. For what I can see not if you have newer versions of .NET such as 2.0, which is basically the defacto standard at the moment. So please elaborate a bit more so that I gain some insight about this, because I am needing this in order to build a working pyDB2 on my Windows system to do some testing. -- Jeroen Ruigrok van der Werven ___ 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
