Python-Dev September 2001

python-dev@python.org

55 participants
99 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.

16 years, 8 months

imputil and modulefinder replacements

by Gordon McMillan

Dev-er's After numerous false-starts and dead-ends, I've come up with two modules that do what imputil and modulefinder do, but better. Code and detailed descriptions are available here: http://www.mcmillan-inc.com/importhooks.html I would like to propose these (or something quite like them) as replacements for the official versions. The code is quite similar (in fact, the modulefinder code could have been written by subclassing the imputil stuff, but I wrote them the other way 'round). If the charter of the Import-SIG is not as dead as the list is, I would promote the basic structure as a potential model for a reformed import. For now, though, it's enough to consider the code. The differences are too extreme to consider these patches, but the subject hardly seems PEPable so I bring it up here. - Gordon

20 years

Integrating Expat

by Martin von Loewis

[I know I've asked this before, but Fred wanted me to ask it again :-] What do you think about an integration of Expat into Python, to be always able to build pyexpat (and with the same version also)? Which version of Expat would you use? Would you put the expat files into a separate directory, or all into modules? Here is my proposal: Integrate Expat 2.95.2 for release together with Python 2.2; into an expat subdirectory of Modules (taking only the lib files of expat). This would affect build procedures on all targets; in particular, pyexpat would not link to a shared expat DLL, but incorporate the object files. Regards, Martin

20 years

Crude Python->Parrot compiler

by Andrew Kuchling

Over the last few days I've been experimenting with a simple Python->Parrot compiler. This morning I finally implemented binding variables to a register, so it now can actually compute something. See http://www.mems-exchange.org/software/files/parrot-gen.py for the code. Limitations: * Currently this only understands a *really* limited subset of Python. * The only allowable type is integer; strings, floats, long ints, &c., aren't supported at all. * It will die with an assertion if you feed it a language construct it doesn't handle (def, class, most operators). * Code structure is suboptimal; this is just a quick-and-dirty hack. Example usage: ute parrot>cat euclid.py # Python implementation of Euclid's algorithm m = 96 n = 64 print m,n r = m % n while r != 0: m = n n = r r = m % n print n ute parrot>python euclid.py 96 64 32 ute parrot>python parrot-gen.py -r euclid.py 96 64 32 ute parrot>cat euclid.pasm main: set I3, 96 set I10, 64 set I9, 0 add I0, I3, I9 ... <rest deleted; you get the idea> ... Currently the Parrot interpreter only supports integer, floating point, and string registers. There's no way to store the contents of a register in memory as far as I can tell, and PMCs -- the polymorphic objects that would correspond to PyObjects -- aren't implemented either. This means it's not possible to handle general variables, and therefore we'll have to wait for PMCs before general Python programs can be handled. --amk

20 years

Python 2.2a* getattr suggestion and question

by Roman Suzi

Well, now every attr access goes thru __getattr__-method, so this could cause situations which give not so clear diagnostics: ----------------------------------------------------------------- Python 2.2a3 (#1, Sep 26 2001, 22:42:46) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. HELP loaded. Readline loaded. History loaded. >>> class A: ... def aa(self): ... print self ... >>> class B(A): ... def __getattr__(self, x): ... print "getattr:", x ... >>> b = B() >>> b.aa getattr: __repr__ Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object is not callable: None ----------------------------------------------------------------- The problem above is that __repr__ can't be called because __getattr__ intercepts it's call, giving None. Could something be done with this to make it easy to trace such kinds of problems? Also, the question is what is the proper way (1 and only 1 way) to check if attribute exists inside __getattr__ method? How can it be done by one simple check like: def __getattr__(self, attr): if hasattr(self, attr): .... Or do I need some other tricks? Sincerely yours, Roman Suzi -- _/ Russia _/ Karelia _/ Petrozavodsk _/ rnd(a)onego.ru _/ _/ Sunday, September 30, 2001 _/ Powered by Linux RedHat 6.2 _/ _/ "Killer Rabbit's Motto: "Lettuce Prey."" _/

20 years

Informacion de Interes

by informacion.general＠lideralia.com

Estimado amigo, nos complace comunicarte que Iberosoft, líder de soluciones software e implantaciones de portales interactivos en Español, ha cambiado su web corporativa. Visitanos en http://www.iberosoft.com/ y disfruta de nuestros exclusivos servicios Gratuitos. -Traceador Visual (VisualRoute Server en Español, Único en el mundo en nuestro idioma!!) -VisualPulse, monitor de tiempos de latencia de IPs, servidores, etc. -Webmail -Chat -Foros -Noticias. Y muchas mas.... Esperamos contar pronto con tu visita y te agradecemos todo tipo de comentarios Así mismo te expresamos nuestro interés en conocer tu opinión sobre nuestras actividades. ¿quieres trabajar con nosotros? Envíanos tu CV lo mas detallado posible a rrhh(a)iberosoft.com Recibe un saludo del equipo de Iberosoft.com noticias(a)iberosoft.com

20 years

descr PLAN.txt

by Samuele Pedroni

Hi. Some questions, I have discovered the PLAN.txt in the CVS for the descr changes sometimes ago but more or less in trance :) Now I have developed some more awareness, some questions: - to which extent is what is listed there complete? - please, Guido advertise if you delete it, I know I can resurrect it with the right cvs incantation but ... I think and it seems it contains some useful information for when we try to port the descr changes to jython, or will all this stuff be completely documented somewhere else? Thanks.

20 years

channews.rdf

by Guido van Rossum

Looking at the new webstats (still at http://www.python.org/~thomas/wwwstats.new/ -- Thomas, when are you going to move these to a better place?) I noticed that /channews.rdf is the most requested file after / -- but the channews.rdf file hasn't been updated in ages! This page is used to be used by the "my netscape" python channel, but I can't find that any more ("my netscape" no longer seems to support personalized channels?). I wonder what other services reference it automatically? --Guido van Rossum (home page: http://www.python.org/~guido/)

20 years

Re: descr PLAN.txt (ii, oops)

by Samuele Pedroni

> - please, Guido advertise if you delete it, I know I can > resurrect it with the right cvs incantation but ... This is irrelevant, I can still see it in the Attic through viewcvs. Right? regards.

20 years

[development doc updates]

by Fred L. Drake

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Various small adjustments and bug fixes. Added preliminary docs for the SimpleXMLRPCServer module.

20 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev September 2001