Python-Dev December 2000

python-dev@python.org

50 participants
96 discussions

by bckfnn＠worldonline.dk

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

20 years, 3 months

Re: [Python-Dev] reuse of address default value (was Re: [Python-checkins] CVS: python/dist/src/Lib SocketServer.py)

by Jack Jansen

> 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

20 years, 3 months

Online help scope

by Paul Prescod

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

20 years, 4 months

memory leaks

by Charles G Waldman

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.

20 years, 4 months

fuzzy logic?

by Fredrik Lundh

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>

20 years, 4 months

[PEP-212] new draft

by Peter Schneider-Kamp

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?

20 years, 4 months

reuse of address default value (was Re: [Python-checkins] CVS: python/dist/src/Lib SocketServer.py)

by pf＠artcom-gmbh.de

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)

20 years, 4 months

Re: [Python-Dev] fuzzy logic?

by Michael Hudson

"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

20 years, 4 months

Re: [Python-Dev] fuzzy logic?

by Michael Hudson

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

20 years, 4 months

Re: [Python-Dev] Splitting up _cursesmodule

by Thomas Gellekum

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

20 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 December 2000