Re: [Python-Dev] PEP 328 and PEP 338, redux
Guido van Rossum wrote: However, I'm fine with setting *another* variable to the full package name so someone who *really* wants to do relative imports here knows the package name. OK, I'll do that. Any objections to __module_name__ as the name of the variable? (to keep things simple, run_module() will always define the variable, even if __name__ and __module_name__ say the same thing). I'll then put a note in PEP 338 about the necessary hackery to make relative imports work correctly from a main module - I don't see any reason to include something like that in the normal docs, since the recommended approach is for main modules to use absolute imports. 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
Talin [EMAIL PROTECTED] wrote: My version of this is to add to Python the notion of a simple old-fashioned subroutine - that is, a function with no arguments and no additional scope, which can be referred to by name. For example: I don't like the idea of an embedded subrutine for a few reasons. One of them is because you need to define the case - sub mapping dictionaries in each pass, you are getting no improvement in speed (which is a motivating factor in this discussion). Even worse, the disconnect between case definition and dispatch makes it feel quite a bit like a modified label/goto proposal. The ultimate killer is that your proposed syntax (even using def) make this construct less readable than pretty much any if/elif/else chain I have ever seen. - 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] PEP 3103: A Switch/Case Statement
Guido van Rossum wrote: I think we all agree that side effects of case expressions is one way how we can deduce the compiler's behind-the-scenes tricks (even School Ib is okay with this). So I don't accept this as proof that Option 2 is better. OK, I worked out a side effect free example of why I don't like option 3: def outer(cases=None): def inner(option, force_default=False): if cases is not None and 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 believe it's reasonable to expect this to work fine - the case expressions don't refer to any local variables, and the subscript operations on the closure variable are protected by a sanity check to ensure that variable isn't None. There certainly isn't anything in the code above to suggest to a reader that the condition attempting to guard evaluation of the switch statement might not do its job. With first-time-execution jump table evaluation, there's no problem - when the closure variable is None, there's no way to enter the body of the if statement, so the switch statement is never executed and the case expressions are never evaluated. Such functions will still be storing a cell object for the switch's jump table, but it will always be empty because the code to populate it never gets a chance to run. With the out of order execution involved in def-time evaluation, however, the case expressions would always be executed, even though the inner function is trying to protect them with a sanity check on the value of the closure variable. Using Option 3 semantics would mean that calling outer() given the above function definition will give you the rather surprising result TypeError: 'NoneType' object is unsubscriptable, with a traceback pointing to the line case cases[0]: in the body of a function that hasn't been called, and that includes an if statement preventing that line from being reached when 'cases' is None. When it comes to the question of where do we store the result? for the first-execution calculation of the jump table, my proposal is a hidden cell in the current namespace. Um, what do you mean by the current namespace? You can't mean the locals of the function containing the switch. There aren't always outer functions so I must conclude you mean the module globals. But I've never seen those referred to as the current namespace. 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. For functions, the cell objects would be created at function definition time, for code handled via exec-style execution, they'd be created just before execution of the first statement begins. In either case, the cell objects would already be in locals() before any bytecode gets executed. It's only the calculation of the cell *contents* that gets deferred until first execution of the switch statement. So do I understand that the switch gets re-initialized whenever a new function object is created? That seems a violation of the first time executed rule, or at least a modification (first time executed per defined function). Or am I misunderstanding? I took it as a given that 'first time execution' had to be per function and/or invocation of exec - tying caching of expressions that rely on module globals or closure variables to code objects doesn't make any sense, because the code object may have different globals and/or closure variables next time it gets executed. I may not have explained my opinion about that very well though, because the alternative didn't even seem to be an option. But if I have a code object c containing a switch statement (not inside a def) with a side effect in one of its cases, the side effect is activated each time through the following loop, IIUC: d = {} for i in range(10): exec c in d Yep. For module and class level code, the caching really only has any speed benefit if the switch statement is inside a loop. The rationale for doing it that way becomes clearer if you consider what would happen if you created a new dictionary each time through the loop: for i in range(10): d = {} exec c in d print d[result] I'm confused how you can first argue that tying things to the function definition is one of the main drawbacks of Option 3, and then proceed to tie Option 2 to the function definition as well. This sounds like by far the most convoluted specification I have seen so far. I hope I'm misunderstanding what you mean by namespace. It's not the link to function definitions that I object to in Option 3, it's the idea of evaluating the cases at function
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
Nick Coghlan wrote: There certainly isn't anything in the code above to suggest to a reader that the condition attempting to guard evaluation of the switch statement might not do its job. that's why the evaluation model used in the case statement needs to be explicit. that applies to the once but not really approach, as well as the static = in global scope approach (http://online.effbot.org/2006_06_01_archive.htm#pep-static). there are no shortcuts here, if we want things to be easy to explain and easy to internalize. /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] School IIb?
Phillip J. Eby wrote: Hear, hear! We already have if/elif, we don't need another way to spell it. The whole point of switch is that it asserts that exactly *one* case is supposed to match that's not true for all programming languages that has a switch construct, though; the common trait is that you're dispatching on a single value, not necessarily that there cannot be potentially overlapping case conditions. /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 3103: A Switch/Case Statement
Guido van Rossum wrote: Is it unacceptable - or impractical - to break the addition of switch to python in two (minor version separated) steps ? But what's the point? We have until Python 3000 anyway. except that we may want to reserve the necessary keywords in 2.6... /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] Is Lib/test/crashers/recursive_call.py really a crasher?
Hi Brett, On Tue, Jun 27, 2006 at 10:32:08AM -0700, Brett Cannon wrote: OK, with you and Thomas both wanting to keep it I will let it be. I just won't worry about fixing it myself during my interpreter hardening crusade. I agree with this too. If I remember correctly, you even mentioned in your rexec docs that sys.setrecursionlimit() should be disallowed from being run by untrusted code, which means that an untrusted interpreter would be safe. I guess we could add an example of a bogus 'new.code()' call in the Lib/test/crashers directory too, without you having to worry about it in untrusted mode if new.code() is forbidden. I could also add my 'gc.get_referrers()' attack, which should similarly not be callable from untrusted code anyway. 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] ImportWarning flood
Ralf W. Grosse-Kunstleve wrote: If there is a consenus, I'd create a new exception ImportErrorNoModule(name) that is used consistently from all places. This would ensure uniformity of the message in the future. A correction proposal should only be given if it is likely correct. There can be many reasons why an import could fail: there might be no read permission for the file, or the PYTHONPATH might be setup incorrectly. IOW, a hint about a missing __init__.py should only be given if a directory with the name of module was found, but lacked an __init__.py (i.e. in the cases where currently a warning is produced). 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] xturtle.py a replacement for turtle.py(!?)
xturtle.py, extended turtle graphics a new Tkinter based turtle graphics module for Python I just have released xturtle.py (v.0.91). It can be found at: http://sourceforge.net/tracker/?group_id=5470atid=305470 with RequestID 1513695 (and 1513699 for the docs) and also here http://ada.rg16.asn-wien.ac.at/~python/xturtle with some supplementary information. xturtle was first announced at the edu-sig and is reported to work properly on all major platforms (Mac, Linux and Windows) Now I was suggested to discuss it on this list. So I'll try. For now I'll give only two indroductory statements and wait for a response, hoping that a fruitful discussion will evolve. (I) The module xturtle.py is an extended reeimplementation of turtle.py, retains its merits and is backward compatible to turtle.py. Enhancements over turtle.py are: # Better animation of the turtle movements, especially of turning the turtle. So the turtles can more easily be used as a visual feedback instrument by the (beginning) programmer. # Different turtle shapes, gif-images as turtle shapes, user defined and user controllable turtle shapes, among them compound (multicolored) shapes. # Fine control over turtle movement and screen updates via delay(), and enhanced tracer() and speed(), update() methods. # Aliases for the most commonly used commands, like fd for forward etc., following the early Logo traditions. This reduces the boring work of typing long sequences of commands, which often occur in a natural way when kids try to program fancy pictures on their first encounter with turtle graphcis (still not knowing nothing about loops). # Some simple commands/methods for creating event driven programs (mouse-, key-, timer-events). Especially useful for programming simple games. # A scrollable Canvas class. The scrollable Canvas can be extended interactively as needed while playing around with the turtle(s) (e. g. to follow some escaped turtle). The Window containing the default canvas when using the Pen - class also can be resized and repositioned programmatically. # Commands for controlling background color or background image. (II) Motives: I designed this module to provide utmost easy access to a sufficiently rich graphics toolkit. I consider this crucial as well for students as for teachers, who e. g. have to decide which programming language to use for teaching programming. Considering turtle graphics as a very appropriate tool for introductory programming courses I used the current turtle.py as a central tool in my book Python for kids despite beeing well aware of its deficiencies. Now I propose a better one. You may unterstand by intentions best by having a look at the 25+ example scripts (with the included demoViewer) provided in the xturtle.zip file, which can be downloaded from the above mentioned website. (I think these demos should not be included in the standard distribution, they could go into a special edu-distro as Kirby Urner suggested lately.) I would very much appreciate if xturtle.py could go into Python 2.5 Let's see Gregor ___ 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] xturtle.py - a replacement for turtle.py
xturtle.py, extended turtle graphics is a new Tkinter based turtle graphics module for Python xturtle.py (Version 0.91) can be found at: http://sourceforge.net/tracker/?group_id=5470atid=305470 (Request ID 1513695, and 1513699 for the docs) and at http://ada.rg16.asn-wien.ac.at/~python/xturtle together with a set of example scripts and a demoViewer xturtle was first announced at edu-sig and is reported to work properly on all major platforms (Mac, Linux and Windows) I propose to use it as a replacement for turtle.py It was suggested to me to discuss it on this list. So I'll try that. For now I'll give only two introductory statements and then wait for a response, hoping that a fruitful discussion will evolve. (I) xturtle.py is a reimplementation of turtle.py, retaining its merits and is backward compatible to turtle.py. Enhancements over turtle.py are: # Better animation of the turtle movements, especially of turning the turtle. So the turtles can more easily be used as a visual feedback instrument by the (beginning) programmer. # Different turtle shapes, gif-images as turtle shapes, user defined and user controllable turtle shapes, among them compound (multicolored) shapes. # Fine control over turtle movement and screen updates via |delay()|, and enhanced |tracer()| and |speed()|, |update()| methods. # Aliases for the most commonly used commands, like |fd| for |forward| etc., following the early Logo traditions. This reduces the boring work of typing long sequences of commands, which often occur in a natural way when kids try to program fancy pictures on their first encounter with turtle graphcis (still not knowing loops). # Some simple commands/methods for creating event driven programs (mouse-, key-, timer-events). Especially useful for programming simple games. # A scrollable Canvas class. The scrollable Canvas can be extended interactively as needed while playing around with the turtle(s) (e. g. to follow some escaped turtle). # Commands for controlling background color or background image. (II) Motives: My goal was to provide utmost easy access to a sufficiently rich graphics toolkit. I consider this of crucial importance for students and teachers who, e. g., have to decide which language to use for introductory programming courses. Moreover I consider turtle graphics as an excellent tool to visualize programming concept. So I already used the current turtle.py as a central tool in the first edition of my book Python für Kids, despite of its apparent deficiencies. Now I propose an alternative: xturtle.py. You will best understand my intentions by having a look at the 25+ demo scripts using the accompanying demoViewer, which are provided with turtle.zip at the above mentioned website. (I do not propose to include these into the standard distribution. Perhaps they could go into some special edudistro as Kirby Urner suggested lately) I would appreciate it very much if xturtle.py could go into Python2.5. I'm ready to do the amendments, which may emerge as necessary from the dicussion here. Regards, Gregor Lingl ___ 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] Oh-why that?? Please ignore one of the two
Sorry (dunno why) Gregor ___ 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] ImportWarning flood
--- Martin v. L�wis [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve wrote: If there is a consenus, I'd create a new exception ImportErrorNoModule(name) that is used consistently from all places. This would ensure uniformity of the message in the future. A correction proposal should only be given if it is likely correct. It is not a proposal, just a note. Maybe a better alternative would be ImportError: No module name foo Reminder: To resolve import problems consult the section on Packages at http://www.python.org/doc/tut/ There can be many reasons why an import could fail: there might be no read permission for the file, The warning in 2.5b1 doesn't fire in this case: % ls -l junk.py -- 1 rwgk cci 16 Jun 28 05:01 junk.py % python Python 2.5b1 (r25b1:47027, Jun 26 2006, 02:59:25) [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2 Type help, copyright, credits or license for more information. import junk Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named junk or the PYTHONPATH might be setup incorrectly. That's impossible to detect. IOW, a hint about a missing __init__.py should only be given if a directory with the name of module was found, but lacked an __init__.py (i.e. in the cases where currently a warning is produced). I am thinking you'd need to build up a buffer of potential warnings while trying to resolve an import. If the import succeeds the buffer is discarded, if it fails it is added to the exception message, or the warnings are flushed right before the ImportError is raised. Does that sound right? How would this interact with threading (it seems you'd need a separate buffer for each thread)? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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] PEP 328 and PEP 338, redux
Nick Coghlan wrote: Guido van Rossum wrote: However, I'm fine with setting *another* variable to the full package name so someone who *really* wants to do relative imports here knows the package name. OK, I'll do that. Any objections to __module_name__ as the name of the variable? (to keep things simple, run_module() will always define the variable, even if __name__ and __module_name__ say the same thing). I'll then put a note in PEP 338 about the necessary hackery to make relative imports work correctly from a main module - I don't see any reason to include something like that in the normal docs, since the recommended approach is for main modules to use absolute imports. These two bits have been done. 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__'. With the patch in place, relative imports from a main module executed using '-m' would work out of the box. So given a test_foo.py that started like this: import unittest import ..foo # Define the tests # Run the tests if __name__ = '__main__' A file layout like this: /home /ncoghlan /devel /package /__init__.py /foo.py /test /__init__.py /test_foo.py And a current working directory of /home/ncoghlan/devel, then the tests could be run simply by doing: python -m package.test.test_foo With beta 1 or current SVN, that would blow up with a ValueError. We can't do anything to help directly executed files, though - the interpreter simply doesn't have access to the info it needs in order to determine the location of such files in the module namespace. I'll post the patch to SF tomorrow (assuming the site decides to come back by then). In addition to the import.c changes, the patch includes some additional tests for runpy that exercise this and make sure it works, since runpy is the intended client. 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] ImportWarning flood
Ralf W. Grosse-Kunstleve wrote: There can be many reasons why an import could fail: there might be no read permission for the file, The warning in 2.5b1 doesn't fire in this case: Sure, but it would produce your note, right? And the note would be essentially wrong. Instead, the ImportError should read ImportError: No module named junk; could not open junk.py (permission denied) or the PYTHONPATH might be setup incorrectly. That's impossible to detect. Right. So the ImportError should not guess that there is a problem with packages if there could be dozens of other reasons why the import failed. I am thinking you'd need to build up a buffer of potential warnings while trying to resolve an import. If the import succeeds the buffer is discarded, if it fails it is added to the exception message, or the warnings are flushed right before the ImportError is raised. Does that sound right? That might work, yes. How would this interact with threading (it seems you'd need a separate buffer for each thread)? There are several solutions. I think you are holding the import lock all the time, so there can be only one import running (one would have to check whether the import lock is really held all the time); in that case, a global variable would work just fine. Another option is to pass-through all import-related data across all function calls as a parameter; that may actually cause a reduction in the number of parameters to the current functions, and simplify the code. Define a struct to hold all the relevant data, allocate it when entering the import code, pass it to every function, fill it out as needed, and deallocate it when leaving the import code. Allocation of the struct itself could likely be done on stack. Yet another option is to put the data into thread storage (although care is needed wrt. recursive imports within one thread). 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
Gregor Lingl wrote: I would appreciate it very much if xturtle.py could go into Python2.5. I'm ready to do the amendments, which may emerge as necessary from the dicussion here. I see little chance for that. Python 2.5 is feature-frozen. 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] doc for new restricted execution design for Python
On 6/27/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 6/27/06, Brett Cannon [EMAIL PROTECTED] wrote: (5) I think file creation/writing should be capped rather than binary; it is reasonable to say You can create a single temp file up to 4K or You can create files, but not more than 20Meg total. That has been suggested before. Anyone else like this idea? [ What exactly does the limit mean? bytes written? bytes currently stored? bytes stored after exit?] IMHO, I would prefer that it limit disk consumption; a deleted or overwritten file would not count against the process, but even a temporary spike would need to be less than the cap. That said, I would consider any of the mentioned implementations an acceptable proxy; the point is just that I might want to let a program save data without letting it have my entire hard disk. -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(!?)
On Wed, Jun 28, 2006 at 12:57:23PM +0200, Gregor Lingl wrote: I would very much appreciate if xturtle.py could go into Python 2.5 That decision is up to Anthony Baxter, the release manager. Unfortunately 2.5beta1 is already out, and the developers try to avoid large changes during the beta series, so I wouldn't be optimistic about 2.5. Enhancing the turtle module would be an excellent candidate for 2.6, though. Please file a patch on SourceForge for this so the improved module doesn't get forgotten. Great demos, BTW! I especially like the gravity ones. --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] School IIb?
On 6/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote: Phillip J. Eby wrote: Hear, hear! We already have if/elif, we don't need another way to spell it. The whole point of switch is that it asserts that exactly *one* case is supposed to match that's not true for all programming languages that has a switch construct, though; the common trait is that you're dispatching on a single value, not necessarily that there cannot be potentially overlapping case conditions. You have a point. Suppose you're switching on some os-specific constants (e.g. exported by the os module or some module like that). You have a case for each. But on some os, two different constants have the same value (since on that os they are implemented the same way -- like O_TEXT and O_BINARY on Unix). Now your switch wouldn't work at all on that os; it would be much better if you could arrange the cases so that one case has preference over another. There's also the (more likely) use case where you have a set of cases to be treated the same, but one member of the set must be treated differently. It would be convenient to put the exception in an earlier case and be done with it. Yet, it seems a shame not to be able to diagnose dead code due to accidental case duplication. Maybe that's less important, and pychecker can deal with it? After all we don't diagnose duplicate method definitions either, and that must have bitten many of us (usually due to a copy-and-paste error)... This doesn't move me to school I. But I do want to introduce school IIb which resolves redundant cases by saying the first match wins. This is trivial to implement when building the dispatch dict (skip keys already present). (An alternative would be to introduce new syntax to indicate okay to have overlapping cases or ok if this case is dead code but I find that overkill.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
Looks like this doesn't help at all when pre-computing the dispatch dict based on named constants. So this is a no-go. I should add that ABC had such named subroutines (but not for switching); I dropped them to simplify things. They're not an intrinsically undesirable or even unnecessary thing IMO. But it doesn't solve my use case for switching. The syntax is also seriously cumbersome compared to a PEP-3103-style switch. --Guido On 6/27/06, Talin [EMAIL PROTECTED] wrote: This parallels some of my thinking -- that we ought to somehow make the dict-building aspect of the switch statement explicit (which is better than implicit, as we all have been taught.) My version of this is to add to Python the notion of a simple old-fashioned subroutine - that is, a function with no arguments and no additional scope, which can be referred to by name. For example: def MyFunc( x ): sub case_1: ... sub case_2: ... sub case_3: ... # A direct call to the subroutine: do case_1 # An indirect call y = case_2 do y # A dispatch through a dict d = dict( a=case_1, b=case_2, c_case_3 ) do d[ 'a' ] -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] School IIb?
Guido van Rossum wrote: that's not true for all programming languages that has a switch construct, though; the common trait is that you're dispatching on a single value, not necessarily that there cannot be potentially overlapping case conditions. You have a point. that can happen to the best of us ;-) Suppose you're switching on some os-specific constants (e.g. exported by the os module or some module like that). You have a case for each. But on some os, two different constants have the same value (since on that os they are implemented the same way -- like O_TEXT and O_BINARY on Unix). Now your switch wouldn't work at all on that os; it would be much better if you could arrange the cases so that one case has preference over another. There's also the (more likely) use case where you have a set of cases to be treated the same, but one member of the set must be treated differently. It would be convenient to put the exception in an earlier case and be done with it. same approach as for try/except, in other words. Yet, it seems a shame not to be able to diagnose dead code due to accidental case duplication. Maybe that's less important, and pychecker can deal with it? After all we don't diagnose duplicate method definitions either, and that must have bitten many of us (usually due to a copy-and-paste error)... we could use a warning for this... This doesn't move me to school I. But I do want to introduce school IIb which resolves redundant cases by saying the first match wins. This is trivial to implement when building the dispatch dict (skip keys already present). I just wish I could figure out what school my original micro-PEP belongs to (but as long as my implementation note is still just a draft, I guess no- body else can figure that out either... ;-) /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 3103: A Switch/Case Statement
On 6/28/06, Nick Coghlan [EMAIL PROTECTED] wrote: Guido van Rossum wrote: I think we all agree that side effects of case expressions is one way how we can deduce the compiler's behind-the-scenes tricks (even School Ib is okay with this). So I don't accept this as proof that Option 2 is better. OK, I worked out a side effect free example of why I don't like option 3: def outer(cases=None): def inner(option, force_default=False): if cases is not None and 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 believe it's reasonable to expect this to work fine - the case expressions don't refer to any local variables, and the subscript operations on the closure variable are protected by a sanity check to ensure that variable isn't None. It's only reasonable if you're in school I. As I have repeatedly said, the only use cases I care about are those where the case expressions are constants for the lifetime of the process. (The compiler doesn't need to know this but the programmer does.) There certainly isn't anything in the code above to suggest to a reader that the condition attempting to guard evaluation of the switch statement might not do its job. With first-time-execution jump table evaluation, there's no problem - when the closure variable is None, there's no way to enter the body of the if statement, so the switch statement is never executed and the case expressions are never evaluated. Such functions will still be storing a cell object for the switch's jump table, but it will always be empty because the code to populate it never gets a chance to run. With the out of order execution involved in def-time evaluation, however, the case expressions would always be executed, even though the inner function is trying to protect them with a sanity check on the value of the closure variable. Using Option 3 semantics would mean that calling outer() given the above function definition will give you the rather surprising result TypeError: 'NoneType' object is unsubscriptable, with a traceback pointing to the line case cases[0]: in the body of a function that hasn't been called, and that includes an if statement preventing that line from being reached when 'cases' is None. That's a perfectly reasonable outcome to me. When it comes to the question of where do we store the result? for the first-execution calculation of the jump table, my proposal is a hidden cell in the current namespace. Um, what do you mean by the current namespace? You can't mean the locals of the function containing the switch. There aren't always outer functions so I must conclude you mean the module globals. But I've never seen those referred to as the current namespace. 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. For functions, the cell objects would be created at function definition time, for code handled via exec-style execution, they'd be created just before execution of the first statement begins. In either case, the cell objects would already be in locals() before any bytecode gets executed. It's only the calculation of the cell *contents* that gets deferred until first execution of the switch statement. So do I understand that the switch gets re-initialized whenever a new function object is created? That seems a violation of the first time executed rule, or at least a modification (first time executed per defined function). Or am I misunderstanding? I took it as a given that 'first time execution' had to be per function and/or invocation of exec - tying caching of expressions that rely on module globals or closure variables to code objects doesn't make any sense, because the code object may have different globals and/or closure variables next time it gets executed. I may not have explained my opinion about that very well though, because the alternative didn't even seem to be an option. PEP 3103 discusses several ways to implement first-time-really. I suggest that you edit the PEP to add option 2a which is first-time-per-function-definition. But if I have a code object c containing a switch statement (not inside a def) with a side effect in one of its cases, the side effect is activated each time through the following loop, IIUC: d = {} for i in range(10): exec c in d Yep. For module and class level code, the caching really only has any speed benefit if the switch statement is inside a loop. The rationale for doing it that way becomes clearer if you consider what would happen if you created a new
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?)
On Wednesday 28 June 2006 20:57, Gregor Lingl wrote: I would very much appreciate if xturtle.py could go into Python 2.5 Unfortunately Python 2.5b1 came out last week. Now that we're in beta, we're feature frozen (unless some horrible issue comes up that means we really need to do a feature change). This looks very nice, but it's going to have to wait until 2.6 :-( Sorry. Timing is everything. For others reading along at home - I kinda think that the post-beta-feature-freeze is a similar sort to the one we have for bugfix releases (maybe _slightly_ lower hurdles for a new feature, but only just). Does this seem reasonable? If so, I'll add a note to the [still unfinished :-(] PEP 101 rewrite. 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] [Python-checkins] r47142 - in python/trunk: Doc/lib/librunpy.tex Lib/runpy.py Lib/test/test_runpy.py
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? 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] xturtle.py a replacement for turtle.py(!?)
Anthony Baxter schrieb: On Wednesday 28 June 2006 20:57, Gregor Lingl wrote: I would very much appreciate if xturtle.py could go into Python 2.5 Unfortunately Python 2.5b1 came out last week. Now that we're in beta, we're feature frozen (unless some horrible issue comes up that means we really need to do a feature change). This looks very nice, but it's going to have to wait until 2.6 :-( Sorry. Timing is everything. So you mean that will at least last one more year? Not fine. I wonder if this xturtle.py is a Python feature. When Vern Ceder did his patch of turtle.py some weeks ago, there arouse a discussion if a PEP was necessary to change turtle.py and the general opinion in the discussion then was no. So I thought, that turtle-graphics is some marginal element in the Python standard distribution. (I thought something like features get defined in PEPs) Already now, only one week after publishing it I have some very positive feedback and people start to use it. So I think there is some demand for it. Moreover I think it could also help to convince more teachers to use Python as a first language. Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1 or something like this? I'll have a talk at Europython 2006 on July 5th about xturtle - an opportunity if sombody feels it's worth discussing it. Regards, Gregor ___ 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] once [was: Simple Switch statementZ]
On 6/25/06, Ka-Ping Yee python-dev at zesty.ca wrote: def f(x): def g(y): return y + once x return g Does once mean not really once here, but once for each new function object that's created for g? Until today, it hadn't really occurred to me that once could mean once per module load rather than once per defining scope. I suppose that is reasonable if the values really are constant, but most of the concerns are about what to do when this assumption is violated. It does add a bit of funny flow-control, though. def f(): def g(): def h(): once x # or switch Normally, there wouldn't be any need to even look inside g (let alone h) at module load time, because the definition of f was run, but the definitions of g and h were not. With module-level once, x is implicitly a module-level variable despite the nesting. Guido: He specifically wants the latter semantics because it solves the problem of binding the value of a loop control variable in an outer scope: Not really. To solve the loop control problem (where the constant is certainly not a run-time constant), a once variable also has to be eagerly evaluated. (function definition time?) Nick suggested using once to delay computation of expensive defaults. This means that even if every generated function has its own once variable, none of those variables would be bound to any specific value until they are called -- by which time the loop variable may well be rebound. -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(!?)
Gregor Lingl wrote: Already now, only one week after publishing it I have some very positive feedback and people start to use it. So I think there is some demand for it. some demand != should be added to the core distribution a few days after its first release. (and if everything that someone somewhere is using should be added to the core, a stock Python distro wouldn't fit on a DVD...) Moreover I think it could also help to convince more teachers to use Python as a first language. and teachers won't be able to install a second package ? sorry, but I don't believe that for a second. /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
Gregor Lingl wrote: I would appreciate it very much if xturtle.py could go into Python2.5. +1 The need for turtle.py improvements was discussed at the last PyCon. It would be a nice plus for people teaching programming to kids. In theory, it is a little late to be adding new modules. In practice, it's probably not a problem. Next time, type faster ;-) Raymond ___ 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
Talin [EMAIL PROTECTED] wrote: Josiah Carlson wrote: Talin [EMAIL PROTECTED] wrote: My version of this is to add to Python the notion of a simple old-fashioned subroutine - that is, a function with no arguments and no additional scope, which can be referred to by name. For example: I don't like the idea of an embedded subrutine for a few reasons. One of them is because you need to define the case - sub mapping dictionaries in each pass, you are getting no improvement in speed (which is a motivating factor in this discussion). Even worse, the disconnect between case definition and dispatch makes it feel quite a bit like a modified label/goto proposal. The ultimate killer is that your proposed syntax (even using def) make this construct less readable than pretty much any if/elif/else chain I have ever seen. - Josiah The case - sub mapping doesn't need to be defined every time - that's the point, you as the programmer decide when and how to construct the dictionary, rather than the language trying to guess what it is you want. EIBTI. Beautiful is better than ugly. You could also define the switch in an outer function that contains an inner function that is called multiple times: def Outer(): sub S1: ... sub S2: ... sub S3: ... dispatch = { parser.IDENT: S1, parser.NUMBER: S2, parser.COMMENT: S3 } def Inner( x ): do dispatch[ x ] return Inner This allows direct access to a namespace that was previously read-only from other namespaces (right now closure namespaces are read-only, objects within them may not be). ... There is also the possibility of building the dict before the function is run, however this requires a method of peeking into the function body and extracting the definitions there. For example, suppose the subroutine names were also attributes of the function object: def MyFunc( x ): sub upper: ... sub lower: ... sub control: ... sub digit: ... do dispatch[ x ] # Lets use an array this time, for variety dispatch = [ MyFunc.upper, MyFunc.lower, MyFunc.upper, # Yes, 2 and 3 are the same as 0 and 1 MyFunc.lower, MyFunc.control, MyFunc.digit, ] ... One of my other desires for switch/case or its equivalent is that of encapsulation. Offering such access from outside or inside the function violates what Python has currently defined as its mode of operations for encapsulation. With regards to your second and third points: sure, I freely admit that this proposal is less readable than a switch statement. The question is, however, is it more readable than what we have *now*? As I have explained, comparing it to if/elif/else chains is unfair, because they don't have equivalent performance. The real question is, is it more readable than, say, a dictionary of references to individual functions; and I think that there are a number of possible use cases where the answer would be 'yes'. Why is the comparison against if/elif/else unfair, regardless of speed? We've been comparing switch/case to if/elif/else from a speed perspective certainly, stating that it must be faster (hopefully O(1) rather than O(n)), but that hasn't been the only discussion. In fact, one of the reasons we are considering switch/case is because readability still counts, and people coming from C/etc., are familliar with it. Some find switch/case significantly easier to read, I don't, but I also don't find it significantly harder to read. On the other hand, if I found someone using sub in a bit of Python code, I'd probably cry, then rewrite the thing using if/elif/else. If I was fiesty, I'd probably do some branch counting and reorder the tests, but I would never use subs. I think that language features should just work in all cases, or at least all cases that are reasonable. I don't like the idea of a switch statement that is hedged around with unintuitive exceptions and strange corner cases. And I don't like the idea of making my code ugly. I would honestly rather have no change than to have sub/def+do. - 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] once [was: Simple Switch statementZ]
On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/25/06, Ka-Ping Yee python-dev at zesty.ca wrote: def f(x): def g(y): return y + once x return g Does once mean not really once here, but once for each new function object that's created for g? Until today, it hadn't really occurred to me that once could mean once per module load rather than once per defining scope. Funny. Until today (in a different post) it hadn't occurred to me that the proponents of first-use switch evaluation were talking about first-use within a function object. I guess the words are ambiguous. I'm not really a proponent of once-per-module-scope semantics in either case, so I'll gladly drop this issue. I suppose that is reasonable if the values really are constant, but most of the concerns are about what to do when this assumption is violated. It does add a bit of funny flow-control, though. def f(): def g(): def h(): once x # or switch Normally, there wouldn't be any need to even look inside g (let alone h) at module load time, because the definition of f was run, but the definitions of g and h were not. With module-level once, x is implicitly a module-level variable despite the nesting. Guido: He specifically wants the latter semantics because it solves the problem of binding the value of a loop control variable in an outer scope: Not really. To solve the loop control problem (where the constant is certainly not a run-time constant), a once variable also has to be eagerly evaluated. (function definition time?) Nick suggested using once to delay computation of expensive defaults. This means that even if every generated function has its own once variable, none of those variables would be bound to any specific value until they are called -- by which time the loop variable may well be rebound. Hm. We couldn't use this interpretation of 'once' to capture the value of a loop variable in a nested function. Recall the typical example; the goal is to return a list of argument-less functions that return 0, 1, 2, corresponding to their position in the list. The naive approach is def index_functions(n): return [(lambda: i) for i in range(n)] This returns a list of 10 functions that each return the final variable of 'i', i.e. 9. The current fix is def index_functions(n): return [(lambda i=i: i) for i in range(n)] which works but has the disadvantage of returning a list of functions of 0 or 1 argument I believe at least one poster has pointed out that 'once' (if defined suitably) could be used as a better way to do this: def index_functions(n): return [(lambda: once i) for i in range(n)] But delaying the evaluation of the once argument until the function is called would break this, since none of these functions are called until after the loop is over, so the original bug would be back. Perhaps 'once' is too misleading a name, given the confusion you alluded to earlier. Maybe we could use 'capture' instead? A capture expression would be captured at every function definition time, period. Capture expressions outside functions would be illegal or limited to compile-time constant expressions (unless someone has a better idea). A capture expression inside if 0: would still be captured to simplify the semantics (unless the compiler can prove that it has absolutely no side effects). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] School IIb?
On 6/28/06, Fredrik Lundh [EMAIL PROTECTED] wrote: I just wish I could figure out what school my original micro-PEP belongs to (but as long as my implementation note is still just a draft, I guess no- body else can figure that out either... ;-) There aren't just schools; there are alternatives (1-4 and A-D) and options (1-4). :-) Please publish your implementation! (Again if I just missed it.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
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. 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! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?)
Gregor Lingl [EMAIL PROTECTED] wrote: Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1 or something like this? Changing features/abilities of Python in micro releases (2.5 - 2.5.1), aside from bugfixes, is a no-no. See the Python 2.2 - 2.2.1 availability of True/False for an example of where someone made a mistake in doing this. - 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] doc for new restricted execution design for Python
On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/27/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 6/27/06, Brett Cannon [EMAIL PROTECTED] wrote: (5) I think file creation/writing should be capped rather than binary; it is reasonable to say You can create a single temp file up to 4K or You can create files, but not more than 20Meg total. That has been suggested before. Anyone else like this idea? [ What exactly does the limit mean? bytes written? bytes currently stored? bytes stored after exit?] IMHO, I would prefer that it limit disk consumption; a deleted or overwritten file would not count against the process, but even a temporary spike would need to be less than the cap. Some additional notes: - File size should be rounded up to some block size (512 if you don't have filesystem specific information) before adding to the total. - Total number of files (i.e. inodes) in existence should be capped, too. - If sandboxed code is allowed to create dierctories, the total depth and the total path length should also be capped. (I find reading about trusted and untrusted code confusing; a few times I've had to read a sentence three times before realizing I had swapped those two words. Perhaps we can distinguish between trusted and sandboxed? Or even native and sandboxed?) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
On 6/27/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 6/27/06, Brett Cannon [EMAIL PROTECTED] wrote: (5)I think file creation/writing should be capped rather than binary; it is reasonable to say You can create a single temp file up to 4K or You can create files, but not more than 20Meg total. That has been suggested before.Anyone else like this idea?What would this code do:MAX = 4 for i in xrange(10):fp = open(str(i), 'w+')fp.write(' ' * (MAX // 4))fp.close()if i % 2:os.unlink(str(i))First of all, it would require that the file names have been cleared for writing. Otherwise an exception will be thrown the first time open() is called. Second, the os.unlink() will fail unless you whitelist your platform's OS-specific module that is used by 'os' (e.g., posix). How many times should this execute, 4 or 8?What about if there is noif i % 2 and the file is unlinked at the end of each loop?Shouldthat loop 10 times without error?What would happen if we used thesame file name?What would happen if we did something like: fp = open(str(i), 'w+')MAX = 4for i in xrange(1):fp.seek(0)fp.write(' ' * (MAX // 4))Should this succeed?If I put in any cap, I would make it universal for *all* disk writes (and probably do the same for network sends). -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] PEP 3103: A Switch/Case Statement
Let's just drop the switchable subroutine proposal. It's not viable. On 6/28/06, Josiah Carlson [EMAIL PROTECTED] wrote: Talin [EMAIL PROTECTED] wrote: Josiah Carlson wrote: Talin [EMAIL PROTECTED] wrote: My version of this is to add to Python the notion of a simple old-fashioned subroutine - that is, a function with no arguments and no additional scope, which can be referred to by name. For example: I don't like the idea of an embedded subrutine for a few reasons. One of them is because you need to define the case - sub mapping dictionaries in each pass, you are getting no improvement in speed (which is a motivating factor in this discussion). Even worse, the disconnect between case definition and dispatch makes it feel quite a bit like a modified label/goto proposal. The ultimate killer is that your proposed syntax (even using def) make this construct less readable than pretty much any if/elif/else chain I have ever seen. - Josiah The case - sub mapping doesn't need to be defined every time - that's the point, you as the programmer decide when and how to construct the dictionary, rather than the language trying to guess what it is you want. EIBTI. Beautiful is better than ugly. You could also define the switch in an outer function that contains an inner function that is called multiple times: def Outer(): sub S1: ... sub S2: ... sub S3: ... dispatch = { parser.IDENT: S1, parser.NUMBER: S2, parser.COMMENT: S3 } def Inner( x ): do dispatch[ x ] return Inner This allows direct access to a namespace that was previously read-only from other namespaces (right now closure namespaces are read-only, objects within them may not be). ... There is also the possibility of building the dict before the function is run, however this requires a method of peeking into the function body and extracting the definitions there. For example, suppose the subroutine names were also attributes of the function object: def MyFunc( x ): sub upper: ... sub lower: ... sub control: ... sub digit: ... do dispatch[ x ] # Lets use an array this time, for variety dispatch = [ MyFunc.upper, MyFunc.lower, MyFunc.upper, # Yes, 2 and 3 are the same as 0 and 1 MyFunc.lower, MyFunc.control, MyFunc.digit, ] ... One of my other desires for switch/case or its equivalent is that of encapsulation. Offering such access from outside or inside the function violates what Python has currently defined as its mode of operations for encapsulation. With regards to your second and third points: sure, I freely admit that this proposal is less readable than a switch statement. The question is, however, is it more readable than what we have *now*? As I have explained, comparing it to if/elif/else chains is unfair, because they don't have equivalent performance. The real question is, is it more readable than, say, a dictionary of references to individual functions; and I think that there are a number of possible use cases where the answer would be 'yes'. Why is the comparison against if/elif/else unfair, regardless of speed? We've been comparing switch/case to if/elif/else from a speed perspective certainly, stating that it must be faster (hopefully O(1) rather than O(n)), but that hasn't been the only discussion. In fact, one of the reasons we are considering switch/case is because readability still counts, and people coming from C/etc., are familliar with it. Some find switch/case significantly easier to read, I don't, but I also don't find it significantly harder to read. On the other hand, if I found someone using sub in a bit of Python code, I'd probably cry, then rewrite the thing using if/elif/else. If I was fiesty, I'd probably do some branch counting and reorder the tests, but I would never use subs. I think that language features should just work in all cases, or at least all cases that are reasonable. I don't like the idea of a switch statement that is hedged around with unintuitive exceptions and strange corner cases. And I don't like the idea of making my code ugly. I would honestly rather have no change than to have sub/def+do. - 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/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org
Re: [Python-Dev] doc for new restricted execution design for Python
On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/27/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 6/27/06, Brett Cannon [EMAIL PROTECTED] wrote:(5)I think file creation/writing should be capped rather than binary; it is reasonable to say You can create a single temp file up to 4K or You can create files, but not more than 20Meg total. That has been suggested before.Anyone else like this idea? [ What exactly does the limit mean?bytes written?bytes currently stored?bytes stored after exit?]IMHO, I would prefer that it limit disk consumption; a deleted oroverwritten file would not count against the process, but even a temporary spike would need to be less than the cap.That said, I would consider any of the mentioned implementations anacceptable proxy; the point is just that I might want to let a programsave data without letting it have my entire hard disk. Well, that's easy to solve; don't allow any files to be open for writing. =)-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] doc for new restricted execution design for Python
On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/27/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 6/27/06, Brett Cannon [EMAIL PROTECTED] wrote: (5)I think file creation/writing should be capped rather thanbinary; it is reasonable to say You can create a single temp file up to 4K or You can create files, but not more than 20Meg total. That has been suggested before.Anyone else like this idea? [ What exactly does the limit mean?bytes written?bytes currently stored?bytes stored after exit?] IMHO, I would prefer that it limit disk consumption; a deleted or overwritten file would not count against the process, but even a temporary spike would need to be less than the cap. Some additional notes:- File size should be rounded up to some block size (512 if you don'thave filesystem specific information) before adding to the total.Why? - Total number of files (i.e. inodes) in existence should be capped, too.If you want that kind of cap, just specify individual files you are willing to let people open for reading; that is your cap. Only have to worry about this if you open an entire directory open for writing. - If sandboxed code is allowed to create dierctories, the total depthand the total path length should also be capped. Once again, another one of those balance issues of where do we draw the line in terms of simplicity in the setting compared to controlling every possible setting people will want (especially, it seems, when it comes to writing to disk). And if you want to allow directory writing, you need to allow use of the platform's OS-specific module ( e.g., posix) to do it since open() won't let you create a directory.I really want to keep the settings and setup simple. I don't want to overburden people with a ton of security settings. (I find reading about trusted and untrusted code confusing; a fewtimes I've had to read a sentence three times before realizing I hadswapped those two words. Perhaps we can distinguish between trustedand sandboxed? Or even native and sandboxed?) Fair enough. When I do the next draft I will make them more distinctive (probably trusted and sandboxed).-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] doc for new restricted execution design for Python
On 6/27/06, Bill Janssen [EMAIL PROTECTED] wrote: The plan is to allow pure Python code to be embedded into web pages like _javascript_.I am not going for the applet approach like Java.Java support is now just a plug-in.Should be easy to make a Python plug-in system that works the same way.If only we had a GUI... :-)Yep, it would be. Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't be too bad. If this really takes off, will probably want both: get into Firefox, but have an extension for pre-existing installations.-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] xturtle.py a replacement for turtle.py(!?)
Josiah Carlson schrieb: Gregor Lingl [EMAIL PROTECTED] wrote: Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1 or something like this? Changing features/abilities of Python in micro releases (2.5 - 2.5.1), aside from bugfixes, is a no-no. I understand. Nevertheless one should see, that there is _not_a _single_ module_ in the whole of Standard Python distro which _depends_ on turtle.py. This certainly makes a difference to the True/False-change problem. Gregor See the Python 2.2 - 2.2.1 availability of True/False for an example of where someone made a mistake in doing this. - 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] xturtle.py a replacement for turtle.py(!?)
On 6/28/06, Josiah Carlson [EMAIL PROTECTED] wrote: Gregor Lingl [EMAIL PROTECTED] wrote: Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1 or something like this? Changing features/abilities of Python in micro releases (2.5 - 2.5.1), aside from bugfixes, is a no-no. See the Python 2.2 - 2.2.1 availability of True/False for an example of where someone made a mistake in doing this. This may be a stupid question, but we're talking about replacing the turtle.py in Lib/lib-tk/, right? The one that's basically just a GUI demo / introduction to programming tool? If so, can someone explain to me how improving something like this is akin to introducing new keywords that everyone will take advantage of (to use Josiah's True/False example)? While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). Thanks, Collin Winter ___ 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(!?)
On Wed, Jun 28, 2006, Collin Winter wrote: This may be a stupid question, but we're talking about replacing the turtle.py in Lib/lib-tk/, right? The one that's basically just a GUI demo / introduction to programming tool? If so, can someone explain to me how improving something like this is akin to introducing new keywords that everyone will take advantage of (to use Josiah's True/False example)? While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). The problem is that it's a slippery slope. There is a *LOT* of political value coming from no features in bug releases, period. People feel that they can rely on Python to stay stable and not have to check what the actual changes were; it increases the confidence level in bugfix releases. Either the new turtle module goes in for beta2 (after suitably convincing the release manager and Guido) or it waits for 2.6. I don't have a strong feeling about this issue, though I'm a mild -0 on allowing it. Nobody can claim there wasn't notice about the beta release date and the restrictions after it. -- 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] once [was: Simple Switch statementZ]
On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: def index_functions(n): return [(lambda i=i: i) for i in range(n)] which works but has the disadvantage of returning a list of functions of 0 or 1 argument I believe at least one poster has pointed out that 'once' (if defined suitably) could be used as a better way to do this: Cleaner, yes. But you would still have to remember the once, just as you have to remember the i=i, so I don't think it would actually save any confusion in practice. Another alternative might be letting functions get at themselves, rather than just their names. (Methods can save attributes on self, but functions are out of luck if someone else reused their name.) Perhaps 'once' is too misleading a name, given the confusion you alluded to earlier. Maybe we could use 'capture' instead? A capture expression would be captured at every function definition time, period. I think it would have the same problem; I would still want to read that as The first time you run this, capture the result., rather than Capture the binding current at funcdef time, even though you're skipping all the other statements at this indent level. Capture expressions outside functions would be illegal or limited to compile-time constant expressions (unless someone has a better idea). At a minimum, it should be able to capture the expression's current value at load-time, which might well involve names imported from another module. A capture expression inside if 0: would still be captured to simplify the semantics (unless the compiler can prove that it has absolutely no side effects). Running code that was guarded by if 0: sounds like a really bad idea. -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(!?)
On Thursday 29 June 2006 03:03, Collin Winter wrote: This may be a stupid question, but we're talking about replacing the turtle.py in Lib/lib-tk/, right? The one that's basically just a GUI demo / introduction to programming tool? If so, can someone explain to me how improving something like this is akin to introducing new keywords that everyone will take advantage of (to use Josiah's True/False example)? 2.x.y releases should be compatible for all values of y, (including the empty value wink). PEP-006 has the details and rationale. People shouldn't have to worry that things break with a minor release. It's important that packagers of Python for distributions can feel confident that a bugfix release of Python is _actually_ just a bugfix release, and that they can push it out to their users. This means everyone wins. I'm unconvinced that a new turtle module is worth ramming in on short notice to make it into 2.5 final. It can easily be made available via the cheeseshop and with setuptools for extremely easy installation between 2.5 and 2.6. With all the work that's been done to make 2.5 what will hopefully be the most solid Python release ever, I don't want to slip up now. :-) And needless to say, there is no way it is suitable for a bugfix release. Had it been pushed through a couple of weeks earlier (while we were in alpha) - sure, it looks like it could have been a good addition to the stdlib. But the release timeline's been out there for a while now - heck, b1 was actually a few days later than originally planned. 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 328 and PEP 338, redux
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. -- 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] doc for new restricted execution design for Python
On 6/28/06, Brett Cannon [EMAIL PROTECTED] wrote: On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: - File size should be rounded up to some block size (512 if you don't have filesystem specific information) before adding to the total. Why? That reflects the amount of disk I no longer have available for other purposes. - Total number of files (i.e. inodes) in existence should be capped, too. If you want that kind of cap, just specify individual files you are willing to let people open for reading; that is your cap. Only have to worry about this if you open an entire directory open for writing. Right, but on some systems, inodes are themselves a limited resource. I'm not sure how common that is. - If sandboxed code is allowed to create directories, the total depth and the total path length should also be capped. Once again, another one of those balance issues of where do we draw the line in terms of simplicity ... you need to allow use of the platform's OS-specific module ( e.g., posix) to do it since open() won't let you create a directory. I *think* this is to avoid security holes, and your solution of letting the open filter out bad names should be OK, but ... what if it isn't? What if cd then mkdir will let them create something too long? Do we have to wait for an OS patch? (I find reading about trusted and untrusted code confusing; a few times I've had to read a sentence three times before realizing I had swapped those two words. Perhaps we can distinguish between trusted and sandboxed? Or even native and sandboxed?) unlimited vs sandboxed? -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] PEP 3103: A Switch/Case Statement
Guido van Rossum wrote: Let's just drop the switchable subroutine proposal. It's not viable. Perhaps not - but at the same time, when discussing new language features, let's not just limit ourselves to what other languages have done already. 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. -- Talin ___ 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]
On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: def index_functions(n): return [(lambda i=i: i) for i in range(n)] which works but has the disadvantage of returning a list of functions of 0 or 1 argument I believe at least one poster has pointed out that 'once' (if defined suitably) could be used as a better way to do this: Cleaner, yes. But you would still have to remember the once, just as you have to remember the i=i, so I don't think it would actually save any confusion in practice. Yes it would, to the reader; if you see a function with a default argument now, you have to wonder if the default is there just to capture a value. Another alternative might be letting functions get at themselves, rather than just their names. (Methods can save attributes on self, but functions are out of luck if someone else reused their name.) This has been proposed before. Because (as you say) the function name is not generally safe to use, there's no good API; all proposals I've seen are ugly. And anyway this would be way too complex for the little lambda I was using as an example. Perhaps 'once' is too misleading a name, given the confusion you alluded to earlier. Maybe we could use 'capture' instead? A capture expression would be captured at every function definition time, period. I think it would have the same problem; I would still want to read that as The first time you run this, capture the result., rather than Capture the binding current at funcdef time, even though you're skipping all the other statements at this indent level. Capture can have many meanings. Of course some people will still misunderstand it. But it's more likely that they would look it up the first time they saw it rather than assumign they knew what it meant. Capture expressions outside functions would be illegal or limited to compile-time constant expressions (unless someone has a better idea). At a minimum, it should be able to capture the expression's current value at load-time, which might well involve names imported from another module. I'm not sure what you mean by load time. If you mean to do this before the execution of the module body starts, then none of the imported names are known (import is an executable statement, too). A capture expression inside if 0: would still be captured to simplify the semantics (unless the compiler can prove that it has absolutely no side effects). Running code that was guarded by if 0: sounds like a really bad idea. Assuming that the compiler will treat code guarded by if 0: different from code guarded by if x: where you happen to know that x is always false sounds like a really bad idea too. I'm happy to treat elimination of if 0: blocks as optimizations. I'm not happy to state into the language spec that the compiler should treat such code differently. next, you're going to claim that a local variable only assigned within such a block is not really a local (and references to it outside the block should be treated as globals)... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3103: A Switch/Case Statement
On 6/28/06, Talin [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Let's just drop the switchable subroutine proposal. It's not viable. Perhaps not - but at the same time, when discussing new language features, let's not just limit ourselves to what other languages have done already. Well, Python 3000 is explcitly not intended as a platform for arbitrary experimentation with feature invention (read PEP 3000). I've gotten quite a bit of mileage out of borrowing from other languages instead of inventing my own stuff, so I don't want to go out inventing as a replacement of researching options that have already been tried elsewhere. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Brett Cannon wrote: The plan is to allow pure Python code to be embedded into web pages like JavaScript. ... ...Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't be too bad. If this really takes off, will probably want both: get into Firefox, but have an extension for pre-existing installations. You should really speak with Mark, if you haven't recently. He's gotten a lot further than just PyXPCOM. My understanding (I might be a bit off on the branches and timing) is that his DOM_AGNOSTIC work on the Mozilla code has mostly been checked into the trunk. This work is to do mostly what you are describing: Python as a client-side scripting language along-side JavaScript. I can't recall what Mozilla's distribution plans are for this. Certainly it wouldn't be before Firefox 3. Then again, default Firefox builds would like not include Python by default. It sounds to me that a restricted-execution/security-model story for Python would be important here. Mark (and me a little bit) has been sketching out creating a Python for Mozilla/Firefox extension for installing an embedded Python into an existing Firefox installation on the pyxpcom list: http://aspn.activestate.com/ASPN/Mail/Message/pyxpcom/3167613 The idea is that there be a separate Python interpreter per web browser page instance. I think there may be scaling issues there. JavaScript isn't doing that is it, do you know? As well, that doesn't seem like it would translate well to sharing execution between separate chrome windows in a non-browser XUL/Mozilla-based app. Trent -- Trent Mick [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] doc for new restricted execution design for Python
On 6/28/06, Brett Cannon [EMAIL PROTECTED] wrote: On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: - File size should be rounded up to some block size (512 if you don't have filesystem specific information) before adding to the total. Why? Because that's how filesystems work. Allocations are in terms of block sizes. 1000 files of 1 byte take up the same space as 1000 files of 512 bytes (in most common filesystems anyway -- I think Reiserfs may be different). - Total number of files (i.e. inodes) in existence should be capped, too. If you want that kind of cap, just specify individual files you are willing to let people open for reading; that is your cap. Only have to worry about this if you open an entire directory open for writing. I'm not talking about filedescriptors (although that's another cappable resource); I'm talking about number of files in the filesystem. Most unix filesystems have a limit; I've run into it occasionally when I had a really large partition with not enough inodes configured and I was creating lots of tiny files. See df(1). - If sandboxed code is allowed to create directories, the total depth and the total path length should also be capped. Once again, another one of those balance issues of where do we draw the line in terms of simplicity in the setting compared to controlling every possible setting people will want (especially, it seems, when it comes to writing to disk). And if you want to allow directory writing, you need to allow use of the platform's OS-specific module ( e.g., posix) to do it since open() won't let you create a directory. I really want to keep the settings and setup simple. I don't want to overburden people with a ton of security settings. Well, I prefixed it with if you want to allow directory creation. If you don't allow that, fine. But if you do allow that (and it's an easily controlled operation just like file creation) I've given you some things to watch out for. I once ran into a situation where a script had gone off into deep recursion and created a near-infinite hierarchy of directories that rm -r couldn't remove (because it constructs absolute paths that exceeded MAXPATH). (I find reading about trusted and untrusted code confusing; a few times I've had to read a sentence three times before realizing I had swapped those two words. Perhaps we can distinguish between trusted and sandboxed? Or even native and sandboxed?) Fair enough. When I do the next draft I will make them more distinctive (probably trusted and sandboxed). Great! -- --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] RFC: trunk checkins between now and 2.5 final
This is a request for comments - this is my current thinking on a policy for checkins to the trunk between now and the release of 2.5 final. Now that we're in beta: If you don't add an entry to Misc/NEWS, a test (if relevant or possible) and docs (if relevant), the checkin is probably going to get reverted. This continues through the release candidate stages. I mean it about Misc/NEWS, too. Every change to the code gets a NEWS entry. If it adds a feature in beta, and you didn't get signoff first, it's going to get treated as a revert candidate. People like myself or Neal shouldn't have to run after you to review the patch after it's in SVN. If a checkin breaks the buildbots, unless the bug is very shallow and it's easier for someone of us to fix than revert, it's going to get a little set of three red dots on it's forehead ala Predator. Once we hit release candidate 1, the trunk gets branched to release25-maint. On release25-maint, between rc1 and 2.5 final: If you checkin to that branch, get signoff first. This is regardless of whether it's bugfix or feature. The checkin is going to get the big revert cannon targetting it, otherwise. If you need to go round one of these things, get signoff (in public!) first, or else if not in public, mention the signoff in the commit message. Preferably in public, though. Once 2.5 final is out, the normal maintenance branch guidelines come into effect for release25-maint. That is, bugfixes only. This is all documented in PEP-0008. A few notes on rationale for my being such a pain in the backside about this: Now that we're in beta, we should be spending the time nailing down bugs. Every feature added has the potential to add bugs - in addition, other people are going to have to review that change to make sure it's sane. There's only so many mental cycles to go around, and they should be spent on fixing existing bugs, not creating new ones wink. Once we're in RC, we're going to really, really want to ratchet up the quality meter. Between Neal and myself we have a fair amount of timezone coverage, so you should be able to get hold of one of us easily enough. My contact details (including all manner of instant messenger type things) are also pretty easy to find, they've been posted here a number of times before. Anyway, this is the current thinking. Am I being too dogmatic here? Comments solicited. 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. Anthony ___ 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
On 6/28/06, Anthony Baxter [EMAIL PROTECTED] wrote: 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. Right. But I agree with the policy. FWIW, I think Nick's change for -m is okay given that it's a pretty minor feat and -m is new anyway, but I'd like you and/or Neal decide on that. Leaving it broken is also pretty minor IMO (and was my first preference whe he brought it up -- see my posts in response to his proposal). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/28/06, Brett Cannon [EMAIL PROTECTED] wrote: On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: - File size should be rounded up to some block size (512 if you don't have filesystem specific information) before adding to the total. Why?That reflects the amount of disk I no longer have available for otherpurposes.Ah, OK. - Total number of files (i.e. inodes) in existence should be capped, too. If you want that kind of cap, just specify individual files you are willing to let people open for reading; that is your cap.Only have to worry about this if you open an entire directory open for writing. Right, but on some systems, inodes are themselves a limited resource.OK. I'm not sure how common that is. - If sandboxed code is allowed to create directories, the total depth and the total path length should also be capped. Once again, another one of those balance issues of where do we draw the line in terms of simplicity ... you need to allow use of the platform's OS-specific module ( e.g., posix) to do it since open() won't let you create a directory.I *think* this is to avoid security holes, and your solution ofletting the open filter out bad names should be OK, but ... what if it isn't?What if cd then mkdir will let them create something too long? Do we have to wait for an OS patch?Then isn't that a problem with cwd() and mkdir()?And we can play the what if scenario forever with security. There is always the possibility me or some originally trusted code is going to turn out to be unsafe. This is why I am preferring an approach of just not allowing the importation of possibly unsafe code unless you *really* trust it yourself. -Brett (I find reading about trusted and untrusted code confusing; a few times I've had to read a sentence three times before realizing I had swapped those two words. Perhaps we can distinguish between trusted and sandboxed? Or even native and sandboxed?) unlimited vs sandboxed?-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] RFC: trunk checkins between now and 2.5 final
Only one gripe: [Anthony Baxter] ... Once we hit release candidate 1, the trunk gets branched to reease25-maint. Save the branch for 2.5 final (i.e., the 2.5final tag and the release25-maint branch start life exactly the same). Adding a new step before it's possible to fix rc1 critical bugs is the worst possible time to add a new step. PEP 356 shows only one week between rc1 and final, and nobody is gonna from frustration waiting a week to merge their (currently non-existent, AFAICT) 2.6 branches into the trunk. As to the rest, I'll be happy to help revert things ;-) ___ 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, Trent Mick [EMAIL PROTECTED] wrote: Brett Cannon wrote: The plan is to allow pure Python code to be embedded into web pages like _javascript_. ... ...Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't be too bad. If this really takes off, will probably want both: get into Firefox, but have an extension for pre-existing installations.You should really speak with Mark, if you haven't recently. He's gotten a lot further than just PyXPCOM. My understanding (I might be a bit offon the branches and timing) is that his DOM_AGNOSTIC work on theMozilla code has mostly been checked into the trunk. This work is to do mostly what you are describing: Python as a client-side scriptinglanguage along-side _javascript_.Handling the Firefox integration is next month, so I will be talking to him. I can't recall what Mozilla's distribution plans are for this. Certainlyit wouldn't be before Firefox 3. Then again, default Firefox buildswould like not include Python by default.It sounds to me that a restricted-execution/security-model story for Python would be important here.Yep. One of the reasons I am dealing with it. Mark (and me a little bit) has been sketching out creating a Python forMozilla/Firefox extension for installing an embedded Python into anexisting Firefox installation on the pyxpcom list: http://aspn.activestate.com/ASPN/Mail/Message/pyxpcom/3167613 The idea is that there be a separate Python interpreter per web browser page instance.I think there may be scaling issues there. _javascript_ isn't doing that is it, do you know? As well, that doesn't seem like it would translatewell to sharing execution between separate chrome windows in anon-browser XUL/Mozilla-based app.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. And if you don't think it is going to scale, how do you think it should be done?-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] PEP 328 and PEP 338, redux
Guido van Rossum wrote: On 6/27/06, Greg Ewing [EMAIL PROTECTED] wrote: Giovanni Bajo 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. Added to PEP 3100. 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] PEP 3103: A Switch/Case Statement
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. -- Eric Sumner Note: I sent an email yesterday with a proposal to this effect, but it seems to have been lost. If anybody wants, I can resend it. ___ 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 Jun 28, 2006, at 10:54 AM, Brett Cannon wrote:On 6/28/06, Trent Mick [EMAIL PROTECTED] wrote: Brett Cannon wrote: Mark (and me a little bit) has been sketching out creating a "Python forMozilla/Firefox" extension for installing an embedded Python into anexisting Firefox installation on the pyxpcom list: http://aspn.activestate.com/ASPN/Mail/Message/pyxpcom/3167613 The idea is that there be a separate Python interpreter per web browser page instance.I think there may be scaling issues there. _javascript_ isn't doing that is it, do you know? As well, that doesn't seem like it would translatewell to sharing execution between separate chrome windows in anon-browser XUL/Mozilla-based app.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. And if you don't think it is going to scale, how do you think it should be done?Why wouldn't it scale? How much interpreter state is there really anyway?-bob___ 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]
On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 6/28/06, Jim Jewett [EMAIL PROTECTED] wrote: It basically requires a reserved word. def f(a, b=key, __func__.extra=i): if __func__.extra 43: ... And anyway this would be way too complex for the little lambda I was using as an example. def index_functions(n): return [(lambda __func__.i=i: i) for i in range(n)] I told you it was ugly. :-) I'm not sure what you mean by load time. The first time a module is imported. When running from a .py file, this is the same as compile time. I didn't say compile-time because I don't want it frozen permanently for the entire installation when the .pyc file is first written. So it won't have access to imported modules, contradicting your earlier statement which might well involve names imported from another module. A capture expression inside if 0: would still be captured to simplify the semantics (unless the compiler can prove that it has absolutely no side effects). Running code that was guarded by if 0: sounds like a really bad idea. Assuming that the compiler will treat code guarded by if 0: different from code guarded by if x: where you happen to know that x is always false sounds like a really bad idea too. The indent rules mean it will never be reached, so it can't have side effects. I expect that if 0: push_the_red_button will not risk pushing the red button. Freezing a once-variable at funcdef time means that I have to look inside the indent after all. If 0: is just an especially bad special case. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Yep, it would be. Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't be too bad. Of course, that's the road Sun first went down with Java, and that turned out not-so-well for them. I think the plug-in approach may be stronger (but admittedly more limited), as lots of plug-ins work with many different browsers, thus encouraging page designers to actually use them. Bill ___ 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(!?)
Collin Winter wrote: While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). It's a stdlib module, even if no other stdlib modules depend on it; try import turtle. In the specific case, the problem with adding it to 2.5 is that xturtle is a huge rewrite, so ideally, the code should be reviewed before being added. Given that this is a lot of code, nobody will have the time to perform a serious review. It will be hard enough to find somebody to review it for 2.6 - often, changes of this size take several years to review (primarily because it is so specialized that only few people even consider reviewing it). 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] doc for new restricted execution design for Python
Guido van Rossum wrote: On 6/28/06, Brett Cannon [EMAIL PROTECTED] wrote: On 6/28/06, Guido van Rossum [EMAIL PROTECTED] wrote: - File size should be rounded up to some block size (512 if you don't have filesystem specific information) before adding to the total. Why? Because that's how filesystems work. Allocations are in terms of block sizes. 1000 files of 1 byte take up the same space as 1000 files of 512 bytes (in most common filesystems anyway -- I think Reiserfs may be different). Forgive me if I'm missing the obvious but shouldn't block size be taken into consideration when setting the cap rather than for testing the file size? E.g., what happens if you specify a cap of 100 bytes, your block size is 512 and the user tries to write a single byte? Fail, because it's logically allocation 512 and the cap is at 100? That seems backwards to me since it would require that the app first determine the block size of the OS it's running on before it can even set a working cap. And if the interpreter implicitly rounds the cap up to block size, then there isn't much of a point in specifying the number of bytes to begin with - perhaps use number of blocks instead? In any case, I'd argue that if you allow the cap to be set at any specific number of bytes, the interpreter should honor *exactly* that number of bytes, blocks or not. Cheers, - Andreas ___ 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] ImportWarning flood
On Jun 25, 2006, at 9:47 PM, James Y Knight wrote: On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote: --- Jean-Paul Calderone [EMAIL PROTECTED] wrote: I think it is safe to say that Twisted is more widely used than anything Google has yet released. Twisted also has a reasonably plausible technical reason to dislike this change. Google has a bunch of engineers who, apparently, cannot remember to create an empty __init__.py file in some directories sometimes. Simply adding a note to the ImportError message would solve this problem just in time: import mypackage.foo Traceback (most recent call last): File stdin, line 1, in ? ImportError: No module named mypackage.foo Note that subdirectories are searched for imports only if they contain an __init__.py file: http://www.python.org/doc/essays/packages.html I also dislike the warning solution. Making the ImportError message more verbose seems like a much nicer solution. I just found another reason to dislike the warnings: my homedir on one machine has a lot of random directories in it. One of them is named readline. Every time I run python 2.5, it now helpfully notes: sys:1: ImportWarning: Not importing directory 'readline': missing __init__.py It used to be the case that it was very unlikely that running python in your homedir would cause issues. Even though the current directory is on the default pythonpath, you needed to have either a file ending in .py or a directory with an __init__.py with the same name as a python module to cause problems. And that is generally unlikely to happen. Now, however, you get warnings just by having _any_ directory in your CWD with the same name as a python module. That's much more likely to happen; I can't be the only one who will have this issue. I'd like to suggest the simple solution quoted above with a constant string added to the ImportError message would be good enough, and better than the current warning situation. Clearly it would be even better if someone did the complicated thing of keeping track of which directories would have been used had they had __init__.py files in them, and appending _that_ to the eventual ImportError message, but I don't think removing the warning should be held up on doing that. James ___ 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, Bill Janssen [EMAIL PROTECTED] wrote: Yep, it would be.Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't be too bad.Of course, that's the road Sun first went down with Java, and that turned out not-so-well for them.I think the plug-in approach may bestronger (but admittedly more limited), as lots of plug-ins work withmany different browsers, thus encouraging page designers to actually use them.Right. As I have said, for widespread use an extension will be needed.-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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Martin v. Löwis schrieb: Collin Winter wrote: While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). It's a stdlib module, even if no other stdlib modules depend on it; try import turtle. In the specific case, the problem with adding it to 2.5 is that xturtle is a huge rewrite, so ideally, the code should be reviewed before being added. Given that this is a lot of code, nobody will have the time to perform a serious review. It will be hard enough to find somebody to review it for 2.6 - often, changes of this size take several years to review (primarily because it is so specialized that only few people even consider reviewing it). Sorry Martin, but to me this seems not to be the right way to manage things. We have turtle.py revised in Python2.5b1 Please try this example (as I just did) : IDLE 1.2b1 No Subprocess from turtle import * begin_fill() circle(100,90) # observe the turtle backward(200) circle(100,90) color(red) end_fill() IDLE internal error in runcode() Traceback (most recent call last): File pyshell#6, line 1, in module end_fill() File C:\Python25\lib\lib-tk\turtle.py, line 724, in end_fill def end_fill(): _getpen.end_fill() AttributeError: 'function' object has no attribute 'end_fill' An error occurs, because in line 724 it should read def end_fill(): _getpen().end_fill() (Who reviewed it? This is a _newly_added_ function - did nobody try it out yet? Incredible!!) I corrected it and did: IDLE 1.2b1 No Subprocess from turtle import * begin_fill() circle(100,90) backward(200) circle(100,90) color(red) end_fill() What a shame!! An immanent bug, persistent for years now! Is this what Anthony Baxter calls the most solid Python release ever In contrast to this: IDLE 1.2b1 No Subprocess from xturtle import * begin_fill() circle(100,90) backward(200) circle(100,90) color(red) end_fill() works correctly and the turtle travels along the arcs with the same speed as along the straight lines. Bugs like the one I detected above (by chance) cannot occur in the code of my xturtle, because I don't have to type the definitions of those frunctions into the script by hand. Instead they are generated automatically from the corresponding methods of RawPen and Pen respectively. And aren't 25+ bugfree samplescripts of great variety and broad range in complexity to consider a more reliable proof of at least usability than the procedure you applied? My xturtle is certainly not bugfree. But it's (also certainly) not worse than turtle.py and way more versatile. A more courageous and less bureaucratic approach to the problem would be appropriate. Perhaps combined with some fantasy. For example: put turtle.py and xturtle.py both into beta2 and see which one stands better the (beta)test of time. Or perhaps you have an even better idea! Regards, Gregor P.S.: If this posting doesn't move points of view, at least it reveals one fixable bug in turtle.py (albeit also one unfixable!) 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/glingl%40aon.at ___ 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] ImportWarning flood
On Wed, Jun 28, 2006, James Y Knight wrote: I just found another reason to dislike the warnings: my homedir on one machine has a lot of random directories in it. One of them is named readline. Every time I run python 2.5, it now helpfully notes: sys:1: ImportWarning: Not importing directory 'readline': missing __init__.py It used to be the case that it was very unlikely that running python in your homedir would cause issues. Even though the current directory is on the default pythonpath, you needed to have either a file ending in .py or a directory with an __init__.py with the same name as a python module to cause problems. And that is generally unlikely to happen. Now, however, you get warnings just by having _any_ directory in your CWD with the same name as a python module. That's much more likely to happen; I can't be the only one who will have this issue. Oo! Yuck! I am now +1 for reverting the warning. -- 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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: What a shame!! An immanent bug, persistent for years now! Is this what Anthony Baxter calls the most solid Python release ever do you really think stuff like this helps your cause ? /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, Trent Mick [EMAIL PROTECTED] wrote: Brett Cannon wrote: The idea is that there be a separate Python interpreter per web browser page instance. I think there may be scaling issues there. _javascript_ isn't doing that is it, do you know? As well, that doesn't seem like it would translate well to sharing execution between separate chrome windows in a non-browser XUL/Mozilla-based app. And if you don't think it is going to scale, how do you think it should be done?That was an ignorant response (I haven't read what you've suggested andreally though about it). Sorry for the unsubstantiated babbling. To Bob's question on how much interpreter state *is* there: I don'tknow. Have you done any measuring of that, Brett?Not yet; as of right now I just want a coherent security model since this whole idea is dead in the water without it. But I do know that interpreters are basically execution stack, a new sys module, and a new sys.modules. It isn't horrendously heavy. And C extension modules are shared between them.-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] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
On Jun 28, 2006, at 1:05 PM, Gregor Lingl wrote: Martin v. Löwis schrieb: Collin Winter wrote: While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). It's a stdlib module, even if no other stdlib modules depend on it; try import turtle. In the specific case, the problem with adding it to 2.5 is that xturtle is a huge rewrite, so ideally, the code should be reviewed before being added. Given that this is a lot of code, nobody will have the time to perform a serious review. It will be hard enough to find somebody to review it for 2.6 - often, changes of this size take several years to review (primarily because it is so specialized that only few people even consider reviewing it). Sorry Martin, but to me this seems not to be the right way to manage things. We have turtle.py revised in Python2.5b1 Please try this example (as I just did) : IDLE 1.2b1 No Subprocess from turtle import * begin_fill() circle(100,90) # observe the turtle backward(200) circle(100,90) color(red) end_fill() IDLE internal error in runcode() Traceback (most recent call last): File pyshell#6, line 1, in module end_fill() File C:\Python25\lib\lib-tk\turtle.py, line 724, in end_fill def end_fill(): _getpen.end_fill() AttributeError: 'function' object has no attribute 'end_fill' An error occurs, because in line 724 it should read def end_fill(): _getpen().end_fill() File a patch, this is a bug fix and should definitely be appropriate for inclusion before the release of Python 2.5! -bob ___ 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!
It was already patched by the other Georg. Thanks for the quick fix, georgbot! --Guido On 6/28/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Jun 28, 2006, at 1:05 PM, Gregor Lingl wrote: Martin v. Löwis schrieb: Collin Winter wrote: While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). It's a stdlib module, even if no other stdlib modules depend on it; try import turtle. In the specific case, the problem with adding it to 2.5 is that xturtle is a huge rewrite, so ideally, the code should be reviewed before being added. Given that this is a lot of code, nobody will have the time to perform a serious review. It will be hard enough to find somebody to review it for 2.6 - often, changes of this size take several years to review (primarily because it is so specialized that only few people even consider reviewing it). Sorry Martin, but to me this seems not to be the right way to manage things. We have turtle.py revised in Python2.5b1 Please try this example (as I just did) : IDLE 1.2b1 No Subprocess from turtle import * begin_fill() circle(100,90) # observe the turtle backward(200) circle(100,90) color(red) end_fill() IDLE internal error in runcode() Traceback (most recent call last): File pyshell#6, line 1, in module end_fill() File C:\Python25\lib\lib-tk\turtle.py, line 724, in end_fill def end_fill(): _getpen.end_fill() AttributeError: 'function' object has no attribute 'end_fill' An error occurs, because in line 724 it should read def end_fill(): _getpen().end_fill() File a patch, this is a bug fix and should definitely be appropriate for inclusion before the release of Python 2.5! -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: Sorry Martin, but to me this seems not to be the right way to manage things. As you explain later, this is precisely the right way; it is unfortunate that it isn't always followed. (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. [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. Bugs like the one I detected above (by chance) cannot occur in the code of my xturtle, because I don't have to type the definitions of those frunctions into the script by hand. Instead they are generated automatically from the corresponding methods of RawPen and Pen respectively. That's all good and well. It still needs to be reviewed. And aren't 25+ bugfree samplescripts of great variety and broad range in complexity to consider a more reliable proof of at least usability than the procedure you applied? It's not only about finding bugs. It's also about studying the consistency of the new API, and so on. As for reliable proofs: An automatic test suite for turtle.py would be a good thing to have. A more courageous and less bureaucratic approach to the problem would be appropriate. Perhaps combined with some fantasy. This bureaucracy has worked fine all the years, and in cases where it was relaxed, we had to regret the changes we accepted more often than not (just like the bug you discovered: the patch should not have been accepted without test cases). P.S.: If this posting doesn't move points of view, at least it reveals one fixable bug in turtle.py (albeit also one unfixable!) The approach used in xturtle (i.e. represent circles as polylines) could also be used for turtle.py, no? 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] xturtle.py
[Collin Winter] While I have no opinion on Gregor's app, and while I fully agree that new language features and stdlib modules should generally stay out of bug-fix point releases, xturtle doesn't seem to rise to that level (and hence, those restrictions). [Martin] It's a stdlib module, even if no other stdlib modules depend on it; try import turtle. In the specific case, the problem with adding it to 2.5 is that xturtle is a huge rewrite, so ideally, the code should be reviewed before being added. Given that this is a lot of code, nobody will have the time to perform a serious review. It will be hard enough to find somebody to review it for 2.6 - often, changes of this size take several years to review (primarily because it is so specialized that only few people even consider reviewing it). As a compromise. we could tack Gregor Lingl's module under the Tools directory. This makes the tool more readily available for student use and allows it a more liberal zone to evolve than if it were in the standard library. 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). Raymond ___ 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: For example: put turtle.py and xturtle.py both into beta2 and see which one stands better the (beta)test of time. Or perhaps you have an even better idea! As a compromise, we could put an ad into the turtle document (a see also link). 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] once [was: Simple Switch statementZ]
I believe at least one poster has pointed out that 'once' (if defined suitably) could be used as a better way to do this: def index_functions(n): return [(lambda: once i) for i in range(n)] But delaying the evaluation of the once argument until the function is called would break this, since none of these functions are called until after the loop is over, so the original bug would be back. I've been trying to sort out the different terms once, const, and static. Below is what feels right to me. Not that it is right, but how I think I would interpret them as if I were new to python and what would be easiest to understand. The once below isn't what is being discussed but it seems to me what the word implies. once = Evaluate an expression once and use that value in place of the expression if the same line is executed again. for n in range(10): print n# print 0 through 9 for n in range(10): print (once n) # prints 0 ten times a = (once 3 * pi) # replaces 3 * pi with value b = i + (once sum(range(10))) # evaluate 'sum()' only once # use the result many times # in a loop const = Bind a name to a value and protect it from further change in the current scope at execution time. This protects the name, but not the object. A constant mutable is still mutable. The name just can't be rebound to another object. def foo(i): i += 1# this is ok const i # it becomes locked at this point i = 2 # this gives an exception static = Evaluate an expression at function compile time. Any values in the expression need to be known at function compile time. They can be static names in the current scope previously evaluated. a, b = 1, 2 def foo(i): static j = a+b static k = j*2 k = 25 # ok if not also const const j # protect it from further change j = 12 # give an exception The term static does seem to suggest lack of change, so it could also have the const property by default. If it were allowed to be changed, then would it keep the changed value on the next call? Probably not a good idea for the use cases being discussed. So given the above only the static version solves the above lambda loop and returns a list of functions that return values 0 through n. I think all three of these properties are useful, but I don't think we need all three of them. Cheers, Ron (* I'll be away from my computer for about a week after Tomorrow morning.) ___ 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: As a compromise. we could tack Gregor Lingl's module under the Tools directory. This makes the tool more readily available for student use and allows it a more liberal zone to evolve than if it were in the standard library. That could also work. See my other compromise proposal: advertising it in the docs. 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). Thanks for the report. xturtle does provide a fatter API; it goes up from 50 turtle functions in turtle.py to 93 in xturtle.py (counting with len([s for s in dir(turtle) if 'a' s 'z']) - I think turtle should grow an __all__ attribute). 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!
Fredrik Lundh schrieb: Gregor Lingl wrote: What a shame!! An immanent bug, persistent for years now! Is this what Anthony Baxter calls the most solid Python release ever do you really think stuff like this helps your cause ? Perhaps it dosn't help the turtle - cause. (I confess, I was a bit upset, please excuse!) But please let me clarify one point. 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. 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. 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) The only point is, that it leaves Python's turtle.py an (imho) unsatisfactory solution. See for instance Vern Ceder judgment: http://mail.python.org/pipermail/edu-sig/2006-June/006625.html Regards, Gregor Final remark: I know, that my English is not very good. So I feel, that possibly I have not complete control over the 'undertones' of my writing. If sombody feels offended, please excuse, that was not my intent. /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/glingl%40aon.at ___ 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
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. -- Greg ___ 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
Talin wrote: The case - sub mapping doesn't need to be defined every time - that's the point, you as the programmer decide when and how to construct the dictionary, Then you seem to be proposing a variation on the constant-only case option, with a more convoluted control flow. -- Greg ___ 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] xturtle.py
Raymond 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). This argues against xturtle as it stands today. By all means, mention it in the docs as a possibly superior replacement that people can install themselves. Consider it for 2.6. But give it some time to mature before freezing it into the stdlib. (1) The API got much bigger. (2) Despite minor backwards compatibility problems, such as no longer re-exporting math.* (3) The auto-generation of code is clever, but probably not the best example to start with when teaching a raw beginner. I think that by 2.6, it probably will be ready to replace the existing turtle.py But I also think that if it goes in today, there will be at least a few decisions that we regret. These are much easier to fix while it is still an independent project. -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] doc for new restricted execution design for Python
Jim Jewett wrote: IMHO, I would prefer that it limit disk consumption; a deleted or overwritten file would not count against the process, but even a temporary spike would need to be less than the cap. The problem is that there's no easy way to reliably measure disk consumption by a particular process, particularly on Unix. For example, os.unlink() doesn't necessarily free the space used by a file -- there could be other links to it, or the same or another process may hold another file descriptor referencing it. Another problem is that Unix files can have holes in them, e.g. if you create a file, seek to position 100, and write a byte, you're not using a megabyte of disk. Accounting for all these possibilities reliably would be very complicated, and maybe even impossible to get exactly right. -- Greg ___ 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: xturtle 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? -- Greg ___ 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(!?)
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'. 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