Mailman 3 February 2001 - Python-Dev

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

Feb. 21, 2001

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 … [View More]

2 1

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

Feb. 21, 2001

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 … [View More]

1 0

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

Feb. 21, 2001

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? … [View More]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. [View Less]

1 0

Modulefinder?
by Thomas Heller Feb. 20, 2001

Feb. 20, 2001

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 Feb. 20, 2001

Feb. 20, 2001

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 #… [View More]

2 4

Demo/embed/import.c
by Jack Jansen Feb. 20, 2001

Feb. 20, 2001

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.… [View More]

2 2

Demos are out of Data: Requesting Permission to Change
by Moshe Zadka Feb. 20, 2001

Feb. 20, 2001

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 Feb. 19, 2001

Feb. 19, 2001

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 … [View More]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. [View Less]

6 5

[development doc updates]
by Fred L. Drake Feb. 19, 2001

Feb. 19, 2001

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 Feb. 19, 2001

Feb. 19, 2001

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 … [View More]

3 3