Hey Michael,
On Thu, Nov 12, 2020 at 01:50:12PM +0100, Michael Felt wrote:
> Not clear on where to report this - so I hope someone else sees the same and
> can notify whoever needs to be notified.
There's a "Submit Website Bug" in the footer of the website, taking you
to the respective bugtracker
* R. David Murray [2015-08-27 15:00:40 -0400]:
> It is possible to create a "virtual" X on an otherwise headless linux
> system, but I've never tried to do it myself. If someone comes up
> with a recipe we could add it to the devguide chapter on running
> a buildbot.
It's usually as easy as inst
* Nikolaus Rath [2015-07-21 20:23:15 -0700]:
> On Jul 21 2015, Nick Coghlan wrote:
> > All of this is why the chart that I believe should be worrying people
> > is the topmost one on this page:
> > http://bugs.python.org/issue?@template=stats
> >
> > Both the number of open issues and the number
* Ron Adam [2015-07-20 12:57:08 -0400]:
> >It's "unsafe" because tests which:
> >
> >1) are using the assert_* methods of a mock, and
> >2) where the programmer did a typo (assert_called() instead of
> >assert_called_with() for example)
> >
> >do silently pass.
>
> And further down, you say..
* Ron Adam [2015-07-19 18:06:22 -0400]:
>
>
> On 07/19/2015 02:33 PM, Florian Bruhin wrote:
> >* Ron Adam [2015-07-19 11:17:10 -0400]:
> >>>I had to look at the source to figure out what this thread was really all
> >>>about.
>
> And it seems I d
* Ron Adam [2015-07-19 11:17:10 -0400]:
> I had to look at the source to figure out what this thread was really all
> about.
>
> Basically it looks to me the purpose of adding "assret" is to add an "alias
> check" for "unsafe" methods. It doesn't actually add an "alias". It allows
> a developer
* Steven D'Aprano [2015-07-14 23:41:56 +1000]:
> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
> > https://bugs.python.org/issue21238 introduces detection of
> > missing/misspelt mock.assert_xxx() calls on getattr level in Python
> > 3.5
> >
> > Michael and Kushal are of the opinio
* Nick Coghlan [2015-06-01 00:15:01 +1000]:
> On 31 May 2015 at 19:07, Ludovic Gasc wrote:
> > About Python 3 migration, I think that one of our best control stick is
> > newcomers, and by extension, Python trainers/teachers.
> > If newcomers learn first Python 3, when they will start to work
> >
* Mark Rosenblitt-Janssen [2015-05-10 11:34:52
-0500]:
> Here's something that might be wrong in Python (tried on v2.7):
>
> >>> class int(str): pass
>
> >>> int(3)
> '3'
What's so odd about this? "class int" is an assignment to "int", i.e.
what you're doing here is basically:
int = str
int(3
* Dima Tisnek [2015-04-30 13:41:53 +0200]:
> # lambda
> Not mentioned in the PEP, omitted for convenience or is there a rationale?
> f = lambda x: None if x is None else str(x ** 2)
> Current syntax seems to preclude annotation of `x` due to colon.
> Current syntax sort of allows lamba return type
* Wolfgang Langner [2015-04-23 10:43:52 +0200]:
> 2. Using it in the language as part of the function signature, my first
> thought was oh good, then I changed my mind
>to: oh it can be very ugly and unreadable, it is the wrong place.
>Now I am against it, best is, if I have to specify typ
* Zaur Shibzukhov [2015-03-17 22:29:07 +0300]:
> Yes... But I expected that dict constructor will use `__getitem__` or
> `items` method of MyDict instance in order to retrieve items of the MyDict
> instance during construction of the dict instance... Instead it interpreted
> MyDict instance as t
* lou xiao [2015-03-11 01:27:21 +0800]:
> I find a bug in str.lstrip, when i call str.lstrip, i get this result.
You're misunderstanding how str.strip works. It takes a set of
characters and removes them all from the beginning:
>>> "abababcd".lstrip('ab')
>>> 'cd'
Florian
--
http://ww
* Demian Brecht [2015-02-20 10:24:53 -0800]:
> These and other implementations return a string representation of the
> instance’s value, not a string representation of the object itself. Whereas
> elsewhere in the standard library:
>
> >>> str(ProtocolError('url', 42, 'msg', ''))
> '’
> >>> str
* Nikolaus Rath [2014-06-12 19:11:07 -0700]:
> "R. David Murray" writes:
> > Also notice that using a list with shell=True is using the API
> > incorrectly. It wouldn't even work on Linux, so that torpedoes
> > the cross-platform concern already :)
> >
> > This kind of confusion is why I opened
* anatoly techtonik [2014-06-12 02:00:55 +0300]:
> On Thu, Jun 12, 2014 at 1:30 AM, Chris Angelico wrote:
>
> > Why pass shell=True when executing a single
> > command? I don't get it.
> >
>
> I don't know about Linux, but on Windows programs are not directly
> available as /usr/bin/python, so
* Florian Bruhin [2014-04-25 16:22:06 +0200]:
> I noticed configparser does behave in a surprising way when a key
> has a special meaning in ini-format.
I've now submitted an issue here: http://bugs.python.org/issue21498
Florian
--
() ascii ribbon campaign - sto
Hi,
I noticed configparser does behave in a surprising way when a key
has a special meaning in ini-format.
Consider this example:
>>> cp = configparser.ConfigParser()
>>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>>> cp.write(sys.stdout)
[DEFAULT]
;foo = bar
Now when readin
18 matches
Mail list logo
