Re: [Python-Dev] 2.5 and beyond
[Tim Peters] >> Note that this is quite unlike Scheme, in which declaration must >> appear before use (ignoring fancy letrec cases), [Greg Ewing] > I think that's overstating things a bit -- So do I :-), but I don't really care about Scheme here. > mutually recursive functions are quite easy to write in > Scheme and don't look at all "fancy" (unless you object for > some reason to using (define ...)). In this context, yes, I object to using "define", because the semantics of internal definitions are defined in terms of an equivalent (letrec ...) form. The "fancy" gimmick is that letrec views all its bindings as occurring simultaneously, so strains a natural, linear understanding of "no use before declaration". But none of this appears to have any relevance to Python, so I'm happiest _here_ just calling that "fancy" and ignoring the details. Ditto "top level" definitions, which have unique rules of their own. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
On Saturday 01 July 2006 12:55, 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. ;-) At this point, I think removing the warning code is the prudent course. If someone wanted to find an easy and safe way to make it only be triggered when the import fails, it could stay in. I'm not convinced that _anything_ in import.c is easy and safe. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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
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 [email protected] 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
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 [email protected] 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] >> >>> 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 [email protected] 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 [email protected] 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 [email protected] 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
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 [email protected] 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
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 [email protected] 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 [email protected] 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?
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
[email protected]
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?
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. ___ Python-Dev mailing list [email protected] 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?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 328 and PEP 338, redux
Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Real-world usage case for import __main__? Otherwise, I say screw it :)
I have used it as a workaround for timeit.py's requirement that I pass
it strings instead of functions.
>>> def compute():
... 1+1
...
>>> import timeit
>>> t = timeit.Timer("__main__.compute()", "import __main__")
>>> t.timeit()
1.9755008220672607
>>>
You can argue (as many have) that timeit.py needs a better API for
this. That's a different world than the existing real one.
Andrew
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] weakattr
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 [email protected] 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
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 [email protected] 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
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 [email protected] 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 [email protected] 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
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 [email protected] 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
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 [email protected] 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
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
On 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 [email protected] 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
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 [email protected] 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
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. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
Martin v. Löwis 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 [email protected] 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
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 [email protected] 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
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 [email protected] 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
[email protected]
http://mail.python.org/mailman/
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 [email protected] 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
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 [email protected] 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
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 [email protected] 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
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 "", line 1, in ? File "", 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 [email protected] 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?
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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/noamraph%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Brett Cannon wrote: > > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For sandboxing: alternative to crippling file()
On 6/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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] More Switch: Explicit freezing
Here's another stab at the "explicit freezing" school of thought on the switch semantics. The idea is to borrow the freeze protocol and apply it to functions. In this scheme, the default behavior of switch is to rebuild the dictionary each time the switch is executed. However, by calling freeze(), you can get a 'frozen' version of the function in which all switch dictionaries contained within the function are precalculated: # Emulating 'freeze at function definition time' def myfunc( x ): switch y: case a: ... case b: ... myfunc = freeze( myfunc ) This of course lends itself well to decorator syntax: @freeze def myfunc( x ): switch y: case a: ... case b: ... You can also get 'freeze on first use' via the appropriate decorator function, although that's a litte harder to white (essentially, you need a way to test if the function is already frozen.) Each time you call freeze(), you get a new copy of the function object with the switch dictionaries bound to the values that were in the scope of the call to 'freeze'. This means that you can call freeze several times and get several different versions of the function: def myfunc( x ): switch y: case a: ... case b: ... a = 1 b = 2 f1 = freeze( myfunc ) a = 3 b = 4 f2 = freeze( myfunc ) Now we have two versions of the function, each having a different switch dictionary. Note that 'switch' is still usable without 'freeze', it just won't run as fast. This means that the folks who are interested in a switch statement purely for its improved expressiveness can simply not bother with freezing the function. -- Talin ___ Python-Dev mailing list [email protected] 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
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 [email protected] 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?
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 [email protected] 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
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 [email protected] 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 [email protected] 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 <>: body is equivalent to for <> in <>: local i = <> body This explanation doesn't need to rest on recursion. ___ Python-Dev mailing list [email protected] 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
[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 <>: > body > > is equivalent to > > for <> in <>: > local i = <> > 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 [email protected] 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?
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. ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
Talin <[EMAIL PROTECTED]> wrote: > Here's another stab at the "explicit freezing" school of thought on the > switch semantics. The idea is to borrow the freeze protocol and apply it > to functions. -1 . Freezing was previously questionably useful in the realm of general data structures. Using switch/case as a use-case for this functionality, I think, is a non-starter. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
