date:20060628

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.

___
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.

___
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...

 



___
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?

2006-06-28 Thread Armin Rigo

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=5470&atid=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=5470&atid=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

2006-06-28 Thread Ralf W. Grosse-Kunstleve

--- "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 "", line 1, in 
  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

2006-06-28 Thread Nick Coghlan

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(!?)

2006-06-28 Thread A.M. Kuchling

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... ;-)

 



___
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 sta

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  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.

___
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

2006-06-28 Thread Raymond Hettinger

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

2006-06-28 Thread Josiah Carlson


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  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(!?)

2006-06-28 Thread Josiah Carlson

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/o

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 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'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(!?)

2006-06-28 Thread Collin Winter

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(!?)

2006-06-28 Thread Aahz

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 ). 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

2006-06-28 Thread Giovanni Bajo

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

2006-06-28 Thread Talin

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

2006-06-28 Thread Trent Mick

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 .

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 .

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 .

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] doc for new restricted execution design for Python

On 6/28/06, Guido van Rossum <[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?Because that's how filesystems work. Allocations are in terms of blocksizes. 1000 files of 1 byte take up the same space as 1000 files of
512 bytes (in most common filesystems anyway -- I think Reiserfs maybe 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 thefilesystem. Most unix filesystems have a limit; I've run into itoccasionally when I had a really large partition with not enoughinodes configured and I was creating lots of tiny files. See df(1).
I understand that.  What I am saying is that by specifying only specific files to open you cap the number of open inodes you create.  If you only have room for five more inodes for the program to open, only specify five specific files for the sandboxed interpreter (see?  I learn fast  =) that it can open.
> > - 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 aneasily controlled operation just like file creation) I've given yousome things to watch out for. I once ran into a situation where ascript had gone off into deep recursion and created a near-infinite
hierarchy of directories that rm -r couldn't remove (because itconstructs absolute paths that exceeded MAXPATH).I would rather not handle that and just warn people that if they allow full use of 'os' that they better know what they are doing. 
-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?)
> 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

Re: [Python-Dev] RFC: trunk checkins between now and 2.5 final

2006-06-28 Thread Tim Peters

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

2006-06-28 Thread Georg Brandl

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

2006-06-28 Thread Eric Sumner

> > 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] once [was: Simple Switch statementZ]

On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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

> > 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.

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)]

> > > 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".

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.

> > > 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.

-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

2006-06-28 Thread Bob Ippolito

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

2006-06-28 Thread Bill Janssen

> 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

2006-06-28 Thread Andreas Raab

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

2006-06-28 Thread James Y Knight

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 "", 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 "", line 1, in 
   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

2006-06-28 Thread Aahz

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] doc for new restricted execution design for Python

2006-06-28 Thread Trent Mick

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 and 
really though about it). Sorry for the unsubstantiated babbling.

To Bob's question on how much interpreter state *is* there: I don't 
know. Have you done any measuring of that, Brett?

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] 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 ?



___
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!

2006-06-28 Thread Bob Ippolito


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 "", line 1, in 
>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 "", line 1, in 
> >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

2006-06-28 Thread python

[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]

2006-06-28 Thread Ron Adam

> 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 a replacement for turtle.py(!?) ATTENTION PLEASE!

2006-06-28 Thread Georg Brandl

Guido van Rossum wrote:
> It was already patched by the other Georg. Thanks for the quick fix, georgbot!

My pleasure, even if there's a difference between "Georg" and "Gregor" ;)

cheers,
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] 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.

> 
>
> ___
> 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(!?)