Mailman 3 February 2001 - Python-Dev

Re: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni 21 Feb '01

21 Feb '01

This is becoming too much politics. > > >>>>> "TW" == Thomas Wouters <thomas(a)xs4all.net> writes: > > TW> On Tue, Feb 20, 2001 at 10:29:36PM -0500, Andrew Kuchling wrote: > >> Let's not waffle. If nested scopes are worth doing, they're > >> worth breaking code. > > TW> I'm sorry, but that's bull -- I mean, I disagree > TW> completely. Nested scopes *are* a nice feature, but if we can't > TW> do them without breaking code in weird ways, we shouldn't, or at > TW> least *not yet*. I am still uneasy by the restrictions seemingly > TW> created just to facilitate the implementation issues of nested > TW> scopes, but I could live with them if they had been generating > TW> warnings at least one release, preferably more. > > A note of clarification seems important here: The restrictions are > not being introduced to simplify the implementation. They're being > introduced because there is no sensible meaning for code that uses > import * and nested scopes with free variables. There are two > possible meanings, each plausible and neither satisfying. > I think that y=3 def f(): exec "y=2" def g() return y return g() with f() returning 2 would make sense (given python dynamic nature). But it is not clear if we can reach consensus on the this or another semantic. (Implementing this would be ugly, but this is not the point). On the other hand just saying that new feature X make code Y (previously valid) meaningless and so the unique solution is to discard Y as garbage, is something that cannot be sold for cheap. I have the feeling that this is the *point*. regards, Samuele Pedroni.

2 1

I think it's time to give import * the heave ho
by Skip Montanaro 21 Feb '01

21 Feb '01

Jeremy> Posters of c.l.py have suggested both alternatives as the Jeremy> logical choice: (1) import * is dynamic so the static scoping Jeremy> rule ignores the names it introduces, Bad alternative. import * works just fine today and is very mature, well understood functionality. This would introduce a special case that is going to confuse people. Jeremy> (2) Python is a late binding language so the name binding Jeremy> introduced by import * is used. This has to be the only reasonable alternative. Nonetheless, as mature and well understood as import * is, the fact that it can import a variable number of unknown arguments into the current namespace creates problems. It interferes with attempts at optimization, it can introduce bugs by importing unwanted symbols, it forces programmers writing code that might be imported that way to work to keep their namespaces clean, and it encourages complications like __all__ to try and avoid namespace pollution. Now it interferes with nested scopes. There are probably more problems I haven't thought of and new ones will probably crop up in the future. The use of import * is generally discouraged in all but well-defined cases ("from Tkinter import *", "from types import *") where the code was specifically written to be imported that way. For notational brevity in interactive use you can use import as (e.g., "import Tkinter as tk"). For use in modules and scripts it's probably best to simply use import module or explicitly grab the names you need from the module you're importing ("from types import StringType, ListType"). Both would improve the readability of the importing code. The only place I can see its use being more than a notational convenience is in wrapper modules like os and re and even there, it can be avoided. I believe in the long haul the correct thing to do is to deprecate import *. Skip

1 0

Re: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni 21 Feb '01

21 Feb '01

Hi. [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 should hear Jeremy H. position and we will need a final BDFL statement. regards, Samuele Pedroni.

1 0

Modulefinder?
by Thomas Heller 20 Feb '01

20 Feb '01

Who is maintaining freeze/Modulefinder? I have some issues I would like to discuss... Thomas (Heller)

2 3

Embedding demos are broken
by barry＠digicool.com 20 Feb '01

20 Feb '01

Something changed recently, and now the Demo/embed programs are broken, e.g. % ./loop pass 2 Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] 'import site' failed; use -v for traceback Segmentation fault (core dumped) The crash is happening in the second call to init_exceptions() (gdb) where #0 PyModule_GetDict (m=0x0) at Objects/moduleobject.c:40 #1 0x8075ea8 in init_exceptions () at Python/exceptions.c:1058 #2 0x8051880 in Py_Initialize () at Python/pythonrun.c:147 #3 0x80516db in main (argc=3, argv=0xbffffa34) at loop.c:28 because the attempt to import __builtin__ returns NULL. I don't have time right now to look any deeper, but I suspect that the crash may be due to changes in the semantics of PyImport_ImportModule() which now goes through __import__. I'm posting this in case someone with spare cycles can look at it. -Barry

2 4

Demo/embed/import.c
by Jack Jansen 20 Feb '01

20 Feb '01

Can I request that the new file Demo/embed/import.c be renamed? The name clashes with the import.c we all know and love, and the setup of things under CodeWarrior on the Mac is such that it will search for sourcefiles recursively from the root of the Python sourcefolder. I can fix this, of course, but it's a lot of work... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

2 2

Demos are out of Data: Requesting Permission to Change
by Moshe Zadka 20 Feb '01

20 Feb '01

Random example: Demo/scripts/pi.py: # Use int(d) to avoid a trailing L after each digit Would anyone have a problem if I just went and checked in updates to the demos? Putting it as a patch on SF seems like needless beuracracy. -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez(a)debian.org |http://www.{python,debian,gnu}.org

2 1

python-dev summary, 2001-02-01 - 2001-02-15
by Michael Hudson 19 Feb '01

19 Feb '01

It is with some trepidation that I post: This is a summary of traffic on the python-dev mailing list between Feb 1 and Feb 14 2001. It is intended to inform the wider Python community of ongoing developments. To comment, just post to python-list(a)python.org or comp.lang.python in the usual way. Give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration) All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on a PEP if you have an opinion. This is the first python-dev summary written by Michael Hudson. Previous summaries were written by Andrew Kuchling and can be found at: <http://www.amk.ca/python/dev/> New summaries will probably appear at: <http://starship.python.net/crew/mwh/summaries/> When I get round to it. Posting distribution (with apologies to mbm) Number of articles in summary: 498 80 | ]|[ | ]|[ | ]|[ | ]|[ | ]|[ ]|[ 60 | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ | ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ 40 | ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 20 | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ | ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ ]|[ 0 +-029-067-039-037-080-048-020-009-040-021-008-030-043-027 Thu 01| Sat 03| Mon 05| Wed 07| Fri 09| Sun 11| Tue 13| Fri 02 Sun 04 Tue 06 Thu 08 Sat 10 Mon 12 Wed 14 A fairly busy fortnight on python-dev, falling just short of five hundred articles. Much of this is making ready for the Python 2.1 release, but people's horizons are beginning to rise above the present. * Python 2.1a2 * Python 2.1a2 was released on Feb. 2. One of the more controversial changes was the disallowing of "from module import *" at anything other than module level; this restriction was weakened after some slightly heated discussion on comp.lang.python. <http://mail.python.org/pipermail/python-dev/2001-February/012815.html> It is possible that non-module-level "from module import *" will produce some kind of warning in Python 2.1 but this code has not yet been written. * Performance * Almost two weeks ago, we were talking about performance. Michael Hudson posted the results of an extended benchmarking session using Marc-Andre Lemburg's pybench suite: <http://mail.python.org/pipermail/python-dev/2001-January/012330.html> to which the conclusion was that python 2.1 will be marginally slower than python 2.0, but it's not worth shouting about. The use of Vladimir Marangoz's obmalloc patch in some of the benchmarks sparked a discussion about whether this patch should be incorporated into Python 2.1. There was support from many for adding it on an opt-in basis, since when nothing has happened... * Imports on case-insensitive file systems * There was quite some discussion about how to handle imports on a case-insensitive file system (eg. on Windows). I didn't follow the details, but Tim Peters is on the case (sorry), so I'm confident it will get sorted out. * Sets & iterators * The Sets discussion rumbled on, moving into areas of syntax. The syntax: for key:value in dict: was proposed. Discussion went round and round for a while and moved on to more general iteration constructs, prompting Ka-Ping Yee to write a PEP entitled "iterators": <http://python.sourceforge.net/peps/pep-0234.html> Please comment! Greg Wilson announced that BOFs for both sets and iterators have been arranged at the python9 conference in March: <http://mail.python.org/pipermail/python-dev/2001-February/012824.html> * Stackless Python in Korea * Christian Tismer gave a presentation on stackless python to over 700 Korean pythonistas: <http://mail.python.org/pipermail/python-dev/2001-February/012601.html> I think almost everyone was amazed and delighted to find that Python has such a fan base. Next stop, the world! * string methodizing the standard library * Eric Raymond clearly got bored one evening and marched through the standard library, converting almost all uses of the string module to use to equivalent string method. * Python's release schedule * Skip Montanaro raised some concerns about Python's accelerated release schedule, and it was pointed out that the default Python for both debian unstable and Redhat 7.1 beta was still 1.5.2. Have *you* upgraded to Python 2.0? If not, why not? * Unit testing (again) * The question of replacing Python's hoary old regrtest-driven test suite with something more modern came up again. Andrew Kuchling enquired whether the issue was to be decided by voting or BDFL fiat: <http://mail.python.org/pipermail/python-dev/2001-February/012830.html> Guido obliged: <http://mail.python.org/pipermail/python-dev/2001-February/012831.html> There was then some discussion of what changes people would like to see made in the standard-Python-unit-testing-framework-elect (PyUnit) before they would be happy with it. Cheers, M.

6 5

[development doc updates]
by Fred L. Drake 19 Feb '01

19 Feb '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/

1 0

Activating SF mailing lists for PEP discussion.
by M.-A. Lemburg 18 Feb '01

18 Feb '01

Ping just recently posted a request here to discuss the iterator PEP on a yahoogroups mailing list. Since the move of eGroups under the Yahoo umbrella, joining those lists requires signing up with Yahoo -- with all strings attached. I don't know when they started this feature, but SourceForge now offers Mailman lists for the various projects. Wouldn't it be much simpler to open a mailing list for each PEP (possible on request only) ? That way, the archives would be kept in a cenral place and also in reach for other developers who are interested in the background discussions about the PEPs. Also, the PEPs could reference the mailing list archives to enhance the information availability. Thoughts ? I would appreciate if one of the Python SF admins would enable the feature and set up a mailing list for PEP 234 (iterators). Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 3