Python-Dev March 2001

python-dev@python.org

76 participants
192 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

Hi. [Mark Hammond] > The point isn't about my suffering as such. The point is more that > python-dev owns a tiny amount of the code out there, and I don't believe we > should put Python's users through this. > > Sure - I would be happy to "upgrade" all the win32all code, no problem. I > am also happy to live in the bleeding edge and take some pain that will > cause. > > The issue is simply the user base, and giving Python a reputation of not > being able to painlessly upgrade even dot revisions. I agree with all this. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR] > > Another way is to use special rules > > (similar to those for class defs), e.g. having > > > > <frag> > > y=3 > > def f(): > > exec "y=2" > > def g(): > > return y > > return g() > > > > print f() > > </frag> > > > > # print 3. > > > > Is that confusing for users? maybe they will more naturally expect 2 > > as outcome (given nested scopes). > > This seems the best compromise to me. It will lead to the least > broken code, because this is the behavior that we had before nested > scopes! It is also quite easy to implement given the current > implementation, I believe. > > Maybe we could introduce a warning rather than an error for this > situation though, because even if this behavior is clearly documented, > it will still be confusing to some, so it is better if we outlaw it in > some future version. > Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond] > > This probably won't be a very popular suggestion, but how about pulling > > nested scopes (I assume they are at the root of the problem) > > until this can be solved cleanly? > > Agreed. While I think nested scopes are kinda cool, I have lived without > them, and really without missing them, for years. At the moment the cure > appears worse then the symptoms in at least a few cases. If nothing else, > it compromises the elegant simplicity of Python that drew me here in the > first place! > > Assuming that people really _do_ want this feature, IMO the bar should be > raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion. [Andrew Kuchling] > >Assuming that people really _do_ want this feature, IMO the bar should be > >raised so there are _zero_ backward compatibility issues. > > Even at the cost of additional implementation complexity? At the cost > of having to learn "scopes are nested, unless you do these two things > in which case they're not"? > > Let's not waffle. If nested scopes are worth doing, they're worth > breaking code. Either leave exec and from..import illegal, or back > out nested scopes, or think of some better solution, but let's not > introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression. IMO import * in an inner scope should end up being an error, not sure about 'exec's. We will need a final BDFL statement. regards, Samuele Pedroni.

15 years, 1 month

Removing doc/howto on python.org

by Andrew Kuchling

Looking at a bug report Fred forwarded, I realized that after py-howto.sourceforge.net was set up, www.python.org/doc/howto was never changed to redirect to the SF site instead. As of this afternoon, that's now done; links on www.python.org have been updated, and I've added the redirect. Question: is it worth blowing away the doc/howto/ tree now, or should it just be left there, inaccessible, until work on www.python.org resumes? --amk

18 years, 10 months

nested scopes and global: some corner cases

by Samuele Pedroni

Hi. Writing nested scopes support for jython (now it passes test_scope and test_future <wink>), I have come across these further corner cases for nested scopes mixed with global decl, I have tried them with python 2.1b1 and I wonder if the results are consistent with the proposed rule: a free variable is bound according to the nearest outer scope binding (assign-like or global decl), class scopes (for backw-comp) are ignored wrt this. (I) from __future__ import nested_scopes x='top' def ta(): global x def tata(): exec "x=1" in locals() return x # LOAD_NAME return tata print ta()() prints 1, I believed it should print 'top' and a LOAD_GLOBAL should have been produced. In this case the global binding is somehow ignored. Note: putting a global decl in tata xor removing the exec make tata deliver 'top' as I expected (LOAD_GLOBALs are emitted). Is this a bug or I'm missing something? (II) from __future__ import nested_scopes x='top' def ta(): x='ta' class A: global x def tata(self): return x # LOAD_GLOBAL return A print ta()().tata() # -> 'top' should not the global decl in class scope be ignored and so x be bound to x in ta, resulting in 'ta' as output? If one substitutes global x with x='A' that's what happens. Or only local binding in class scope should be ignored but global decl not? regards, Samuele Pedroni

18 years, 10 months

Unicode and the Windows file system.

by Mark Hammond

I understand the issue of "default Unicode encoding" is a loaded one, however I believe with the Windows' file system we may be able to use a default. Windows provides 2 versions of many functions that accept "strings" - one that uses "char *" arguments, and another using "wchar *" for Unicode. Interestingly, the "char *" versions of function almost always support "mbcs" encoded strings. To make Python work nicely with the file system, we really should handle Unicode characters somehow. It is not too uncommon to find the "program files" or the "user" directory have Unicode characters in non-english version of Win2k. The way I see it, to fix this we have 2 basic choices when a Unicode object is passed as a filename: * we call the Unicode versions of the CRTL. * we auto-encode using the "mbcs" encoding, and still call the non-Unicode versions of the CRTL. The first option has a problem in that determining what Unicode support Windows 95/98 have may be more trouble than it is worth. Sticking to purely ascii versions of the functions means that the worst thing that can happen is we get a regular file-system error if an mbcs encoded string is passed on a non-Unicode platform. Does anyone have any objections to this scheme or see any drawbacks in it? If not, I'll knock up a patch... Mark.

18 years, 11 months

Case-sensitive import

by Tim Peters

I'm still trying to sort this out. Some concerns and questions: I don't like the new MatchFilename, because it triggers on *all* platforms that #define HAVE_DIRENT_H. Anyone, doesn't that trigger on straight Linux systems too (all I know is that it's part of the Single UNIX Specification)? I don't like it because it implements a woefully inefficient algorithm: it cycles through the entire directory looking for a case-sensitive match. But there can be hundreds of .py files in a directory, and on average it will need to look at half of them, while if this triggers on straight Linux there's no need to look at *any* of them there. I also don't like it because it apparently triggers on Cygwin too but the code that calls it doesn't cater to that Cygwin possibly *should* be defining ALTSEP as well as SEP. Would rather dump MatchFilename and rewrite in terms of the old check_case (which should run much quicker, and already comes in several appropriate platform-aware versions -- and I clearly minimize the chance of breakage if I stick to that time-tested code). Steven, there is a "#ifdef macintosh" version of check_case already. Will that or won't that work correctly on your variant of Mac? If not, would you please supply a version that does (along with the #ifdef'ery needed to recognize your Mac variant)? Jason, I *assume* that the existing "#if defined(MS_WIN32) || defined(__CYGWIN__)" version of check_case works already for you. Scream if that's wrong. Steven and Jack, does getenv() work on both your flavors of Mac? I want to make PYTHONCASEOK work for you too.

19 years

Making types behave like classes

by Paul Prescod

These are some half-baked ideas about getting classes and types to look more similar. I would like to know whether they are workable or not and so I present them to the people best equipped to tell me. Many extension types have a __getattr__ that looks like this: static PyObject * Xxo_getattr(XxoObject *self, char *name) { // try to do some work with known attribute names, else: return Py_FindMethod(Xxo_methods, (PyObject *)self, name); } Py_FindMethod can (despite its name) return any Python object, including ordinary (non-function) attributes. It also has complete access to the object's state and type through the self parameter. Here's what we do today for __doc__: if (strcmp(name, "__doc__") == 0) { char *doc = self->ob_type->tp_doc; if (doc != NULL) return PyString_FromString(doc); } Why can't we do this for all magic methods? * __class__ would return for the type object * __add__,__len__, __call__, ... would return a method wrapper around the appropriate slot, * __init__ might map to a no-op I think that Py_FindMethod could even implement inheritance between types if we wanted. We already do this magic for __methods__ and __doc__. Why not for all of the magic methods? Many other types implement no getattr at all (the slot is NULL). In that case, I think that we have carte blanche to define their getattr behavior as instance-like as possible. Finally there are the types with getattrs that do not dispatch to Py_FindMethod. we can just change those over manually. Extension authors will do the same when they realize that their types are not inheriting the features that the other types are. Benefits: * objects based on extension types would "look more like" classes to Python programmers so there is less confusion about how they are different * users could stop using the type() function to get concrete types and instead use __class__. After a version or two, type() could be formally deprecated in favor of isinstance and __class__. * we will have started some momentum towards type/class unification which we could continue on into __setattr__ and subclassing. -- Take a recipe. Leave a recipe. Python Cookbook! http://www.activestate.com/pythoncookbook

19 years

nano-threads?

by Neil Schemenauer

Here are some silly bits of code implementing single frame coroutines and threads using my frame suspend/resume patch. The coroutine example does not allow a value to be passed but that would be simple to add. An updated version of the (very experimental) patch is here: http://arctrix.com/nas/generator3.diff For me, thinking in terms of frames is quite natural and I didn't have any trouble writing these examples. I'm hoping they will be useful to other people who are trying to get their mind around continuations. If your sick of such postings on python-dev flame me privately and I will stop. Cheers, Neil ##################################################################### # Single frame threads (nano-threads?). Output should be: # # foo # bar # foo # bar # bar import sys def yield(): f = sys._getframe(1) f.suspend(f) def run_threads(threads): frame = {} for t in threads: frame[t] = t() while threads: for t in threads[:]: f = frame.get(t) if not f: threads.remove(t) else: frame[t] = f.resume() def foo(): for x in range(2): print "foo" yield() def bar(): for x in range(3): print "bar" yield() def test(): run_threads([foo, bar]) test() ##################################################################### # Single frame coroutines. Should print: # # foo # bar # baz # foo # bar # baz # foo # ... import sys def transfer(func): f = sys._getframe(1) f.suspend((f, func)) def run_coroutines(args): funcs = {} for f in args: funcs[f] = f current = args[0] while 1: rv = funcs[current]() if not rv: break (frame, next) = rv funcs[current] = frame.resume current = next def foo(): while 1: print "foo" transfer(bar) def bar(): while 1: print "bar" transfer(baz) transfer(foo)

19 years

submitted patch to linuxaudiodev

by Christopher Lee

I'm a long-time listener/first-time caller and would like to know what I should do to have my patch examined. I've included a description of the patch below. Cheers, -chris ----------------------------------------------------------------------------- [reference: python-Patches #412553] Problem: test_linuxaudiodev.py failed with "Resource temporarily busy message" (under the cvs version of python) Analysis: The lad_write() method attempts to write continuously to /dev/dsp (or equivalent); when the audio buffer fills, write() returns an error code and errorno is set to EAGAIN, indicating that the device buffer is full. The lad_write() interprets this as an error and instead of trying to write again returns NULL. Solution: Use select() to check when the audio device becomes writable and test for EAGAIN after doing a write(). I've submitted patch #412553 that implements this solution. (use python21-lihnuxaudiodev.c-version2.diff). With this patch, test_linuxaudiodev.py passes. This patch may also be relevant for the python 2.0.1 bugfix release. System configuration: linux kernel 2.4.2 and 2.4.3 SMP on a dual processor i686 with the soundblaster live value soundcard.

19 years

Assigning to __debug__

by Martin v. Loewis

After the recent change that assignments to __debug__ are disallowed, I noticed that IDLE stops working (see SF bug report), since it was assigning to __debug__. Simply commenting-out the assignment (to zero) did no good: Inside the __debug__ blocks, IDLE would try to perform print statements, which would write to the re-assigned sys.stdout, which would invoke the code that had the __debug__, which would give up thanks to infinite recursion. So essentially, you either have to remove the __debug__ blocks, or rewrite them to writing to save_stdout - in which case all the ColorDelegator debug message appear in the terminal window. So anybody porting to Python 2.1 will essentially have to remove all __debug__ blocks that were previously disabled by assigning 0 to __debug__. I think this is undesirable. As I recall, in the original description of __debug__, being able to assign to it was reported as one of its main features, so that you still had a run-time option (unless the interpreter was running with -O, which eliminates the __debug__ blocks). So in short, I think this change should be reverted. Regards, Martin P.S. What was the motivation for that change, anyway?

19 years

PEP: Use site-packages on all platforms

by Moore, Paul

It was suggested that I post this to python-dev, as well as python-list and the distutils SIG. I apologise if this is being done backwards? Should I get a proper PEP number first, or is it appropriate to ask for initial comments like this? Paul -----Original Message----- From: Moore, Paul Sent: 30 March 2001 13:32 To: distutils-sig(a)python.org Cc: 'python-list(a)python.org' Subject: [Distutils] PEP: Use site-packages on all platforms Attached is a first draft of a proposal to use the "site-packages" directory for locally installed modules, on all platforms instead of just on Unix. If the consensus is that this is a worthwhile proposal, I'll submit it as a formal PEP. Any advice or suggestions welcomed - I've never written a PEP before - I hope I've got the procedure right... Paul Moore PEP: TBA Title: Install local packages in site-packages on all platforms Version $Revision$ Author: Paul Moore <gustav(a)morpheus.demon.co.uk> Status: Draft Type: Standards Track Python-Version: 2.2 Created: 2001-03-30 Post-History: TBA Abstract The standard Python distribution includes a directory Lib/site-packages, which is used on Unix platforms to hold locally-installed modules and packages. The site.py module distributed with Python includes support for locating modules in this directory. This PEP proposes that the site-packages directory should be used uniformly across all platforms for locally installed modules. Motivation On Windows platforms, the default setting for sys.path does not include a directory suitable for users to install locally-developed modules. The "expected" location appears to be the directory containing the Python executable itself. Including locally developed code in the same directory as installed executables is not good practice. Clearly, users can manipulate sys.path, either in a locally modified site.py, or in a suitable sitecustomize.py, or even via .pth files. However, there should be a standard location for such files, rather than relying on every individual site having to set their own policy. In addition, with distutils becoming more prevalent as a means of distributing modules, the need for a standard install location for distributed modules will become more common. It would be better to define such a standard now, rather than later when more distutils-based packages exist which will need rebuilding. It is relevant to note that prior to Python 2.1, the site-packages directory was not included in sys.path for Macintosh platforms. This has been changed in 2.1, and Macintosh includes sys.path now, leaving Windows as the only major platform with no site-specific modules directory. Implementation The implementation of this feature is fairly trivial. All that would be required is a change to site.py, to change the section setting sitedirs. The Python 2.1 version has if os.sep == '/': sitedirs = [makepath(prefix, "lib", "python" + sys.version[:3], "site-packages"), makepath(prefix, "lib", "site-python")] elif os.sep == ':': sitedirs = [makepath(prefix, "lib", "site-packages")] else: sitedirs = [prefix] A suitable change would be to simply replace the last 4 lines with else: sitedirs = [makepath(prefix, "lib", "site-packages")] Changes would also be required to distutils, in the sysconfig.py file. It is worth noting that this file does not seem to have been updated in line with the change of policy on the Macintosh, as of this writing. Notes 1. It would be better if this change could be included in Python 2.1, as changing something of this nature is better done sooner, rather than later, to reduce the backward-compatibility burden. This is extremely unlikely to happen at this late stage in the release cycle, however. 2. This change does not preclude packages using the current location - the change only adds a directory to sys.path, it does not remove anything. 3. In the Windows distribution of Python 2.1 (beta 1), the Lib\site-packages directory has been removed. It would need to be reinstated. Copyright This document has been placed in the public domain. _______________________________________________ Distutils-SIG maillist - Distutils-SIG(a)python.org http://mail.python.org/mailman/listinfo/distutils-sig

19 years

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev March 2001