Re: [Python-Dev] The docs, reloaded
Armin Ronacher schrieb: Hoi, Additionally to the offline docs that Georg published some days ago there is also a web version which currently looks and works pretty much like the offline version. There are however some differences that are worth knowing: - Cleaner URLs. You can actually guess them because we took the idea the PHP people had and check for similar pages if a page does not exist. We do however redirect if there was a match so that the URL stays unique. - The search doesn't require JavaScript (but is currently disabled due to a buggy stemmer and indexer) Also, try http://pydoc.gbrandl.de:3000/os.path.exists and ___ 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
Georg Brandl schrieb: Armin Ronacher schrieb: Hoi, Additionally to the offline docs that Georg published some days ago there is also a web version which currently looks and works pretty much like the offline version. There are however some differences that are worth knowing: - Cleaner URLs. You can actually guess them because we took the idea the PHP people had and check for similar pages if a page does not exist. We do however redirect if there was a match so that the URL stays unique. - The search doesn't require JavaScript (but is currently disabled due to a buggy stemmer and indexer) Also, try http://pydoc.gbrandl.de:3000/os.path.exists and http://pydoc.gbrandl.de:3000/os.paht.exists Georg ___ 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 5/23/07, Georg Brandl [EMAIL PROTECTED] wrote: Also, try http://pydoc.gbrandl.de:3000/os.path.exists Beautiful! STeVe -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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
Georg Brandl [EMAIL PROTECTED] wrote: Nick Craig-Wood schrieb: Being a seasoned unix user, I tend to reach for pydoc as my first stab at finding some documentation rather than (after excavating the mouse from under a pile of paper) use a web browser. If you've ever used pydoc you'll know it reads docstrings and for some modules they are great and for others they are sorely lacking. If pydoc could show all this documentation as well I'd be very happy! Maybe your quick dispatch feature could be added to pydoc too? It is my intention to work together with Ron Adam to make the pydoc - documentation integration as seamless as possible. So I'll be able to read the main docs for a module in a terminal without reaching for the web browser (or info)? That would be great! How would pydoc decide which bit of docs it is going to show? If I type pydoc re is it going to give me the rather sparse __doc__ from the re module or the nice reST docs? Or maybe both, one after the other? Or will I have to use a flag to dis-ambiguate? If you type pydoc re at the moment then it says in it MODULE DOCS http://www.python.org/doc/current/lib/module-re.html which is pretty much useless to me when ssh-ed in to a linux box half way around the world... It is missing conversion of ``comment'' at the moment as I'm sure you know... Sorry, what did you mean? ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. For an example see the first paragraph here: http://pydoc.gbrandl.de/reference/index.html -- 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] The docs, reloaded
Am Wed, 23 May 2007 08:30:17 +0200 schrieb Georg Brandl [EMAIL PROTECTED]: [...] Also, try http://pydoc.gbrandl.de:3000/os.path.exists [...] Looks good. But should the source pages really use syntax highlighting? I think if somebody is interested in the source then they should get the real source without any highlighting. If you decide to keep the syntax highlighting then the highlighting of multiline ReST strings should be fixed. For example see the source for splitext(). Thanks for the work, Dennis Benzinger ___ 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, Dennis Benzinger Dennis.Benzinger at gmx.net writes: Looks good. But should the source pages really use syntax highlighting? I think if somebody is interested in the source then they should get the real source without any highlighting. If you decide to keep the syntax highlighting then the highlighting of multiline ReST strings should be fixed. For example see the source for splitext(). Yeah. Georg said the same yesterday. I'll revert that change so that it displays the plain sources as text/plain in the online version too. 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] The docs, reloaded
Nick If you type pydoc re at the moment then it says in it Nick MODULE DOCS Nick http://www.python.org/doc/current/lib/module-re.html Nick which is pretty much useless to me when ssh-ed in to a linux box Nick half way around the world... I get quite a bit of information about re (I've never known /F to be a documentation slouch). Only one bit of that information is a reference to the page in the library reference manual. And if I happen to be ssh'd into a machine halfway round the world through a Gnome terminal I can right mouse over that URL and pop the page up in my default local browser. If you set the PYTHONDOCS environment variable you can point it to a local (or at least different) copy of the libref manual. A flag could be added to pydoc to show that content instead, however being html it probably would be difficult to read unless pumped through lynx -dump or something similar. Skip ___ 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
2007/5/23, Nick Craig-Wood [EMAIL PROTECTED]: Georg Brandl [EMAIL PROTECTED] wrote: Nick Craig-Wood schrieb: Being a seasoned unix user, I tend to reach for pydoc as my first stab at finding some documentation rather than (after excavating the mouse from under a pile of paper) use a web browser. If you've ever used pydoc you'll know it reads docstrings and for some modules they are great and for others they are sorely lacking. If pydoc could show all this documentation as well I'd be very happy! Maybe your quick dispatch feature could be added to pydoc too? It is my intention to work together with Ron Adam to make the pydoc - documentation integration as seamless as possible. So I'll be able to read the main docs for a module in a terminal without reaching for the web browser (or info)? That would be great! One option is to use a text-mode browser (lynx, links, or the likes). The other is to develop a terminal mode application (currently in pydoc, I believe) How would pydoc decide which bit of docs it is going to show? If I type pydoc re is it going to give me the rather sparse __doc__ from the re module or the nice reST docs? Or maybe both, one after the other? Or will I have to use a flag to dis-ambiguate? I really think that making pydoc a solid library to extract/search/navigate the documentation offers a lot of interesting perspectives. When one think beyond the application discussed here, there are a lot of tools (ipython, or any IDE for example) that could make great use of the facility. [note: Ron and I seemed to disagree on what (and how) pydoc should be, and that in particular, but I keep a keen interest in having such a library.] If you type pydoc re at the moment then it says in it MODULE DOCS http://www.python.org/doc/current/lib/module-re.html which is pretty much useless to me when ssh-ed in to a linux box half way around the world... It is missing conversion of ``comment'' at the moment as I'm sure you know... Sorry, what did you mean? ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. For an example see the first paragraph here: http://pydoc.gbrandl.de/reference/index.html -- 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/lgautier%40gmail.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
Re: [Python-Dev] The docs, reloaded
On Wednesday, May 23, 2007, at 12:40PM, [EMAIL PROTECTED] wrote: Nick If you type pydoc re at the moment then it says in it Nick MODULE DOCS Nick http://www.python.org/doc/current/lib/module-re.html Nick which is pretty much useless to me when ssh-ed in to a linux box Nick half way around the world... I get quite a bit of information about re (I've never known /F to be a documentation slouch). Only one bit of that information is a reference to the page in the library reference manual. And if I happen to be ssh'd into a machine halfway round the world through a Gnome terminal I can right mouse over that URL and pop the page up in my default local browser. If you set the PYTHONDOCS environment variable you can point it to a local (or at least different) copy of the libref manual. A flag could be added to pydoc to show that content instead, however being html it probably would be difficult to read unless pumped through lynx -dump or something similar. pydoc can already do this for the language reference (try 'pydoc import' on a system with a local install of the python documentation). Ronald Skip ___ 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/ronaldoussoren%40mac.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] Return value from socket.fileno()
Dear all, I am writing to seek information about the socket.fileno() method, and opinions on how best to implement it on jython. On cpython, socket.fileno() returns a file descriptor, i.e. an integer index into an array of file objects. This integer is then passed to select.select and select.poll, to register interest in specified events on the socket, i.e. readability, writability, connectedness, etc. Importantly, it is possible to select and poll on a socket's file descriptor immediately after the socket is created, e.g. before it is connected and even before a non-blocking connect process has been started. This is problematic on java, because java has different classes for client and server sockets. Therefore, on jython, creation of the actual socket implementation is deferred until the user has called a method which commits the socket to being a client or server socket, e.g. connect, listen, etc. This means that there is no meaningful descriptor/channel that can be returned from fileno() until the nature of the socket is determined. Also, file descriptors have no meaning on java. Instead, java Selectors select on java.nio.channels.SelectableChannel objects. But, ideally, this should not matter: AFAICT, the return value from fileno should be simply an opaque handle which has no purpose other than to be handed to select and poll, to indicate interest in events on the associated socket. I have been thinking that the simplest way to implement socket.fileno() on jython is to return the actual socket object, i.e. return self. When this object is passed to select/poll as a parameter, the select/poll implementation would know to retrieve the underlying java SelectableChannel, if it exists yet. If it does not yet exist, because the socket is not yet commited to being a server or client socket, then it is simply excluded from the select/poll operation. The only problem with it is returning a non-integer from the fileno() method; instead a socket object would be returned. So the question I'm asking is: Does anyone know of existing cpython code which relies on the return value from socket.fileno() being an integer? Or code that would break if it were returned a socket instance instead of an integer? Thanks, Alan. P.S. If anyone is interested, a non-blocking sockets and select (and soon asyncore) implementation is currently residing in the jython sandbox. It is hoped that it will be included in jython 2.2rc1. More here http://wiki.python.org/jython/NewSocketModule ___ 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
Nick Craig-Wood schrieb: It is missing conversion of ``comment'' at the moment as I'm sure you know... Sorry, what did you mean? ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. Ahh, now the dime has fallen ;) (sorry, German phrase) Yes, it should probably use Unicode equivalents of these quotes, as it does with en- and em-dashes. There are also nifty post-processor filters which operate on complete HTML pages and replace normal quotes by smart ones, perhaps that is the way to go. Georg ___ 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] -OO and Docstrings
Bug #1722485 reports that Py 2.5+ doesn't ignore docstrings anymore if
used with -OO.
Attached patch should fix this.
Georg
Index: Python/compile.c
===
--- Python/compile.c (Revision 55526)
+++ Python/compile.c (Arbeitskopie)
@@ -1119,7 +1119,8 @@
if (!asdl_seq_LEN(stmts))
return 1;
st = (stmt_ty)asdl_seq_GET(stmts, 0);
- if (compiler_isdocstring(st)) {
+ if (compiler_isdocstring(st) Py_OptimizeFlag 2) {
+ /* don't generate docstrings if -OO */
i = 1;
VISIT(c, expr, st-v.Expr.value);
if (!compiler_nameop(c, __doc__, Store))
___
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] Introduction and request for commit access to the sandbox.
On 5/23/07, Neal Norwitz [EMAIL PROTECTED] wrote: On 5/22/07, Alexandre Vassalotti [EMAIL PROTECTED] wrote: As you see, cStringIO's code also needs a good cleanup to make it, at least, conforms to PEP-7. Alexandre, It would be great if you could break up unrelated changes into separate patches. Some of these can go in sooner rather than later. I don't know all the things that need to be done, but I could imagine a separate patch for each of: * whitespace normalization * function name modification * other formatting changes * bug fixes * changes to make consistent with StringIO I don't know if all those items in the list need to change, but that's the general idea. Separate patches will make it much easier to review and get benefits from your work earlier. I totally agree, and that was already my current idea. I look forward to seeing your work! Thanks! -- Alexandre ___ 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
Nick Craig-Wood wrote: ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. For an example see the first paragraph here: http://pydoc.gbrandl.de/reference/index.html What latex does here for typeset output is nice, but it's also a bit of a hack job. The ` and ' characters aren't smart, the fonts just have curved glyphs for them. `` and '' are mapped to additional glyphs using ligatures, again part of the font information. The result, of course, is really nice. :-) Scott Dial wrote: In fairness to Georg, latex2html also misses the smart quotes. See the same paragraph here: http://docs.python.org/ref/front.html There's a way to make latex2html do the right thing for these, except... it then happily does so even to ` and '' (and `` and '') in code samples, since there's no equivalent to the font information used to handle this in latex. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Nick Craig-Wood wrote: ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. For an example see the first paragraph here: http://pydoc.gbrandl.de/reference/index.html In fairness to Georg, latex2html also misses the smart quotes. See the same paragraph here: http://docs.python.org/ref/front.html -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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
Martin Blais wrote: On 5/22/07, Martin Blais [EMAIL PROTECTED] wrote: ReST works well only when there is little markup. Writing code documentation generally requires a lot of markup, you want to make variables, classes, functions, parameters, constants, etc.. (A better avenue IMHO would be to augment docutils with some code to automatically figure out the syntax of functions, parameters, classes, etc., i.e., less markup, and if we do this in Python we may be able to use introspection. This is a challenge, however, I don't know if it can be done at all.) Just to follow-up on that idea: I don't think it would be very difficult to write a very small modification to docutils that interprets the default role with more smarts, for example, you can all guess what the types of these are about: `class Foo` (this is a class Foo) `bar(a, b, c) - str` (this is a function bar which returns a string) `name (attribute)` (this is an attribute) ...so why couldn't the computer solve that problem for you? I'm sure we could make it happen. Essentially, what is missing from ReST is less markup for documenting programs. By restricting the problem-set to Python programs, we can go a long way towards making much of this automatic, even without resorting to introspecting the source code that is being documented. I was going to suggest something similar. Ideally, any markup language ought to have a kind of Huffman Coding of complexity - in other words, the markup symbols that are used the most frequently are the ones that should be the shortest and easiest to type. Just as in real Huffman Coding, the popularity of a given element is going to depend on context. This would imply that there should be customizations of the markup language for different knowledge domains. While there are some benefits to having a 'standard' markup, any truly universal markup is going to be much heavier and more cumbersome than one that is specialized for the task. I would advocate a system in which the author inserts minimalistic 'hints' into the text, and the document processor uses those hints along with some automatic reasoning to determine the final markup. As in the above example, the use of backticks can be signal to the document processor that the enclosed text should be examined for identifiers and other Python syntax. I would also suggest that one test for evaluating the quality of markup syntax is whether or not it can be learned by example - can a user follow the pattern of some other part of the docs, without having to learn the syntax in a formal way? -- Talin ___ 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] Adventures with x64, VS7 and VS8 on Windows
-Original Message- From: Martin v. Löwis [mailto:[EMAIL PROTECTED] That couldn't work for me. I try avoid building on a network drive, and with local drives, I just can't have a Windows build and a Linux build on the same checkout - they live on separate file systems, after all (Linux on ext3, Windows on NTFS, with multi-boot switching between them). Very well, leaving linux aside, I don't see why this: /win32mount/trunk/PCbuild/ /x64mount/trunk/PCbuild/ Is any different from /winmount/trunk/PCBuild/win32 /winmount/trunk/PCBuild/x64 I don't understand this extraordinary reluctance to add a single extra directory. The windows build process is different from any other build process, so even If all the other platforms live one directory higher, why must windows? I don't *use* them simultaneously, of course - I cannot work on two architectures simultaneously, anyway. I do so on a daily basis. I designed PCBuild8 to be easy for interactive work using VisualStudio, using property sheets and such to group common settings for easy editing. During the course of my work, I will edit a file (which is checked out from Perforce), compile debug for two platforms, test, and repeat. I say let's just admit that tools can compile for more than one target. Let's adapt to it and we will all be happier. You might be; I will be sad. It comes for a price, I well understand the benefits, I use it all the time, but the price still eludes me. how can a different name for the output folder for a different platform be such a big problem? And btw, there is no need to install the msvcr8.dll. We can distribute them as a private assembly. then they (and the manifest) exist in the same directory as python2x.dll. Yes, but then python2x.dll goes into system32, and so will msvcr8.dll, no? Yes, that is correct. Well, there is a CRT .exe redist if you want to deploy this into the SxS cache, it just has to be run as part of the install process. But that may or may not be problematic, I don't know. Not sure whether anything really is needed. Python works fine on Vista. If you are an administrator. A limited user will have problems installing it and then running it. Is there a bug report for that? I don't know. At any rate, I think any vista issues is a completely separate thing, something that needs to be handled as a whole, rather than responding to a particular problem reported in a bug report. 1) supplying python.dll as a Side By Side assembly What would that improve? Well, it should reduce dll-hell problems of applications that ship with python2x.dll. You ship with and link to your own and tested dll. We have some concerns here, for example, now that we are moving away from embedding python in our blue.dll and using python25.dll directly, that this exposes a vulnerability to the integrity of the software. Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release? Someone could replace the python25.dll that we ship with their own patched version, thereby gaining backdoor access to the software. The way windows searches for old style dlls makes this easy. Using the SxS signed loading scheme, you can protect yourself up to a point from such attacks. Of course, this doesn't have to be a problem for vanilla python, we can do this on our own for the patched python25 that we employ, but it still might be something others could find useful. Install in the ProgramFiles folder. Only over my dead body. *This* is silly. Bill doesn't think so. And he gets to decide. I mean we do want to play nice, don't we? Nothing installs itself in the root anymore, not since windows 3.1 Just as C does. Ah, and this also means that we could install both 32 bit and 64 bit versions, another plus. What about the registry? I don't know about the registry, what is it used for? 64 bit windows already ships with dual versions of some apps, notably explorer.exe so that shouldn't be a big problem. Interesting. We are definitely interested in that. You see, Someone installs a game or accounting software using vista. He then runs as a limited user. Python insists on saving its .pyc files in the installation folder, but this is not something that is permitted on Vista. But that's not a problem, is it? Writing silently fails, i.e. it just won't save the pyc files. Happens all the time on Unix. It may not silently fail, depending on your user status. An admin might get a confirmation window, for example. Sure, and have they reported problems with Python on Vista (problems specific to Vista?) Certainly. We are working on them, of course. But, of course, they have not been reported. These are not python errors as such, but rather EVE errors. We ship the .py files precompiled and therefore avoid the aforementioned problems. But we have had to move all sorts of
[Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk Is my buildbot the only reliable Windows buildbot machine? It is possible that within a couple of weeks or so I'll have to take this one offline. Are there others that can provide a Windows buildbot? It would probably be good to have two -- and a WinXP one would be good. 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
Re: [Python-Dev] The docs, reloaded
Nick Craig-Wood wrote:
Georg Brandl [EMAIL PROTECTED] wrote:
Nick Craig-Wood schrieb:
Being a seasoned unix user, I tend to reach for pydoc as my first stab
at finding some documentation rather than (after excavating the mouse
from under a pile of paper) use a web browser.
If you've ever used pydoc you'll know it reads docstrings and for some
modules they are great and for others they are sorely lacking.
If pydoc could show all this documentation as well I'd be very happy!
Maybe your quick dispatch feature could be added to pydoc too?
It is my intention to work together with Ron Adam to make the pydoc -
documentation integration as seamless as possible.
So I'll be able to read the main docs for a module in a terminal
without reaching for the web browser (or info)? That would be great!
How would pydoc decide which bit of docs it is going to show?
Pydoc currently gets topic info for some items by scraping the text from
document 'local' web pages. This is kind of messy for a couple of reasons.
- The documents may not be installed locally.
- It can be problematic locating the docs even if they are installed.
- They are not formatted well after they are retrieved.
I think this is an area for improvement.
This feature is also limited to a small list where the word being searched
for is a keyword, or a very common topic reference, *and* they are not
likely to clash with other module, class, or function names.
The introspection help parts of pydoc are completely separate from topic
help parts. So replacing this part can be done without much trouble. What
the best behavior is and how it should work would need to be discussed.
Keep in mind doc strings are meant to be more of a quick reference to an
item, and Pydoc is the interface for that.
If I type pydoc re is it going to give me the rather sparse __doc__
from the re module or the nice reST docs? Or maybe both, one after
the other? Or will I have to use a flag to dis-ambiguate?
If retrieval from the full docs is desired, then it will probably need to
be disambiguated in some way or be a separate interface.
help('re')# Quick reference on 're'.
helpdocs('re')# Full documentation for 're'.
If you type pydoc re at the moment then it says in it
MODULE DOCS
http://www.python.org/doc/current/lib/module-re.html
which is pretty much useless to me when ssh-ed in to a linux box half
way around the world...
It is missing conversion of ``comment'' at the moment as I'm sure you
know...
Sorry, what did you mean?
``comment'' produces smart quotes in latex if I remember correctly.
You probably want to convert it somehow because it looks a bit odd on
the web page as it stands. I'm not sure what the reST replacement
might be, but converting it just to comment would probably be OK.
Likewise with `comment' to 'comment'.
For an example see the first paragraph here:
http://pydoc.gbrandl.de/reference/index.html
___
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
Laurent Gautier wrote: 2007/5/23, Nick Craig-Wood [EMAIL PROTECTED]: Georg Brandl [EMAIL PROTECTED] wrote: Nick Craig-Wood schrieb: Being a seasoned unix user, I tend to reach for pydoc as my first stab at finding some documentation rather than (after excavating the mouse from under a pile of paper) use a web browser. If you've ever used pydoc you'll know it reads docstrings and for some modules they are great and for others they are sorely lacking. If pydoc could show all this documentation as well I'd be very happy! Maybe your quick dispatch feature could be added to pydoc too? It is my intention to work together with Ron Adam to make the pydoc - documentation integration as seamless as possible. So I'll be able to read the main docs for a module in a terminal without reaching for the web browser (or info)? That would be great! One option is to use a text-mode browser (lynx, links, or the likes). The other is to develop a terminal mode application (currently in pydoc, I believe) How would pydoc decide which bit of docs it is going to show? If I type pydoc re is it going to give me the rather sparse __doc__ from the re module or the nice reST docs? Or maybe both, one after the other? Or will I have to use a flag to dis-ambiguate? I really think that making pydoc a solid library to extract/search/navigate the documentation offers a lot of interesting perspectives. When one think beyond the application discussed here, there are a lot of tools (ipython, or any IDE for example) that could make great use of the facility. [note: Ron and I seemed to disagree on what (and how) pydoc should be, and that in particular, but I keep a keen interest in having such a library.] But we agree on making it a useful library module or package. ;-) And I don't see anything above I disagree with. Cheers, Ron If you type pydoc re at the moment then it says in it MODULE DOCS http://www.python.org/doc/current/lib/module-re.html which is pretty much useless to me when ssh-ed in to a linux box half way around the world... It is missing conversion of ``comment'' at the moment as I'm sure you know... Sorry, what did you mean? ``comment'' produces smart quotes in latex if I remember correctly. You probably want to convert it somehow because it looks a bit odd on the web page as it stands. I'm not sure what the reST replacement might be, but converting it just to comment would probably be OK. Likewise with `comment' to 'comment'. For an example see the first paragraph here: http://pydoc.gbrandl.de/reference/index.html -- 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/lgautier%40gmail.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/rrr%40ronadam.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
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Trent Mick schrieb: http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk Is my buildbot the only reliable Windows buildbot machine? It is possible that within a couple of weeks or so I'll have to take this one offline. Are there others that can provide a Windows buildbot? It would probably be good to have two -- and a WinXP one would be good. How much work is it to set one up, and to maintain it? Maybe I can offer an XP VMWare image. 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] 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. How much work is it to set one up, and to maintain it? Maybe I can offer an XP VMWare image. It has been a while since I set it up. Tim did so at about the same time and wrote down his steps to setup... but I can't find the reference to those instructions right now. I've found maintenance to be low -- just have to have to start a cmd shell and run the buildbot slave command. However, that may be because the box on which it is running isn't one I use regularly, so I don't have to worry about accidentally killing the process, frequent reboots or anything like that. I'll try to dig around and see what I can find for setup instructions. 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
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
On Wed, May 23, 2007 at 12:08:52PM -0700, Trent Mick wrote: - 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. - - How much work is it to set one up, and to maintain it? Maybe I can offer an XP VMWare image. - - It has been a while since I set it up. Tim did so at about the same time - and wrote down his steps to setup... but I can't find the reference to - those instructions right now. - - I've found maintenance to be low -- just have to have to start a cmd - shell and run the buildbot slave command. However, that may be because - the box on which it is running isn't one I use regularly, so I don't - have to worry about accidentally killing the process, frequent reboots - or anything like that. - - I'll try to dig around and see what I can find for setup instructions. It's mildly tricky to install, but very easy to set up a slave process; I have several. I can offer an image, but what kills me is the maintenance. It's rarely a big deal -- reboot after some updates, install some startup scripts, etc. -- but when it *does* require an effort I hate it off because I dislike Windows so intensely ;). Not a good reason, I know, but... cheers, --titus ___ 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] Adventures with x64, VS7 and VS8 on Windows
[MarkH] I'm guessing vsextcomp doesn't use the Visual Studio 'ReleaseAMD64' configuration - would it be OK for me to check in changes to the PCBuild projects for this configuration? [Martin v. Löwis] Please don't. It exclusively relies on vsextcomp, and is only useful if you have that infrastructure installed. See for yourself: it uses the /USE_CL:MS_OPTERON command line switch, which isn't a Microsoft invention (but instead invented by Peter Tröger). Aside: it isn't my experience that vsextcomp is necessary to cross-compile for AMD64 and IA64. My cross-build process basically equates to: - Run the appropriate environment setup for the correct compiler. E.g., for the Platform SDK AMD64 compiler and with the current Platform SDK this is: C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd /X64 /RETAIL - Run the solution file with devenv.com (IIRC, devenv.exe doesn't take command-line args) and be sure to pass ing /useenv to pick up the environment changes. (*) set DEVENV_COM=path/to/devenv.com %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 (*) Note that for a cross-build the make_versioninfo and make_buildinfo projects need to be built natively first: C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 /project make_versioninfo %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 /project make_buildinfo This is all VS7.1, though. I don't yet know if VS8 throws a spanner into the works. For VS6 I use msdev instead of devenv.com and PC\VC6\pcbuild.dsw instead of PCbuild\pcbuild.sln. I haven't looked into what vsextcomp does, so apologies if this is ignorant. 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
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Trent Mick wrote: It has been a while since I set it up. Tim did so at about the same time and wrote down his steps to setup... but I can't find the reference to those instructions right now. http://wiki.python.org/moin/BuildbotOnWindows If you run into problems setting it up, feel free to ping me. chat: (Gtalk/Jabber) [EMAIL PROTECTED] I've found maintenance to be low -- just have to have to start a cmd shell and run the buildbot slave command. I believe MarkH posted some notes on getting a buildbot Windows slave running as a service as well, but I didn't try that. Getting that working easily could help cut down on the maintenance. 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
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
It seems the best thing might be to modify the PCBuild8 build process so the output binaries are in the ../PCBuild' directory - this way distutils and others continue to work fine. Does that sound reasonable? I think Kristjan will have to say a word here: I think he just likes it the way it is right now. That would rather suggest that build_ext needs to be changed. I use this patch in ActivePython to get distutils to find the correct PCbuild dir (see attached). Trent -- Trent Mick trentm at activestate.com --- python/Lib/distutils/command/build_ext.py Tue Mar 13 03:19:35 2007 +++ python/Lib/distutils/command/build_ext.py Tue Apr 17 12:51:26 2007 @@ -176,7 +176,16 @@ # Append the source distribution include and library directories, # this allows distutils on windows to work in the source tree self.include_dirs.append(os.path.join(sys.exec_prefix, 'PC')) -self.library_dirs.append(os.path.join(sys.exec_prefix, 'PCBuild')) +from distutils.msvccompiler import get_build_version +msvc_version = get_build_version() +if msvc_version == 6: +self.library_dirs.append(os.path.join(sys.exec_prefix, 'PC', 'VC6')) +elif 6 msvc_version 8: +self.library_dirs.append(os.path.join(sys.exec_prefix, 'PCbuild')) +elif msvc_version = 8: +self.library_dirs.append(os.path.join(sys.exec_prefix, 'PCbuild8')) +else: +log.warn(unexpected MSVC version: %r, msvc_version) # OS/2 (EMX) doesn't support Debug vs Release builds, but has the # import libraries in its Config subdirectory ___ 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] Adventures with x64, VS7 and VS8 on Windows
On 5/23/07, Kristján Valur Jónsson [EMAIL PROTECTED] wrote: Install in the ProgramFiles folder. Only over my dead body. *This* is silly. Bill doesn't think so. And he gets to decide. I mean we do want to play nice, don't we? Nothing installs itself in the root anymore, not since windows 3.1 Maybe installing in the root is not good, but installing to Program Files is just asking for trouble. All sorts of development tools might suddenly break because of that space in the middle of the path and requirement to use quotes around it. I thus usually install things to drive:\Programs. I'm not sure if any packages/programs will break because of that space, but what if some will? ___ 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] Adventures with x64, VS7 and VS8 on Windows
Very well, leaving linux aside, I don't see why this:
/win32mount/trunk/PCbuild/
/x64mount/trunk/PCbuild/
Is any different from
/winmount/trunk/PCBuild/win32
/winmount/trunk/PCBuild/x64
I don't understand this extraordinary reluctance to add a single extra
directory.
The windows build process is different from any other build process, so even
If all the other platforms live one directory higher, why must windows?
It doesn't need to, and reluctance is not wrt. to the proposed new
layout, but wrt. changing the current one. Tons of infrastructure
depends on the files having exactly the names that they have now,
and being located in exactly the locations where they are currently
located. Any change to that, whatever minor, will cause problems
to some people.
So for the change to be made, the advantages must clearly outweigh
the incompatibility of the change in the first place.
I say let's just admit that tools can compile for
more than one target. Let's adapt to it and we will all be happier.
You might be; I will be sad. It comes for a price,
I well understand the benefits, I use it all the time, but the price
still eludes me. how can a different name for the output folder
for a different platform be such a big problem?
When running Python now, I type (after having changed to the source
directory in the cmd.exe window) PCbtabpyttabtab or some
such. To navigate to a subdirectory, I need many more keystrokes.
I find it very painful to invoke python.exe from the
PCbuild8 directory. I don't want that pain to be the default.
Yes, that is correct. Well, there is a CRT .exe redist if you want to deploy
this into the SxS cache, it just has to be run as part of the install process.
But that may or may not be problematic, I don't know.
Microsoft recommends to use the merge module (.msm), and I think this
is what should be done (if feasible).
Why should there be versioning problems with python25.dll? Are there
any past issues with incompatibilities with any python2x.dll release?
Someone could replace the python25.dll that we ship with their own patched
version, thereby gaining backdoor access to the software. The way
windows searches for old style dlls makes this easy. Using the SxS
signed loading scheme, you can protect yourself up to a point from such
attacks. Of course, this doesn't have to be a problem for vanilla
python, we can do this on our own for the patched python25 that we
employ, but it still might be something others could find useful.
I personally think that if hostile users can replace DLLs on your
system, you have bigger problems than SxS installation of pythhonxy.dll,
but perhaps that's just me.
Install in the ProgramFiles folder.
Only over my dead body. *This* is silly.
Bill doesn't think so. And he gets to decide.
He can decide not to give Python the Vista ready logo. If so,
I don't want it. He cannot decide to make the Python installer
to install into a directory with a space in its name by default.
I mean we do want to play nice, don't we?
Nice to users of Python, sure. I would not have said a word if
the standard directory would have been, say \usr\bin. However,
they happened to chose Program Files, making it language dependent,
and putting a space in the name. That space has caused numerous
problems to Python scripts, and I expect changing the default
would cause a lot of problems to end users.
What about the registry?
I don't know about the registry, what is it used for?
For two things, with different importance to different users:
1. File extensions are registered there, e.g. .py and .pyc.
With two binaries installed, the will stomp over each other's
file associations; only one of them can win.
2. Python installs keys under
HL{LM|CU}\Software\Python\PythonCore\version, namely
InstallPath
InstallGroup
PythonPath
Documentation
Modules
For some of these, add-on libraries and applications may modify
these keys, and the interpreter will pick up the changes.
Again, there can be only one installation on the system
owning these settings; two simultaneous installations will
stomp on each other's settings.
64 bit windows already ships with dual versions of some apps, notably
explorer.exe so that shouldn't be a big problem.
The two versions of MSIE actually *are* a big problem, that's
why MS only runs the 32-bit IE, even on Win64 (otherwise, ActiveX
controls downloaded from the net wouldn't work).
Also, while they are both shipped, you can't the two versions of
explorer.exe simultaneously (without trickery), so its far from
simple.
But that's not a problem, is it? Writing silently fails, i.e. it just
won't save the pyc files. Happens all the time on Unix.
It may not silently fail, depending on your user status. An admin might
get a confirmation window, for example.
Can you describe the precise scenario which makes that happen? To my
knowledge, Vista will *not* open a confirmation window when Python
attempts
Re: [Python-Dev] Windows buildbot (Was: buildbot failure in x86 W2k trunk)
Trent Mick schrieb: http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk Is my buildbot the only reliable Windows buildbot machine? Tim Peter's machine comes and goes, depending on whether he starts the buildbot. Alan McIntyre's machien should be mostly he reliable, but nobody really notices if it goes away. It is possible that within a couple of weeks or so I'll have to take this one offline. Don't worry about that. It's a volunteer service, so if nobody volunteers, regular building on Windows just won't happen. 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). Regards, Martin ___ 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] Adventures with x64, VS7 and VS8 on Windows
I use this patch in ActivePython to get distutils to find the correct PCbuild dir (see attached). Would you like to commit this to 2.6? (or perhaps 2.5 even?) Regards, Martin ___ 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] Adventures with x64, VS7 and VS8 on Windows
- Run the appropriate environment setup for the correct compiler. E.g., for the Platform SDK AMD64 compiler and with the current Platform SDK this is: C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd /X64 /RETAIL - Run the solution file with devenv.com (IIRC, devenv.exe doesn't take command-line args) and be sure to pass ing /useenv to pick up the environment changes. (*) set DEVENV_COM=path/to/devenv.com %DEVENV_COM% PCbuild\pcbuild.sln /useenv /build ReleaseAMD64 Yes, that should work equally fine. I haven't looked into what vsextcomp does, so apologies if this is ignorant. It spares you having to setup the environment; it provides a cl.exe wrapper that locates the SDK from the registry, and then invokes the cl.exe in the SDK if necessary. As a consequence, you can still just double-click the solution file, without having to run devenv.exe/com manually. Regards, Martin ___ 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. How much work is it to set one up, and to maintain it? Maybe I can offer an XP VMWare image. Setting it up essentially requires to put all the software into place, see the wiki. Maintaining it requires attention in case it suddenly hangs, which it does more often on Windows than it does on Unix. In particular, when a process fails to terminate, subsequently it may fail to remove or modify files, and then it breaks completely until the process is killed. A weekly reboot would like fix the majority of the maintenance problems. Regards, Martin ___ 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] Adventures with x64, VS7 and VS8 on Windows
Very well, leaving linux aside, I don't see why this: /win32mount/trunk/PCbuild/ /x64mount/trunk/PCbuild/ Is any different from /winmount/trunk/PCBuild/win32 /winmount/trunk/PCBuild/x64 In the former case, assuming python is running from the 'trunk' directory, all architectures know how to locate the binary directory - it is always named 'PCBuild'. In the latter case, the directory name depends on the architecture. A number of existing tools already know about the 'PCBuild' directory, so these tools will not need to be taught anything new for x64. I don't understand this extraordinary reluctance to add a single extra directory. I think that this thread has enumerated the concerns fairly well. You may not agree with them, but if you don't understand them it might be worth re-reading Martin's responses. Note that I also understand your concerns and goals - I certainly see where you are coming from - but we have 2 competing goals - work with as many existing, external build tools as possible versus take this opportunity to create a new cross-compile-capable x64 build environment for Windows and let those external tools deal with the breakage. As I mentioned in a previous email, my personal opinion would be swayed by looking externally. Specifically, if we could determine the likelihood of external build processes (eg, mozilla) working unchanged if we stick with 'PCBuild', and if we could determine the cross-compilation strategy being adopted by the external libs we use (zlib, bsddb, etc), I think we could make an informed decision. You might be; I will be sad. It comes for a price, I well understand the benefits, I use it all the time, but the price still eludes me. how can a different name for the output folder for a different platform be such a big problem? Please see above - its not a problem if you think of the PCBuild8 process as the last step in a build process - but often it is not. External tools that use Python (ie, things you try and build after the Python build has completed) are impacted. I understand that you might not use such tools, but they do exist. Why should there be versioning problems with python25.dll? Are there any past issues with incompatibilities with any python2x.dll release? Someone could replace the python25.dll that we ship with their own patched version, thereby gaining backdoor access to the software. The way windows searches for old style dlls makes this easy. Using the SxS signed loading scheme, you can protect yourself up to a point from such attacks. I'm not sure I buy this. If someone has enough access to your machine to change pythonxx.dll, you are pretty screwed already. What about the registry? I don't know about the registry, what is it used for? Please see PC/getpathp.c in Python source tree. However, I agree that there are a number of things we could do to help Python play nicely on Vista. It might help if we can enumerate the specific problems and potential solutions in a more formal way (eg, a Python bug) Cheers, Mark attachment: winmail.dat___ 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] Adventures with x64, VS7 and VS8 on Windows
Martin v. Löwis wrote: I use this patch in ActivePython to get distutils to find the correct PCbuild dir (see attached). Would you like to commit this to 2.6? (or perhaps 2.5 even?) Sure, if others think it is a good thing. Will do tomorrow unless I hear a -1 before then. 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
Re: [Python-Dev] Adventures with x64, VS7 and VS8 on Windows
Martin v. Löwis wrote: I use this patch in ActivePython to get distutils to find the correct PCbuild dir (see attached). Would you like to commit this to 2.6? (or perhaps 2.5 even?) Sure, if others think it is a good thing. Will do tomorrow unless I hear a -1 before then. I'm not quite a '-1', but am a little confused about where this would leave us. To some extent, this would formalize PCBuild8 and VC6 directories. External tools would then slowly start growing support for these additional directories and the previous benefits of PCBuild is the canonical location appear to vanish. Further, I expect that such a patch would confuse any attempts to manually copy from PCBuild8 into PCBuild, for example (ie, some tools knowing about PCBuild8 while others assume PCBuild is likely to get confusing.) Trent: I assume you use the same source tree for multiple platforms and compilers, meaning that changing these optional build processes to copy from PCBuild8/VC6 into PCBuild would cause pain? If not, do you think that would be a reasonable solution? Cheers, Mark ___ 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] Adventures with x64, VS7 and VS8 on Windows
I'm not quite a '-1', but am a little confused about where this would leave us. To some extent, this would formalize PCBuild8 and VC6 directories. External tools would then slowly start growing support for these additional directories and the previous benefits of PCBuild is the canonical location appear to vanish. Further, I expect that such a patch would confuse any attempts to manually copy from PCBuild8 into PCBuild, for example (ie, some tools knowing about PCBuild8 while others assume PCBuild is likely to get confusing.) Trent: I assume you use the same source tree for multiple platforms and compilers, meaning that changing these optional build processes to copy from PCBuild8/VC6 into PCBuild would cause pain? If not, do you think that would be a reasonable solution? Changing to have bits always in PCbuild would work for me -- i.e. I *don't* build for multiple compilers/platforms in the same tree. Perhaps that is a better solution -- in the long run, anyway. Having the bits always in one dir for whatever the configuration is more akin to the Unix-y configure/make system. Is this something that could work for Python 2.5? Or just 2.6? Long term/aside: Moving to a configure/make build system on Windows, as you proposed in your first email, would be interesting. With MSYS though, not cygwin (a la bsmedberg's new MozillaBuild stuff). I just wish there were an autoconf alternative that wasn't as painful as autoconf. I have a few attempts for my purposes that are written in Python (an obvious bootstrapping problem for building Python itself :). 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] nodef
Hi I often have the need for a generic object to use as the default value for a function parameter, where 'None' is a valid value for the parameter. For example: _sentinel = object() def first(iterable, default=_sentinel): Return the first element of the iterable, otherwise the default value (if specified). for elem in iterable: # thx to rhettinger for optim. return elem if default is _sentinel: raise StopIteration return default Here, 'default' could legally accept None, so I cannot use that as the default value, nor anything else as far as I'm concerned (I don't know what lives in the iterable, so why should I make assumptions?). Sometimes in the past I've create generic objects, declared a class, e.g.: class NoDef: pass def foo(default=NoDef): ... and lately I've even started using the names of builtin functions (it bothers me a little bit though, that I do that). I think Python needs a builtin for this very purpose. I propose 'nodef', a unique object whose sole purpose is to serve as a default value. It should be unique, in the same sense that 'None' is unique. Comments or alternative solutions? ___ 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] nodef
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 23, 2007, at 8:08 PM, Martin Blais wrote:
I often have the need for a generic object to use as the default value
for a function parameter, where 'None' is a valid value for the
parameter.
I do the same thing for 'get' calls, where None is a legal return
value. I often call this unique object 'missing', e.g.
missing = object()
if some_dict.get('foo', missing) is missing:
# It's missing
I like the way that reads. Still, I'm -1 on adding something like
this to built-ins because any built-in could potentially be a value
in a mapping or a default argument. Have some super-secret module
global instantiated just for the purpose prevents that.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQCVAwUBRlTfBHEjvBPtnXfVAQI3kQP6AzYa1VNUIgaqY4aQAW3dUX2sxicEikts
NT6NIo/F676b1P7XYCrN7RA9JYWoyJmMhqrz7EN3SL2dkzd4mcY/XZF/zbY9ph8d
W1SEWo00ImFitSRwngIlUmhlcZimpIQ0Of0hCdm9uK0Cpyk03FXbUelY1LvunJ2T
z8tCQzd8hOw=
=R8bc
-END PGP SIGNATURE-
___
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)
On 5/23/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Trent Mick schrieb: http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk Is my buildbot the only reliable Windows buildbot machine? Tim Peter's machine comes and goes, depending on whether he starts the buildbot. Alan McIntyre's machien should be mostly he reliable, but nobody really notices if it goes away. I ping buildbot owners from time to time if their bot is unavailable or otherwise having problems. I know I've talked to Alan recently, but in this case I think he contacted me. 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
Re: [Python-Dev] Return value from socket.fileno()
Alan Kennedy wrote: I am writing to seek information about the socket.fileno() method, and opinions on how best to implement it on jython. I would hope that the new i/o system will make it unnecessary to use fileno() in portable code. It's really a unix-specific thing. So the question I'm asking is: Does anyone know of existing cpython code which relies on the return value from socket.fileno() being an integer? Or code that would break if it were returned a socket instance instead of an integer? If you only pass it to other things supported on that platform that use filenos, probably not. BTW, you can pass socket objects directly to select() anyway. I'd regard this as the current portable way to use sockets and select. The man page says that this works via the fileno() method, but it doesn't have to be implemented that way -- select() could be taught to recognise socket objects natively. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] Return value from socket.fileno()
On 5/23/07, Greg Ewing [EMAIL PROTECTED] wrote: Alan Kennedy wrote: I am writing to seek information about the socket.fileno() method, and opinions on how best to implement it on jython. I would hope that the new i/o system will make it unnecessary to use fileno() in portable code. It's really a unix-specific thing. So the question I'm asking is: Does anyone know of existing cpython code which relies on the return value from socket.fileno() being an integer? Or code that would break if it were returned a socket instance instead of an integer? If you only pass it to other things supported on that platform that use filenos, probably not. BTW, you can pass socket objects directly to select() anyway. I'd regard this as the current portable way to use sockets and select. The man page says that this works via the fileno() method, but it doesn't have to be implemented that way -- select() could be taught to recognise socket objects natively. I want to emphasize this option. Passing the socket to select should be more portable than using fileno(). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Georg Brandl wrote: Ahh, now the dime has fallen ;) (sorry, German phrase) In English it's the penny has dropped, so it's not much different. :-) Although I thought dimes were an American thing, and Germans would be more likely to use a different coin. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Talin wrote: As in the above example, the use of backticks can be signal to the document processor that the enclosed text should be examined for identifiers and other Python syntax. Does this mean it's time for pyST -- Python-structured text?-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] nodef
Martin Blais wrote: I don't know what lives in the iterable, so why should I make assumptions? I think Python needs a builtin for this very purpose. I propose 'nodef', a unique object whose sole purpose is to serve as a default value. If the aforementioned iterable can yield *anything*, then it might yield this 'nodef' value as well. For this reason, there *can't* exist any *standard* guaranteed-unambiguous sentinel value. Each use case needs its own, to ensure it's truly unambiguous in the context of that use case. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] nodef
From: Greg Ewing If the aforementioned iterable can yield *anything*, then it might yield this 'nodef' value as well. For this reason, there *can't* exist any *standard* guaranteed-unambiguous sentinel value. Each use case needs its own, to ensure it's truly unambiguous in the context of that use case. Right. That's why Barry and others write: missing = object() v = d.get(k, missing) That is the guaranteed way to get a unique object. Raymond ___ 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
