Mailman 3 February 2001 - Python-Dev

Re: [Python-Dev] RE: Please use __progress__ instead of __future__ (was Other situations like this)
by Michael Hudson 24 Feb '01

24 Feb '01

"Tim Peters" <tim.one(a)home.com> writes: > [Peter Funk] > > I believe __future__ is a bad name. What appears today as the bright > > shining future will be the distant dusty past of tomorrow. But the > > name of the module is not going to change anytime soon. right? > > The name of what module? > > Any statement of the form > > from __future__ import shiny > > becomes unnecessary as soon as shiny's future arrives, at which point the > statement can be removed. The statement is necessary only so long as shiny > *is* in the future. So the name is thoroughly appropriate. Ever been to Warsaw? There's the Old Town, which was built around 1650. Then there's the New Town, which was built around 1700. (The dates may be wrong). I think this is what Peter was talking about. also-see-New-College-Oxford-ly y'rs M. -- MAN: How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind? -- The Hitch-Hikers Guide to the Galaxy, Episode 12

1 0

distutils, uninstaller
by Thomas Heller 23 Feb '01

23 Feb '01

I've uploaded the bdist_wininst uninstaller patch to sourceforge: http://sourceforge.net/patch/?func=detailpatch&patch_id=103948&group_id=5470 Just in case someone cares. Another thing: Shouldn't the distutils version number change before the beta? I suggest going from 1.0.1 to 1.0.2. Thomas Heller

2 1

OS2 support ?
by Thomas Wouters 23 Feb '01

23 Feb '01

Is OS2 still supported at all ? I noticed this, in PC/os2vacpp/config.h: /* Provide a default library so writers of extension modules * won't have to explicitly specify it anymore */ #pragma library("Python15.lib") -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

3 2

test_builtin failing on Windows
by Tim Peters 23 Feb '01

23 Feb '01

But only if run under a debug build *and* passing -O to Python: > python_d -O ../lib/test/test_builtin.py Adding parser accelerators ... Done. 4. Built-in functions test_b1 __import__ abs apply callable chr cmp coerce compile complex delattr dir divmod eval execfile filter float getattr hasattr hash hex id int isinstance issubclass len long map max min test_b2 and here it blows up with some kind of memory error. Other systems?

4 8

nested scopes: I'm glad (+excuses)
by Samuele Pedroni 23 Feb '01

23 Feb '01

Hi. I'm really glad that the holy war has come to an end, and that a technical solution has been found. This was my first debate here and I have said few wise things, more stupid ones and some violent or unfair: my excuses go to Jeremy, Guido and the biz mind (in some of us) that make money out of software (nobody can predict how he will make his living ;)) I'm glad that we have nested scopes, a transition syntax and path and no new keyword (no irony in the latter). Cheers, Samuele.

3 2

compile leaks memory. lots of memory.
by Martin von Loewis 23 Feb '01

23 Feb '01

> It would be helpful to get some analysis on this known problem > before the beta release. It looks like there is a leak of symtable entries. In particular, symtable_enter_scope has if (st->st_cur) { prev = st->st_cur; if (PyList_Append(st->st_stack, (PyObject *)st->st_cur) < 0) { Py_DECREF(st->st_cur); st->st_errors++; return; } } st->st_cur = (PySymtableEntryObject *)\ PySymtableEntry_New(st, name, type, lineno); if (strcmp(name, TOP) == 0) st->st_global = st->st_cur->ste_symbols; if (prev) if (PyList_Append(prev->ste_children, (PyObject *)st->st_cur) < 0) st->st_errors++; First, it seems that Py_XDECREF(prev); is missing. That alone does not fix the leak, though, since prev is always null in the test case. The real problem comes from st_cur never being released, AFAICT. There is a DECREF in symtable_exit_scope, but that function is not called in the test case - symtable_enter_scope is called. For symmetry reasons, it appears that there should be a call to symtable_exit_scope of the global scope somewhere (which apparently is build in symtable_build). I can't figure how what the correct place for that call would be, though. Regards, Martin

2 1

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

22 Feb '01

I will try to be intellectually honest: [Thomas Wouters] > And I'd like to note that none of these issues were addressed in the PEP. This also a *point*. Few days ago I have scanned the pre-checkin archive on this topic, the fix-point was, under BDFL influence: - It will not do that much harm (but many issues were not raised) - Please no explicit syntax - Let's do it - Future newbies will be thankful because this was always a confusing point for them (if they come from pascal-like languages?) I should admit that I like the idea of nested scopes, because I like functional programming style, but I don't know whether this returning 3 is nice ;)? def f(): def g(): return y # put as many innoncent code lines as you like y=3 return g() The point is that nested scopes cause some harm, not that much but people are asking themself whether is that necessary. Maybe the request that old code should compile as it is, is a bit pedantic, and making it always work but with a new semantic is worse. But simply catching up as problem arise does not give a good impression. It really seems that there's not been enough discussion about the change, and I think that is also ok to honestely be worried about what user will feel about this? (and we can only think about this beacuse the feedback is not that much) Will this code breakage "scare" them and slow down migration to new versions of python? They are already afraid of going 2.0(?). It is maybe just PR matter but ... The *point* is that we are not going from version 0.8 to version 0.9 of our toy research lisp dialect, passing from dynamic scoping to lexical scoping. (Yes, I think, that changing semantic behind the scene is not a polite move.) We really need the BDFL proposing the right thing. regards, Samuele Pedroni.

4 6

a doc bug
by Samuele Pedroni 22 Feb '01

22 Feb '01

I don't know if someone was still aware of this but the tutorial in the development version of the doc still refers to the old scoping rules and refers to the old hack trick: http://python.sourceforge.net/devel-docs/tut/node6.html#SECTION006740000000… Something to fix, in the case. regards.

1 0

Those import related syntax errors again...
by Mark Hammond 22 Feb '01

22 Feb '01

Hi all, I'm a little confused by the following exception: File "f:\src\python-cvs\xpcom\server\policy.py", line 18, in ? from xpcom import xpcom_consts, _xpcom, client, nsError, ServerException, COMException exceptions.SyntaxError: BuildInterfaceInfo: exec or 'import *' makes names ambiguous in nested scope (__init__.py, line 71) This sounds alot like Tim's question on this a while ago, and from all accounts this had been resolved (http://mail.python.org/pipermail/python-dev/2001-February/012456.html) In that mail, Jeremy writes: -- quote -- > from Percolator import Percolator > > in a class definition. That smells like a bug, not a debatable design > choice. Percolator has "from x import *" code. This is what is causing the exception. I think it has already been fixed in CVS though, so should work again. -- end quote -- However, Tim replied saying that it still didn't work for him. There was never a followup saying "it does now". In this case, the module being imported from does _not_ use "from module import *" at all, but is a parent package. The only name referenced by the __init__ function is "ServerException", and that is a simple class. The only "import *" I can track is via the name "client", which is itself a package and does the "import *" about 3 modules deep. Any clues? Thanks, Mark.

10 36

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

22 Feb '01

Hi. I have learned that I should not play diplomacy between people that make money out of software. I partecipated to the discussion for two reasons: - I want to avoid an ugly to implement solution (I'm the guy that should code nested scopes in jython) - I got annoyed by Jeremy using his "position" and (your) BDFL decisions and the fact that code is already in, in order to avoid to be completely intellectually honest wrt to his creature. (But CLEARLY this was just my feeling, and getting annoyed is a feeling too) > > > I should admit that I like the idea of nested scopes, because I like functional > > programming style, but I don't know whether this returning 3 is nice ;)? > > > > def f(): > > def g(): > > return y > > # put as many innoncent code lines as you like > > y=3 > > return g() > This works. > This is a red herring; I don't see how this differs from the confusion > in > > def f(): > print y > # lots of code > y = 3 > > and I don't see how nested scopes add a new twist to this known issue. > This raises an error (at least at runtime). But yes it is just matter of taste and readability, mostly personal stuff. And on the long run maybe the second should raise a compile-time error (your choice). > > and I think that is also ok to honestely be worried about what user > > will feel about this? (and we can only think about this beacuse > > the feedback is not that much) > > FUD. > > > Will this code breakage "scare" them and slow down migration to new versions > > of python? They are already afraid of going 2.0(?). It is maybe just PR matter > > but ... > > More FUD. > Hey, I don't make money out of python or jython. I not invoked FUD, I was just pointing out what - I thought - was behind the discussion. FUD is already among us but you and the others make money with python, this is not the case for me. > > The *point* is that we are not going from version 0.8 to version 0.9 > > of our toy research lisp dialect, passing from dynamic scoping to lexical > > scoping. (Yes, I think, that changing semantic behind the scene is not > > a polite move.) > > Well, I'm actually glad to hear this -- Python now has such a large > user base that language changes are deemed impractical. > I'm just a newbie, I always read in books and e-articles: "python is a simple, elegant, consistent language, developed (slowly) with extremal care". It's all about being intellectually honest (yes this is my personal holy war): e.g. [GvR] > > I would consider the type/class split, making something > > like ExtensionClass neccessary, much more annoying for > > the advanced programmer. IMHO more efforts should go > > into this issue _even before_ p3000. > > Yes, indeed. This will be on the agenda for Python 2.2. Digital > Creations really wants PythonLabs to work on this issue! this is an honest statement. Things has changed (people are getting aware of this). With nested scope there were two possibilities: given the code: (I) y=1 def f(): y=666 def g(): return y one could go the way we are going and breaks this unless people fix it (II) y=1 def f(): y=666 def g(): global y return y or need some explicit syntax for the new behaviour: (III) y=1 def f(): nest y y=666 def g(): return y I agree designing solution (III) could be not simpler, and on the long run is just inelegant lossage (I can agree with this) up to other orthogonal issues (see above). Python is not closed source, it's your language, your user-base and you make money indirectly out of it: you are the BDFL and you can choose (if you would make money directly out of python maybe you must choose (III) or you are MS or Sun...) But I think it's clear that you should accept people (for their biz reason) saying "please can we go slower". And you can reply FUD... regards, Samuele Pedroni. PS: Yes I will not play this anymore. Lesson learned ;)

1 0