Hello,
Are they bugs in the Python docs or just some CPython implementation
details that are purposely not documented? (but then, again, some of
the docs seem to be at least not precise...):
In https://docs.python.org/3.4/reference/datamodel.html#object.__eq__
there is the statement:
> There are
07.07.2014 18:11, Andreas Maier wrote:
Am 07.07.2014 17:58, schrieb Xavier Morel:
On 2014-07-07, at 13:22 , Andreas Maier
wrote:
While discussing Python issue #12067
(http://bugs.python.org/issue12067#msg222442), I learned that Python
3.4 implements '==' and '!=' on the object type such
23.02.2014 19:51, Stefan Behnel wrote:
I see a risk of interfering with in-place assignment operators, e.g.
x /= y except ZeroDivisionError: 1
might not do what one could expect, because (as I assume) it would
behave
differently from
x = x / y except ZeroDivisionError: 1
[snip]
Pl
21.02.2014 18:37, Guido van Rossum wrote:
I'm put off by the ':' syntax myself (it looks to me as if someone
forgot a newline somewhere)
As I mentioned at python-ideas I believe that parens neutralize,
at least to some extent, that unfortunate statement-ish flavor
of the colon.
This one has s
16.01.2014 17:33, Michael Urman wrote:
On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon
wrote:
Fine, if you're worried about bytes.format() overstepping by
implicitly
calling str.encode() on the return value of __format__() then you
will need
__bytes__format__() to get equivalent support.
Cou
17.11.2013 23:05, Guido van Rossum wrote:
The correct rule should be "don't use assert (the statement) to check
for valid user input" and the stated reason should be that the assert
statement was *designed* to be disabled globally, not to be a
shorthand for "if not X: raise (mumble) Y". A coroll
24.09.2013 10:16, Antoine Pitrou wrote:
On Tue, 24 Sep 2013 18:06:15 +1000
Nick Coghlan wrote:
How is it wrong? At the point where the interpreter says "This
exception is now unraisable", what, precisely, is it saying that is
wrong?
It isn't saying "this has never been raised". It is saying,
Is '__locallookup__' a really good name? In Python, *local* --
especially in context of *lookups* -- usually associates with locals()
i.e. a namespace of a function/method execution frame or a namespace of
a class, during *definition* of that class... So '__locallookup__' can
be confusing.
Wh
23.07.2013 00:01, Gregory P. Smith wrote:
On Mon, Jul 22, 2013 at 2:44 PM, Ben North
wrote:
A friend of mine, Ruadhan O'Flanagan, came across a bug which turned
out
to be the one noted in [http://bugs.python.org/issue18019 [1]],
i.e.:
>>> d={}
>>> d[42]=d.viewvalues()
>>> d
This issue h
Guido van Rossum wrote:
> we'd like to be able to define methods for the enum values, and the simplest
> way (for the user) to define methods for the enum values would be to allow
> def statements, possibly decorated, in the class. But now the implementation
> has to draw a somewhat murky line
11.02.2013 23:29, Nick Coghlan wrote:
3. I'm trying to avoid any custom magic specific to this method, but
making it implicitly a static or class method is fairly easy if we so
choose - the standard retrieval code during class creation can just
bypass the descriptor machinery, and wrap it in sta
Hello,
In http://docs.python.org/release/3.2.3/reference/expressions.html#in
we read: "[...] This can create the illusion of non-transitivity between
supported cross-type comparisons and unsupported comparisons. For
example, Decimal(2) == 2 and 2 == float(2) but Decimal(2) != float(2)."
(The
Terry Reedy dixit (2012-06-05, 12:42):
> On 6/5/2012 8:09 AM, nick.coghlan wrote:
>
> > Add PEP 422: Dynamic Class Decorators
[snip]
> >+So too will the following be roughly equivalent (aside from inheritance)::
> >+
> >+class C:
> >+__decorators__ = [deco2, deco1]
>
> I think you
Paul Moore dixit (2012-04-17, 08:14):
> On 16 April 2012 17:10, Nam Nguyen wrote:
> > PEP 8 suggests no extra spaces after and before square brackets, and
> > colons. So code like this is appropriate:
> >
> > a_list[1:3]
> >
> > But I find it less readable in the case of:
> >
> > a_list[pos + 1:-
Nick Coghlan dixit (2010-12-13, 23:25):
> Function arguments are not lists. Even when separated onto multiple
> lines, the closing "):" should remain on the final line with other
> content.
Not necessarily, IMHO.
1.
What about my example with '-> xxx' return-value annotation? (especially
when th
Dear Python Developers,
It is s my first post to python-dev, so let me introduce myself briefly:
Jan Kaliszewski, programmer and composer, sometimes also NGO activist.
Coming to the matter... The discussion started with remark by Mark
Dickinson about such a syntax oddity:
> def f(a
16 matches
Mail list logo
