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.
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
[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
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
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."" _/
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
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.
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/)
> - 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.
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.
