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 relevan
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...
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
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
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 grou
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
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 wo
[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
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 T
[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
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,
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
12 matches
Mail list logo
