Hi,
I'm trying to understand the initialization of sys.path and especially
if CWD is supposed to be included in sys.path by default. (I understand
the purpose of sys.path[0], that is not the focus of my question).
My setup is Python2.0 on Win2000, no PYTHONHOME or PYTHONPATH envvars.
In this setup, an empty string exists as sys.path[1], but I'm unsure if
this is by careful design or some freak accident. The empty entry is
added because
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.0\PythonPath
does *not* have any subkey. There are a default value, but that value
appears to be ignored. If I add a subkey "foo":
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.0\PythonPath\foo
with a default value of "d:\foo", the CWD is no longer in sys.path.
i:\java\jython.cvs\org\python\util>d:\Python20\python.exe -S
Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'd:\\foo', 'D:\\PYTHON20\\DLLs', 'D:\\PYTHON20\\lib',
'D:\\PYTHON20\\lib\\plat-win', 'D:\\PYTHON20\\lib\\lib-tk',
'D:\\PYTHON20']
>>>
I noticed that some of the PYTHONPATH macros in PC/config.h includes the
'.', others does not.
So, to put it as a question (for jython): Should CWD be included in
sys.path? Are there some situation (like embedding) where CWD shouldn't
be in sys.path?
regards,
finn
> The reason for the patch is that without this, if you kill a TCP server
> and restart it right away, you'll get a 'port in use" error -- TCP has
> some kind of strange wait period after a connection is closed before
> it can be reused. The patch avoids this error.
Well, actually there's a pretty good reason for the "port in use" behaviour:
the TCP standard more-or-less requires it. A srchost/srcport/dsthost/dstport
combination should not be reused until the maximum TTL has passed, because
there may still be "old" retransmissions around. Especially the "open" packets
are potentially dangerous.
Setting the reuse bit while you're debugging is fine, but setting it in
general is not a very good idea...
--
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/spg-l/sigaction.htm
I think Guido and I are pretty far apart on the scope and requirements
of this online help thing so I'd like some clarification and opinions
from the peanut gallery.
Consider these scenarios
a) Signature
>>> help( dir )
dir([object]) -> list of stringsb)
b) Usage hint
>>> help( dir )
dir([object]) -> list of stringsb)
Return an alphabetized list of names comprising (some of) the attributes
of the given object. Without an argument, the names in the current
scope
are listed. With an instance argument, only the instance attributes are
returned. With a class argument, attributes of the base class are not
returned. For other types or arguments, this may list members or
methods.
c) Complete documentation, paged(man-style)
>>> help( dir )
dir([object]) -> list of stringsb)
Without arguments, return the list of names in the current local symbol
table. With an argument, attempts to return a list of valid attribute
for that object. This information is gleaned from the object's __dict__,
__methods__ and __members__ attributes, if defined. The list is not
necessarily complete; e.g., for classes, attributes defined in base
classes are not included, and for class instances, methods are not
included. The resulting list is sorted alphabetically. For example:
>>> import sys
>>> dir()
['sys']
>>> dir(sys)
['argv', 'exit', 'modules', 'path', 'stderr', 'stdin', 'stdout']
d) Complete documentation in a user-chosen hypertext window
>>> help( dir )
(Netscape or lynx pops up)
I'm thinking that maybe we need two functions:
* help
* pythondoc
pythondoc("dir") would launch the Python documentation for the "dir"
command.
> That'S What Some People Think. I Disagree That It Would Be Either
> Feasible Or A Good Idea To Put All Documentation For A Typical Module
> In Its Doc Strings.
Java and Perl people do it regularly. I think that in the greater world
of software development, the inline model has won (or is winning) and I
don't see a compelling reason to fight the tide. There will always be
out-of-line tutorials, discussions, books etc.
The canonical module documentation could be inline. That improves the
liklihood of it being maintained. The LaTeX documentation is a major
bottleneck and moving to XML or SGML will not help. Programmers do not
want to learn documentation systems or syntaxes. They want to write code
and comments.
> I said above, and I'll say it again: I think the majority of people
> would prefer to use their standard web browser to read the standard
> docs. It's not worth the effort to try to make those accessible
> through help().
No matter what we decide on the issue above, reusing the standard
documentation is the only practical way of populating the help system in
the short-term. Right now, today, there is a ton of documentation that
exists only in LaTeX and HTML. Tons of modules have no docstrings.
Keywords have no docstrings. Compare the docstring for
urllib.urlretrieve to the HTML documentation.
In fact, you've given me a good idea: if the HTML is not available
locally, I can access it over the web.
Paul Prescod
The following code (extracted from test_extcall.py) leaks memory:
class Foo:
def method(self, arg1, arg2):
return arg1 + arg2
def f():
err = None
try:
Foo.method(*(1, 2, 3))
except TypeError, err:
pass
del err
One-line fix (also posted to Sourceforge):
--- Python/ceval.c 2000/10/30 17:15:19 2.213
+++ Python/ceval.c 2000/12/14 20:54:02
@@ -1905,8 +1905,7 @@
class))) {
PyErr_SetString(PyExc_TypeError,
"unbound method must be called with instance as first argument");
- x = NULL;
- break;
+ goto extcall_fail;
}
}
}
I think that there are a bunch more memory leaks lurking around...
this only fixes one of them. I'll send more info as I find out what's
going on.
here's a simple (but somewhat strange) test program:
def spam():
a = 1
if (0):
global a
print "global a"
a = 2
def egg():
b = 1
if 0:
global b
print "global b"
b = 2
egg()
spam()
print a
print b
if I run this under 1.5.2, I get:
2
Traceback (innermost last):
File "<stdin>", line 19, in ?
NameError: b
</F>
In an attempt to revive PEP 212 - Loop counter iteration I have
updated the draft. The HTML version can be found at:
http://python.sourceforge.net/peps/pep-0212.html
I will appreciate any form of comments and/or criticisms.
Peter
P.S.: Now I have posted it - should I update the Post-History?
Or is that for posts to c.l.py?
Hi,
I think the following change is incompatible and will break applications.
At least I have some server type applications that rely on
'allow_reuse_address' defaulting to 0, because they use
the 'address already in use' exception, to make sure, that exactly one
server process is running on this port. One of these applications,
which is BTW build on top of Fredrik Lundhs 'xmlrpclib' fails to work,
if I change this default in SocketServer.py.
Would you please explain the reasoning behind this change?
Moshe Zadka:
> *** SocketServer.py 2000/09/01 03:25:14 1.19
> --- SocketServer.py 2000/12/13 20:39:17 1.20
> ***************
> *** 158,162 ****
> request_queue_size = 5
>
> ! allow_reuse_address = 0
>
> def __init__(self, server_address, RequestHandlerClass):
> --- 158,162 ----
> request_queue_size = 5
>
> ! allow_reuse_address = 1
>
> def __init__(self, server_address, RequestHandlerClass):
Regards, Peter
--
Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260
office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen)
"Fred L. Drake, Jr." <fdrake(a)acm.org> writes:
> Michael Hudson writes:
> > 1) Is there anything is the standard library that does the equivalent
> > of
>
> No, but I have a chunk of code that does in a different way.
I'm guessing everyone who's played with the parser much does, hence
the suggestion. I agree my implementation is probably not optimal - I
just threw it together as quickly as I could!
> Where in the library do you think it belongs? The compiler package
> sounds like the best place, but that's not installed by default.
> (Jeremy, is that likely to change soon?)
Actually, I'd have thought the parser module would be most natural,
but that would probably mean doing the _module.c trick, and it's
probably not worth the bother. OTOH, it seems that wrapping any given
extension module in a python module is becoming if anything the norm,
so maybe it is.
Cheers,
M.
--
I don't remember any dirty green trousers.
-- Ian Jackson, ucam.chat
1) Is there anything is the standard library that does the equivalent
of
import symbol,token
def decode_ast(ast):
if token.ISTERMINAL(ast[0]):
return (token.tok_name[ast[0]], ast[1])
else:
return (symbol.sym_name[ast[0]],)+tuple(map(decode_ast,ast[1:]))
so that, eg:
>>> pprint.pprint(decode.decode_ast(parser.expr("0").totuple()))
('eval_input',
('testlist',
('test',
('and_test',
('not_test',
('comparison',
('expr',
('xor_expr',
('and_expr',
('shift_expr',
('arith_expr',
('term',
('factor', ('power', ('atom', ('NUMBER', '0'))))))))))))))),
('NEWLINE', ''),
('ENDMARKER', ''))
? Should there be? (Especially if it was a bit better written).
... and Greg's just said everything else I wanted to!
Cheers,
M.
--
please realize that the Common Lisp community is more than 40
years old. collectively, the community has already been where
every clueless newbie will be going for the next three years.
so relax, please. -- Erik Naggum, comp.lang.lisp
Andrew Kuchling <akuchlin(a)mems-exchange.org> writes:
> I'm ambivalent about the list_of_panels. It's a linked list storing
> (PyWindow, PyPanel) pairs. Probably it should use a dictionary
> instead of implementing a little list, just to reduce the amount of
> code.
I don't like it either, so feel free to shred it. As I said, this is
the first (piece of an) extension module I've written and I thought it
would be easier to implement a little list than to manage a Python
list or such in C.
> So, I suggest we create _curses_panel.c, which would be available as
> curses.panel. (A panel.py module could then add any convenience
> functions that are required.)
>
> Thomas, do you want to work on this, or should I?
Just do it. I'll try to add more examples in the meantime.
tg