Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)

Fredrik Lundh wrote: > just one question: where do you want [to put] the "vendor" checkins ? I'm > using > a flat "kits" namespace in my own repositories, e.g. > anyone has a better name? anyone ? _

Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)

Martin v. Löwis wrote: > > Since all the relevant module names start with "Element", putting it > > directly > > under xml wouldn't be too bad. But an xml subpackage is better, and prior > > art says "etree". > > So etree it is. I just realized that the prior art (lxml.etree) uses etree as an a

Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)

Steve Holden wrote: >>>anyone ? >> >> I think "contrib" is somewhat conventional for the purpose. >> > Indeed, but conventionally *all* code in the Python core is contributed, > and I think we need a name that differentiates externally-maintained > packages from the contributions that are integrat

[Python-Dev] should I really have to install Python before I can build it ?

looks like you need to have a recent Python version installed to be able to build the current trunk: ./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl ./Parser/asdl_c.py:150: SyntaxWarning: local name 'self' in 'sum_with_constructors' shadows use of 'self' as global in nested scope

Re: [Python-Dev] should I really have to install Python before Ican build it ?

Jeremy Hylton wrote: > The C files are checked into subversion. Perhaps there is some > problem with the timestamps that causes the Makefile to try to rebuild > them anyway? I have a modern Python and I've been doing a fair amount > of development on these files; as a result, I haven't noticed a

[Python-Dev] stupid package tricks

the xml/__init__.py file contains a cute little hack that overrides the *entire* xml subtree with stuff from PyXML, if available. the code basically does import _xmlplus sys.modules[__name__] = _xmlplus (exception handling and version checks not shown). however, this means that as thing

Re: [Python-Dev] should I really have to install Python before Icanbuild it ?

Brett Cannon wrote: > > maybe the right thing here would be to change this to > > > > #!./python > > """Generate C code from an ASDL description.""" > > > > and only run the script if ./python has been built ? > > What if you build with a different suffix for the executable? Or do > diffe

Re: [Python-Dev] Incorporating external packages into Python's stddistribution

[EMAIL PROTECTED] wrote: > BTW, there is one project I'm theoretically familiar with that attempts to > handle the dual source situation: XEmacs. I'm still trying to come to terms > with the practical issues involved. I'm supposed to be updating the > python-mode code, and am only taking baby st

Re: [Python-Dev] ElementTree in stdlib

Nick Coghlan wrote: > > Having to define classes that conform to a certain API and registering > > instances of those classes as callbacks with the parser doesn't look > > that pythonic to me. An iterator API seems much more pythonic. > > If this is a comment on the ElementTree API, then /F must a

Re: [Python-Dev] ElementTree in stdlib

M.-A. Lemburg wrote: > Some questions: > > * Are you going to contribute cElementTree as well ? yes, but there are some build issues we need to sort out first (both pyexpat and cET link to their own copies of expat) we also need to figure out how to import the bundled version; should it be cElem

[Python-Dev] Jython and CPython

BTW, what's the policy wrt. Jython-specific modules in the standard library? Expat isn't available under Jython, but I have a Java/Jython-driver for ElementTree on my disk. Can / should this go into the CPython standard library ? ___ Python-Dev m

[Python-Dev] Sharing expat instances

Martin v. Löwis wrote: > > - sort out expat bundling issues, and include cElementTree as well > > (using the same approach as above). ... > > (one way to do this would be to add an "function pointer table" to pyexpat > > that contains pointers to selected portions of the expat API, and the

Re: [Python-Dev] Deprecate __ private (was Re: PEP 8updates/clarifications)

Steven Bethard wrote: > > Everybody here agrees that this style makes the code much less legible. > > Partly because of the constant indirection. Also because it imposes > > learning all those two-letter abbreviations before reading a module, and > > the learning has to be redone on each visit, i

Re: [Python-Dev] Sharing expat instances

Fred L. Drake, Jr. wrote: > > 1. add an Include/pyexpat.h header file which contains a structure > > similar to the following: > ... > > comments ? > > +1 I take that as a "go ahead" ;-) ___ Python-Dev mailing list Python-Dev@python.org http://m

Re: [Python-Dev] ElementTree in stdlib

Fred wrote: > > That's not true. The current xml package *is* the consensus of > > xml-sig. > > It pretty much was at the time, at any rate. It's not clear to me that the > xml package shipped in 2.4 and several preceeding versions of Python would > pass muster in the current XML-SIG. There's be

Re: [Python-Dev] Sharing expat instances

I wrote: > 1. add an Include/pyexpat.h header file which contains a structure > similar to the following: > 2. during pyexpat initialization, initialize all members of this structure, > and > make it available as a PyCObject: > 3. in cElementTree (or _elementtree, or whatever the python version

Re: [Python-Dev] Sharing expat instances

Michael McLay wrote: > Avoiding imaginaary name collisions and putting cElementTree into the xml > package there's nothing imaginary here -- cElementTree is an existing and quite popular module, and will remain available as a separate distribution. it would be nice if people could install that k

Re: [Python-Dev] Sharing expat instances

Phillip J. Eby wrote. > >my current idea is to > > > > 1. include it under a different name (_elementtree.so) > > > > 2. add a cElementTree.py under xml.etree, which simply does > > > > from _elementtree import * > > > >does anyone have a better idea ? > > I was under the imp

Re: [Python-Dev] "xml" package in standard library

Fred L. Drake, Jr. wrote: > On Tuesday 13 December 2005 18:40, A.M. Kuchling wrote: > > +1; it's what should have been done in the first place. > > If only I'd understood that when I added the xml/PyXML hack to the stdlib > years ago. :-( > > Fixed now. I'll deal with the documentation in a few

Re: [Python-Dev] "xml" package in standard library

> you also broke my subversion: > > $ svn up > svn: subversion/libsvn_ra_svn/marshal.c:434: vwrite_tuple: Assertion `opt || > cstr' failed. > Aborted > > (but that's probably not your fault). > > has anyone seen this error? any ideas on how to fix it? google indicated that people had seen this

Re: [Python-Dev] ElementTree in stdlib

Jeremy Hylton wrote: > On 12/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > > > we also need to figure out how to import the bundled version; should it be > > > cElementTree, xml.etree.cElementTree, or just xml.etree.ElementTree > > > (which would then fallback on the Python version if cElement

Re: [Python-Dev] Sharing expat instances

Scott David Daniels wrote: > > > One good reason for this is that the .pyd's or .so's cannot necessarily > > > be used from zip files > > > > When you say "cannot necessarily", are the situations where they can be > > imported from zip files? I thought the answer to that was always "no". > > I th

Re: [Python-Dev] Sharing expat instances

I wrote: > my current idea is to > > 1. include it under a different name (_elementtree.so) > > 2. add a cElementTree.py under xml.etree, which simply does > > from _elementtree import * I've implemented this, for now. can anyone with a working windows setup look at buildin

Re: [Python-Dev] Sharing expat instances

Trent Mick wrote: > [Fredrik Lundh wrote] > > can anyone with a working windows setup look at building the > > _elementtree module for windows ? > > > > (see the setup.py file for build options; it wants the same defines > > as pyexpat, plus one extra define.). &g

Re: [Python-Dev] Expose Subversion revision number to Python

Armin Rigo wrote: > What about having instead: > > sys.build_info = ("CPython", , "trunk") > > This would make it clear that it's the CPython svn rev number, and it > could possibly be used to distinguish between branches, too, which the > revision number alone cannot do. ("trunk" is the last

Re: [Python-Dev] Expose Subversion revision number to Python

Phillip J. Eby wrote: > I have not found any way to establish a stable "revision number" for a > directory tree in Subversion except by using -R and "Last Changed Rev" (or > the equivalent scanning of .svn/entries files). Through my experience > working on setuptools in the sandbox, it is clearly

Re: [Python-Dev] ref leak in element tree/pyexpat

Neal Norwitz wrote: > I'm not sure where the problem is, but this code leaks a reference: >parser = ET.XMLParser() ; parser.feed('text') > > You need this to set it up: > from xmlcore.etree import cElementTree as ET > > This isn't a memory leak according to valgrind. looks like it's stealin

[Python-Dev] fresh checkout won't build

$ svn up At revision 41759. $ make ... Python/compile.c: In function `PyNode_Compile': Python/compile.c:301: parse error before `mod' Python/compile.c:302: `mod' undeclared (first use in this function) Python/compile.c:302: (Each undeclared identifier is reported only once Python/compile.c:302: for

Re: [Python-Dev] fresh checkout won't build

> $ svn up > At revision 41759. > $ make > ... > Python/compile.c: In function `PyNode_Compile': > Python/compile.c:301: parse error before `mod' > Python/compile.c:302: `mod' undeclared (first use in this function) > Python/compile.c:302: (Each undeclared identifier is reported only once > Python/

Re: [Python-Dev] Expose Subversion revision number to Python

Armin Rigo wrote: > Should I propose / check-in a patch to expose sys.build_info instead > ("CPython", "41761", "trunk"), as this got positive feedback so far? > It's also less surprizing than the current sys.build_number, which is a > string despite its name. fwiw, I'm still +1 on that. ___

[Python-Dev] fixing log messages

just noticed an embarrasing misspelling in one of my recent checkins, only to find that I cannot fix it: $ svn propedit --revprop -r 41759 svn:log svn: Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook $ would it be a good i

Re: [Python-Dev] fixing log messages

Martin v. Löwis wrote: > I have now installed this hook to allow editing svn:log; please try > again. $ svn propedit --revprop -r 41759 svn:log Set new value for property 'svn:log' on revision 41759 thanks! /F ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] fixing log messages

Steve Holden wrote: > That's "embarrassing", by the way. You're obviously having a bad > spelling day :-) I'd say that any spelling with more than 500,000 google hits is perfectly valid... ___ Python-Dev mailing list Python-Dev@python.org http://

[Python-Dev] status of development documentation

the "Documentation Development" page at http://www.python.org/dev/doc/ contains a link to a "SVN trunk" version which was last updated nearly four months ago. what would it take to automatically update the trunk docs, say, once a day or so ? or is it time to move away from the current "odd-

Re: [Python-Dev] fixing log messages

Steve Holden wrote: >> I'd say that any spelling with more than 500,000 google hits is perfectly >> valid... >> > Anything you say, Frederick ... > > thirteen-million-google-hits-can't-possibly-be-wrong-ly y'rs - steve oh, frederick is a perfectly valid english spelling of the germanic name "F

Re: [Python-Dev] status of development documentation

Martin v. Löwis wrote: > If you just want to know what your changes look like: type "make html" > in the Doc directory, and wait a moment for it to complete. I get > xml.etree as section 13.13. provided you have all the right stuff on your machine, that is: $ make html TEXINPUTS=... +++ TEXINPUT

Re: [Python-Dev] status of development documentation

Josiah Carlson wrote: > -1 for choosing something not ReST or latex. yeah, because using something that everyone else uses would of course not be the python way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listi

Re: [Python-Dev] status of development documentation

Phillip J. Eby wrote: > >(as I hinted, I'd prefer HTML with microformat annotations as the main > >format; > >with roundtripping to markdown or rest (etc) for people who prefer to > >author in that, and tidy->xhtml->python tools for the HTML generation) > > I don't see how HTML is any "lighter" t

Re: [Python-Dev] status of development documentation

A.M. Kuchling wrote: > I don't see how HTML can be used to support printed versions of the > docs (e.g. PostScript, PDF). Even if you generated one big HTML file > instead of a zillion section-by-section files, web browsers are > terrible at printing. I don't know how you could get a table of >

Re: [Python-Dev] status of development documentation

Fred L. Drake, Jr. wrote: > LaTeX, for all the tool requirements, is a fairly light-weight markup > language. Yes, it has too many special characters. But someone else > invented it, and I'm not keen on inventing any more than we have to. "someone else invented it" is of course why I'm advocati

Re: [Python-Dev] status of development documentation

Phillip J. Eby wrote: > > > And attempting to roundtrip HTML back to reST would lose far too much > > > information > > > >in a less dogmatic Python universe, that would be considered a major > >design flaw in ReST. > > Since when is having a more expressive source language than HTML a flaw? :)

Re: [Python-Dev] status of development documentation

Josiah Carlson wrote: > > yeah, because using something that everyone else uses would of course > > not be the python way. > > No, because ReST is significantly easier to learn and use than basically > every other markup language I've gotten my hands on. I'm not really interested in optimizing fo

Re: [Python-Dev] status of development documentation

Barry Warsaw wrote: > Sorry, but HTML and (even more so) XML are not human-writable. :) Yeah, > we can all do the simple stuff, but I absolutely hate authoring in HTML, > and it would be a nightmare if the documentation production system > didn't handle lots and lots of magic for you (like weavin

Re: [Python-Dev] status of development documentation

Barry Warsaw wrote: > > Sure, and some people hate using whitespace for block structure. > > A more proper analogy would be people who hate braces and parentheses. > You have to type so many more < and > characters (not to mention &s > and ;s) to make happy-joy html than you have to type \s and {s

Re: [Python-Dev] status of development documentation

Phillip J. Eby wrote: > And where characters like '<' and '>' occur frequently as part of the text, > especially in showing Python interactions like this: > > >>> print "hello world" > hello world > > I can't imagine trying to author the above in an HTML/XML based format, it's spelled

Re: [Python-Dev] status of development documentation

Trent Mick wrote: > > - could a cronjob that does this be set up on some python.org machine > > (or on some volunteer's machine) > > I bit: > > http://trentm.com/python/ you rule! thanks /F ___ Python-Dev mailing list Python-Dev@python.org http:

Re: [Python-Dev] status of development documentation

Torsten Bronger wrote: > > [...] Are there any HTML-to-print converters that are better? > > I don't understand exactly how the HTML is to be used for Python but > I assume that not everything could be done via CSS, so own > converters will be necessary for perfect output. If done right, it shou

Re: [Python-Dev] status of development documentation

Fred L. Drake, Jr. wrote: > > I'm not convinced it's the toolchain though. People hate writing > > documentation. Getting people to contribute documentation is worse than > > pulling teeth. > > I don't think it's the toolchain either. While most people don't have it, > it's easier and easier

Re: [Python-Dev] status of development documentation

Ian Bicking wrote: > This is somewhat tangential to this discussion, but I did have the > Python documentation in mind as a potential future target for > Commentary: http://pythonpaste.org/comment/commentary/ -- which would > allow more casual contributions that seem to work well for other project

Re: [Python-Dev] status of development documentation

Michael Chermside wrote:¨ > Me too. Specifically, I think if you make it really easy to write notes > on the docs you will get some helpful documentation content. You will > also get lots of things that are too lengthy or exhaustive, to specific > to one person's problem, helpdesk style questions,

Re: [Python-Dev] reST limitations? (was Re: status of development documentation)

Martin Blais wrote: > > So, definitions of functions, classes, and other structured stuff would > > just use fields under a directive, and references to those definitions > > would just be reST links. > > So you end up with a document with a bunch of custom directives, like:: > > .. python-class::

Re: [Python-Dev] status of development documentation

Reinhold Birkenfeld wrote: > > I can only speak for my own experience, but maybe it will help. I > > once tried to help fix a piece of the python docs. The description > > of Py_UNICODE on was > > -- and still is -- incorrect. > > The current docs

[Python-Dev] that library reference, again

as seen on the doc-sig: > > > javadoc's > > > > > > [EMAIL PROTECTED] os.popen} > > > > > > is even shorter. > > > > > > hmm. maybe a combination of rest/html/whatever and pythondoc markup > > > would be the ultimate tool for the library reference... > > > > <* heavy clapping sound of my foot

[Python-Dev] a quit that actually quits

sourceforge just went off the air, so I'm posting this patch here, in order to distract you all from Christian's deque thread. this silly little patch changes the behaviour of the interpreter so that "quit" and "exit" actually exits the interpreter. it does this by installing a custom excepthook

Re: [Python-Dev] file() vs open(), round 7

Aahz wrote: > class file(object) > | file(name[, mode[, buffering]]) -> file object > | > | Open a file. The mode can be 'r', 'w' or 'a' for reading (default), > [...] > | Note: open() is an alias for file(). > > This is confusing. I suggest that we make ``open()`` a factory function > right

Re: [Python-Dev] status of development documentation

Neal Norwitz wrote: > And hopefully of interest to many here: > >http://docs.python.org/dev/results/ > > These are the results of svn update, configure, build, test, install > and the doc run. the "trunk" link on http://www.python.org/dev/doc/ still points to the old http://www.pyt

Re: [Python-Dev] file() vs open(), round 7

M.-A. Lemburg wrote: >> can we add a opentext factory for file/codecs.open while we're at it ? > > Why a new factory function ? Can't we just redirect to codecs.open() > in case an encoding keyword argument is passed to open() ?! I think open is overloaded enough as it is. Using separate functio

Re: [Python-Dev] a quit that actually quits

Reinhold Birkenfeld wrote: > What is wrong with something like this: > > >>> class Quitter: > ... def __repr__(self): raise SystemExit > ... > >>> exit = quit = Quitter() >>> vars() # oops! ___ Python-Dev mailing list Python-Dev@python.org http:/

Re: [Python-Dev] file() vs open(), round 7

Phillip J. Eby wrote: > >Here's a rough draft: > > > > def textopen(name, mode="r", encoding=None): > > if "U" not in mode: > > mode += "U" > > if encoding: > > return codecs.open(name, mode, encoding) > > return file(name, mode) > > Nice. It sho

Re: [Python-Dev] a quit that actually quits

Ronald Oussoren wrote: > Why must quit and exit be so special in the first place? They could > be plain functions, or even something like:: > > class _QuitOrExit: > def __init__(self, name): > self.name = name > > def __repr__(self): > return "Use %(name)s() to exit."%(self.__dict__) > > def __cal

Re: [Python-Dev] file() vs open(), round 7

Phillip J. Eby wrote: > >but that was made at a time when it wasn't clear if "open" or "file" would > >be the preferred way to open a file. now that we've settled on the verb > >form, I think "textopen" or "opentext" would be slightly more consistent. > > Sorry, I'm confused. Who settled on the

Re: [Python-Dev] a quit that actually quits

[EMAIL PROTECTED] wrote: > Fredrik> whaddya think? > > We're going to wind up with the same problem that spawned the atexit module: > multiple code sources wanting to fiddle with sys.excepthook step on one > another's toes. in this case, I'm not sure it matters that much. if you add your own

Re: [Python-Dev] a quit that actually quits

Hans Nowak wrote: > My point is that there is currently no acceptable, universal way to exit > the interpreter. Again, it's not that big of a deal... but it seems > silly that something apparently trivial like that cannot be done right. it's the usual problem: getting enough developers to agree

Re: [Python-Dev] a quit that actually quits

Adal Chiriliuc wrote: > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> exit > 'Use Ctrl-Z plus Return to exit.' > >>> > > I've just tried Ctrl+Z (plus Return) and some variations on Win X

Re: [Python-Dev] a quit that actually quits

Ka-Ping Yee wrote > It sounds to me like what is being proposed amounts to essentially > "promote sys.exit to a builtin". no, what's being proposed is what the subject says: a quit/exit command that actually quits, instead of printing a "you didn't say please!" message. _

Re: [Python-Dev] a quit that actually quits

Ka-Ping Yee wrote: > Fredrik's NameError-based proposal (exit when there's an exception > with no tb_next that says "name 'exit' is not defined") causes the > interpreter to quit when you enter any expression involving 'exit'. > > print exit # seems surprising > [3, 4, 5,

Re: [Python-Dev] a quit that actually quits

Martin v. Löwis wrote: > > In short, I think it makes a lot of sense to support a bare "exit" and/or > > "quit" as a completely intuitive platform-independent newbie-friendly way to > > exit the interpreter. > > I can readily agree to this part of Fredrik's proposal. What slightly > bothers me is

Re: [Python-Dev] a quit that actually quits

Jeremy Kloth wrote: > Ka-Ping Yee wrote: > > I'd be happy with having Python exit when the user types just plain > > 'exit' without parentheses, but only in that case, not others. > > However, i'm starting to think that may be impossible to implement. > > I can't think of any way to make 'print ex

Re: [Python-Dev] a quit that actually quits

Martin v. Löwis wrote: > Introducing sys.commandline is fine; overriding sys.excepthook > still worrisome. > > What's wrong with triggering this in some __repr__ implementation? because simple introspection may exit your program. unexpected exits are a lot more annoying than unexpected non-exits

[Python-Dev] floating point literals don't work in non-US locale in 2.5

someone recently broke floating point literals in a rather spectacular way: $ export LANG=sv_SE.utf8 $ ./python Python 2.5a0 (41806M, Dec 25 2005, 12:12:29) Type "help", "copyright", "credits" or "license" for more information. >>> 3.14 3.1401 >>> import locale >>> locale.setlocale(loc

Re: [Python-Dev] a quit that actually quits

Michael Hudson wrote: > In other news, clever hacks with tb_next and so on also seem > excessive. Why not have the equivalent of "if input.rstrip() == > 'exit': sys.exit()" in the implementation of the interactive > interpreter? that would turn exit and quit into reserved keywords.

Re: [Python-Dev] a quit that actually quits

Michael Hudson wrote: > > that would turn exit and quit into reserved keywords. > > In what sense? Not in the sense of "things in single quotes in > Grammar"... no, but in the sense of "names that can no longer be used in code" >>> def exit(): ... print "bye" >>> # what is it?

Re: [Python-Dev] a quit that actually quits

Walter Dörwald wrote: > We have sys.displayhook and sys.excepthook. Why not add a sys.inputhook? > sys.inputhook gets passed each line entered and may return True if it has > processed the line inself and False if normal handling of the input should be > done. This allows special treatment of "qui

Re: [Python-Dev] a quit that actually quits

Guido van Rossum wrote: > > but now we're back to today's situation: > > > > >>> quit > > 'Use Ctrl-Z plus Return to exit.' > > > > which violates the basic "if you know what I mean, why the /!"&/&!//%¤ > > don't you do what I say" usability rule. > > What nonsense. Every Python programmer

Re: [Python-Dev] a quit that actually quits

Steve Holden wrote: > I *have* been surprised by the amount on brainpower that's been > expended on this discussion. number of posts != amount of brainpower ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/p

Re: [Python-Dev] a quit that actually quits

> (for those who follow non-python forums make that "those who don't follow" ___ 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

Re: [Python-Dev] When do sets shrink?

Martin v. Löwis wrote: > Adal Chiriliuc wrote: > > MSVC 7.1 and 8.0 malloc always uses the Windows heap functions > > (HeapAlloc & friends) if running on Windows 2000 or newer > > (malloc.c and heapinit.c). > > > > So it seems that for both Linux (gcc) and Win (msvc) the memory is > > released to

Re: [Python-Dev] a quit that actually quits

[EMAIL PROTECTED] wrote: > Fredrik> make that "those who don't follow" > > What might some of those non-python forums be? assorted corners of the blogosphere, mostly. no time to dig up any explicit references, since I'm preparing for a 650 km trip through a major snowstorm, but searching bac

Re: [Python-Dev] a quit that actually quits

Aahz wrote: > Does that also include my suggestion about improving the startup message? when newbies get to the point that they want to quit, chances are that the message have scrolled out of sight. and if they only skim the instructions, they'll probably get confused anyway... e.g. Python ver

Re: [Python-Dev] When do sets shrink?

Noam Raphael wrote: > I'm not saying that practically it must be used - I'm just saying that > it can't be called a heuristic, and that it doesn't involve any "fancy > overkill size hinting or history tracking". It actually means > something like this: > 1. If you want to insert and the table is f

Re: [Python-Dev] a quit that actually quits

Fernando Perez wrote: > In [1]: x='hello' > > In [2]: x? /.../ > Docstring: > str(object) -> string > > Return a nice string representation of the object. > If the argument is a string, the return value is the same object. I'm not sure what I find more confusing: a help system that cl

Re: [Python-Dev] a quit that actually quits

Guido van Rossum wrote: > Regarding the meme floating about the arrogance of Pythoneers: > bloggers (pretty much by definition) are actually the most arrogant > species; don't confuse "bloggers say" with "most people think". Sure, but I'm not only talking about the mindless ranters here; it's als

Re: [Python-Dev] floating point literals don't work in non-USlocale in 2.5

Guido wrote: > Not the first time this happened. :-( > > Could someone add a unit test for this please? Hye-Shik Chang just added the necessary tests to his bugfix patch. I'll check this in later tonight. ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] [Doc-SIG] that library reference, again

David Goodger wrote: > > however, given that the discussion that led up to this has been dead for > > almost a week, > > You mean since Christmas? > > > I'm beginning to fear that I've wasted my time on a project > > that nobody's interested in. > > Could be. I don't see HTML+PythonDoc as a signif

Re: [Python-Dev] New PEP: Using ssize_t as the index type

Martin v. Löwis wrote: > Please let me know what you think. +1. in honor of the Bike Shed Effect, I'm going to assume that you've thought of everything. ::: well, one thing seems to missing from your PEP: in several modules, you've changed the cast used in the type table. e.g. --- python/bran

Re: [Python-Dev] [Doc-SIG] that library reference, again

Robey Pointer wrote: > > [Fredrik Lundh] > >> Really? > > > > Yes, really. > > Just out of curiosity (really -- not trying to jump into the flames) > why not just use epydoc? If it's good enough for 3rd-party python > libraries, isn't that j

Re: [Python-Dev] [Doc-SIG] that library reference, again

> [David Goodger] > >> Could be. I don't see HTML+PythonDoc as a significant improvement > >> over LaTeX. > > [Fredrik Lundh] > > Really? > > Yes, really. Your reply makes it obvious that you don't understand the issues involved here, nor how the

Re: [Python-Dev] [Doc-SIG] that library reference, again

M.-A. Lemburg wrote: > I haven't followed the thread, so many I'm repeating things. > > Has anyone considered using e.g. MediaWiki (the wiki used for > Wikipedia) for Python documentation ? > > I'm asking because this wiki has proven to be ideally suited > for creating complex documentation tasks

Re: [Python-Dev] [Doc-SIG] that library reference, again

Donovan Baarda wrote: > > No, it's a fundamental goal: to support light-weight generation of rendered > > markup directly from source code, to enable simple tools (CGI scripts, etc) > > to be able to render reference documentation. > > Python is run-time interpreted, but I don't think we need its

Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0

Thomas Wouters wrote: > > Only in the most severe cases does it make sense to create a PEP > > specifically to be rejected. > > Yet if it isn't recorded, people will keep bringing it up. How about a > 'rejected ideas' PEP for ideas that are right out no matter how people > argue? A single PEP, wit

Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0

Ralf W. Grosse-Kunstleve wrote: > ***Please*** make Python more selfish. Note that this is also an obvious > avenue > for significant performance increases. If self is implicit you don't have to > do > the dictionary lookup for "self" all the time as is the case now. what dictionary lookup ?

Re: [Python-Dev] Checking in a broken test was: Re: [Python-checkins]r41940 - python/trunk/Lib/test/test_compiler.py

Neal Norwitz wrote: > In the past, we haven't checked in tests which are known to be broken. > There are several good reasons for this. I would prefer you, 1) also > fix the code so the test doesn't fail, 2) revert the change (there's > still a bug report open, right?), or 3) generalize tests fo

Re: [Python-Dev] Draft proposal: Implicit self in Python 3.0

Ralf W. Grosse-Kunstleve wrote: > > what dictionary lookup ? > > IIUC, "self" is first looked up in the local dictionary. no, self is a local variable. self.x means that "x" is looked up in the in- stance dictionary, though. > Please try the code below to see the performance impact. oh, please

Re: [Python-Dev] [Doc-SIG] that library reference, again

> anyone knows anything about support for semantic markup ? http://meta.wikimedia.org/wiki/Semantic_MediaWiki not sure a full-blown RDF-in-wiki-syntax is really that optimal, though ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.

Re: [Python-Dev] locale and LC_NUMERIC

Neal Norwitz wrote: > > No. %-formatting should always use the C locale. One should use > > locale.format to get locale-aware formatting. > > I know very little about locale's. /f assigned me a bug > http://python.org/sf/1391872 which suggests I run all the tests in a > different locale than C.

Re: [Python-Dev] locale and LC_NUMERIC

Neal Norwitz wrote: > > I feel I'm lacking some link here: why do you think we should do that? > > [EMAIL PROTECTED] ~/build/python/svn/clean-ish $ LC_ALL=de_DE ./python > >>> import locale > >>> locale.setlocale(locale.LC_ALL) > 'C' > >>> locale.setlocale(locale.LC_ALL, 'de_DE') > 'de_DE' > > I w

Re: [Python-Dev] Tkinter

Guido van Rossum wrote: > But for sure, Tkinter is still being maintained by the Python > developers (mainly MvL I believe). If it appears stagnant that's > probably because Tcl/Tk itself isn't changing much. afaict, Tcl/Tk 8.5 isn't moving quite as fast as Python 2.5, but they're probably a lot

Re: [Python-Dev] r42003 - python/trunk/Lib/test/outstanding_bugs.pypython/trunk/Lib/test/outstanding_crashes.py

time to synchronize your activities a bit ? > Author: neal.norwitz > Date: Tue Jan 10 08:49:41 2006 > New Revision: 42000 > > Added: >python/trunk/Lib/test/crashers/ >python/trunk/Lib/test/crashers/README >python/trunk/Lib/test/crashers/coerce.py >python/trunk/Lib/test/crashers/wea

[Python-Dev] building a module catalogue with buildbot

I've been playing with "automatic module discovery" in an attempt to figure out how complete the library reference really is. I've created a simple script that tweaks the path to get rid of site-package stuff, and then scans the path for python modules and extensions, and writes the result to a te

Re: [Python-Dev] building a module catalogue with buildbot

Neal Norwitz wrote: > Does that make sense? We would just need /f's script in SVN. in python/Tools/something or sandbox/something ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

<    2   3   4   5   6   7   8   >