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 and offers many features > which would make Python documentation a lot easier and more > accessible: > > * people wouldn't have to learn LaTeX to commit doc-patches > * it's easy to monitor and revert changes, discuss changes > * there's version history available > * new docs would be instantly available on the web > * builtin search facility, categories and all the other nifty > wiki stuff > * it's one of the more popular wikis around and due to Wikipedia > it's here to stay > * conversion to XML and DocBook is possible, providing > entry points for conversion to other formats (including > LaTeX) > * more following means more tools (over time) > > Just a thought. anyone knows anything about support for semantic markup ? (afaict, the current moinmoin wiki would solve 80% of the issues involved here; I'm aiming for those 80% plus 80% of the remaining 20%). ___ 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] ConfigParser to save with order
ConfigParser saves the data in a not-predefined order. This is because it keeps, internally, the information in dictionaries. I opened a patch in SF 1399309 that orders the info to be saved in the file through the ConfigParser write() method. This patch does not let the user to specify the order, but allows to predict the order in which it'll be saved. There's another patch, the 1371075, that allows to specify the order through an "ordered dict". What do we want ConfigParser to do? Regards, .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Checking in a broken test was: Re: [Python-checkins] r41940 - python/trunk/Lib/test/test_compiler.py
[moving to python-dev] > On 1/7/06, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > > Well, it is not the test that's broken... it's compiler. [In reference to: http://mail.python.org/pipermail/python-checkins/2006-January/048715.html] 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 for known bugs. I strongly prefer #1, but have been thinking about adding #3. There are many open bug reports that fall into two broad categories: incorrect behaviour and crashers. I've been thinking about adding two tests which incorporate these bugs as a way of consolidating where the known problems are. Also, it's great when we have test cases that can be moved to the proper place once the fix has been checked in. I'm proposing something like add two files to Lib/test: outstanding_bugs.py and outstanding_crashes.py. Both would be normal test files with info about the bug report and the code that causes problems. This test in test_compiler should be moved to outstanding_bugs.py. And for a different discussion: On 1/7/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > Maybe. Guido's statement (maybe short of a pronouncement) > was that keyword-only arguments were OK in principle, and > that *args could follow keywords. It wasn't true yet because > no one had put in the work, but it would be an acceptable > change. > > I interpret this to mean that > > def f(a=1, b): pass > > should not necessarily raise an error, but I would like to see what > it does to > > def f(a=1, b): > print a,b > f(b=7) > > before saying that it is OK. ___ 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] some interesting readings
because I was reminded of them recently, because they may be useful landmarks in the prospective of future discussions, because expanding one's understanding of the problem/solution space of language design is quite a good thing if one is interested in such things... 1) Gilad Bracha. Pluggable Type Systems . OOPSLA04 Workshop on Revival of Dynamic Languages ( http://pico.vub.ac.be/%7Ewdmeuter/RDL04/papers/Bracha.pdf ) As a talk: Pluggable Types, originally given at Aarhus University in March 2003, and repeated since at Berne and elsewhere. ( http://bracha.org/pluggable-types.pdf ) 2) http://homepages.cwi.nl/~ralf/OOHaskell/ state of the art experiment on trying to reconcile object orientation, type inference and as much as possible expressiveness PS: I think 1 is much more relevant than 2 for Python as we know it. happy reading. ___ 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] Checking in a broken test was: Re: [Python-checkins] r41940 - python/trunk/Lib/test/test_compiler.py
[Neal Norwitz] > ... > In the past, we haven't checked in tests which are known to be broken. It's an absolute rule that you never check in a change (whether a test or anything else) that causes ``regretst.py -uall`` to fail. Even if it passes on your development box, but fails on someone else's box, it's fair game to revert that change. Since this particular change caused -uall to fail on all boxes, I had no qualms about reverting rev 41940. Reinhold, if you're working on a fix for the problem too, feel free to check that test in on a branch instead (short-lived branches are easy & fast under SVN). Branches aren't required to pass any tests. The test on the branch can be merged into the trunk later, after a fix has also been checked in on that branch. ... > There are many open bug reports that fall into two broad categories: > incorrect behaviour and crashers. I've been thinking about adding two > tests which incorporate these bugs as a way of consolidating where the > known problems are. Also, it's great when we have test cases that can > be moved to the proper place once the fix has been checked in. > > I'm proposing something like add two files to Lib/test: > outstanding_bugs.py and outstanding_crashes.py. Both would be normal > test files with info about the bug report and the code that causes > problems. > > This test in test_compiler should be moved to outstanding_bugs.py. That would be fine provided that the failing tests aren't normally run via -uall. ___ 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] Checking in a broken test was: Re: [Python-checkins] r41940 - python/trunk/Lib/test/test_compiler.py
On 1/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > I'm proposing something like add two files to Lib/test: > outstanding_bugs.py and outstanding_crashes.py. Both would be normal > test files with info about the bug report and the code that causes > problems. I like this approach. regrtest.py won't runthem, but you can run them manually to help in finding the bug (if the cause isn't known yet) or verifying it's been fixed (if it is). > And for a different discussion: > > On 1/7/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > Maybe. Guido's statement (maybe short of a pronouncement) > > was that keyword-only arguments were OK in principle, and > > that *args could follow keywords. It wasn't true yet because > > no one had put in the work, but it would be an acceptable > > change. > > > > I interpret this to mean that > > > > def f(a=1, b): pass > > > > should not necessarily raise an error, but I would like to see what > > it does to > > > > def f(a=1, b): > > print a,b > > f(b=7) > > > > before saying that it is OK. I suspect you've got that wrong. I don't recall saying that you should be able to put positional arguments after keyword arguments in a call -- the meaning would be ambiguous to humans even if it can be given a clear meaning by the compiler. Similarly, in a def it would also be unclear to the human reader, and I'm not sure what the point would be. (In the above example, the real question is what f(7) would mean -- does it set b to 7 or a?) However, I *do* recall saying something about the relative ordering of *args and **kwds. In particular, I think we should be allowed to write f(1, 2, 3, *args, x=1, y=2, **kwds) # also without **kwds and perhaps also f(1, 2, 3, *args, 4, 5, 6) (though I'm less interested in supporting the latter). -- --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] Compiler warnings for 64-bit portability problems
On 1/6/06, von Löwis Martin <[EMAIL PROTECTED]> wrote: > I just found that the intel compiler (icc 9.0) > also supports compiler warnings for portability > problems. Cool. Thanks for the info. It would be nice if Intel would provide Python developers with a permanent icc license for Python. Can anyone help with that? > 4. don't try the Intel install.sh, it won't work >(atleast, it didn't work for me) I don't follow directions very well (I'm also a doubter), so I had to try it myself. :-) It worked for me on gentoo amd64 non-root install. I needed to set LD_LIBRARY_PATH to ~/intel/cce/9.0/lib, but otherwise it was pretty painless. This worked: CC=icc ./configure --without-cxx But I think this should work too: CC=icc CXX=icc ./configure I've fixed a bunch of problems on HEAD. I think I will move to ssize branch since that will be a much bigger help. I have some outstanding modifications, but here are the results of make: http://python.org/neal/icc-warnings.txt Summary (type, warning count, description): warning.#170:2 pointer points outside of underlying object (obmalloc.c PT(0)) warning.#188: 14 enumerated type mixed with another type warning.#810: 1478 conversion from "long" to "int" may lose significant bits warning.#1418: 137 external definition with no prior declaration warning.#1419: 53 external declaration in primary source file warning.#1684: 285 conversion from pointer to same-sized integral type (potential portability problem) -- all due to offsetof() remark.#111: 121 statement is unreachable remark.#177:1 func "marshal_write_mod" was declared but never referenced remark.#181:9 arg is incompatible w/corresponding format string conversion remark.#279: 862 controlling expression is constant remark.#593: 17 variable set, but not used remark.#869: 1317 parameter not used remark.#981: 130 operands are evaluated in unspecified order remark.#1469: 10 "cc" clobber ignored (wtf? use of htons() causes this msg) remark.#1572: 111 floating-point equality/inequality comparisons are unreliable remark.#1599: 30 declaration hides parameter Note there are a lot of warning even when we mask off the higher bits (e.g., x = y & 0xff still generats a warning if x is a char). 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] Compiler warnings for 64-bit portability problems
On 1/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > Cool. Thanks for the info. It would be nice if Intel would provide > Python developers with a permanent icc license for Python. Can anyone > help with that? I'll try. A dutch friend from long ago (CWI) is now working for Intel's compiler group and has tried to interest me in providing feedback about their compiler (and also their alternative to valgrind). I'll contact him. -- --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] ConfigParser to save with order
I think it's moot unless you also preserve comments. Ideally would be something that prserved everything (ordering, blank lines, comments etc.) from how it was read in. Modifying a value should keep its position. Adding a value should add it to the end of the section it's in (unless there are cases where ordering is important to the semantics -- are there?). --Guido On 1/7/06, Facundo Batista <[EMAIL PROTECTED]> wrote: > ConfigParser saves the data in a not-predefined order. This is because > it keeps, internally, the information in dictionaries. > > I opened a patch in SF 1399309 that orders the info to be saved in the > file through the ConfigParser write() method. > > This patch does not let the user to specify the order, but allows to > predict the order in which it'll be saved. > > There's another patch, the 1371075, that allows to specify the order > through an "ordered dict". > > What do we want ConfigParser to do? > > Regards, > > .Facundo > > Blog: http://www.taniquetil.com.ar/plog/ > PyAr: http://www.python.org/ar/ > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --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] Draft proposal: Implicit self in Python 3.0
On 1/6/06, Kay Schluehr <[EMAIL PROTECTED]> wrote: > Then simply reject the PEP and the discussion can be stopped on > comp.lang.python too. Only in the most severe cases does it make sense to create a PEP specifically to be rejected. > Or why do you think it should be discussed there > again and again or elsewhere on the web ( e.g. in Bruce Eckels blog on > Artima )? Perhaps because people don't understand it? -- --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] some interesting readings
Samuele Pedroni wrote: > because I was reminded of them recently, because they may be useful > landmarks in the prospective of future discussions, because expanding > one's understanding of the problem/solution space of language design > is quite a good thing if one is interested in such things... > > 1) > Gilad Bracha. Pluggable Type Systems . OOPSLA04 Workshop on Revival of > Dynamic Languages ( > http://pico.vub.ac.be/%7Ewdmeuter/RDL04/papers/Bracha.pdf ) > > As a talk: > Pluggable Types, originally given at Aarhus University in March 2003, > and repeated since at Berne and elsewhere. > ( http://bracha.org/pluggable-types.pdf ) > > 2) > http://homepages.cwi.nl/~ralf/OOHaskell/ > state of the art experiment on trying to reconcile object orientation, > type inference and as much as possible expressiveness > > PS: I think 1 is much more relevant than 2 for Python as we know it. I'd have to agree with that - I didn't actually make it all the way through the second one, but an awful of lot of what I did read seemed to taken up with clever workarounds designed to trick the Haskell type inferencer into letting the authors of the paper do some fairly basic things (like having a heterogeneous collection of subtypes). There are some fascinating ideas in the first paper, though. It actually had me wondering about the possibilities of PyPy's object spaces, but I don't really know enough about those to determine whether or not such a connection is actually meaningful. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] some interesting readings
At 02:01 PM 1/8/2006 +1000, Nick Coghlan wrote: >Samuele Pedroni wrote: > > 2) > > http://homepages.cwi.nl/~ralf/OOHaskell/ > > state of the art experiment on trying to reconcile object orientation, > > type inference and as much as possible expressiveness > > > > PS: I think 1 is much more relevant than 2 for Python as we know it. > >I'd have to agree with that - I didn't actually make it all the way through >the second one, but an awful of lot of what I did read seemed to taken up >with >clever workarounds designed to trick the Haskell type inferencer into letting >the authors of the paper do some fairly basic things (like having a >heterogeneous collection of subtypes). Yeah, I thought the second one was a really strong argument for *not* trying to transpose "traditional" OO code directly into Haskell, but rather focusing on polymorphic functions instead. In Python terms, functions like len() and copy() rather than focusing on building methods like __len__() and __copy__(). Since Haskell allows you to provide multiple definitions for a function based on matching types or values, there's really no point to trying to make actual methods. It seemed to me a lot like the whole "implicit self" argument; i.e., imposing a foreign paradigm on the language for familiarity's sake. ___ 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
