Re: [Python-Dev] The docs, reloaded [PEP?]
Martin v. Löwis schrieb: > Michael Foord schrieb: >> This subject is generating a lot of discussion and [almost entirely] >> positive feedback. It would be a great shame to run out of steam. >> >> Does it need a PEP to see a chance of it getting accepted as the formal >> documentation system? (or a pronouncement that it will never happen...) > > No. First of all, it needs a dedicated developer (preferably, but not > necessarily a committer) who indicates willingness to maintain that > for the coming years and releases. > > It might be that Fred Drake's offer > to maintain the documentation would be still valid after such a switch, > but we should not assume so without explicit confirmation. It might > be that this would be the time to pass one documentation maintenance > to somebody else (and I seriously do not have any one particular > in mind here). Assuming that Fred goes into well-earned retirement from the doc maintainer position (private mail exchange hinted that way), and nobody more qualified steps up, I'd be available to take that post. (If someone else wants to take maintainership of the content, very good, I'd have to be maintainer of the build tools anyway.) I'd then try to form a doc maintaining team, just as the PEP editor team that was created recently, to deal with the (hopefully relatively large ;) ) amount of comments and edit requests. > Then, I think a should be made where the documentation is converted. > Again, a volunteer would be needed to create the branch, and then > eventually merge it back to the trunk. It might be helpful, but isn't > strictly necessary, to close all documentation patches before doing > so, as they all break with the conversion. For that activity, > multiple volunteers would be useful. I agree. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
>> Are there others that can provide a Windows buildbot? It would probably >> be good to have two -- and a WinXP one would be good. > > It certainly would be good. Unfortunately, Windows users are not that > much engaged in the open source culture, so few of them volunteer > (plus it's more painful, with Windows not being a true multi-user > system). I'll try to setup a buildbot under WinXP. Whom do I contact to get HOST:PORT and PASSWORD ? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
On Thu, May 24, 2007 at 12:43:18PM -0500, Ron Adam wrote: > And for console text output, is the unmodified reST suitable, or would it > be desired to modify it in some way? Currently pydoc output looks like a man page under Unix. if it could look like that then that would be great. Otherwise raw reST is fine! > Should a subset of the main documents be included with pydoc to avoid the > documents not available messages if they are not installed? > > Or should the topics retrieval code be moved from pydoc to the main > document tools so it's installed with the documents. Then that can be > maintianed with the documents instead of being maintained with pydoc. Then > pydoc will just looks for it, instead of looking for the html pages. I think the latter proposal sounds like the correct one. In debian for instance, the python docs are a seperate package, and it would seem reasonable that you'd have to have that package installed to get the long docs. > > I think that if reST was an acceptable form for the documentation, and > > it could be auto included in the main docs from docstrings then you > > would find more modules completely documented in __doc__. > > That would be fine for third party modules if they want to do that or if > there is not much difference between the two. If you look at the documentation for subprocess for instance, you'll see that the docstring is pretty much the same as the library reference documentation which seems like needless duplication and opportunity for code/doc skew. Maybe one is auto generated from the other - I don't know! > > Actually if it gave both sets of docs quick, then long, one after the > > other that would suit me fine. > > That may work well for the full documentation, but the quick reference > wouldn't be a short quick reference any more. Well you could stop after reading the short bit! > I'm attempting to have a pydoc api call that gets a single item or sub-item > and format it to a desired output so it can be included in other content. > That's makes it possible for the full docs (not necessarily pythons) to > embed pydoc output in it if it's desirable. This will need pydoc > formatters for the target document type. I hope to include a reST output > formatter for pydoc. > > The help() function is imported from pydoc by site.py when you start > python. It may not be difficult to have it as a function that first tries > pydoc to get a request, and if the original request is returned unchanged, > tries to get information from the full documentation. There could be a way > to select one or the other, (or both). > > But this feature doesn't need to be built into pydoc, or the full > documentation. They just need to be able to work together so things like > this are possible in an easy to write 4 or 5 line function. (give or take a > few lines) > > So it looks like most of these issues are more a matter of how to organize > the interfaces. It turns out that what I've done with pydoc, and what > Georg is doing with the main documentation should work together quite > nicely. Sounds good! Nick -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Wither PEP 335 (Overloadable Boolean Operators)?
At 11:25 AM 5/25/2007 +0200, Neville Grech Neville Grech wrote: > >From a user's POV, I'm +1 on having overloadable boolean > functions. In many cases I had to resort to overload add or neg > instead of and & not, I foresee a lot of cases where the and > overload could be used to join objects which represent constraints. > Overloadable boolean operators could also be used to implement > other types of logic (eg: fuzzy logic). Constraining them to just > primitive binary operations in my view will be delimiting for a > myriad of use cases. > >Sure, in some cases, one could overload the neg operator instead of >the not but semantically they have different meanings. Actually, I think that most of the use cases for this PEP would be better served by being able to "quote" code, i.e. to create AST objects directly from Python syntax. Then, you can do anything you can do in a Python expression (including conditional expressions, generator expressions, yield expressions, lambdas, etc.) without having to introduce new special methods for any of that stuff. In fact, if new features are added to the language later, they automatically become available in the same way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Thomas Heller wrote: >>> Are there others that can provide a Windows buildbot? It would probably >>> be good to have two -- and a WinXP one would be good. >> It certainly would be good. Unfortunately, Windows users are not that >> much engaged in the open source culture, so few of them volunteer >> (plus it's more painful, with Windows not being a true multi-user >> system). > > I'll try to setup a buildbot under WinXP. > Whom do I contact to get HOST:PORT and PASSWORD ? Martin, I believe. Trent -- Trent Mick trentm at activestate.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Wither PEP 335 (Overloadable Boolean Operators)?
Greg,
If you do update this PEP, please update the __not__ portion as well,
at least regarding possible return values.
It currently says that __not__ can return NotImplemented, which falls
back to the current semantics. (Why? to override an explicit
__not__? Then why not just put the current semantics on __object__,
and override by calling that directly?)
It does not yet say what will happen for objects that return something
else outside of {True, False}, such as
class AntiBool(object):
def __not__(self): return self
Is that OK, because "not not X" should now be spelled "bool(x)", and
you haven't allowed the overriding of __bool__? (And, if so, how does
that work Py3K?)
-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] whitespace normalization pre-commit hook is giving me grief
In my bcannon-objcap branch I am trying to check in a change that involves a soft symlink from Lib/controlled_importlib.py to ../importlib/controlled_importlib.py through ``ln -s ../controlled_importlib.py controlled_importlib.py`` while in the Lib directory. I have done this before in this branch so as to allow for easy importing of code from the svn import of importlib that the branch contains. But svn keeps rejecting the commit saying that Lib/controlled_importlib.py needs to be whitespace normalized. I have run reindent on both the external import in the branch and in the original sandbox copy and both are coming back clean. I even imported reindent manually and followed what Georg posted when the pre-commit hook was added and it still passes. Unfortunately the pre-commit hook does not specify what line a change was made on so I have no clue where it is failing (maybe this should be added?). Can somebody help me figure out what the hell is going on? I am waiting to find out it is something small and stupid, but at this point I am not seeing a solution to this. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The docs, reloaded
Hoi, Due to some server issues I had to take the web version down. But expect an updated version in a few days. Regards, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief
On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote: > In my bcannon-objcap branch I am trying to check in a change that involves a > soft symlink from Lib/controlled_importlib.py to > ../importlib/controlled_importlib.py through ``ln -s > ../controlled_importlib.py controlled_importlib.py`` while in the Lib > directory. I have done this before in this branch so as to allow for easy > importing of code from the svn import of importlib that the branch contains. I don't know that we've ever tested the commit hook with a link. Maybe there is some other problem. Have you tried running reindent on the actual file (not the symlink)? > Can somebody help me figure out what the hell is going on? I am waiting to > find out it is something small and stupid, but at this point I am not seeing > a solution to this. Can you check in a smaller part of the change (like leaving out the symlink)? That will at least allow you to make progress. You can send me the file if you want. I can try to look at it and see if there are any problems. n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Build problems with sqlite on OSX
First of all 1000 apologies if this is the wrong list. Please redirect me if necessary. I'm attempting to build python 2.5.1 fat binaries on OSX and statically link to a newer sqlite than what ships with OSX. (3.3.17). I'm getting "Bus Error" early when I run my app. If I turn on a lot of malloc debugging options and run under gdb I get this trace: (gdb) info threads * 1 process 18968 local thread 0x1003 0x900e41d1 in strtol_l () (gdb) bt #0 0x900e41d1 in strtol_l () #1 0x900160a5 in atoi () #2 0x9406fd80 in sqlite3InitCallback () #3 0x0381faf2 in sqlite3_exec (db=0x338d080, zSql=0x331f1e0 "SELECT name, rootpage, sql FROM 'main'.sqlite_master WHERE tbl_name='sqlite_sequence'", xCallback=0x9406fd00 , pArg=0xbfffde14, pzErrMsg=0x0) at ./src/legacy.c:93 #4 0x0384c769 in sqlite3VdbeExec (p=0x1945200) at ./src/vdbe.c:4090 #5 0x03816686 in sqlite3Step (p=0x1945200) at ./src/vdbeapi.c:236 #6 0x03816817 in sqlite3_step (pStmt=0x1945200) at ./src/vdbeapi.c:289 #7 0x0380b9aa in _sqlite_step_with_busyhandler (statement=0x1945200, connection=0x32a77a0) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/util.c:33 #8 0x0380850d in cursor_executescript (self=0x32bd4d0, args=0x32a2d10) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/cursor.c:788 #9 0x0020e6fc in PyObject_Call (func=0x329ecd8, arg=0x32a2d10, kw=0x0) at Objects/abstract.c:1860 #10 0x00292a36 in PyEval_CallObjectWithKeywords (func=0x329ecd8, arg=0x32a2d10, kw=0x0) at Python/ceval.c:3433 #11 0x0020e6cd in PyObject_CallObject (o=0x329ecd8, a=0x32a2d10) at Objects/abstract.c:1851 #12 0x03806e1c in connection_executescript (self=0x32a77a0, args=0x32a2d10, kwargs=0x0) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/connection.c:1001 #13 0x002998ae in PyEval_EvalFrameEx (f=0x338c250, throwflag=0) at Python/ceval.c:3564 Can someone advise as to the correct configure arguments for sqlite or something else I might be missing? Thanks in advance. -- Darrin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python/trunk/Lib/test/test_urllib.py (for ftpwrapper)
# Sorry, I posted to inapropreate mailing list. (Python-3000)
http://mail.python.org/pipermail/python-checkins/2007-May/060507.html
Hello. I'm using Windows2000, I tried some investigation for
test_ftpwrapper.
After I did this change, most errors were gone.
Index: Lib/urllib.py
===
--- Lib/urllib.py (revision 55584)
+++ Lib/urllib.py (working copy)
@@ -833,7 +833,7 @@
self.busy = 0
self.ftp = ftplib.FTP()
self.ftp.connect(self.host, self.port, self.timeout)
-self.ftp.login(self.user, self.passwd)
+#self.ftp.login(self.user, self.passwd)
for dir in self.dirs:
self.ftp.cwd(dir)
I don't know, but probably 'login' on Win2000 is problamatic.
Remaining error is:
File "e:\python-dev\trunk\lib\threading.py", line 460, in __bootstrap
self.run()
File "e:\python-dev\trunk\lib\threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "test_urllib.py", line 565, in server
conn.recv(13)
error: (10035, 'The socket operation could not complete without blocking')
And after commented out conn.recv block in test_urllib.py, test passed fine.
def server(evt):
serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serv.settimeout(3)
serv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
serv.bind(("", 9093))
serv.listen(5)
try:
conn, addr = serv.accept()
conn.send("1 Hola mundo\n")
"""
cantdata = 0
while cantdata < 13:
data = conn.recv(13-cantdata)
cantdata += len(data)
time.sleep(.3)
"""
conn.send("2 No more lines\n")
conn.close()
except socket.timeout:
pass
finally:
serv.close()
evt.set()
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Build problems with sqlite on OSX
"Darrin Thompson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | First of all 1000 apologies if this is the wrong list. Please redirect | me if necessary. Usage questions should usually be directed first to comp.lang.python / gmane.comp.python.general / python-list (all 3 are interconnected). Try that unless you get answer here fairly quickly. There are *many* more readers. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] whitespace normalization pre-commit hook is giving me grief
Neal Norwitz schrieb: > On 5/25/07, Brett Cannon <[EMAIL PROTECTED]> wrote: >> In my bcannon-objcap branch I am trying to check in a change that involves a >> soft symlink from Lib/controlled_importlib.py to >> ../importlib/controlled_importlib.py through ``ln -s >> ../controlled_importlib.py controlled_importlib.py`` while in the Lib >> directory. I have done this before in this branch so as to allow for easy >> importing of code from the svn import of importlib that the branch contains. > > I don't know that we've ever tested the commit hook with a link. > Maybe there is some other problem. The cause: For symlinks, SVN saves a file containing "link /target" and sets the "svn:special" property. Since the special file doesn't end with a newline, reindent adds that, and boom. The solution: add if fs.node_prop(txn_root, path, 'svn:special') == '*': continue in the commit hook's for loop. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
