On Feb 15, 2007, at 2:59 PM, Raymond Hettinger wrote:
> * Enhance doctest with a method that computes updated doctest
> results. If the
> only change I make to a matrix suite is to add commas to long
> numbers in the
> matrix repr(), then it would be nice to have an automated way to
> update
Sorry, forgot to include the output of doctest_driver.py --help.
Here it is:
-Edward
Usage: doctest_driver.py [options] NAME ...
Options:
--version show program's version number and exit
-h, --helpshow this help message and exit
Actions (default=check):
Gregor Lingl wrote:
> Yes,, and I have some ideas in this respect, but mainly a prioncipal
> question. I read about
> using doctest and unittest, but how does one devise
> automatic test suites for graphical output. In the end it depends on how
> it looks like.
There are a few options here.. Tw
draconux wrote:
>
> Hello all ,
> string.lstrip("source/old_prog","source/") return "ld_prog" instead of
> "old_prog"
You are misunderstanding what the second argument to lstrip does. It is
interpreted as a list of characters; and lstrip will remove the maximal
prefix of the string that consi
Guido van Rossum wrote:
> On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote:
>> If for Python-3000 similar it will be shown concerning types
>> str(), int(), complex() and so on, and the type of exceptions
>> will strongly vary, it will make problematic redefinition of
>> behavior of fun
Steven Bethard wrote:
> On 5/7/06, Edward Loper <[EMAIL PROTECTED]> wrote:
>> Talin wrote:
>>> Braces can be escaped using a backslash:
>>>
>>> "My name is {0} :-\{\}".format('Fred')
>>>
>>> Which wo
Talin wrote:
> Braces can be escaped using a backslash:
>
> "My name is {0} :-\{\}".format('Fred')
>
> Which would produce:
>
> "My name is Fred :-{}"
Do backslashes also need to be backslashed then? If not, then what is
the translation of this:?
r'abc\{%s\}'
On May 6, 2006, at 2:40 AM, Nick Coghlan wrote:
> Remember, the idea with portable path information is to *never*
> store os.sep
> and os.extsep anywhere in the internal data - those should only be
> added when
> needed to produce strings to pass to OS-specific functions or to
> display to us
Brett Cannon wrote:
> The second question is whether it is worth providing a function that
> will either figure out if a tuple and dict representing arguments
> would work in calling the function. Some have even suggested a
> function that returns the actual bindings if the call were to occur.
>
Fredrik Lundh wrote:
>> And again, why would you *make* me, the user-programmer, type
>>
>> make_person(name=namex, age=agex, phone=phonex, location = locationx)
>> #instead of
>> make_person(namex,agex,phonex,locationx)
>> ?
>
> because a good API designer needs to consider more than just the cur
Fred L. Drake, Jr. wrote:
> On Sunday 30 April 2006 22:50, Edward Loper wrote:
> > I see two possible reasons:
>
> Another use case, observed in the wild:
>
>- An library function is written to take an arbitrary number of
> positional arguments using *args
Martin v. Löwis wrote:
> One reason I see is to have keyword-only functions, i.e. with no
> positional arguments at all:
>
> def make_person(*, name, age, phone, location):
> pass
>
> which also works for methods:
>
> def make_person(self, *, name, age, phone, location):
> pass
>
Terry Reedy wrote:
> There are two subproposals: first, keyword-only args after a variable
> number of positional args, which requires allowing keyword parameter
> specifications after the *args parameter, and second, keyword-only args
> after a fixed number number of positional args, implemente
Rudy Rudolph wrote:
> 2) pass-by-reference:
> def f(wrappedParam):
> wrappedParam[0] += 5 # ugh
> return "this is my result"
>
> # call it
> x = 2
> result = f([x])
> # also ugly, but x is now 7
This example is broken; here's what you get when you run it:
>
Nick Coghlan wrote:
> Edward Loper wrote:
>> This is incompatible with the recent proposal making str.join
>> automatically str-ify its arguments. i.e.:
>>
>>''.join(['a', 12, 'b']) -> 'a12b'.
>>
>> I don&#x
Josiah Carlson wrote:
> [...] get str.join to support objects which
> implement the buffer interface as one of the items in the sequence?
>
> Something like:
>
> y = 'hello world'
> buf1 = buffer(y, 0, 5)
> buf2 = buffer(y, 6)
> print ''.join([buf1, buf2])
>
> should print "h
Nick Coghlan wrote:
> OTOH, if the two protocols are made orthogonal, then it's clear that the
> manager is always the original object with the __context__ method. Then the
> three cases are:
>
> - a pure context manager (only provides __context__)
> - a pure managed context (only provides _
Tim Peters wrote:
> If extension modules in real life prove as sloppy as Python's
> front end, we'll have to revert the objimpl.h + pymem.h part of this
> patch. Note that no problems will show up in a debug build (all
> calls still go thru obmalloc then). Problems will show up on
Martin v. Löwis wrote:
> Edward C. Jones wrote:
>> The contents page for the Python Library Reference
>> ("http://docs.python.org/dev/lib/lib.html";) has become much too long.
>
> I disagree. It serves my purposes very well: I usually search in the
> page for a keywork I think should be there. If
Robey Pointer wrote:
On 30 Dec 2005, at 18:29, Christopher Armstrong wrote:
>> [epydoc] is not really even "good enough" for a lot of my usage without some
>> seriously evil hacks. The fundamental design decision of epydoc to
>> import code, plus some other design decisions on the way it figures
>>
> I had an idea this morning for a simple extension to Python's iterator
> protocol that would allow the user to force an iterator to raise
> StopIteration on the next call to next(). My thought was to add a new
> method to iterators called stop().
There's no need to change the iterator protocol
Michael Chermside wrote:
>> Right now, we say that there's one rule for all *normal* attributes
>> and
>> methods, and a slightly different rule for all double-underbar
>> methods.
Guido responded:
> But it's not normal vs. __xyzzy__. A specific set of slots (including
> next, but excluding thin
As I understand it, you want to improve the performance of interactively
run plot commands by queuing up all the plot sub-commands, and then
drawing them all at once. Hooking into a python event loop certainly
isn't the only way to do this. Perhaps you could consider the following
approach:
23 matches
Mail list logo
