Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #53902 > unrolled thread

Language design

Back to article view | Back to comp.lang.python

Contents

  Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-10 06:09 +0000
    Re: Language design diverman <pavel@schon.cz> - 2013-09-09 23:59 -0700
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-10 17:07 +1000
      Re: Language design Nobody <nobody@nowhere.com> - 2013-09-11 01:03 +0100
        Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 00:53 +0000
          Re: Language design Nobody <nobody@nowhere.com> - 2013-09-12 18:23 +0100
    Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-10 09:58 +0200
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-10 20:20 +1000
    Re: Language design Chris Rebert <clp2@rebertia.com> - 2013-09-10 18:46 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-11 14:21 +1000
    Re: Language design Burak Arslan <burak.arslan@arskom.com.tr> - 2013-09-11 13:38 +0300
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-11 14:32 +0000
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 00:46 +1000
    Re: Language design Wayne Werner <wayne@waynewerner.com> - 2013-09-11 06:42 -0500
    Re: Language design Dave Angel <davea@davea.name> - 2013-09-11 12:05 +0000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-11 07:52 -0700
    Re: Language design Burak Arslan <burak.arslan@arskom.com.tr> - 2013-09-11 18:41 +0300
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-11 22:41 +0200
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 23:40 +0000
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 14:22 -0700
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 14:30 -0700
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-11 23:40 +0000
        Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:49 -0700
          Re: Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-12 05:33 +0000
            Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-12 20:23 -0700
              Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-13 05:08 +0000
                Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 17:39 +1000
                Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-14 19:37 -0700
                Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-15 09:57 +0200
        Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-11 21:40 -0400
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 11:41 +1000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-11 14:15 -0700
    RE: Language design "Prasad, Ramit" <ramit.prasad@jpmorgan.com.dmarc.invalid> - 2013-09-11 21:56 +0000
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:16 +1000
    Please omit false legalese footers (was: Language design) Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:22 +1000
      Re: Please omit false legalese footers (was: Language design) Grant Edwards <invalid@invalid.invalid> - 2013-09-12 20:12 +0000
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 09:27 +1000
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 09:19 +1000
    Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-11 19:51 -0400
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:25 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 10:31 +1000
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-12 02:33 +0000
        Re: Language design Roy Smith <roy@panix.com> - 2013-09-11 22:43 -0400
          Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 12:58 +1000
          Re: Language design Steven D'Aprano <steve@pearwood.info> - 2013-09-12 05:08 +0000
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:34 -0700
    Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-11 17:37 -0700
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-12 10:40 +1000
    Re: Language design Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-09-11 17:54 -0700
    Re: Language design Ben Finney <ben+python@benfinney.id.au> - 2013-09-12 10:57 +1000
    Re: Language design Joshua Landau <joshua@landau.ws> - 2013-09-12 05:17 +0100
    Re: Please omit false legalese footers (was: Language design) Skip Montanaro <skip@pobox.com> - 2013-09-12 04:27 -0500
    Re: Please omit false legalese footers (was: Language design) Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-09-12 10:44 +0100
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 19:51 +0200
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-12 18:06 +0000
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 20:13 +0200
    Re: Language design Markus Rother <python@markusrother.de> - 2013-09-12 20:24 +0200
      Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-12 19:18 +0000
    Re: Language design Ethan Furman <ethan@stoneleaf.us> - 2013-09-12 11:05 -0700
    Re: Language design Ned Batchelder <ned@nedbatchelder.com> - 2013-09-12 14:37 -0400
    Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-12 14:46 -0400
    Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 07:53 +1000
    Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-13 09:04 +0200
      Re: Language design Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-09-13 10:13 +0000
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-13 21:16 +1000
        Re: Language design Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-09-13 13:28 +0200
        Re: Language design Terry Reedy <tjreedy@udel.edu> - 2013-09-13 15:32 -0400
        Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-14 09:57 +1000
          Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 14:57 +0000
            Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-19 01:02 +1000
              Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 15:08 +0000
                Re: Language design Chris Angelico <rosuav@gmail.com> - 2013-09-19 01:12 +1000
                Re: Language design William Ray Wing <wrw@mac.com> - 2013-09-18 12:58 -0400
                  Re: Language design wxjmfauth@gmail.com - 2013-09-18 10:45 -0700
                    Re: Language design Neil Cerutti <neilc@norwich.edu> - 2013-09-18 17:55 +0000
        Re: Language design Mark Janssen <dreamingforward@gmail.com> - 2013-09-13 17:28 -0700
        Re: Language design Vito De Tullio <vito.detullio@gmail.com> - 2013-09-14 07:25 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#53902 — Language design

Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of 
Perl":

http://www.perl.com/doc/FMTEYEWTK/versus/perl.html


What design mistakes, traps or gotchas do you think Python has? Gotchas 
are not necessarily a bad thing, there may be good reasons for it, but 
they're surprising.

To get started, here are a couple of mine:


- Python is so dynamic, that there is hardly anything at all that can be 
optimized at compile time.

- The behaviour of mutable default variables is a gotcha.

- Operators that call dunder methods like __add__ don't use the same 
method resolution rules as regular methods, they bypass the instance and 
go straight to the type, at least for new-style classes.



-- 
Steven

[toc] | [next] | [standalone]

#53905

No exactly bad, but can suprise

>>> foo=([],)
>>> foo[0] += ['bar']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> foo
(['bar'],)



Dne úterý, 10. září 2013 8:09:25 UTC+2 Steven D'Aprano napsal(a):
> Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of 
> 
> Perl":
> 
> 
> 
> http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
> 
> 
> 
> 
> 
> What design mistakes, traps or gotchas do you think Python has? Gotchas 
> 
> are not necessarily a bad thing, there may be good reasons for it, but 
> 
> they're surprising.
> 
> 
> 
> To get started, here are a couple of mine:
> 
> 
> 
> 
> 
> - Python is so dynamic, that there is hardly anything at all that can be 
> 
> optimized at compile time.
> 
> 
> 
> - The behaviour of mutable default variables is a gotcha.
> 
> 
> 
> - Operators that call dunder methods like __add__ don't use the same 
> 
> method resolution rules as regular methods, they bypass the instance and 
> 
> go straight to the type, at least for new-style classes.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

[toc] | [prev] | [next] | [standalone]

#53907

Steven D'Aprano <steve@pearwood.info> writes:

> What design mistakes, traps or gotchas do you think Python has?

* Imports are fiendishly complex, hidden below deceptively simple
  syntax.

  It's a reasonable expectation that one can import a module from a
  source code file given its path on the filesystem, but this turns out
  to be much more complicated than in many other languages.

  There are reasons for this, some good, some merely historical baggage,
  some workarounds for OS misdesign, and some that may be Python's own
  mistakes. Those reasons are difficult to appreciate when first
  encountering the problem.

* Somewhat related, and not really part of language design: The import
  mechanism and the packaging tools are woefully behind the state of the
  art in getting applications and their libraries to cooperate with
  operating system package management.

  This has the terrible effect that developers choose to insulate Python
  from the operating system, essentially losing all the benefits of the
  operating system package manager for their dependencies and needing to
  re-implement package management all over again, badly.

  This is largely the fault of operating systems with package dependency
  managers that are poor (Apple's) to nonexistent (Microsoft's). But the
  result is that Python's tools have been particularly woeful in this
  area compared to some other languages, and the Python community now
  has learned to subvert all OS package managers, even the good ones.

> Gotchas are not necessarily a bad thing, there may be good reasons for
> it, but they're surprising.

* Python requires every programmer to know, or quickly learn, the basics
  of Unicode: to know that text is not, and never will be again,
  synonymous with a sequence of bytes.

  This is, in the long run, a good thing for all programmers and those
  who will use their programs. Programmers should expect to deal with
  non-ASCII text earlier than the innocent might suppose, and the
  likelihood goes up all the time. The sooner we replace the erroneous
  “text is ASCII” in the common wisdom with “text is Unicode”, the
  better.

  Nevertheless, the outstanding robustness of Python's Unicode support
  is different from most languages, and so is a gotcha.

-- 
 \      “Life does not cease to be funny when people die any more than |
  `\  it ceases to be serious when people laugh.” —George Bernard Shaw |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#53933

On Tue, 10 Sep 2013 17:07:09 +1000, Ben Finney wrote:

> * Python requires every programmer to know, or quickly learn, the basics
>   of Unicode: to know that text is not, and never will be again,
>   synonymous with a sequence of bytes.

If only the Python developers would learn the same lesson ...

Some of them are so hooked on Unicode that they won't accept that
sometimes a sequence of bytes really is just a sequence of bytes. Primary
example: most of the POSIX API.

[toc] | [prev] | [next] | [standalone]

#53935

On Wed, 11 Sep 2013 01:03:48 +0100, Nobody wrote:

> On Tue, 10 Sep 2013 17:07:09 +1000, Ben Finney wrote:
> 
>> * Python requires every programmer to know, or quickly learn, the
>> basics
>>   of Unicode: to know that text is not, and never will be again,
>>   synonymous with a sequence of bytes.
> 
> If only the Python developers would learn the same lesson ...
> 
> Some of them are so hooked on Unicode that they won't accept that
> sometimes a sequence of bytes really is just a sequence of bytes.
> Primary example: most of the POSIX API.

And lo, Guido's Time Machine strikes again. Python 3 has not one but TWO 
built-in types for handling sequences of bytes:

* bytes  # immutable string of bytes
* bytearray  # mutable array of bytes


and most routines that handle file names accept either text strings or 
bytes strings:


py> open('aß', 'w').write("hello\n")
6
py> open(b'a\xc3\x9f', 'r').read()
'hello\n'



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#54070

On Wed, 11 Sep 2013 00:53:53 +0000, Steven D'Aprano wrote:

> and most routines that handle file names accept either text strings or 
> bytes strings:

I was going to say "that just leaves environ and argv". But I see that
os.environb was added in 3.2. Which just leaves argv.

[toc] | [prev] | [next] | [standalone]

#53910

Op 10-09-13 08:09, Steven D'Aprano schreef:
> Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of 
> Perl":
> 
> http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
> 
> 
> What design mistakes, traps or gotchas do you think Python has? Gotchas 
> are not necessarily a bad thing, there may be good reasons for it, but 
> they're surprising.
> 
> To get started, here are a couple of mine:
> 
> 
> - Python is so dynamic, that there is hardly anything at all that can be 
> optimized at compile time.
> 
> - The behaviour of mutable default variables is a gotcha.
> 
> - Operators that call dunder methods like __add__ don't use the same 
> method resolution rules as regular methods, they bypass the instance and 
> go straight to the type, at least for new-style classes.

Slice semantics in combination with negative indices.

Take ls = range[10]

What is the reverse of ls[a : b]? It is [b-1 : a-1: -1]

Except of course when a == 0 or b == 0.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#53912

On Tue, Sep 10, 2013 at 4:09 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.

Significant indentation. It gets someone every day, it seems.

The fact that importing twice doesn't reexecute any code.

The whole "consenting adults" philosophy. I happen to quite like it,
as do many of the regulars here, but it does trip up a lot of
programmers who've come from other languages.

Like you say, not necessarily a bad thing; but Admiral Ackbars all the same.

ChrisA

[toc] | [prev] | [next] | [standalone]

#53936

* No explicit variable declarations (modulo `global`+`nonlocal`) means
that variable name typos can't be reliably detected at compile-time.
* The value of the loop variable at call-time for functions defined
within a loop trips people up.
* No self-balancing tree datatype of any kind is included in the std lib.
* Function scope rather than block scope (e.g. `while` doesn't
introduce a new scope) [Personally, I don't have much of a problem
with this, but some people do.]
* No anonymous block syntax (cf. Ruby or Smalltalk). Makes it
harder/uglier to define/use custom control structures. The `with`
statement would have been unnecessary.

Cheers,
Chris


On Mon, Sep 9, 2013 at 11:09 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> Some time ago, Tom Christiansen wrote about the "Seven Deadly Sins of
> Perl":
>
> http://www.perl.com/doc/FMTEYEWTK/versus/perl.html
>
>
> What design mistakes, traps or gotchas do you think Python has? Gotchas
> are not necessarily a bad thing, there may be good reasons for it, but
> they're surprising.
>
> To get started, here are a couple of mine:
>
>
> - Python is so dynamic, that there is hardly anything at all that can be
> optimized at compile time.
>
> - The behaviour of mutable default variables is a gotcha.
>
> - Operators that call dunder methods like __add__ don't use the same
> method resolution rules as regular methods, they bypass the instance and
> go straight to the type, at least for new-style classes.
>
>
>
> --
> Steven
> --
> https://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#53942

On Wed, Sep 11, 2013 at 11:46 AM, Chris Rebert <clp2@rebertia.com> wrote:
> * The value of the loop variable at call-time for functions defined
> within a loop trips people up.

Related: The confusion of 'with' vs __del__ vs del wrt open files etc.
Using 'with' does not guarantee the object's destruction, but the
destruction of the object and the exiting of the with block do have
the same effect, which is confusing. Personally, I'd prefer a
guarantee that this name expires at this point, plus a guarantee that
- if there are no other references - the object will be cleaned up
immediately; it's generally true in CPython, and if that could
actually be made a language feature, there'd be no need for 'with' and
no issues with confusing people.

ChrisA

[toc] | [prev] | [next] | [standalone]

#53949

On 09/10/13 09:09, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has? 

My favourite gotcha is this:

    elt, = elts

It's a nice and compact way to do both:

    assert len(elts) == 0
    elt = elts[0]

but it sure looks strange at first sight. As a bonus, it works on any
iterable, not just ones that support __getitem__.

burak

[toc] | [prev] | [next] | [standalone]

#53968

On 2013-09-11, Burak Arslan <burak.arslan@arskom.com.tr> wrote:
> On 09/10/13 09:09, Steven D'Aprano wrote:
>> What design mistakes, traps or gotchas do you think Python has? 
>
> My favourite gotcha is this:
>
>     elt, = elts
>
> It's a nice and compact way to do both:
>
>     assert len(elts) == 0
>     elt = elts[0]

I'm confused. Your rewrite looks like an assertion error or an
IndexError.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#53969

On Thu, Sep 12, 2013 at 12:32 AM, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-09-11, Burak Arslan <burak.arslan@arskom.com.tr> wrote:
>> My favourite gotcha is this:
>>
>>     elt, = elts
>>
>> It's a nice and compact way to do both:
>>
>>     assert len(elts) == 0
>>     elt = elts[0]
>
> I'm confused. Your rewrite looks like an assertion error or an
> IndexError.

Presumably he meant to assert that the length is 1. If elts is a list,
then yes, these are equivalent, though the expanded form is actually a
bit different (since any iterable can be used).

ChrisA

[toc] | [prev] | [next] | [standalone]

#53952

[Multipart message — attachments visible in raw view] — view raw

On Tue, 10 Sep 2013, Ben Finney wrote:
>  The sooner we replace the erroneous
>  “text is ASCII” in the common wisdom with “text is Unicode”, the
>  better.

I'd actually argue that it's better to replace the common wisdom with 
"text is binary data, and we should normally look at that text through 
Unicode eyes". A little less catchy, but more accurate ;)

-W

[toc] | [prev] | [next] | [standalone]

#53954

On 11/9/2013 07:42, Wayne Werner wrote:

> On Tue, 10 Sep 2013, Ben Finney wrote:
>>  The sooner we replace the erroneous
>>  “text is ASCII” in the common wisdom with “text is Unicode”, the
>>  better.
>
> I'd actually argue that it's better to replace the common wisdom with 
> "text is binary data, and we should normally look at that text through 
> Unicode eyes". A little less catchy, but more accurate ;)
>
> -W
>

"Text is unicode, but text files are binary, and need to be decoded on
read, and encoded on write.  Most other external textual data is also
binary, and similarly need to be converted before use"

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#53973

On 09/11/2013 03:38 AM, Burak Arslan wrote:
> On 09/10/13 09:09, Steven D'Aprano wrote:
>> What design mistakes, traps or gotchas do you think Python has?
>
> My favourite gotcha is this:
>
>      elt, = elts
>
> It's a nice and compact way to do both:
>
>      assert len(elts) == 0

Perhaps you meant 'assert len(elts) == 1' ?

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#53974

On 09/11/13 17:52, Ethan Furman wrote:
> On 09/11/2013 03:38 AM, Burak Arslan wrote:
>> On 09/10/13 09:09, Steven D'Aprano wrote:
>>> What design mistakes, traps or gotchas do you think Python has?
>>
>> My favourite gotcha is this:
>>
>>      elt, = elts
>>
>> It's a nice and compact way to do both:
>>
>>      assert len(elts) == 0
>
> Perhaps you meant 'assert len(elts) == 1' ?
>

yes :)

[toc] | [prev] | [next] | [standalone]

#53995

Hello all,

Thanks for this thread.  Here are my two cents...

On 10.09.2013 08:09, Steven D'Aprano wrote:
> What design mistakes, traps or gotchas do you think Python has? Gotchas 
> are not necessarily a bad thing, there may be good reasons for it, but 
> they're surprising.

    """
    1. Occasionally, one encounters a strange idiom.  Syntactically
    legal and consistent, though:

    >>> +4++4
    8
    >>> -4+-4
    -8
    >>> -4-+4
    -8


    2. Reduce removed from standard library.  That is a big fail, in
    my opinion.


    3. The default return value of methods is None instead of self.
    If it was self, it would be possible to chain method calls (which
    is called a cascade in smalltalk).


    >>> lst = []
    >>> lst.append(1).append(2).append(3) ## FAIL
    Traceback (most recent call last):
    ...
    AttributeError: 'NoneType' object has no attribute 'append'


    Instead, this works:


    >>> class Coll(list):
    ...
    ...     def add(self, e):
    ...         self.append(e)
    ...         return self
    ...
    >>> lst = Coll()
    >>> lst.add(1).add(2).add(3) ## OK
    [1, 2, 3]


    A very practical use case is, that the return value of None makes
    all of these methods unusable for reduce.


    >>> from functools import reduce
    ...
    >>> many = [{1: 'a'}, {2: 'b'}, {3: 'c'}]
    ...
    >>> reduce(lambda d, other : d.update(other), many, {}) ## FAIL
    Traceback (most recent call last):
    ...
    AttributeError: 'NoneType' object has no attribute 'update'


    Again, one would have to define an update function with an
    explicit return value.

    >>> many = [{1: 'a'}, {2: 'b'}, {3: 'c'}]
    ...
    >>> def fn(d, other):
    ...     d.update(other)
    ...     return d
    ...
    >>> reduce(fn, many, {}) ## OK
    {1: 'a', 2: 'b', 3: 'c'}


    4. As has been mentioned already, some built-in functions do magic
    stuff behind the scenes:


    >>> () == []
    False


    But:


    >>> bool(().__eq__([]))
    True


    Because:


    >>> ().__eq__([])
    NotImplemented


    which yields True when cast to boolean.
    """

Greets,
Markus

[toc] | [prev] | [next] | [standalone]

#54009

On Wed, 11 Sep 2013 22:41:50 +0200, Markus Rother wrote:

>     2. Reduce removed from standard library.  That is a big fail, in my
>     opinion.

And Guido's Time Machine strikes again!


py> from functools import reduce
py> reduce
<built-in function reduce>




[...]
>     4. As has been mentioned already, some built-in functions do magic
>     stuff behind the scenes:
> 
>     >>> () == []
>     False
> 
> 
>     But:
> 
> 
>     >>> bool(().__eq__([]))
>     True
> 
> 
>     Because:
> 
> 
>     >>> ().__eq__([])
>     NotImplemented
> 
> 
>     which yields True when cast to boolean. """

I don't see that this is a gotcha, let alone a design mistake. There's no 
reason to be calling __eq__ directly instead of == but if you do, you're 
responsible for handling the operator protocol yourself. Namely, if the 
operator special method returns NotImplemented, you're supposed to 
reverse the operands and try again.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#53998

> * Imports are fiendishly complex, hidden below deceptively simple
>   syntax.
>
>   It's a reasonable expectation that one can import a module from a
>   source code file given its path on the filesystem, but this turns out
>   to be much more complicated than in many other languages.

Why is this so difficult?  Add a Graph class to the collections module
(networkx is quite good) and simply check for circular imports.  The
remaining difficulty I encounter is because the user hasn't defined
their PYTHONPATH variable.

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web