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

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

Commonly-used names in the Python standard library

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

Contents

  Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-20 20:39 +1100
    Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-20 12:22 +0200
      Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-20 21:43 +1100
        Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-20 13:28 +0200
          Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-20 22:37 +1100
          Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-20 22:47 +1100
            Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-20 14:09 +0200
              Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-20 23:19 +1100
                Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-20 14:46 +0200
                  Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 00:34 +1100
                    Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-20 17:14 +0200
                      Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 02:48 +1100
                        Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-20 18:26 +0200
                          Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 03:36 +1100
                          Re: Commonly-used names in the Python standard library 88888 Dihedral <dihedral88888@gmail.com> - 2014-02-21 12:57 -0800
                  Re: Commonly-used names in the Python standard library Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-21 06:49 +0000
              Re: Commonly-used names in the Python standard library Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-21 06:43 +0000
      Re: Commonly-used names in the Python standard library Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-21 06:59 +0000
        Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 18:10 +1100
        Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-21 09:21 +0200
          Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 19:21 +1100
            Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-21 12:26 +0200
              Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 21:49 +1100
                Re: Commonly-used names in the Python standard library Marko Rauhamaa <marko@pacujo.net> - 2014-02-21 14:03 +0200
                  Re: Commonly-used names in the Python standard library Ethan Furman <ethan@stoneleaf.us> - 2014-02-21 11:16 -0800
          Re: Commonly-used names in the Python standard library Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-21 09:12 +0000
    Re: Commonly-used names in the Python standard library Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-02-21 06:51 +0000
      Re: Commonly-used names in the Python standard library Chris Angelico <rosuav@gmail.com> - 2014-02-21 18:02 +1100

Page 2 of 2 — ← Prev page 1 [2]

#66812

On Fri, Feb 21, 2014 at 6:21 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info>:
>
>> On Thu, 20 Feb 2014 12:22:29 +0200, Marko Rauhamaa wrote:
>>> I'm looking forward to the day when every application can add its own
>>> keywords as is customary in Lisp.
>>
>> And what a wonderful day that will be! Reading any piece of code you
>> didn't write yourself -- or wrote a long time ago -- will be an
>> adventure! Every script will have it's own exciting new set of
>> keywords doing who knows what, which makes every script nearly it's
>> own language! Oh joy, I cannot wait!
>>
>> That's sarcasm, by the way.
>
> I don't hear Lispers or C programmers complaining. Yes, you can shoot
> yourself in the foot with macro trickery, but macros can greatly enhance
> code readability and remove the need for code generators. That's why
> they are used extensively in Linux kernel code and GOOPS (Guile's object
> system), for example.

How does C let you create new keywords?

ChrisA

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

#66823

Chris Angelico <rosuav@gmail.com>:

> How does C let you create new keywords?

With #define. Nowhere near as elegant (flexible, hygienic) as in Lisp,
but used to create new syntax:

  include/linux/list.h:
    #define list_for_each(pos, head) \
            for (pos = (head)->next; pos != (head); pos = pos->next)

  include/linux/wait.h:
    #define __wait_event_interruptible(wq, condition, ret)                  \
    do {                                                                    \
            DEFINE_WAIT(__wait);                                            \
                                                                            \
            for (;;) {                                                      \
                    prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE);      \
                    if (condition)                                          \
                            break;                                          \
                    if (!signal_pending(current)) {                         \
                            schedule();                                     \
                            continue;                                       \
                    }                                                       \
                    ret = -ERESTARTSYS;                                     \
                    break;                                                  \
            }                                                               \
            finish_wait(&wq, &__wait);                                      \
    } while (0)

In the latter example, note how "condition" is embedded in the middle of
the macro and evaluated repeatedly.


Marko

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

#66824

On Fri, Feb 21, 2014 at 9:26 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> How does C let you create new keywords?
>
> With #define. Nowhere near as elegant (flexible, hygienic) as in Lisp,
> but used to create new syntax:

That can't create new syntax, though. All it can do is create a thing
that looks like a symbol or a function call and plonks a bit of code
in at that point. That's all. It's more akin to creating a function
that's able to work with blocks of unexecuted code.

ChrisA

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

#66828

Chris Angelico <rosuav@gmail.com>:

> On Fri, Feb 21, 2014 at 9:26 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> With #define. Nowhere near as elegant (flexible, hygienic) as in
>> Lisp, but used to create new syntax:
>
> That can't create new syntax, though. All it can do is create a thing
> that looks like a symbol or a function call and plonks a bit of code
> in at that point. That's all. It's more akin to creating a function
> that's able to work with blocks of unexecuted code.

Exactly! Lisp functions and macros (including special forms) are closely
related. The whole scheme (no pun intended) is so attractive because of
the S expression "supersyntax." A "while" macro is syntactically no
different from a "while" function. A macro is a "function" whose
automatic argument evaluation is disabled; the macro "function" gets the
ASTs of the arguments as input. A macro can always simulate a function
but not the other way round.

With the addition of macros, Python would become a (remote) Lisp
dialect. Defining macros would become more complicated because of
Python's more complex "supersyntax."


Marko

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

#66844

On 02/21/2014 04:03 AM, Marko Rauhamaa wrote:
>
> With the addition of macros, Python would become a (remote) Lisp
> dialect. Defining macros would become more complicated because of
> Python's more complex "supersyntax."

Have you tried MacroPy?  If not, you should.  If so, what were its failings?

--
~Ethan~

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

#66817

On Fri, 21 Feb 2014 09:21:56 +0200, Marko Rauhamaa wrote:

> I don't hear Lispers or C programmers complaining. 

Lisp is not a popular language. Despite being more powerful, more 
efficient, and a lot older, I expect that there are far fewer people who 
know Lisp (let alone use it regularly) than Python. I wouldn't go so far 
as to say that the Lisp/Scheme family of languages is moribund, but they 
are certainly niche.

And by the way, that niche includes some of the best and brightest 
developers. (Some of whom are too clever by half, but that's another 
story.) Merely mediocre programmers don't learn Lisp. So if you take the 
smartest 0.1% of programmers, and give them a language that lets them 
chainsaw their leg off, they won't complain, they're just keep their leg 
out of the way. But if you take the average 50% programmers, and give 
them a language that lets them chainsaw their leg off, there will be a 
lot of one-legged programmers.

I'm really glad that Lisp exists, but I don't want Python to aspire to be 
Lisp. In the same way, I am very fond of Forth. Forth too lets you re-
define *everything* about the language, including creating new flow-
control commands. I love that language. But there is a very good reason 
why there are a thousand Python coders for every one Forth coder, and it 
isn't the stack or the reverse Polish notation.

As for C, there are a lot of mediocre C programmers writing mediocre C 
programs filled with buffer overflows, null-pointer bugs and all sorts of 
other problems. And they don't complain about those either. Because the 
smart ones know how not to chainsaw their leg off (but even they still 
make mistakes, which is why there are periodic security vulnerabilities 
even in code written by people of the calibre of Linus Torvalds and the 
Linux kernel devs), or have moved to another language and write the bare 
minimum of code in C only when they really need to.


> Yes, you can shoot
> yourself in the foot with macro trickery, but macros can greatly enhance
> code readability

Or greatly destroy it, which is precisely the reason why Python doesn't 
have a macro system. When Guido van Rossum reads Python code, he wants it 
to look like Python code, not some arbitrary custom-built language.


-- 
Steven

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

#66798

On Thu, 20 Feb 2014 20:39:10 +1100, Chris Angelico wrote:

> In working on a proposal that might result in the creation of a new
> keyword, I needed to ascertain what names were used extensively in
> existing Python code. 

I would love to steal^W see your script for doing this :-)


-- 
Steven

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

#66801

On Fri, Feb 21, 2014 at 5:51 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 20 Feb 2014 20:39:10 +1100, Chris Angelico wrote:
>
>> In working on a proposal that might result in the creation of a new
>> keyword, I needed to ascertain what names were used extensively in
>> existing Python code.
>
> I would love to steal^W see your script for doing this :-)

No probs! It's part of my ancillary stuff for the PEP 463 research:

https://github.com/Rosuav/ExceptExpr/blob/master/find_except_expr.py

It basically just runs over one file at a time, parses it into an AST,
and walks the tree. Pretty simple.

Actually, some of these sorts of things might make neat examples of
what can be done with the ast module. Until this week, I had no idea
how easy it was to analyze Python code this way.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web