> [I think >> = ChrisA]
>>> However, it doesn't matter.
>> Of course it matters. It's the difference between changing the spec and
>> changing the spec AND some implementation. There is a difference between
>> those two things. You might not care but that's another topic.
>
> In terms of
In response to my problem-solution pair (fixing a typo)
> TITLE: Debug print() statements cause doctests to fail
Rhodri James wrote:
> Or write your debug output to stderr?
Perhaps I've been too concise. If so, I apologise. My proposal is that
the system be set up so that
debug(a, b, c)
On 04/10/18 18:41, Jonathan Fine wrote:
TITLE:
PROBLEM: Debug print() statements cause doctests to fail
Adding debug print(...) statements to code can cause doctests to fail.
This is because both use sys.stdout as the output stream.
POSSIBLE SOLUTION:
Provide and use a special stream for debug
Hi Steven
On 10/04/2018 12:32 AM, Steven D'Aprano wrote:
On Wed, Oct 03, 2018 at 10:29:45PM +0200, Marcus Harnisch wrote:
When trying to import lzma on one of my machines, I was suprised to get
a normal import error like for any other module. According to the docs
lzma has been part of stdlib
On Wed, Oct 3, 2018 at 3:28 AM Eric V. Smith wrote:
>
> Here’s the idea: for f-strings, we add a !d conversion operator, which
> is superficially similar to !s, !r, and !a. The meaning of !d is:
> produce the text of the expression (not its value!), followed by an
> equal sign, followed by the
TITLE:
PROBLEM: Debug print() statements cause doctests to fail
Adding debug print(...) statements to code can cause doctests to fail.
This is because both use sys.stdout as the output stream.
POSSIBLE SOLUTION:
Provide and use a special stream for debug output. In other words,
something like
Hello all
I think we've established enough basic facts for now, about using a
non-identifier string as a keyword in a kwargs dictionary.
I'd be most grateful if discussion of this particular topic could be
suspended for now, to be resumed when it again becomes relevant.
If you are keen to
On Thu, 4 Oct 2018 08:32:55 +1000
Steven D'Aprano wrote:
>
> > Also, maybe add a little note in the docs, stating that despite being
> > part of stdlib this module might not be available on all systems.
>
> That should be uncontroversial. Raise an issue on the bug tracker for
> that, or a
On 10/04/2018 06:51 PM, Antoine Pitrou wrote:
I don't know. Realistically, any decent distributor of Python
should include those optional modules, and I don't remember
encountering a Python that doesn't has them.
What is the point, then, of making these packages optional in the first
place?
[Tim]
>
> > Note that transforming
> >
> > {EXPR!d:FMT}
> >
> > into
> >
> > EXPR={repr(EXPR):FMT}
> >
> > is actually slightly more involved than transforming it into
> >
> > EXPR={EXPR:FMT}
> >
> > so I don't buy the argument that the original idea is simpler. More
> > magical and
Good morning,
I read about a "time machine" debugger a long time ago. The debugger
would collect all the information of all the calls and the programmer
can just execute the code without breakpoints. Later, the programmer can
follow the evolution of a variable until it reaches an erroneous
> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work
> in very old versions?
> I'm not saying that this is important, because language changes always are
> for new versions. However, Anders' claim that this not a language change
> seemed too broad to me.
> It may be
On Thu, Oct 4, 2018 at 6:33 PM Anders Hovmöller wrote:
>
>
> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work
> in very old versions?
> I'm not saying that this is important, because language changes always are
> for new versions. However, Anders' claim that this
On 10/3/2018 8:47 PM, Tim Peters wrote:
Note that transforming
{EXPR!d:FMT}
into
EXPR={repr(EXPR):FMT}
is actually slightly more involved than transforming it into
EXPR={EXPR:FMT}
so I don't buy the argument that the original idea is simpler. More
magical and less useful, yes
>> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it
>> work in very old versions?
>> I'm not saying that this is important, because language changes always are
>> for new versions. However, Anders' claim that this not a language change
>> seemed too broad to me.
>> It
On 04/10/18 13:27, Anders Hovmöller wrote:
[I think >> = ChrisA]
However, it doesn't matter.
Of course it matters. It's the difference between changing the spec and
changing the spec AND some implementation. There is a difference between those
two things. You might not care but that's another
16 matches
Mail list logo
