date:20060701

Guido van Rossum wrote:
 It's up to the release manager now to decide whether the pitchforks at
 Google or the pitchforks in the larger Python community are sharper.
 ;-)
 
 --Guido (ducks)

I vaguely recall one of the reasons we went with the warning approach was to 
find out whether or not dropping __init__.py would cause serious problems - I 
think we have our answer to that question now :)

How does this sound for a way forward?:

2.5b2:
  - ignore ImportWarning by default (like PendingDeprecationWarning)
  - include in What's New instructions to enable it via the command line or 
Python code

2.6:
  - only show ImportWarning if the import ultimately fails
  - enable ImporWarning by default
  - consider allowing a .py extension on a directory name as an alternative to 
an __init__.py file.

Google could then change their sitecustomize.py to enable the warning by 
default when they roll out 2.5 :)

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] 2.5 and beyond

2006-07-01 Thread Anthony Baxter

On Saturday 01 July 2006 05:19, Martin v. Löwis wrote:
 James Y Knight wrote:
  I just submitted http://python.org/sf/1515169 for the
  ImportWarning issue previously discussed here. IMO it's
  important.

 At the moment (i.e. without an acceptable alternative
 implementation) it's primarily a policy issue. There really isn't
 any bug here; (to speak with Microsoft's words): This behavior is
 by design.

 Only the release manager or the BDFL could revert the feature, and
 Guido already stated that the warning stays until Python 3, and
 probably even after that. I personally believe the only chance to
 get this changed now is a well-designed alternative implementation
 (although this is no promise that such an alternative would
 actually be accepted).

given the number of people and ways that this can emit a spurious 
warning, I think it should be reverted for 2.5. At _best_ we could 
maybe have a new -W switch to make it be generated, but this should 
be off by default.

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] 2.5 and beyond

2006-07-01 Thread Tim Peters

[Giovanni Bajo]
  a = []
  for i in range(10):

 ... a.append(lambda: i)
 ...

  print [x() for x in a]

 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]

 This subtle semantic of lambda is quite confusing, and still forces people to
 use the i=i trick.

[Greg Ewing]
 This has *nothing* to do with the semantics of lambda!
 It's because Python's for-loop doesn't put its control
 variable in a new scope, the way Scheme's equivalent
 construct does.

I don't think I follow that.  Scheme has no loops in Python's sense --
things like do are shorthand for expressing stylized recursion,
where each conceptual iteration gets a fresh set of loop variables.
When people talk about giving a Python for-loop vrbl its own scope,
they generally don't mean a new scope on _each iteration_, they just
mean that, e.g.,

i = 5
for i in range(10):
 # do stuff
print i

prints 5 intead of 9, about the same as creating a nested block with
its own autos in C.  The Scheme way is more like:

i = 5
def step(i):
 # do stuff
 if i  9:
 step(i+1)
step(0)
print i

except with tail-recursion elimination.  That also prints 5, but does
a hell of a lot more than _just_ arrange for that.

 *That's* what needs to be addressed to fix this problem.
 I've made a suggestion about that before, but Guido
 rejected it, so I won't repeat it here.

Don't recall what that was, but creating a new scope on each iteration
sounds hard to explain in Python.  If Giovanni wants the Scheme way
;-), it's available:


a = []
def step(i):
a.append(lambda: i)
if i  9:
step(i+1)
step(0)
print [x() for x in a]


prints [0, 1, 2, 3, 4, 5, 6, 7, 8, 9], although it's more sanely
written in Python with a loop:


def make_lambda(i):
return lambda: i
a = []
for i in range(10):
a.append(make_lambda(i))
print [x() for x in a]


Abusing the default-argument machinery to capture current bindings is
never necessary, and _is_ abuse.  Of course I do it too -- but rarely
:-)
___
Python-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] 2.5 and beyond

Giovanni Bajo wrote:
 Yes but:
 
 a = []
 for i in range(10):
 ... a.append(lambda: i)
 ...
 print [x() for x in a]
 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
 
 This subtle semantic of lambda is quite confusing, and still forces people to
 use the i=i trick.

If you'd like each function instance to have a separate closure scope, then 
*give* each function a separate closure scope, instead of making them all 
share the same one the way you have above:

  def make_f(i):
... def f():
... return i
... return f
...
  a = []
  for i in range(10):
... a.append(make_f(i))
...
  print [x() for x in a]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

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] 2.5 and beyond

Anthony Baxter wrote:
 given the number of people and ways that this can emit a spurious 
 warning, I think it should be reverted for 2.5. At _best_ we could 
 maybe have a new -W switch to make it be generated, but this should 
 be off by default.

Last line of warnings.py

Copy, paste, s/PendingDeprecationWarning/ImportWarning

-Wd to enable it again :)

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] Cleanup of test harness for Python

2006-07-01 Thread Armin Rigo

Hi all,

On Fri, Jun 30, 2006 at 10:05:14AM -0400, Frank Wierzbicki wrote:
 some checks for CPython internal tests that should be excluded from
 Jython

I know Frank already knows about this, but I take the occasion to remind
us that
http://codespeak.net/svn/pypy/dist/lib-python/modified-2.4.1/test
already shows which tests we had to modify for PyPy to make them less
implementation-detail-dependent, and which changes were made.

A possible first step here would be to find a consistent way to check,
in the test, which implementation we are running on top of, so that we
can (re-)write the tests accordingly.


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] sys.settrace() in Python 2.3 vs. 2.4

2006-07-01 Thread Armin Rigo

Hi Josiah,

On Fri, Jun 30, 2006 at 01:27:24PM -0700, Josiah Carlson wrote:
 I'll just have to gracefully degrade functionality for older Pythons. 

More precisely, the bug shows up because in

  while 1:
  pass

the current line remains on the 'pass' forever.  It works for a loop
like that:

  while 1:
  sys
  sys

but it's admittedly quite obscure.


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] Lexical scoping in Python 3k


Greg Ewing [EMAIL PROTECTED] wrote:
 
 Josiah Carlson wrote:
 
  What I asked before, and what I'd like to ask again, is if there are any
  _nontrivial uses_ of lexically nested scopes which are made cumbersome
  by our inability to write to parent scopes.
 
 The trouble with taking that position is that the very
 cases which would benefit are very *simple* ones, where
 it would be cumbersome to refactor it to use a class,
 or mutable object in the outer scope, etc. So you've
 effectively set up your acceptance criteria to be
 unmeetable.

If the only code that benefits from such changes are very *simple*,
then I think that says something about its necessity.  That is, if
anything more complicated than those that are very *simple* generally
don't benefit, then I don't believe that such a modification would be
beneficial to the language overall. Further, a simple namespace factory
can handle much of the current issues, without needing to create or
change keywords.

def namespace(**kwds):
class namespace(object):
__slots__ = kwds.keys()
def __init__(self):
for i,j in kwds.iteritems():
setattr(self, i,j)
return namespace()

def trivial_counter(start):
ns = namespace(current=start-1)
def next():
ns.current += 1
return ns.current
return next

Maybe a variant of the above namespace factory should make it into the
collections module.


  If there aren't, then I'm
  going to again have to argue against new syntax, keywords, and their use.
 
 There's one very simple way we could do this in Py3k
 without requiring any new syntax or keywords: just
 redefine the meaning of global to mean not local.

I would probably be a solid -0 on such a proposal; I still don't think
it's really necessary, but I've never used (or really seen) global more
than one level deep, so would guess its impact would be low.


 - 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] Bug in stringobject?

2006-07-01 Thread Georg Brandl

Georg Brandl wrote:
 In string_replace, there is
 
   if (PyString_Check(from)) {
 /* Can this be made a '!check' after the Unicode check? */
   }
 #ifdef Py_USING_UNICODE
   if (PyUnicode_Check(from))
   return PyUnicode_Replace((PyObject *)self,
from, to, count);
 #endif
   else if (PyObject_AsCharBuffer(from, tmp_s, tmp_len))
   return NULL;
 
 [the same check with to]
 
   return (PyObject *)replace((PyStringObject *) self,
  (PyStringObject *) from,
  (PyStringObject *) to, count);
 
 
 Can this be correct if from or to isn't a string object, but a
 char buffer compatible object?

May I note that this is still unresolved? I can submit a bug report
and add it to PEP 356, too...

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] Bug in stringobject?

2006-07-01 Thread Fredrik Lundh

Georg Brandl wrote:

 Can this be correct if from or to isn't a string object, but a
 char buffer compatible object?
 
 May I note that this is still unresolved? I can submit a bug report
 and add it to PEP 356, too...

it's already on my todo list, but that list is full of stuff, so having 
it on the official todo list is probably a good idea.  if you do add it, 
assign it to me.

/F

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug in stringobject?

2006-07-01 Thread Georg Brandl

Fredrik Lundh wrote:
 Georg Brandl wrote:
 
 Can this be correct if from or to isn't a string object, but a
 char buffer compatible object?
 
 May I note that this is still unresolved? I can submit a bug report
 and add it to PEP 356, too...
 
 it's already on my todo list, but that list is full of stuff, so having 
 it on the official todo list is probably a good idea.  if you do add it, 
 assign it to me.

Done. #1515471.

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

[Python-Dev] weakattr

2006-07-01 Thread tomer filiba

weakattr (weak attributes) are attributes that are weakly referencedby their containing object. they are very useful for cyclic references --an object that holds a reference to itself. when a cyclic reference is found by the GC, the memory may be 
freed, but __del__ is not called, because it's impossible to tell which __del__ to call first. this is an awkward asymmetry with no clean solution: most such objects provide a close or dispose method
that must be called explicitly.weakattrs to solve this problem, by providing a magical attributethat disappears when the attribute is no longer strongly-referenced. you can find the code, as well as some examples, on this link
http://sebulba.wikispaces.com/recipe+weakattr
since the stdlib already comes with weakref.py, which provideshigher level concepts over the builtin _weakref module, i'd like tomake weakattr a part of it. it's only ~20 lines of code, and imho saves the trouble of explicitly 
releasing the resource of un__del__able objects.i think it's useful. here's a snippet: from weakref import weakattr  class blah(object):...  yada = weakref()
... o1 = blah() o2 = blah() o1.yada = o2 o2.yada = o1o1.yada is a *weakref* to o2, so that when o2 is no longer strongly-referenced... del o2
o1.yada magically disappears as well.  o1.yada... AttributeError(...)since the programmer explicitly defined yada as a weakatt, he/she knows it might disappear. it might look awkward at first, but that's 
exactly the *desired* behavior (otherwise we'd just use the regular strong attributes).another thing to note is that weakattrs are likely to be gone onlywhen the object's __del__ is already invoked, so the only code that
needs to take such precautions is __del__ (which already has some constraints)for example: class blah(object):... me = weakattr().. def __init__(self):... 
self.me = self.. def something(self):... # we can rest assure me exists at this stage... print self.me.. def __del__(self):... # by the time __del__ is called, me is removed
... print me exists?, hasattr(self, me)... b = blah() b.me__main__.blah object at 0x00C0EC10 b.something()__main__.blah object at 0x00C0EC10
 del b import gc gc.collect()me exists? False0-tomer
___
Python-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] Lexical scoping in Python 3k

2006-07-01 Thread Neil Schemenauer

Ka-Ping Yee [EMAIL PROTECTED] wrote:
 Most other languages that support lexical scoping (including Scheme,
 JavaScript, Ruby, Perl, E, Java, Smalltalk) provide a uniform way
 to read and write to scopes at all levels.  This is done by letting
 programmers specify the scope in which they want a variable bound
 (usually with a keyword like var in JavaScript, my in Perl, or
 define in E).

That's not the Python way, IMO.  I think the right way (assuming we
actually want to allow it) is to introduce a pure assignment
statement in addition to the assignment/declaration statement that
we already have.  For example:


a = 1 
def f():
b = 2
a := 2
def g():
b := 3
print a, b, c
g()
f()

would print 2 3 4.  The := would assign but not declare a variable
in the current scope.

  Neil

___
Python-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] zlib module build failure on Mac OSX 10.4.7

2006-07-01 Thread Ronald Oussoren



On Jul 1, 2006, at 5:32 AM, [EMAIL PROTECTED] wrote:

Just upgraded my Mac to OSX 10.4.7 yesterday.  svn up'd Python  
trunk, then
make clean ; configure ; make and I see that building the zlib  
module

fails:

gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno- 
fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/Users/ 
skip/src/python-svn/trunk/./Include -I/Users/skip/src/python-svn/ 
trunk/./Mac/Include -I/Users/skip/local/include -I../Include -I. -I/ 
usr/local/include -I/Users/skip/src/python-svn/trunk/Include -I/ 
Users/skip/src/python-svn/trunk/build -c /Users/skip/src/python-svn/ 
trunk/Modules/zlibmodule.c -o build/temp.macosx-10.3-ppc-2.5/Users/ 
skip/src/python-svn/trunk/Modules/zlibmodule.o
/Users/skip/src/python-svn/trunk/Modules/zlibmodule.c: In  
function 'PyZlib_uncopy':
/Users/skip/src/python-svn/trunk/Modules/zlibmodule.c:724:  
warning: implicit declaration of function 'inflateCopy'
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3- 
ppc-2.5/Users/skip/src/python-svn/trunk/Modules/zlibmodule.o -L/ 
Users/skip/local/lib -L/usr/local/lib -lz -o build/lib.macosx-10.3- 
ppc-2.5/zlib.so -Wl,-search_paths_first
*** WARNING: renaming zlib since importing it failed: dlopen 
(build/lib.macosx-10.3-ppc-2.5/zlib.so, 2): Symbol not found:  
_inflateCopy

  Referenced from: build/lib.macosx-10.3-ppc-2.5/zlib.so
  Expected in: dynamic lookup

Anybody else seen this?  I checked the buildbot trunk osx 10.4.  It  
seemed
to have no trouble.  And what's with the 10.3 bit in the  
directory names?


Are you sure you're building on a 10.4 box? Both the macosx-10.3  
thingy and lack of inflateCopy seem to indicate that you're running  
on 10.3.


Ronald



Skip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/ 
ronaldoussoren%40mac.com




smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

2006-07-01 Thread Almann T. Goo

On 7/1/06, Josiah Carlson [EMAIL PROTECTED] wrote:
There's one very simple way we could do this in Py3k without requiring any new syntax or keywords: just redefine the meaning of global to mean not local.I would probably be a solid -0 on such a proposal; I still don't think
it's really necessary, but I've never used (or really seen) global morethan one level deep, so would guess its impact would be low.This has been discussed at length in the following thread that I started in February and at least one time before that.
http://mail.python.org/pipermail/python-dev/2006-February/061568.htmlI think using the global keyword is probably the lowest impact form and has the least amount of backwards incompatibility. Below is the part of the last thread that I talked about changing the meaning of global.
http://mail.python.org/pipermail/python-dev/2006-February/061852.htmlHaving the global keyword semantics changed to be lexically global
would break in the cases that global is used on a name within anested scope that has an enclosing scope with the same name. I wouldsuppose that actual instances in real code of this would be rare.
Consider: x = 1 def f() :... x = 2... def inner() :... global x... print x... inner()... f()1Under the proposed rules:
f()2PEP 227 also had backwards incompatibilities that were similar and Isuggest handling them the same way by issuing a warning in these caseswhen the new semantics are not being used (
i.e. no from __future__).Most people probably think that this is a low impact wart on the Python language that not really worth fixing as there are workarounds (i.e. mutable objects) or other ways to express (
i.e. use classes) such things, but it does trip people up from time to time as warts typically do--I guess that's why this gets brought up now and again. Best regards,Almann-- Almann T. Goo
[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] zlib module build failure on Mac OSX 10.4.7

2006-07-01 Thread skip


Ronald Are you sure you're building on a 10.4 box?  Both the
Ronald macosx-10.3 thingy and lack of inflateCopy seem to indicate that
Ronald you're running on 10.3.

Well, yeah, pretty sure.  Let's see.  The box with the disk says Mac OS X
Tiger - Version 10.4 on the spine. The About This Mac popup says
10.4.7.  It used to run 10.3 though.  Is there some possibility the update
from 10.3 to 10.4 had problems?

Note that the compile log on the buildbot 10.4 box also has 10.3 in its
directory names.  If I remember correctly, it came from Apple with 10.4
installed.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ImportWarning flood

2006-07-01 Thread Sergey A. Lipnevich

All,

I tried to implement Jean-Paul Calderone's idea for the following patch,
plagiarizing Ralf W. Grosse-Kunstleve's error text. It delays import
warning until end of search for modules, but remembers how many
potential modules (candidates without __init__.py) it didn't import. I
didn't really try to analyze any conditions, instead I simply assumed
that wherever ImportWarning would be issued, we have a suitable
candidate, and saved it on the stack. If nothing is found, Python emits
ImportWarning right before ImportError, and explains what happened.
Please let me know if this would work and if anything needs to be done
for this patch to be accepted.
Thank you!

Sergey.
Index: Python/import.c
===
--- Python/import.c	(revision 47190)
+++ Python/import.c	(working copy)
@@ -1203,6 +1203,10 @@
 		return NULL;
 	}
 
+	/* prepare to find a directory without __init__.py and report it */
+	char candidate_path[MAXPATHLEN];
+	int candidate_count = 0;
+
 	npath = PyList_Size(path);
 	namelen = strlen(name);
 	for (i = 0; i  npath; i++) {
@@ -1307,15 +1311,8 @@
 return fd_package;
 			}
 			else {
-char warnstr[MAXPATHLEN+80];
-sprintf(warnstr, Not importing directory 
-	'%.*s': missing __init__.py, 
-	MAXPATHLEN, buf);
-if (PyErr_Warn(PyExc_ImportWarning,
-	   warnstr)) {
-	Py_XDECREF(copy);
-	return NULL;
-}
+if (candidate_count++ == 0)
+	strncpy(candidate_path, buf, MAXPATHLEN);
 			}
 		}
 #else
@@ -1328,15 +1325,9 @@
 return fd_package;
 			}
 			else {
-char warnstr[MAXPATHLEN+80];
-sprintf(warnstr, Not importing directory 
-	'%.*s': missing __init__.py, 
-	MAXPATHLEN, buf);
-if (PyErr_Warn(PyExc_ImportWarning,
-	   warnstr)) {
-	Py_XDECREF(copy);
-	return NULL;
-}
+if (candidate_count++ == 0)
+	strncpy(candidate_path, buf, MAXPATHLEN);
+			}
 		}
 #endif
 #endif
@@ -1409,6 +1400,16 @@
 			break;
 	}
 	if (fp == NULL) {
+		if (candidate_count  0) {
+			char warnstr[MAXPATHLEN+256];
+			sprintf(warnstr, Found but not imported %d directory(ies)
+ due to missing __init__.py. First such directory follows\n
+%.*s\n
+See the section on \Packages\ in the Python tutorial for
+ details (http://www.python.org/doc/tut/).,
+candidate_count, MAXPATHLEN, candidate_path);
+			PyErr_Warn(PyExc_ImportWarning, warnstr);
+		}
 		PyErr_Format(PyExc_ImportError,
 			 No module named %.200s, name);
 		return NULL;
___
Python-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-07-01 Thread Aahz

On Sat, Jul 01, 2006, Sergey A. Lipnevich wrote:

 Please let me know if this would work and if anything needs to be done
 for this patch to be accepted.

The first thing you need to do for ANY patch to be considered is to post
it so SourceForge (or at least post to python-dev explaining that you'll
post to SF as soon as it comes back).
-- 
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] ImportWarning flood

2006-07-01 Thread Martin v. Löwis

Sergey A. Lipnevich wrote:
 I tried to implement Jean-Paul Calderone's idea for the following patch,
 plagiarizing Ralf W. Grosse-Kunstleve's error text. It delays import
 warning until end of search for modules, but remembers how many
 potential modules (candidates without __init__.py) it didn't import. I
 didn't really try to analyze any conditions, instead I simply assumed
 that wherever ImportWarning would be issued, we have a suitable
 candidate, and saved it on the stack. If nothing is found, Python emits
 ImportWarning right before ImportError, and explains what happened.
 Please let me know if this would work and if anything needs to be done
 for this patch to be accepted.

Please notice that there is also python.org/sf/1515361

I had no time to compare this with your patch, yet.

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] ImportWarning flood

2006-07-01 Thread Sergey A. Lipnevich

Martin v. Löwis wrote:
 Sergey A. Lipnevich wrote:
 I tried to implement Jean-Paul Calderone's idea for the following patch,
 plagiarizing Ralf W. Grosse-Kunstleve's error text. It delays import
...
 Please notice that there is also python.org/sf/1515361
 
 I had no time to compare this with your patch, yet.

Thanks! I made python.org/sf/1515609. The difference (also documented in
the description) is that my patch saves memory and some CPU cycles by
not trying to collect all directories Python did not import because of
missing __init__.py. It only reports how many such directories there are
and what is the first one.

Sergey.

___
Python-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] Lexical scoping in Python 3k

2006-07-01 Thread Simon Percivall

What about doing something similar to how import was changed?

.a = 5 # this scope (self might be too magical
..a = 3 # up one scope
...a # up three

Of course, this looks ... perhaps a bit strange. Also, counting is a  
bother.

//Simon
___
Python-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] zlib module build failure on Mac OSX 10.4.7

2006-07-01 Thread Martin v. Löwis

Ronald Oussoren wrote:
 What  I don't understand yet is why your copy of libz doesn't have
 inflateCopy. 

What I don't understand is that configure does not detect that.

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] 2.5 and beyond


 a = []
 for i in range(10):
 a.append(lambda: i)
 print [x() for x in a]

 [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]

Aha! -- Thank you for jogging my memory.

You seem to be right -- the problem is not that Python is lexically scoped,
but that when you define a variable with =, it leaks out into the
surrounding function scope.

Here's an example:

If True:
y = 123
print y

It may be obvious that this should print 123, but that's only because =
combines properties of assignment and definition.  In particular, if we were
to write

y = 42
if True:
y = 123
print y

it would be very surprising if this example were to print anything but 123.

Here is a corresponding fragment in C++:

int y = 42;
if (true) {
y = 123;
}
std::cout  y  \n;

The int in the first line means that the variable y is being defined.  Its
lack in the third line means that y refers to a variable defined in an outer
scope.  So both instances of y here refer to the same variable, as they do
in Python.

But because definition and assignment are separated in C++, we can also
write

int y = 42;
if (true) {
int y = 123;
}
std::cout  y  \n;

and the fragment will print 42.  In this example, there are two distinct
variables, both named y.

So the problem, as I see it, is indeed that in Python there are suites that
look to me as if they should define scopes, but don't.  Indeed, if I write

if (foo):
y = 123

I can't even determine by inspecting the program whether y is defined at
all.  I might argue that y is always defined, by virtue of appearing before
= somewhere in this scope, but the compiler tells me name 'y' is not
defined if I try it, so I guess that's the right way to treat it.

So here's how I understand what Greg was saying.

Suppose I write

x = []
for i in range(10):
x.append(lambda:i)
print [f() for f in x]

This example will print [9, 9, 9, 9, 9, 9, 9, 9, 9, 9], which I think is
wildly unintuitive.

My intuition in this matter is partly formed by C++, but it is also formed
by other languages going as far back as Algol 68.  That intuition says that
because the suite controlled by a for statement is executed any number of
times, potentially including zero, it should be considered as its own scope,
and any variables defined in that scope should stay there.

In particular, the variable i should be defined in the scope of the for,
which implies that each time through the loop, the name i should be
(re)bound to a different object.

What surprises me even more is that if I try to define such a variable
explicitly, it still doesn't work:

x = []
for i in range(10):
j = i
x.append(lambda:j)
print [f() for f in x]

This example still prints [9, 9, 9, 9, 9, 9, 9, 9, 9, 9].  If I understand
the reason correctly, it is because even though j is defined only in the
body of the loop, loop bodies are not scopes, so the variable's definition
is hoisted out into the surrounding function scope.

To convince myself of this behavior, I defined an extra function scope, the
purpose of which is to localize j:

x = []
for i in range(10):
def foo():
j = i
return lambda:j
x.append(foo())
print [f() for f in x]

Indeed, this example prints [0, 1, 2, 3, 4, 5, 6, 7, 8, 9].  The example
also points up the fact that

x.append(lambda:i)

and

def foo():
j = i
return lambda:j
x.append(foo())

behave differently, where my intuition (and, I suspect, many other people's
as well) would be that they would be equivalent.

Finally, I observe that this second example above is also equivalent to

x.append(lambda i=i: i)

which is what explains the fairly common idiom

x = []
for i in range(10):
x.append(lambda i=i:i)
print [f() for f in x]

So maybe what I meant when I asked for lexical scopes was two things:

1) Every indentation level should be a scope;
2) In general, variable definitions should not leak into
   surrounding scopes.

I realize that (2) is too simplistic.  Someone who writes

if x  0:
y = -x
else:
y = x

will expect y to be defined in the scope surrounding the if even if it was
not already defined there.  On the other hand, I think that the subtle
pitfalls that come from allowing for variables to leak into the
surrounding scopes are much harder to deal with and understand than would be
the consequences of restricting their scopes as outlined above.



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:

Re: [Python-Dev] Lexical scoping in Python 3k

 What about doing something similar to how import was changed?
 
 .a = 5 # this scope (self might be too magical
 ..a = 3 # up one scope
 ...a # up three
 
 Of course, this looks ... perhaps a bit strange. Also, counting is a
 bother.

I'd rather see a simpler rule: = never defines a variable in a surrounding
scope.  If you want to affect the binding of such a variable, you have to
define it explicitly in the scope in which you want it.

Example:

x = 42
def f():
x = 123 # rebinds x as defined above
y = 123 # defines local variable
f()
print x # prints 123
print y # error -- y not defined

Yes, I know that rule is too simplistic.  But I think I'd still prefer it to
the way things are now.



___
Python-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] zlib module build failure on Mac OSX 10.4.7

2006-07-01 Thread Ronald Oussoren



On Jul 1, 2006, at 8:46 PM, Martin v. Löwis wrote:


Ronald Oussoren wrote:

What  I don't understand yet is why your copy of libz doesn't have
inflateCopy.


What I don't understand is that configure does not detect that.


You may be onto something there. Skip, do you have another copy of  
libz somewhere? Given the link line in your first message either in / 
usr/local/lib or /Users/skip/local/lib. And if you have, is that a  
static library (libz.a) instead of a dylib?


As background to my question: the linker on OSX behaves slightly  
different than the one on most other unix-y systems. It first  
searches the entire linker path for shared libraries (dylibs) before  
looking for static libraries. I added a flag to the link flags for  
the zlib extension a while back that changes the search order into a  
more traditional one: look in every directory on the linker path for  
either a dylib or static library.  The new flag is  -Wl,- 
search_paths_first.


If skip does indeed have libz somewhere else we'll either have to  
make a matching update to configure, or roll back my change. If the  
latter I'll have to tweak the build script for the binary installer  
for OSX because I want to link that using a static copy of libz for  
binary compatibility with OSX 10.3.9.


Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] zlib module build failure on Mac OSX 10.4.7

2006-07-01 Thread Bob Ippolito


On Jul 1, 2006, at 10:45 AM, Ronald Oussoren wrote:


 On Jul 1, 2006, at 6:57 PM, [EMAIL PROTECTED] wrote:


 Ronald Are you sure you're building on a 10.4 box?  Both the
 Ronald macosx-10.3 thingy and lack of inflateCopy seem to  
 indicate that
 Ronald you're running on 10.3.

 Well, yeah, pretty sure.  Let's see.  The box with the disk says  
 Mac OS X
 Tiger - Version 10.4 on the spine. The About This Mac popup says
 10.4.7.

 That gets the easy solution out of the way ;-)

   It used to run 10.3 though.  Is there some possibility the update
 from 10.3 to 10.4 had problems?

 Note that the compile log on the buildbot 10.4 box also has 10.3  
 in its
 directory names.  If I remember correctly, it came from Apple with  
 10.4
 installed.

 /me slaps head.

 Having 10.3 in the directory names is intentional, the version in  
 the directory name is the value of MACOSX_DEPLOYMENT_TARGET, with  
 is defaulted to 10.3 in the configure script.

 What  I don't understand yet is why your copy of libz doesn't have  
 inflateCopy. What does /usr/lib/libz.dylib point to on your system?  
 On my 10.4 box it is a symlink that points to libz.1.2.3.dylib and  
 there is an older version of libz (libz.1.1.3.dylib) in /usr/lib as  
 well.

Maybe Skip didn't upgrade to the latest version of Xcode? Perhaps  
he's still got an old SDK?

-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] 2.5 and beyond

2006-07-01 Thread Giovanni Bajo

Andrew Koenig wrote:

 Suppose I write

 x = []
 for i in range(10):
 x.append(lambda:i)
 print [f() for f in x]

 This example will print [9, 9, 9, 9, 9, 9, 9, 9, 9, 9], which I think
 is wildly unintuitive.

That is my point: to me, it's counter-intuitive just like the infamous
except NameError, TypeError. I believe that names in
lambdas/nested-functions referring to local names in the outer scope should
really be bound at function definition time (much like default arguments
are).

 What surprises me even more is that if I try to define such a variable
 explicitly, it still doesn't work:

 x = []
 for i in range(10):
 j = i
 x.append(lambda:j)
 print [f() for f in x]

 This example still prints [9, 9, 9, 9, 9, 9, 9, 9, 9, 9].  If I
 understand the reason correctly, it is because even though j is
 defined only in the body of the loop, loop bodies are not scopes, so
 the variable's definition is hoisted out into the surrounding
 function scope.

Yes. And by itself, I like this fact because it's very handy in many cases.
And it's also handy that the iteration variable of the for loop is
accessible after the for loop is terminated (in fact, this specific
behaviour is already listed among the wont-change for Py3k).

 On the other hand, I think that
 the subtle pitfalls that come from allowing for variables to leak
 into the surrounding scopes are much harder to deal with and
 understand than would be the consequences of restricting their scopes
 as outlined above.

As I said, to me there's nothing wrong with the way Python variables leak
out of the suites; or, in other words, with the fact that Python has only
two namespaces, the function-local and the global namespace. What I don't
like is that the lookup of lambda's names are fully deferred at execution
time. This behaviour is already not fully followed for local variables in
functions, since:

 y = 0
 def foo():
... print y
... y = 2
...
 foo()
Traceback (most recent call last):
  File stdin, line 1, in ?
  File stdin, line 2, in foo
UnboundLocalError: local variable 'y' referenced before assignment

which means that Python users *already* know that a variable is not really
looked up only at run-time, but there's something going on even at
function definition time. I don't see anything wrong if lambdas (or nested
scopes) did the same for names provably coming from the outer scope.
-- 
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] Empty Subscript PEP on Wiki - keep or toss?

2006-07-01 Thread Noam Raphael

Hello,

I posted it as a pre-PEP, in the hope that it may become a PEP and
be accepted. As it happened, Guido said no at the end, so I stopped
pushing the subject.

I think that the main reason for the no was that my use case wasn't
convincing enough - the objections were that this wasn't useful
enough, not that it does anything harmful*. As the one who does think
it's useful, I have the tiniest hope that if, in the future, people
will become familiar with the package and see the usefulness of
allowing empty subscript list, the decision will change. If the only
result of me posting it as a PEP is a final rejected status that
will prevent any chance of that happening, I don't think I'll bother
to make it a PEP. If it's not the case, then I'll make it a PEP and
post it.

Have a good week,
Noam

* Yes, I know that adding unneeded feature to the language can be
considered harmful. You may not agree with my distinction in this
case. As it is, I barely consider this as an added feature - I would
say it's mostly a small generalization.

2006/6/30, Georg Brandl [EMAIL PROTECTED]:
 [EMAIL PROTECTED] wrote:
  Noam Raphael posted an empty subscript PEP on the Python Wiki:
 
  http://wiki.python.org/moin/EmptySubscriptListPEP
 
  It's not linked to by any other pages on the wiki.  Is there a reason it
  wasn't added to the peps repository?

 Perhaps the author forgot to submit it to the PEP editor, or he decided
 to abandon it after the mostly negative discussion here.

 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/noamraph%40gmail.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] doc for new restricted execution design for Python

2006-07-01 Thread Samuele Pedroni

Brett Cannon wrote:
 
 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?

if I remember correctly, the boundary/granularity of mutual isolation
is practically web domains, pages from the same domain can liberally 
access each other data, javascript state.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-07-01 Thread Brett Cannon

On 6/30/06, Greg Ewing [EMAIL PROTECTED] wrote:
Brett Cannon wrote: 1) Is removing 'file' from the builtins dict in PyInterpreterState (and maybe some other things) going to be safe enough to sufficiently hide 'file' confidently (short of someone being stupid in their C extension
module and exposing 'file' directly)? 2) Changing open() to return C-implemented delegate objects for files (and thus won't type check, but this is Python so I am not worried about that too much) and delegate socket objects for IP and URL addresses.
My suggestion is to change things so that the constructorof the file type doesn't open files (at least in restrictedmode). Then it wouldn't matter if untrusted code had realfile objects, as they couldn't use them to get access to
any other files.So require use of open() to open a file and then put the access restrictions in open() while turning off the constructor for file?Seems reasonable. It basically shifts the access restrictions to open() instead of 'file'. For some reason this proposal makes me want to remove the checks in read/write methods as well. That way there is only open() that needs to do the checks and 'file' can have the constructor crippled and that be it. Really minimize the impact of code on 'file' itself.
Do people think that having the restriction checks for every read/write method is necessary? I originally thought of doing that so that if an open file object leaked into a restricted interpreter by accident there would still be proper protections, but perhaps that should not be the resopnsibility of 'file' and instead should be more up to modules not passing back exposed 'file' objects into code.
-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] zlib module build failure on Mac OSX 10.4.7

2006-07-01 Thread skip


Ronald What does /usr/lib/libz.dylib point to on your system?  

% cd /usr/lib
% ls -l libz.*
lrwxr-xr-x   1 root  wheel 12 Feb 12 00:32 libz.1.1.3.dylib - 
libz.1.dylib
-rwxr-xr-x   1 root  wheel  72588 Jun 29 18:36 libz.1.2.3.dylib
lrwxr-xr-x   1 root  wheel 16 Feb 12 00:32 libz.1.dylib - 
libz.1.2.3.dylib
lrwxr-xr-x   1 root  wheel 16 Feb 12 00:32 libz.dylib - 
libz.1.2.3.dylib

Looks like everything on my system winds up at 1.2.3.

Ronald What I don't understand yet is why your copy of libz doesn't
Ronald have inflateCopy. 

It appears to:

% nm libz.1.2.3.dylib | egrep -i inflate
 U _inflate
 U _inflateEnd
 U _inflateInit2_
 U _inflateReset
 U _inflate
 U _inflateEnd
 U _inflateInit_
libz.1.2.3.dylib(inflate.o):
9110ea18 T _inflate
911168cc T _inflateCopy
9110e5d8 T _inflateEnd
91116694 t _inflateGetHeader
9110dc84 T _inflateInit2_
9110e680 T _inflateInit_
91116524 t _inflatePrime
9110dddc T _inflateReset
91116584 T _inflateSetDictionary
91116744 T _inflateSync
91116888 T _inflateSyncPoint
 u _inflate_fast
 u _inflate_table
91116b90 T _inflateBack
91117a6c T _inflateBackEnd
91116a38 T _inflateBackInit_
 u _inflate_fast
 u _inflate_table
91118334 s _inflate_copyright
9111047c t _inflate_table
91110930 t _inflate_fast

However, even though the zlib.so is linked with -lz, there's no evidence of
it in the otool -L output:

% make
case $MAKEFLAGS in \
*-s*)  CC='gcc' LDSHARED='gcc  -bundle -undefined dynamic_lookup' 
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ../setup.py -q 
build;; \
*)  CC='gcc' LDSHARED='gcc  -bundle -undefined dynamic_lookup' 
OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python.exe -E ../setup.py 
build;; \
esac
running build
running build_ext
db.h: found (4, 2) in /sw/include/db4
db lib: using (4, 2) db-4.2
sqlite: found /usr/include/sqlite3.h
/usr/include/sqlite3.h: version 3.1.3
building 'zlib' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd 
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I/Users/skip/src/python-svn/trunk/./Include 
-I/Users/skip/src/python-svn/trunk/./Mac/Include -I/Users/skip/local/include 
-I../Include -I. -I/usr/local/include 
-I/Users/skip/src/python-svn/trunk/Include 
-I/Users/skip/src/python-svn/trunk/build -c 
/Users/skip/src/python-svn/trunk/Modules/zlibmodule.c -o 
build/temp.macosx-10.3-ppc-2.5/Users/skip/src/python-svn/trunk/Modules/zlibmodule.o
/Users/skip/src/python-svn/trunk/Modules/zlibmodule.c: In function 
'PyZlib_uncopy':
/Users/skip/src/python-svn/trunk/Modules/zlibmodule.c:724: warning: 
implicit declaration of function 'inflateCopy'
gcc -bundle -undefined dynamic_lookup 
build/temp.macosx-10.3-ppc-2.5/Users/skip/src/python-svn/trunk/Modules/zlibmodule.o
 -L/Users/skip/local/lib -L/usr/local/lib -lz -o 
build/lib.macosx-10.3-ppc-2.5/zlib.so -Wl,-search_paths_first
*** WARNING: renaming zlib since importing it failed: 
dlopen(build/lib.macosx-10.3-ppc-2.5/zlib.so, 2): Symbol not found: _inflateCopy
  Referenced from: build/lib.macosx-10.3-ppc-2.5/zlib.so
  Expected in: dynamic lookup

running build_scripts
montanaro:build% otool -L build/lib.macosx-10.3-ppc-2.5/zlib_failed.so 
build/lib.macosx-10.3-ppc-2.5/zlib_failed.so:
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current 
version 93.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.1.6)

Ah, found it!  There was an antique libz.a in /usr/local/lib dating from
2003.  It's all better now.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Empty Subscript PEP on Wiki - keep or toss?

2006-07-01 Thread skip


Noam If the only result of me posting it as a PEP is a final rejected
Noam status that will prevent any chance of that happening, I don't
Noam think I'll bother to make it a PEP. If it's not the case, then
Noam I'll make it a PEP and post it.

Even if it's ultimately rejected, it still serves as useful documentation of
the process.  I'd go ahead and update it to reflect the latest discussions,
submit it, then let the chips fall where they may.  That would also get it
out of the wiki, orphaned page that it is.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

2006-07-01 Thread Ka-Ping Yee

On Sat, 1 Jul 2006, Greg Ewing wrote:
 I don't disagree with anything you said, but I think it
 would be a good idea to avoid using phrases like proper
 lexical scopes, which is likely to set people off on
 a tangent. The issue isn't lexicality, it's writeability.

Fully functional lexical scopes, then?  Python's scopes are
lexical (except for builtins) but currently somewhat hamstrung.


-- ?!ng
___
Python-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] Lexical scoping in Python 3k

 Fully functional lexical scopes, then? 

Fine-grained scopes?



___
Python-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] 2.5 and beyond

 Don't recall what that was, but creating a new scope on each iteration
 sounds hard to explain in Python.

I don't think it's particularly hard to explain.  For example, one way to
explain it is to say that

for i in stuff:
body

is equivalent to

for hiddenvar in stuff:
local i = hiddenvar
body

This explanation doesn't need to rest on recursion.



___
Python-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] 2.5 and beyond

2006-07-01 Thread Tim Peters

[Tim]
 Don't recall what that was, but creating a new scope on each iteration
 sounds hard to explain in Python.

[Andrew Koenig]
 I don't think it's particularly hard to explain.  For example, one way to 
 explain it is
 to say that

 for i in stuff:
 body

 is equivalent to

 for hiddenvar in stuff:
 local i = hiddenvar
 body

 This explanation doesn't need to rest on recursion.

Sorry, but as a Python programmer that explanation makes little sense
to me.  In effect, it pushes the mystery into what local is supposed
to mean, but there's nothing _already_ in Python that acts the way you
need local to act.

Scope in Python is defined wrt blocks, so you need to phrase this in
terms of blocks, and there are very few kinds of blocks in Python's
execution model:

A block is a piece of Python program text that is executed as a unit.
The following are blocks: a module, a function body, and a class definition.
Each command typed interactively is a block. A script file (a file given as
standard input to the interpreter or specified on the interpreter command
line the first argument) is a code block. A script command (a command
specified on the interpreter command line with the `-c' option) is a code
block. The file read by the built-in function execfile() is a code block.
The string argument passed to the built-in function eval() and to the exec
statement is a code block. The expression read and evaluated by the
built-in function input() is a code block.

That's from section Naming and binding of the Python Reference
Manual.  I expect most Python programmers have module, function,
class ... plus some weird stuff I don't much care about in mind.
Python's execution model also has a one-to-one correspondence between
active blocks and execution frames (see the rest of that section),
which would need to be snapped to consider a finer-grained notion of
block that didn't have its own execution frame.

In short, it's only easy to define this in Python, without invoking
nested functions, if you don't have Python's execution model in mind
to begin with.
___
Python-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] how long to wait for expat to incorpo rate a fix to prevent a crasher?

2006-07-01 Thread Fred L. Drake, Jr.

On Friday 30 June 2006 16:03, Martin v. Löwis wrote:
  If you have a patch, you should commit it to our copy. Make sure you
  activate the test case, so that somebody incorporating the next Expat
  release doesn't mistakenly roll back your change.

A modified version of Brett's patch has been committed to Expat, along with 
regression tests for two specific cases that it handles (only one of which is 
relevant to Python).  The patch to xmlparse.c has also been committed to 
Python's copy, and the crasher test has been moved to the regular 
xml.parsers.expat tests.

  Of course, you might wait a few days to see whether Fred creates another
  release that we could incorporate without introducing new features.

I'm not ready to push for an Expat release, since I've not had much time to 
pay attention to that project over the past year.  I'm trying to catch up on 
that project's email, but don't expect it to be quick.  Once I've had time to 
discuss this with the current principal maintainer, it shouldn't be difficult 
to get a 2.0.1 release out the door.  Once that's done, it'll be time to sync 
with the Expat release again.


  -Fred

-- 
Fred L. Drake, Jr.   fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Lexical scoping in Python 3k

Neil Schemenauer wrote:
   The := would assign but not declare a variable
 in the current scope.

There are other benefits to such a statement, too, since we can make it 
similar to other augmented assignments by letting the object being assigned to 
interfere with the process.

   a := 2

could translate to something like:

   a = a.__assign__(2)

with the default behaviour of __assign__ simply being:

   def __assign__(rhs)
   return rhs

This gives you:
   - runtime checking for typos (you can't accidentally declare a new variable 
with := when you really meant to assign to an existing one)
   - if/when control flow analysis is added to the AST compiler, it will be 
picked up as an error at compile time along with the other augmented assignments
   - the object being assigned to can validate/modify its replacement (e.g. 
automatically wrapping it in a weakref proxy, or checking that it has the 
correct type)

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] sys.settrace() in Python 2.3 vs. 2.4


Armin Rigo [EMAIL PROTECTED] wrote:
 
 Hi Josiah,
 
 On Fri, Jun 30, 2006 at 01:27:24PM -0700, Josiah Carlson wrote:
  I'll just have to gracefully degrade functionality for older Pythons. 
 
 More precisely, the bug shows up because in
 
   while 1:
   pass
 
 the current line remains on the 'pass' forever.  It works for a loop
 like that:
 
   while 1:
   sys
   sys
 
 but it's admittedly quite obscure.

That is good to know, thank you Armin.

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


tomer filiba [EMAIL PROTECTED] wrote:
 weakattr (weak attributes) are attributes that are weakly referenced
 by their containing object. they are very useful for cyclic references --
 an object that holds a reference to itself.

I like the added functionality offered with weakattrs as defined.  I'm
not terribly in love with the syntax of their creation, and I'm curious
as to how it plays with __slots__ (not quite having the time to look at
its implementation right now), but it is quite explicit, so I can get
past that. It would allow us to say, stop using __del__, use weakattrs,
but I'm not sure how well that would work, generally.

Toss it out in python-list, I think some people over there would be able
to offer more feedback.

 - 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] More Switch: Explicit freezing