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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#54015

On Thu, Sep 12, 2013 at 10:25 AM, Mark Janssen
<dreamingforward@gmail.com> 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 ;)
>>
>> No, that's inaccurate. A sequence of bytes is binary data. Unicode is
>> not binary data.
>
> Well now, this is an area that is not actually well-defined.  I would
> say 16-bit Unicode is binary data if you're encoding in base 65,536,
> just as 8-bit ascii is binary data if you're encoding in base-256.
> Which is to say:  there is no intervening data to suggest a TYPE.

Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
word "encod[e]", which is the standard way to turn Unicode into bytes
anyway. No, a Unicode string is a series of codepoints - it's most
similar to a list of ints than to a stream of bytes.

ChrisA

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

#54027

On Thu, 12 Sep 2013 10:31:26 +1000, Chris Angelico wrote:

> On Thu, Sep 12, 2013 at 10:25 AM, Mark Janssen
> <dreamingforward@gmail.com> wrote:

>> Well now, this is an area that is not actually well-defined.  I would
>> say 16-bit Unicode is binary data if you're encoding in base 65,536,
>> just as 8-bit ascii is binary data if you're encoding in base-256.
>> Which is to say:  there is no intervening data to suggest a TYPE.
> 
> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
> word "encod[e]", which is the standard way to turn Unicode into bytes
> anyway. No, a Unicode string is a series of codepoints - it's most
> similar to a list of ints than to a stream of bytes.

And not necessarily ints, for that matter.

Let's be clear: the most obvious, simple, hardware-efficient way to 
implement a Unicode string holding arbitrary characters is as an array of 
32-bit signed integers restricted to the range 0x0 - 0x10FFFF. That gives 
you a one-to-one mapping of int <-> code point.

But it's not the only way. One could implement Unicode strings using any 
similar one-to-one mapping. Taking a leaf out of the lambda calculus, I 
might implement each code point like this:

NULL pointer <=> Code point 0
^NULL <=> Code point 1
^^NULL <=> Code point 2
^^^NULL <=> Code point 3

and so on, where ^ means "pointer to".

Obviously this is mathematically neat, but practically impractical. Code 
point U+10FFFF would require a chain of 1114111 pointer-to-pointer-to-
pointer before the NULL. But it would work. Or alternatively, I might 
choose to use floats, mapping (say) 0.25 <=> U+0376. Or whatever.

What we can say, though, is that to represent the full Unicode charset 
requires 21 bits per code-point, although you can get away with fewer 
bits if you have some out-of-band mechanism for recognising restricted 
subsets of the charset. (E.g. you could use just 7 bits if you only 
handled the characters in ASCII, or just 3 bits if you only cared about 
decimal digits.) In practice, computers tend to be much faster when 
working with multiples of 8 bits, so we use 32 bits instead of 21. In 
that sense, Unicode is a 32 bit character set.

But Unicode is absolutely not a 16 bit character set.

And of course you can use *more* bits than 21, or 32. If you had a 
computer where the native word-size was (say) 50 bits, it would make 
sense to use 50 bits per character.

As for the question of "binary data versus text", well, that's a thorny 
one, because really *everything* in a computer is binary data, since it's 
stored using bits. But we can choose to *interpret* some binary data as 
text, just as we interpret some binary data as pictures, sound files, 
video, Powerpoint presentations, and so forth. A reasonable way of 
defining a text file might be:

    If you decode the bytes making up an alleged text file into 
    code-points, using the correct encoding (which needs to be 
    known a priori, or stored out of band somehow), then provided 
    that none of the code-points have Unicode General Category Cc,
    Cf, Cs, Co or Cn (control, format, surrogate, private-use, 
    non-character/reserved), you can claim that it is at least 
    plausible that the file contains text.

Whether that text is meaningful is another story.

You might wish to allow Cf and possibly even Co (format and private-use), 
depending on the application.


-- 
Steven

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

#54028

In article <523127e2$0$29988$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> just 3 bits if you only cared about decimal digits.

That's a neat trick.

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

#54029

On Thu, Sep 12, 2013 at 12:43 PM, Roy Smith <roy@panix.com> wrote:
> In article <523127e2$0$29988$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> just 3 bits if you only cared about decimal digits.
>
> That's a neat trick.

It is! It's one of the fancy things we can do in the Land Downunder.
By the time we've dodged spiders, snakes, and Drop Bears, squeezing
ten options into three bits is easy!

Of course, we always keep a fourth bit lying around for when the
tourists come through. 33% extra profit when we sell them the
unnecessary spare bit.

ChrisA

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

#54033

On Wed, 11 Sep 2013 22:43:20 -0400, Roy Smith wrote:

> In article <523127e2$0$29988$c3e8da3$5496439d@news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
>> just 3 bits if you only cared about decimal digits.
> 
> That's a neat trick.

Well obviously it's compressed.

:-)


Sorry for the typo, I meant 4.


-- 
Steven

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

#54016

>> Why is this so difficult?
>> Add a Graph class to the collections module (networkx is quite good)
>> and simply check for circular imports.
>
> Er? That doesn't address the task of importing a module from a source
> code file given its path on the filesystem.

That's true, I guess was hooked on Python's abstraction mechanism for
making the file system invisible.  But I like the idea of programming
*relative* path addressing, so you can create a sort of "name space"
for your modules.  So instead of "import /path/to/file.py" which makes
a system dependency (i.e. *yours*), you could have "import
TestPackage.collections.bag" (using periods for file path separators
in keeping with the Pythonic Way).

-- 
MarkJ
Tacoma, Washington

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

#54017

> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
> word "encod[e]", which is the standard way to turn Unicode into bytes
> anyway. No, a Unicode string is a series of codepoints - it's most
> similar to a list of ints than to a stream of bytes.

Okay, now you're in blah, blah land.

--mark

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

#54018

On Thu, Sep 12, 2013 at 10:37 AM, Mark Janssen
<dreamingforward@gmail.com> wrote:
>> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
>> word "encod[e]", which is the standard way to turn Unicode into bytes
>> anyway. No, a Unicode string is a series of codepoints - it's most
>> similar to a list of ints than to a stream of bytes.
>
> Okay, now you're in blah, blah land.

Eh?

Apart from the grammatical oddity (artifact of editing - should be
"more similar" not "most similar"), I don't see anything wrong in what
I said there.

ChrisA

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

#54020

On Wed, Sep 11, 2013 at 5:37 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
>> Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
>> word "encod[e]", which is the standard way to turn Unicode into bytes
>> anyway. No, a Unicode string is a series of codepoints - it's most
>> similar to a list of ints than to a stream of bytes.
>
> Okay, now you're in blah, blah land.
>
> --mark
> --

There's no such thing as 16-bit Unicode. Unicode is a sequence of
characters, not a sequence of bytes. It's an abstract thing. To work
with it on a computer, you need to use a byte encoding because
computers don't deal with with abstract things. UTF-16 is one encoding
method that can map any character defined in Unicode to a sequence of
bytes. UTF-16 isn't Unicode, it's just a function that maps a byte
string to a character string. Python's unicode class is a character
string- as far as the user is concerned, it's made up of those
abstract "character" things and not bytes at all.

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

#54021

Mark Janssen <dreamingforward@gmail.com> writes:

> > Unicode is not 16-bit any more than ASCII is 8-bit. And you used the
> > word "encod[e]", which is the standard way to turn Unicode into bytes
> > anyway. No, a Unicode string is a series of codepoints - it's most
> > similar to a list of ints than to a stream of bytes.
>
> Okay, now you're in blah, blah land.

Text is (in the third millennium) Unicode.

Unicode text is not binary data and never will be.

Unicode text can be *encoded* to binary data, and that data can be
*decoded* back to Unicode text. The two are never the same thing.

You're demonstrating my point: the pernicious “text is binary data”
falsehood needs to be eradicated from everything today's programmers
learn. We need the simple facts about the basic difference between text
and bytes to be learned by every programmer as early as can feasible.

-- 
 \                   德不孤、必有鄰。 (The virtuous are not abandoned, |
  `\                               they shall surely have neighbours.) |
_o__)                             —孔夫子 Confucius, 551 BCE – 479 BCE |
Ben Finney

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

#54031

On 11 September 2013 11:38, 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]
>
> but it sure looks strange at first sight. As a bonus, it works on any
> iterable, not just ones that support __getitem__.

I very much enjoy the "[elt] = elts" spelling, although I don't get
how this is a "gotcha". It's just a semi-obscure usage of unpacking.

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

#54042 — Re: Please omit false legalese footers (was: Language design)

More likely, JP Morgan's mail system added that footer to the message
on the way out the virtual door. My recommendation would be to not
post using your company email address. Get a free email address.

Skip

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

#54044 — Re: Please omit false legalese footers (was: Language design)

On 12 September 2013 10:27, Skip Montanaro <skip@pobox.com> wrote:
>
> More likely, JP Morgan's mail system added that footer to the message
> on the way out the virtual door. My recommendation would be to not
> post using your company email address. Get a free email address.

It wouldn't surprise me if JPMorgan would block free email addresses on site.


Oscar

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

#54071

On 11.09.2013 23:15, Ethan Furman wrote:
> On 09/11/2013 01:41 PM, Markus Rother wrote:
>>      >>> () == []
>>      False
>>
>>      But:
>>
>>      >>> bool(().__eq__([]))
>>      True
> 
> This is not a trap, this is simply the wrong way to do it.  The magic
> methods (aka dunder methods) are there for Python to call, not you
> (except under special circumstances, such as when writing your own
> dunder methods).

While trying to do it, I learned that its not the right way to do it.
However, I was not satisfied with the fact, that there is no built in
pure function for operations on primitives.  Such that

>>> def get_do_stuff (fn):
...     def do_stuff(x,y):
...         return fn(x,y)
...     return do_stuff

I understand that python is not a functional language, but it
frustrates me at times.

Markus

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

#54072

On 2013-09-12, Markus Rother <python@markusrother.de> wrote:
> On 11.09.2013 23:15, Ethan Furman wrote:
>> On 09/11/2013 01:41 PM, Markus Rother wrote:
>>>      >>> () == []
>>>      False
>>>
>>>      But:
>>>
>>>      >>> bool(().__eq__([]))
>>>      True
>> 
>> This is not a trap, this is simply the wrong way to do it.  The magic
>> methods (aka dunder methods) are there for Python to call, not you
>> (except under special circumstances, such as when writing your own
>> dunder methods).
>
> While trying to do it, I learned that its not the right way to do it.
> However, I was not satisfied with the fact, that there is no built in
> pure function for operations on primitives.  Such that
>
>>>> def get_do_stuff (fn):
> ...     def do_stuff(x,y):
> ...         return fn(x,y)
> ...     return do_stuff
>
> I understand that python is not a functional language, but it
> frustrates me at times.

>>> import operator
>>> equal = get_do_stuff(operator.eq)(7, 7.0)
True

-- 
Neil Cerutti

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

#54073

On 12.09.2013 01:27, Chris Angelico wrote:
> On Thu, Sep 12, 2013 at 6:41 AM, Markus Rother <python@markusrother.de> wrote:
>>     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'
> 
> That's a policy decision: a method (or function) will *EITHER* return
> a value, *OR* mutate its primary argument (in the case of a method,
> that's self). 

You are stating: "All getters must be free of side effects".
That is not the case.  Furthermore, the demand for getters with hidden
side effects is the reasoning behind properties.

The policy could as well be: a method (not a function) will either
return a value, or return self, whether or not the object was mutated.

> Why should that be split into two statements? Or alternatively, why
> should an extra copy of the list be created (if you use Python's
> sorted() here)? But for the new programmer, this is a convenient
> safety-net, and if list.sort() worked the other way, it'd be just as
> much a gotcha ("I ask for a sorted list, and it also changed the
> original?!??").
I understand the point you are making in the end, in the interest of
having an easy to start with language.

Markus

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

#54074

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.

I have one more:

Dictionaries should iterate over their items instead of their keys.

Looking forward to contrary opinions.

Greets,
Markus

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

#54080

On 2013-09-12, Markus Rother <python@markusrother.de> wrote:
> 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.
>
> I have one more:
>
> Dictionaries should iterate over their items instead of their keys.
>
> Looking forward to contrary opinions.

Consider the 'in' operator.

-- 
Neil Cerutti

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

#54075

On 09/12/2013 10:51 AM, Markus Rother wrote:
> On 11.09.2013 23:15, Ethan Furman wrote:
>> On 09/11/2013 01:41 PM, Markus Rother wrote:
>>>       >>> () == []
>>>       False
>>>
>>>       But:
>>>
>>>       >>> bool(().__eq__([]))
>>>       True
>>
>> This is not a trap, this is simply the wrong way to do it.  The magic
>> methods (aka dunder methods) are there for Python to call, not you
>> (except under special circumstances, such as when writing your own
>> dunder methods).
>
> While trying to do it, I learned that its not the right way to do it.
> However, I was not satisfied with the fact, that there is no built in
> pure function for operations on primitives.  Such that
>
>>>> def get_do_stuff (fn):
> ...     def do_stuff(x,y):
> ...         return fn(x,y)
> ...     return do_stuff
>
> I understand that python is not a functional language, but it
> frustrates me at times.

--> import operator
--> operator.__all__  # public api methods are in __all__
['abs', 'add', 'and_', 'attrgetter', 'concat', 'contains', 'countOf', 'delitem', 'eq', 'floordiv', 'ge', 'getitem', 
'gt', 'iadd', 'iand', 'iconcat', 'ifloordiv', 'ilshift', 'imod', 'imul', 'index', 'indexOf', 'inv', 'invert', 'ior', 
'ipow', 'irshift', 'is_', 'is_not', 'isub', 'itemgetter', 'itruediv', 'ixor', 'le', 'length_hint', 'lshift', 'lt', 
'methodcaller', 'mod', 'mul', 'ne', 'neg', 'not_', 'or_', 'pos', 'pow', 'rshift', 'setitem', 'sub', 'truediv', 'truth', 
'xor']

Imports are a Good Thing; not everything has to be built in.

--
~Ethan~

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

#54077

On 9/12/13 2:24 PM, Markus Rother wrote:
> 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.
> I have one more:
>
> Dictionaries should iterate over their items instead of their keys.

I understand the natural desire for this, and I sometimes forget and 
have to add a ".items()" to my loops.  But if you consider how "in" 
should work with dicts, it's only reasonable that "k in d" examine if a 
key is in a dict, not if an item is in a dict.  And once you have "in" 
working like that, it's reasonable for iteration to work on keys.

Dicts act like collections of keys, each with an associated value.

--Ned.
> Looking forward to contrary opinions.
>
> Greets,
> Markus

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web