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 [email protected] 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 [email protected] 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 [email protected] 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 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 [email protected] 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 [email protected] 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com > ___ Python-Dev mailing list [email protected] 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 >[email protected] >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com > > ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
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 [email protected] 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. ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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
[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 [email protected] 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
[email protected]
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 >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com >> > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/rrr%40ronadam.com > > ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
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 :\Programs. I'm not sure if any packages/programs will break because of that space, but what if some will? ___ Python-Dev mailing list [email protected] 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) PCbpyt 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\, 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* o
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 <>___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
Greg Ewing wrote: > 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?-) I wasn't going to say it :) Now, at the risk of going even further out of the mainstream (actually, there's no risk, it's a dead certainty), if I had been clever enough to think that I could write a LaTeX translator, I probably would have made my target language Docbook or some other flavor of XML. Now, you might argue that XML is more cumbersome and harder to author than reST, and that is certainly a valid argument. On the other hand, there are a couple of interesting advantages to using XML: 1) You get an instant WYSIWYG preview capability by publishing a standard CSS stylesheet along with the docs. Anyone would be able to see what the output would look like merely by viewing it in a browser. While there would be some document transformations which would be not be previewable in CSS (such as breaking the document up into hyperlinked chapters), you would at least be able to see enough to be able to do a decent job of editing the text without having to install any special tools. And some of those more difficult transformations would be doable with a suitable XSTL stylesheet, which can be directly executed in most browsers. (As an example, I once wrote an XSLT stylesheet that converted OpenDocument XML into the equivalent HTML - this was part of my Firefox ODFReader plugin [http://www.alcoholicsunanimous.com/odfreader/], that allowed ODF documents to be directly viewed in the browser without having to launch an external helper application.) 2) There are a few WYSIWYG XML editors out there, which allow you to edit the styled text directly in an editor (although I don't know of any open source ones.) 3) The document processing tool could be very minimal, mostly assembled out of standard modules for processing XML. 4) XML has a well-specified method of escaping into other (XML-based) languages, which is XML namespaces. So for those who want equations in their docs, they could simply insert a block of MathML inside their Docbook XML. Similarly, illustrations could be embedded using bitmap images or SVG as appropriate. 5) Having XML-based docs would make it easy to write other kinds of processors that operate on the docs in different ways, such as building a keyword index or doing various kinds of analysis. Now, this suggestion of using XML isn't really a serious one. But I think that the various advantages that I have listed ought to be considered when thinking about how the tool chain for python documentations should operate. I think that there is a big advantage to making the document processing tools simple and hosted entirely in Python. People who contribute to the docs are likely to know quite a bit about Python, but it is far from certain what else they might know. And tools written in Python are automatically able to run in diverse environments, which may not be the case for tools written in other languages. This means that tools that are in Python are more likely to be used, and further, they are more likely to be improved or specialized to the task by those who use them. In terms of authoring, the convenience of the markup language is only one factor; A bigger factor I think is having a short feedback cycle between edit and test, where 'test' means seeing what your written text would look like in the finished product. The quicker you can make that feedback loop, the more likely people will be to work on the docs. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
