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

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

Re: how to get the ordinal number in list

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: how to get the ordinal number in list luofeiyu <elearn2014@gmail.com> - 2014-08-09 10:35 -0700
    Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-09 13:06 +1000
      Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-08 20:48 -0700
        Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-09 11:34 -0400
          Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-10 09:43 +1000
          Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 09:28 -0700
            Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 13:10 -0400
              Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 10:34 -0700
                Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 14:14 -0400
                  Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 11:26 -0700
                    Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 05:03 +1000
                      Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-10 22:14 +0300
                        Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 05:20 +1000
                      Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 22:23 -0700
                        Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 15:46 +1000
                          Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 23:22 -0700
                            Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 08:55 +0000
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:15 +1000
                            Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 12:35 +0300
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:51 +1000
                                Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 13:46 +0300
                                  Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 21:06 +1000
                        Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 09:44 +0000
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 19:53 +1000
                            Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 21:30 +1000
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 20:07 +1000
                            Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 10:47 +1000
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 11:31 +1000
                                Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-12 21:45 -0400
                                  Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 12:06 +1000
                        Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-11 07:55 -0400
                          Re: how to get the ordinal number in list Tim Chase <python.list@tim.thechases.com> - 2014-08-11 07:30 -0500
                            Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 15:41 +0300
                              Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 22:53 +1000
                          Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 14:57 +0100
                    Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-10 21:32 +0100
                      Re: how to get the ordinal number in list Roy Smith <roy@panix.com> - 2014-08-10 18:01 -0400
                        Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 08:43 +1000
                        Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 20:35 -0700
                    Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 12:04 +1000
                      Re: how to get the ordinal number in list Robert Kern <robert.kern@gmail.com> - 2014-08-11 12:56 +0100
                        Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-11 05:11 -0700
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-11 22:45 +1000
                          Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-11 15:01 +0100
                        Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-11 12:30 +0000
                          Re: how to get the ordinal number in list Marko Rauhamaa <marko@pacujo.net> - 2014-08-11 15:41 +0300
                          Re: how to get the ordinal number in list Robin Becker <robin@reportlab.com> - 2014-08-11 15:32 +0100
                          Re: how to get the ordinal number in list Terry Reedy <tjreedy@udel.edu> - 2014-08-11 18:01 -0400
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-12 09:27 +1000
                            Re: how to get the ordinal number in list wxjmfauth@gmail.com - 2014-08-12 00:21 -0700
                              Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-12 10:40 +0000
                                Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-12 23:39 +1000
                                  Re: how to get the ordinal number in list alister <alister.nospam.ware@ntlworld.com> - 2014-08-12 18:45 +0000
                                    Re: how to get the ordinal number in list Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-08-12 20:16 +0100
                  Re: how to get the ordinal number in list "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-12 13:40 -0400
                    Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-12 11:20 -0700
                      Re: how to get the ordinal number in list "Neil D. Cerutti" <neilc@norwich.edu> - 2014-08-12 15:29 -0400
                        Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-12 20:49 -0700
                  Re: how to get the ordinal number in list Terry Reedy <tjreedy@udel.edu> - 2014-08-12 18:01 -0400
                Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 13:00 +1000
                  Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-10 21:29 -0700
                    Re: how to get the ordinal number in list Steven D'Aprano <steve@pearwood.info> - 2014-08-11 10:28 +0000
                      Re: how to get the ordinal number in list Rustom Mody <rustompmody@gmail.com> - 2014-08-11 04:49 -0700
                        Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 12:11 +1000
                          Re: how to get the ordinal number in list Chris Angelico <rosuav@gmail.com> - 2014-08-13 12:18 +1000
                          Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-13 13:11 +1000
            Re: how to get the ordinal number in list Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-11 03:17 +1000

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

#76045

Chris Angelico <rosuav@gmail.com>:

> On Mon, Aug 11, 2014 at 7:35 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Python is a formal language with a well-defined syntax and reasonably
>> well-understood semantics. That's all that matters. Any resemblance
>> to the much more ad-hoc syntax of classical mathematics is almost
>> coincidental.
>
> Well, it's a bit more than coincidence. It's the ELIZA effect:
>
> http://www.catb.org/jargon/html/E/ELIZA-effect.html
>
> Using notations that some people will be familiar with is better than
> constructing brand new notations from scratch, even if not everyone
> can gain that benefit.

The main thing is that the definitions must be clear. I must be able to
look up the precise description quickly, and in fact, I always have the
Python Library Reference in a browser tab or two because I have to
review even familiar functionality over and over again. Less often, I
also have to review the Python Language Reference.

You don't have to like the = sign or the trailing comma of 1-tuples.
What matters is that you know how to use them.

The second in priority is that the language/module should be faithful to
its own principles. An example is the so-called "file-like objects" in
Python. A different one would be the principle that a new indentation
level is always introduced by a colon. Yet another specialty of Python
is the numerous "magic" access points that have been named __xyz__.

You don't have to like the naming of __init__. It doesn't have to have a
precedent in other programming languages. However, it is important that
it follows a general, rigorous Python pattern.


Marko

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

#76046

On Mon, Aug 11, 2014 at 8:46 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> The main thing is that the definitions must be clear. I must be able to
> look up the precise description quickly, and in fact, I always have the
> Python Library Reference in a browser tab or two because I have to
> review even familiar functionality over and over again. Less often, I
> also have to review the Python Language Reference.
>
> You don't have to like the = sign or the trailing comma of 1-tuples.
> What matters is that you know how to use them.

Fair enough. I'd say that there are two "main things", of nearly equal
importance: one is clear definitions, as you describe, and the other
is memorable definitions (so you don't have to keep going back to the
reference for every little thing). The consistency you describe as
your second priority is really part of memorability, because you can
learn one principle and have it work for everything. Contrast the PHP
standard library, where there's very little consistency in naming, so
you're constantly going back to the docs - see examples here [1] - I
can fully understand that switching from language to language will
have me doing this sort of thing (often with very good justification -
map() in Python takes func,iter,... but map() in Pike takes
iter,func,...; this is because Python's map() takes multiple
iterables, while Pike's takes exactly one iterable and will pass any
other args through to the function unchanged - which is consistent
with a lot of other Pike callback-calling functions), but within a
single language, it's more reasonable to expect consistency.

There are innumerable facets to the memorability of definitions,
though, and consistency's just one of them. The ELIZA effect factors
heavily in memorability; if you see "a + b" in code, you'll expect it
to be, in some way, adding a and b. If you know what HTTP means from
other places on the internet, you'll have some fairly strong
expectations about the functionality of BasicHTTPServer. If you've
worked with any of a huge bunch of languages, you'll not at all be
surprised that "asdf" is a string containing those four letters. And
that latter is true even though lots of languages have their
variations - biggest one being that Python 3's "asdf" is a string of
four Unicode codepoints, while C's "asdf" is a pointer to a buffer of
four bytes (plus the 0, so five really); it's still a string
containing four lowercase letters. And that's a Good Thing.

ChrisA

[1] http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/#standard-library

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

#76038

On Sun, 10 Aug 2014 22:23:18 -0700, Rustom Mody wrote:

> A C programmer asked to swap variables x and y, typically writes
> something like
> 
> t = x; x = y; y = t;
> 
> Fine, since C cant do better.
> But then he assumes that that much sequentialization is inherent to the
> problem... Until he sees the python:
> 
> x,y = y,x

Which is inherently sequential: the semantics of Python guarantee that 
the right-hand side will be evaluated before being bound to the names on 
the left-hand side.


> The same applies generally to all programmers brought up on imperative
> style.
> 
> Yeah there are problems that need to address time -- OSes, network
> protocols, reactive systems like window managers etc
> 
> But the vast majority of problems that a programmer is likely to solve
> dont need time.

Incorrect. Most problems are time dependent in the sense that you have to 
do X before you do Y. "Print the file, then delete it" has a very 
different effect to "delete the file, then print it".

Even functional programming has an implicit sense of time: f(g(x)) 
applies f *after* g, not the other way around. While there are some 
functions where it doesn't matter what order you call them, in general it 
does.

There has been a huge amount of research into writing fully parallel 
code, where the order that code is executed is indeterminate. If we could 
take a general sequential program and parallelize it, we could speed up 
our programs hugely by throwing more cores or CPUs into the hardware. But 
in general we can't -- comparatively few tasks are easily, or at all 
parallelizable. One cannot make an omelet by cooking the eggs first and 
beating them second, or even at the same time. And even when you can 
parallelize a series of tasks, it's 

I think this is why both declarative and functional programming idioms 
will remain niche (although important niches). Most tasks are inherently 
imperative to at least some degree, and often a *great* degree.


> What is wrong is then thinking that all *problems* are sequential rather
> than seeing that some over-specific sequential *solutions* to
> non-sequential problems are ok.
> 
> A mindset exemplified by your hilarious statement: "computers have a
> sense of time"

Of course they do. Apart from a very few experimental asynchronous CPUs, 
computers are all based on CPUs with an internal clock signal which 
synchronizes distinct parts of the circuit with each other.



-- 
Steven

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

#76040

On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> And even when you can
> parallelize a series of tasks, it's

... easy for one task to get aborted part way while the rest of the
tasks continue on, oblivious to the absence of the rest of that
sentence?

ChrisA

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

#76047

Chris Angelico wrote:

> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> And even when you can
>> parallelize a series of tasks, it's
> 
> ... easy for one task to get aborted part way while the rest of the
> tasks continue on, oblivious to the absence of the rest of that
> sentence?

Exactly!


-- 
Steven

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

#76041

On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> I think this is why both declarative and functional programming idioms
> will remain niche (although important niches). Most tasks are inherently
> imperative to at least some degree, and often a *great* degree.

Maybe that's true as a whole, but there are certainly ways in which
certain declarative or functional elements can be extremely useful to
an otherwise-imperative program. Python's (list etc) comprehensions
are broadly functional in style, as are most of the itertools
oddments. There's not a lot that's declarative in Python, but (at
least in Python 3) the presence of __eq__() in a class disables the
default __hash__ implementation, which effectively makes __eq__ a
declaration "I'm doing custom equality, so I'm unhashable unless I say
otherwise".

I've sometimes done some extremely declarative coding in places; my
MUD client builds its menus by looking for specially-named functions
and getting some metadata from them to work out what the menu item
name should be. An approximate Python equivalent would be:

@filemenu("E_xit")
def exit():
    prompt("Do you really want to exit?")

where the presence of the function is what causes the menu item to
exist. In this case, the 'filemenu' decorator is probably imperative
code that adds the menu item to the File menu, but if you're reading
through a source file that has a bunch of functions like that, you'd
have to agree that that's a declarative style of coding. And it's a
style that works well for this kind of thing.

ChrisA

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

#76157

Chris Angelico wrote:

> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> I think this is why both declarative and functional programming idioms
>> will remain niche (although important niches). Most tasks are inherently
>> imperative to at least some degree, and often a *great* degree.
> 
> Maybe that's true as a whole, but there are certainly ways in which
> certain declarative or functional elements can be extremely useful to
> an otherwise-imperative program.

Oh yes! I think that using functional idioms is *very* valuable. List comps
and similar are great, but more than that, the idea of writing idempotent
functions with no side-effects (except IO) is (I believe) vital for good
programming. Relying on argument passing rather communicating by global
variables (or the OO equivalent, instance attributes) is likewise vital.

It's not *quite* impossible to write good, reliable code without functional
idioms, in the same sense that it is conceivable that somebody might write
bug-free unstructured spaghetti code, but I think one of the failures of OO
programming is the over-reliance on methods that communicate via
side-effects. I don't insist that side-effects are completely verboten, as
some functional programming purists do, but I do endeavour to ensure that
any side-effects are limited, encapsulated, and introduce as little
coupling as practical.

(It is my belief that inappropriate coupling is the great evil in
programming. Having too much coupling between parts of your code which
ought to be independent is like Ebola for reliable code, contagious and
deadly. I'm always looking for ways to reduce coupling between parts of my
code, and functional idioms are good for that.)



> Python's (list etc) comprehensions 
> are broadly functional in style, 

No surprise, since list comps were stolen from Haskell :-)


[...]
> I've sometimes done some extremely declarative coding in places; my
> MUD client builds its menus by looking for specially-named functions
> and getting some metadata from them to work out what the menu item
> name should be. An approximate Python equivalent would be:
> 
> @filemenu("E_xit")
> def exit():
>     prompt("Do you really want to exit?")
> 
> where the presence of the function is what causes the menu item to
> exist. In this case, the 'filemenu' decorator is probably imperative
> code that adds the menu item to the File menu, but if you're reading
> through a source file that has a bunch of functions like that, you'd
> have to agree that that's a declarative style of coding. And it's a
> style that works well for this kind of thing.

I don't think I would agree that's declarative style. I think that's a form
of imperative programming, where the syntax is:

    @ make menu
    def function: ...

rather than:

    def function: ...
    make menu (function)

but I wouldn't start a Holy War over it :-)

There's a fair amount of overlap between the major programming paradigms,
and hence disagreement as to what falls under which paradigm. For instance,
FOLDOC has a good, simple distinction in its definition for "imperative":

[quote]
The Free On-line Dictionary of Computing (20 July 2014) [foldoc]

imperative language
imperative
imperative programming

   <language> Any programming language that specifies explicit
   manipulation of the state of the computer system, not to be
   confused with a procedural language, which specifies an
   explicit sequence of steps to perform.

   An example of an imperative (but non-procedural) language is a
   data manipulation language for a relational database
   management system.  This specifies changes to the database
   but does not necessarily require anyone to specify a sequence
   of steps.

   Both contrast with declarative languages, which specify
   neither explicit state manipulation nor a sequence of steps.
[end quote]

You'll note that it suggests SQL would count as an imperative language, but
Wikipedia's article on declarative languages gives SQL as a paragon of
declarative languages!

http://en.wikipedia.org/wiki/Declarative_programming


In Python terms, we might consider "import" to be declarative, since it
specifies what to do (load a name from a module) but not how to perform
it. "import spam" might find spam anywhere, in any form (source code, byte
code, machine code, in a zip file, somewhere on the disk, inside the Python
executable itself), which to my mind suggests a declarative idiom. Or such
things as test discovery, where unittest and doctest will automatically
locate and run tests. (The tests themselves are typically written in a
procedural paradigm.) Otherwise, Python doesn't really have a lot to offer
in the declarative paradigm.


-- 
Steven

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

#76159

On Wed, Aug 13, 2014 at 10:47 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris Angelico wrote:
>
>> On Mon, Aug 11, 2014 at 7:44 PM, Steven D'Aprano <steve@pearwood.info>
>> wrote:
>>> I think this is why both declarative and functional programming idioms
>>> will remain niche (although important niches). Most tasks are inherently
>>> imperative to at least some degree, and often a *great* degree.
>>
>> Maybe that's true as a whole, but there are certainly ways in which
>> certain declarative or functional elements can be extremely useful to
>> an otherwise-imperative program.
>
> Oh yes! I think that using functional idioms is *very* valuable. List comps
> and similar are great, but more than that, the idea of writing idempotent
> functions with no side-effects (except IO) is (I believe) vital for good
> programming. Relying on argument passing rather communicating by global
> variables (or the OO equivalent, instance attributes) is likewise vital.
> ...
> (It is my belief that inappropriate coupling is the great evil in
> programming. Having too much coupling between parts of your code which
> ought to be independent is like Ebola for reliable code, contagious and
> deadly. I'm always looking for ways to reduce coupling between parts of my
> code, and functional idioms are good for that.)

There are times when coupling is unavoidable, but yes, it's usually
detrimental to the code. Sometimes the alternatives are worse, but
coupling is still bad. I have TODOs against certain pieces of code
where I can't think of a clean way to decouple them...

>> I've sometimes done some extremely declarative coding in places; my
>> MUD client builds its menus by looking for specially-named functions
>> and getting some metadata from them to work out what the menu item
>> name should be. An approximate Python equivalent would be:
>>
>> @filemenu("E_xit")
>> def exit():
>>     prompt("Do you really want to exit?")
>>
>> where the presence of the function is what causes the menu item to
>> exist. In this case, the 'filemenu' decorator is probably imperative
>> code that adds the menu item to the File menu, but if you're reading
>> through a source file that has a bunch of functions like that, you'd
>> have to agree that that's a declarative style of coding. And it's a
>> style that works well for this kind of thing.
>
> I don't think I would agree that's declarative style. I think that's a form
> of imperative programming, where the syntax is:
>
>     @ make menu
>     def function: ...
>
> rather than:
>
>     def function: ...
>     make menu (function)
>
> but I wouldn't start a Holy War over it :-)

In a sense, yes. That's partly because Python doesn't really have the
concept that I'm using here. Here's the actual code (it's Pike):

constant file_closewindow="E_xit";
int closewindow()
{
... actual body of function isn't significant ...
}

The key here is the module-level constant which is "file_" followed by
the name of a function. So a more direct translation into Python would
be:

file_closewindow="E_xit"
def closewindow():
    ... blah blah ...

but since Python code tends to have uppercase constants, this would be
frowned on. Also, it's hard in Python to "enumerate constants", as
there's no such thing (Pike's constants are available at a slightly
different level, which makes them easy to find).

What might make it more declarative than imperative, even in Python,
is that the *order* of items on the menu is alphabetical by function
name, and thus has nothing to do with their position in the file. If
the decorator actually added the items to the menu immediately, their
positions would be based on order in the file; to do them
alphabetically by function name, you basically need to collect them
all up and create them all at the end. That's how the code works in
Pike - a quick loop in the initialization code runs over the constants
and adds the menu items, which means the constants are completely
non-executable.

It really is hard to draw the line. Ultimately, the CPU (at least, if
it's of any architecture I've worked with) doesn't execute declarative
or functional code, just as it doesn't execute callbacks or subthread
multiplexing or anything like that. You need to have, somewhere, a bit
of imperative code (usually a simple loop) that deals with the other
types... which might be called an interpreter. In fact, *all* high
level code is, in a sense, declarations to a lower level interpreter -
consider the distinctions between various Python interpreters (even
some that run inside your web browser), and how they all obey the same
declarations, but implement them completely differently.

> [ quoting FOLDOC ]
>    An example of an imperative (but non-procedural) language is a
>    data manipulation language for a relational database
>    management system.  This specifies changes to the database
>    but does not necessarily require anyone to specify a sequence
>    of steps.
>
>    Both contrast with declarative languages, which specify
>    neither explicit state manipulation nor a sequence of steps.
> [end quote]
>
> You'll note that it suggests SQL would count as an imperative language, but
> Wikipedia's article on declarative languages gives SQL as a paragon of
> declarative languages!
>
> http://en.wikipedia.org/wiki/Declarative_programming

Yeah, it's hard to draw the line. I like to look at SQL as a language
that specifies an end result without specifying how to get there [1]
and Python as a language that specifies exactly what to do. According
to FOLDOC's definition, both of those are imperative languages, but
the techniques for developing and debugging them vary significantly.

Actually, that's probably the most useful way to distinguish,
especially since it's easy to slide from one paradigm to another in
the same language, even in the same program (your event handler is
triggered by the magic of callbacks, but inside it, your code is
strictly imperative). How do you go about debugging a piece of code?
If you reorder things inside the code itself with the expectation that
it'll have a clear and simple effect on the code's behaviour, that's
imperative. If you tweak the external algorithms or change
non-executable code in order to achieve what you want, that's
declarative.

> In Python terms, we might consider "import" to be declarative, since it
> specifies what to do (load a name from a module) but not how to perform
> it. "import spam" might find spam anywhere, in any form (source code, byte
> code, machine code, in a zip file, somewhere on the disk, inside the Python
> executable itself), which to my mind suggests a declarative idiom. Or such
> things as test discovery, where unittest and doctest will automatically
> locate and run tests. (The tests themselves are typically written in a
> procedural paradigm.) Otherwise, Python doesn't really have a lot to offer
> in the declarative paradigm.

It's just as declarative as 'def' or 'class'. Technically, they're all
executable statements; when the interpreter reaches one of them, it
goes off and does what you asked it to do, and then continues on. But
practically, they're usually used declaratively - "if I put this code
in my file, I will have a function with this name". Most people will
happily write Python functions with 'def' in the same way they'd write
C functions, or PHP functions, or anything else, and the significance
of def being executable is only seen when you have nested functions
etc. Even order of execution is almost never a problem, except for
class inheritance - and frankly, I've never seen anyone define a
superclass lower in a file than its subclasses, in *any* language.
When was the last time you needed to be aware that any of these three
(import/def/class) was truly executable?

ChrisA

[1] There are exceptions - the CREATE INDEX command in various engines
lets you do a lot more specification, and there are abominations in a
popular low-end database that let you stipulate how a SELECT statement
is to be processed, but the intent of SQL is to specify only the end
result.

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

#76161

In article <mailman.12903.1407893523.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> I like to look at SQL as a language that specifies an end result 
> without specifying how to get there

Well, sure, but sometimes the how to get there is a matter of 10x, or 
100x, or 1000x in performance.

I'm currently migrating a 3 TB database to a new 5 TB RAID array.  Our 
initial guess is it's going to take two weeks to finish :-(

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

#76164

On Wed, Aug 13, 2014 at 11:45 AM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.12903.1407893523.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> I like to look at SQL as a language that specifies an end result
>> without specifying how to get there
>
> Well, sure, but sometimes the how to get there is a matter of 10x, or
> 100x, or 1000x in performance.

Of course it can! But generally, the "how to get there" is not
stipulated in the SQL statement. If you say, for instance:

select * from some_table where some_column='some_value';

then an index on some_column will make a huge difference to
performance - without changing this statement at all. In contrast,
taking advantage of an index in BTrieve requires recoding your
program, as the index used is a part of the API call. (At least, this
is true of the particular version of BTrieve that back-ended our
accounting package in the 90s. I was able to turn an overnight job
into a thirty-second job by rewriting it as an external program; the
original is closed-source so I can't be sure, but I suspect most of
that improvement is simply because I used an index.)

SQL itself doesn't even have provision for indexes. The 'CREATE INDEX'
command, found in many databases, is an extension. :)

ChrisA

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

#76049

In article <b3c69a72-5f0c-4e2a-8ef0-91842e12c7d0@googlegroups.com>,
 Rustom Mody <rustompmody@gmail.com> wrote:

> A C programmer asked to swap variables x and y, typically writes something 
> like
> 
> t = x; x = y; y = t;
> 
> Fine, since C cant do better.

Sure C can do better.

x = x ^ y
y = y ^ x
x = x ^ y

Any self-respecting C hacker would write it this way :-)

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

#76053

On 2014-08-11 07:55, Roy Smith wrote:
> > A C programmer asked to swap variables x and y, typically writes
> > something like
> > 
> > t = x; x = y; y = t;
> > 
> > Fine, since C cant do better.  
> 
> Sure C can do better.
> 
> x = x ^ y
> y = y ^ x
> x = x ^ y
> 
> Any self-respecting C hacker would write it this way :-)

Pish, such redundancy...everyone knows a C programmer would write
that as

 x ^= y
 y ^= x
 x ^= y

:-)

-tkc

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

#76055

Tim Chase <python.list@tim.thechases.com>:

> Pish, such redundancy...everyone knows a C programmer would write
> that as
>
>  x ^= y
>  y ^= x
>  x ^= y

Aren't you forgetting something?


Marko

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

#76057

On Mon, Aug 11, 2014 at 10:41 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Tim Chase <python.list@tim.thechases.com>:
>
>> Pish, such redundancy...everyone knows a C programmer would write
>> that as
>>
>>  x ^= y
>>  y ^= x
>>  x ^= y
>
> Aren't you forgetting something?

I don't think he is. Those are augmented assignments, just as Python
has (although with slightly different semantics in some places). The
semicolons can be omitted in some C REPLs, although they are of course
mandatory in regular code.

ChrisA

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

#76060

On 11/08/2014 13:30, Tim Chase wrote:
> On 2014-08-11 07:55, Roy Smith wrote:
>>> A C programmer asked to swap variables x and y, typically writes
>>> something like
>>>
>>> t = x; x = y; y = t;
>>>
>>> Fine, since C cant do better.
>>
>> Sure C can do better.
>>
>> x = x ^ y
>> y = y ^ x
>> x = x ^ y
>>
>> Any self-respecting C hacker would write it this way :-)
>
> Pish, such redundancy...everyone knows a C programmer would write
> that as
>
>   x ^= y
>   y ^= x
>   x ^= y
>
> :-)
>
> -tkc
>

That says the LHS is assigned the RHS rotated by some angle, which I'll 
assume to be 90 degrees clockwise, yes?  Well I don't suppose it really 
matters for x as it'll still be x when it gets assigned to y, but what 
would you call the shift on y that gets assigned to x?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#76003

On 10/08/2014 19:26, Rustom Mody wrote:
>
> Its when we have variables that are assigned in multiple places that
> we start seeing mathematical abominations like
> x = x+1
>

I'm not bothered about it being a mathematical or any other type of 
abomination.  It works, practically beats purity, so if it ain't broke, 
please don't fix it, for some definition of fix.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#76005

In article <mailman.12827.1407702752.18130.python-list@python.org>,
 Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:

> On 10/08/2014 19:26, Rustom Mody wrote:
> >
> > Its when we have variables that are assigned in multiple places that
> > we start seeing mathematical abominations like
> > x = x+1
> >
> 
> I'm not bothered about it being a mathematical or any other type of 
> abomination.  It works, practically beats purity, so if it ain't broke, 
> please don't fix it, for some definition of fix.

I'm with Mark.  This isn't math, it's programming.  Sure, the 
intersection of the two is non-null, but they are different things.  
I'll often do things like:

for line in input:
   line = line.strip()
   # do more stuff

Sure, I could invent some other variable name to avoid re-using the same 
name, but does:

for line in input:
   stripped_line = line.strip()
   # do more stuff

really make this any easier to read or understand?  I think not.

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

#76007

On Mon, Aug 11, 2014 at 8:01 AM, Roy Smith <roy@panix.com> wrote:
> I'm with Mark.  This isn't math, it's programming.  Sure, the
> intersection of the two is non-null, but they are different things.
> I'll often do things like:
>
> for line in input:
>    line = line.strip()
>    # do more stuff

What does mathematics even have as a concept of looping? String
manipulation? Input and output?

ChrisA

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

#76017

On Monday, August 11, 2014 3:31:08 AM UTC+5:30, Roy Smith wrote:

>  Mark Lawrence wrote:

> > On 10/08/2014 19:26, Rustom Mody wrote:
> > > Its when we have variables that are assigned in multiple places that
> > > we start seeing mathematical abominations like
> > > x = x+1
> > I'm not bothered about it being a mathematical or any other type of 
> > abomination.  It works, practically beats purity, so if it ain't broke, 
> > please don't fix it, for some definition of fix.

> I'm with Mark.  This isn't math, it's programming.  Sure, the 
> intersection of the two is non-null, but they are different things.  
> I'll often do things like:

> for line in input:
>    line = line.strip()
>    # do more stuff

So would I

> Sure, I could invent some other variable name to avoid re-using the same 
> name, but does:

> for line in input:
>    stripped_line = line.strip()
>    # do more stuff

> really make this any easier to read or understand?  I think not.

You are switching between software-engineer and teacher hat.

As a software engineer you (and I and possibly most reasonable people)
would do things like that.

As a teacher when you introduce problematic concepts you have to answer
questions -- possibly embarrassing -- about them.

Just as parents need to talk of 'birds-and-bees' to their children
sometime but also need good sense and judgement as to when, likewise
teachers should deliver maturity-building easier stuff before
maturity-needing harder ideas.

Assignment is definitely in the latter category because we have to
talk of time, environments and so on.  When one explicates (and not
handwaves) these pre-requisites -- as happens in denotational
semantics or in any language implementation -- then assignment is seen
to be as higher-order a concept as any other 2 level lambda expression.

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

#76013

Rustom Mody wrote:

> Its when we have variables that are assigned in multiple places that
> we start seeing mathematical abominations like
> x = x+1

That's not a mathematical abomination. It's a perfectly reasonable
mathematical equation, one with no solutions since the line f(x) = x and
the line f(x) = x+1 are parallel.

But what does this have to do with programming? Programming *is not*
mathematics, and x = x+1 has a different meaning in programming than in
mathematics. Perhaps it would help if we wrote it using mathematical
notation? Using [x] for subscripts:

x[n+1] = x[n] + 1

we have a perfectly good mathematical recursive definition. All it needs is
an initial value x[0] and we're good to go.



-- 
Steven

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

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

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

csiph-web