subject:"Explanation of this Python language feature\? \[x for x in x for x in x\] \(to flatten a nested list\)"

Mark H Harris harrismh...@gmail.com:

 On 4/4/14 4:53 AM, Steven D'Aprano wrote:
 Python is not a computer-science-ey language.

 Every programming language is interesting from a comp sci standpoint.
 Some are more useful for research; python is one of those.

 For what reasons do you disagree?

Computer science doesn't mean anything related to computers.
Physicists typically couldn't care less about your heating up your lunch
in the microwave oven. Similarly, computer scientists aren't interested
in the mundane applications of their lofty research topics.

Python, BTW, is perfectly suitable for computer science. Normally,
though, you either use a pseudolanguage or some sort of formalism that
hasn't been implemented.

In theoretical computer science, they cherish off-the-wall models that
detach the topic from everyday applications. Here are examples that I
remember from graduate school:

 * combinatory birds in forests

 * unfaithful husbands on an island ruled by female logicians

 * dining philosophers getting into a deadlock over forks

 * Byzantine generals trying to agree on a surprise onslaught on a
   besieged city


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-06 Thread Steven D'Aprano

On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:

 Mark H Harris harrismh...@gmail.com:
 
 On 4/4/14 4:53 AM, Steven D'Aprano wrote:
 Python is not a computer-science-ey language.

 Every programming language is interesting from a comp sci standpoint.
 Some are more useful for research; python is one of those.

 For what reasons do you disagree?
 
 Computer science doesn't mean anything related to computers.
 Physicists typically couldn't care less about your heating up your lunch
 in the microwave oven. Similarly, computer scientists aren't interested
 in the mundane applications of their lofty research topics.
 
 Python, BTW, is perfectly suitable for computer science. 

I don't think it is. Python is not a pure functional language, so it's 
very difficult to prove anything about the code apart from running it. 
For example, see Brett Cannon's master's thesis, where he essentially 
demonstrates that:

- you can't do compile-time type inference of general types in Python;

- although you can infer a very small amount of information about a 
  few built-in types;

- adding specialized byte-codes to handle those types gives, at best,
  a marginal performance boost, and sometimes even slows code down.


To quote from the conclusion:

   Introducing over 3,000 lines of new C code to Python’s compiler 
to get, at best, a 1% improvement is in no way justified. The 
level of added complexity that would be introduced into the
compilation step would definitely need to lead to a noticeable
performance improvement, the 5% that was the goal, to justify the
cost of code maintenance.

http://citeseerx.ist.psu.edu/viewdoc/download?
doi=10.1.1.90.3231rep=rep1type=pdf


What does it mean to say that a language like Python is suitable for use 
in computer science? It can mean (at least) four things:

(1) If you do an undergraduate computer science course, they will teach 
you Python.

While this is good for the general Python community, it's hardly *doing* 
computer science. It's *learning* computer science. (I read a book by 
Richard Dawkins. That doesn't mean I'm a biologist.) So while I agree 
that it is significant that some universities will teach Python to 
undergraduates, I don't count this as Python being used in computer 
science. I think we need to look at postgraduate use of Python, not 
undergraduate.

(2) Some post-grads use Python as a tool, e.g. they use a Python script 
to analyse some data. In this case, the use of Python is incidental to 
the research they are doing. They might have used Perl, or a bash script, 
or calculated the results by hand. In a similar fashion, they probably 
wrote up their results using Microsoft Word. It's just a tool.

(3) Some post-grads do original research *into* Python, as a language. 
Brett Cannon's thesis is proof that this has happened at least once.

I think this does count as doing computer science with Python, although 
only marginally. No slight intended, but it should be obvious that 
something like Brett's thesis has very little application outside of 
Python itself. Perhaps a little: if there is another language with 
similar types of dynamism as Python, you might conclude that it too is 
not a good candidate for compile-time type inference.

(4) This is the category which I was referring to when I said that Python 
wasn't a computer-science-ey language: do people use Python for 
research into language-independent fundamental principles of computation? 
I don't think so. I agree with Marko that normally you:

 you either use a pseudolanguage or some sort of formalism that
 hasn't been implemented.

E.g. most of the really deep stuff by Turing wasn't even performed on a 
computer, since there were no computers[1], or languages to program them 
in. A lot (all?) of Knuth's published work is written in an assembly 
language for an imaginary processor. Douglas Hofstadter invented two 
languages, BlooP and FlooP, to demonstrate the difference between 
programming languages that are, or aren't, Turing complete. (He also 
named a mythical super-Turing language GlooP.)

Some languages are better suited for academic research of this nature. 
Python is too... messy, I suppose. Python's mix of imperative, functional 
and OOP paradigms makes it really useful for solving problems, but less 
useful for academic research of this type, where pure functional, pure 
OOP paradigms are more useful. Naturally I'm not saying that there is 
*absolutely no* comp-sci work done using Python, that would be foolish, 
only that it is in a minority and is not well-suited for the sort of 
problems academics are interested in.

But since I'm not a computer scientist, perhaps I'm wrong. Anyone have 
any studies showing what percentage of research papers use various 
languages?


 In theoretical computer science, they cherish off-the-wall models that
 detach the topic from everyday applications. Here are examples that I
 remember from graduate school:
 
  * combinatory

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Mon, Apr 7, 2014 at 2:52 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 (4) This is the category which I was referring to when I said that Python
 wasn't a computer-science-ey language: do people use Python for
 research into language-independent fundamental principles of computation?
 I don't think so. I agree with Marko that normally you:

 you either use a pseudolanguage or some sort of formalism that
 hasn't been implemented.

 E.g. most of the really deep stuff by Turing wasn't even performed on a
 computer...

A simple reason for that is summed up in the Zen of Python:
Practicality beats purity. For a comp sci theoretical study, you want
something that exemplifies purity. That's why you get examples like
the ones mentioned below - a dining philosopher is fundamentally
unable to do such a simple thing as look to see what his neighbours
are doing, and is also apparently unable to think and eat at the same
time (plus, why on earth can't they afford a few more forks in the
interests of hygiene??!?). Defining all of mathematics in terms of
lambda is wonderfully pure, and utterly useless for any practical
purpose.

It's the same, in my opinion, with the eternal arguments about
functional vs imperative vs declarative programming languages, and
with the differences between compilers and interpreters, and whether
something's a second-generation or third-generation or
fourth-generation language. You can define all those terms in nice
pure ways (a compiler translates code into something that can be
executed directly, but an interpreter parses code bit by bit and
executes it), but most actually-usable systems blur the lines. I
still haven't seen any real definition of FP or OOP (especially the
latter, O!) that doesn't ultimately come down to avoid these language
features which violate FP/OOP principles, which means that most
programming languages (and more so with popular languages) are neither
and/or both. It's all very well to say that everything is a function
whose return value depends solely on its arguments, but practicality
demands that you allow side effects in certain places. And it's all
very well to say that everything's an object and every bit of code is
a method, but aiming too far for purity results in Java-like syntactic
salt. Pike avoids this somewhat by letting you pretend that it's a
C-like module with top-level functions, but actually it's instantiated
an object and called a method on it. That's occasionally useful, but
most of the time you just ignore it and work imperatively. Python goes
a bit further: top-level is just code like anything else, and it gets
executed straight down the line. Practicality beats purity.

  * unfaithful husbands on an island ruled by female logicians

 I don't know that one.

Me neither, although I can see elements of classic logic analysis
elements. Islands ruled by logicians, people who always tell the truth
/ always tell exact falsehoods, etc, etc. I don't know of any that
involve unfaithful husbands, but it wouldn't surprise me. Would like
to hear it though.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sunday, April 6, 2014 10:22:21 PM UTC+5:30, Steven D'Aprano wrote:
 On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:

  Mark H Harris :
  On 4/4/14 4:53 AM, Steven D'Aprano wrote:
  Python is not a computer-science-ey language.
  Every programming language is interesting from a comp sci standpoint.
  Some are more useful for research; python is one of those.
  For what reasons do you disagree?
  Computer science doesn't mean anything related to computers.
  Physicists typically couldn't care less about your heating up your lunch
  in the microwave oven. Similarly, computer scientists aren't interested
  in the mundane applications of their lofty research topics.
  Python, BTW, is perfectly suitable for computer science. 

 I don't think it is. Python is not a pure functional language, so it's 
 very difficult to prove anything about the code apart from running it. 
 For example, see Brett Cannon's master's thesis, where he essentially 
 demonstrates that:

 - you can't do compile-time type inference of general types in Python;

 - although you can infer a very small amount of information about a 
   few built-in types;

 - adding specialized byte-codes to handle those types gives, at best,
   a marginal performance boost, and sometimes even slows code down.

 To quote from the conclusion:

Introducing over 3,000 lines of new C code to Python's compiler 
 to get, at best, a 1% improvement is in no way justified. The 
 level of added complexity that would be introduced into the
 compilation step would definitely need to lead to a noticeable
 performance improvement, the 5% that was the goal, to justify the
 cost of code maintenance.

 http://citeseerx.ist.psu.edu/viewdoc/download?
 doi=10.1.1.90.3231rep=rep1type=pdf

Thanks for the link.

It think however you are reading it more widely than intended.
The appropriate context is a few paras below:

| In the end, it seems that Python, as a language, is not geared towards
| type inference. Its flexibility, considered a great strength,
| interferes with how extensive type inference can be performed. Without
| a significant change to the language, type inference is not worth the
| hassle of implementation

So...
Yes if CS begins and ends with type-inference then your conclusion would be 
valid. However consider that some of the things that people did around 40 years
ago and do today

- use FORTRAN for numerical/simulation work --  now use scipy/sage etc
- NLP with Lisp/Prolog -- look at Nltk
- ??? with Data Analysis in Pandas
- Scheme (basis for programming pedagogy, semantics research) - Python

you can add/multiply ad libitum

Yeah you covered this in your (2) as ...just a tool...

Ask some recent PhD about what is for you just an almost irrelevant
tool and you are very likely to find that that choice may well have
been the difference between completing the research and giving up.

I think python wins because it (usually) lets people do their thing
(includes but not limited to CS-research)
and gets out of the way.  To say therefore that it is irrelevant to the 
research is a strange inversion of its advantages.

[Or simply just switch to C++ for 3 months and report back with
the increment in your white-hair-count]


In short, I just dispute your 'just'!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Mon, Apr 7, 2014 at 3:31 AM, Rustom Mody rustompm...@gmail.com wrote:
 However consider that some of the things that people did around 40 years
 ago and do today

 - use FORTRAN for numerical/simulation work --  now use scipy/sage etc
 - NLP with Lisp/Prolog -- look at Nltk
 - ??? with Data Analysis in Pandas
 - Scheme (basis for programming pedagogy, semantics research) - Python

 you can add/multiply ad libitum

 Yeah you covered this in your (2) as ...just a tool...

 Ask some recent PhD about what is for you just an almost irrelevant
 tool and you are very likely to find that that choice may well have
 been the difference between completing the research and giving up.

 I think python wins because it (usually) lets people do their thing

Allow me to put it another way. Mathematicians use the language of
algebra to describe their research; they don't, by and large, use a
programming language. They use pencils and paper [1] as tools to get
their work done, and may well have strong opinions on which pencil
brand is the best, but the point of the pencil (pun intended) is to
enable something else. It's supposed to get out of the way and let
them do their thing. Python is highly practical because it gets out of
the way. It's not the way that you develop programming language
theory, though.

I might start out designing a language with the express purpose of
implementing everything as an expression. The whole program consists
of one long expression, with perhaps the semicolon being a sequence
point that evaluates its left side, then evaluates its right side, and
returns the latter (like the C comma operator). I could then go
through a whole lot of lovely mental exploration as to what the
benefits and costs of that system are, all the while writing nothing
more than design documents and example code. At some point, if I'm
happy with it, I'll write a reference implementation, and maybe then
I'll use Python for the job. But that's not using Python to explore a
language concept; that's using Python to rapidly prototype the
executable code that I need in order to show my new language at work.
All the work of developing the language is done in the design stage,
with nothing at all even needing a computer (although I *guarantee*
you that if I were to start something like that, I'd find part way
through that I've made some fundamental mistakes early on - and a
computer is better for editing text than anything on paper). I could
just as easily write my reference implementation using yacc/bison and
C, and it wouldn't be materially different.

Using Python at the design stage would be what Steven's talking about
- actually using it to build the theory of programming. I have about
as much experience in the area as he has, so we can't speak to the
lack of examples, but that's the sort of example it would take.

ChrisA

[1] As the old joke goes: The physics department needs a whole lot of
expensive equipment, but the math department needs only pencils,
paper, and wastepaper baskets. And the philosophy department goes even
further: they don't need wastepaper baskets.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-06 Thread Mark Lawrence


On 06/04/2014 18:27, Chris Angelico wrote:

(plus, why on earth can't they afford a few more forks in the
interests of hygiene??!?).


They couldn't get the purchase order for these capital cost items past 
the accountants.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Mon, Apr 7, 2014 at 4:09 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
 On 06/04/2014 18:27, Chris Angelico wrote:

 (plus, why on earth can't they afford a few more forks in the
 interests of hygiene??!?).


 They couldn't get the purchase order for these capital cost items past the
 accountants.

That would explain why they spend so much time thinking. Can't afford
pencils and paper to write their thoughts down, so they sit in the sun
and one by one they collect their thoughts and think them over.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sunday, April 6, 2014 11:24:15 PM UTC+5:30, Chris Angelico wrote:
 On Mon, Apr 7, 2014 at 3:31 AM, Rustom Mody  wrote:
  However consider that some of the things that people did around 40 years
  ago and do today
  - use FORTRAN for numerical/simulation work --  now use scipy/sage etc
  - NLP with Lisp/Prolog -- look at Nltk
  - ??? with Data Analysis in Pandas
  - Scheme (basis for programming pedagogy, semantics research) - Python
  you can add/multiply ad libitum
  Yeah you covered this in your (2) as ...just a tool...
  Ask some recent PhD about what is for you just an almost irrelevant
  tool and you are very likely to find that that choice may well have
  been the difference between completing the research and giving up.
  I think python wins because it (usually) lets people do their thing


 [1] As the old joke goes: The physics department needs a whole lot of
 expensive equipment, but the math department needs only pencils,
 paper, and wastepaper baskets. And the philosophy department goes even
 further: they don't need wastepaper baskets.

HaHa! Very funny and unpleasantly accurate!


 Allow me to put it another way. Mathematicians use the language of
 algebra to describe their research; they don't, by and large, use a
 programming language. They use pencils and paper [1] as tools to get
 their work done, and may well have strong opinions on which pencil
 brand is the best, but the point of the pencil (pun intended) is to
 enable something else. It's supposed to get out of the way and let
 them do their thing. Python is highly practical because it gets out of
 the way. It's not the way that you develop programming language
 theory, though.

Right.
Whats wrong is (the implication -- maybe its not there??) that
CS begins and ends with develop programming language theory

 I might start out designing a language with the express purpose of
 implementing everything as an expression. The whole program consists
 of one long expression, with perhaps the semicolon being a sequence
 point that evaluates its left side, then evaluates its right side, and
 returns the latter (like the C comma operator). I could then go
 through a whole lot of lovely mental exploration as to what the
 benefits and costs of that system are, all the while writing nothing
 more than design documents and example code. At some point, if I'm
 happy with it, I'll write a reference implementation, and maybe then
 I'll use Python for the job. But that's not using Python to explore a
 language concept; that's using Python to rapidly prototype the
 executable code that I need in order to show my new language at work.
 All the work of developing the language is done in the design stage,
 with nothing at all even needing a computer (although I *guarantee*
 you that if I were to start something like that, I'd find part way
 through that I've made some fundamental mistakes early on - and a
 computer is better for editing text than anything on paper). I could
 just as easily write my reference implementation using yacc/bison and
 C, and it wouldn't be materially different.

Again I dispute the 'just'.

Its a right example for the wrong reason: State of art of writing
language implementations in python is no-better-probably-worse than
the venerable yacc ecosystem.
Choose an example where the difference between poor and good tool is more
palpable and the 'just' will no longer be upholdable as just.

Is the diff between cvs/svn and git just one vcs or another?

 Using Python at the design stage would be what Steven's talking about
 - actually using it to build the theory of programming. I have about
 as much experience in the area as he has, so we can't speak to the
 lack of examples, but that's the sort of example it would take.

!Parse Error! What are you saying -- I don get :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Mon, Apr 7, 2014 at 4:13 AM, Rustom Mody rustompm...@gmail.com wrote:
 Is the diff between cvs/svn and git just one vcs or another?

The theory of version control, or source control, or whatever you want
to call it, can be found in some of the docs for those systems (git
goes into some depth about the Directed Acyclic Graph that underpins
everything), but that theory isn't what makes git or cvs/svn useful.

The theory behind my MUD client Gypsum is that it should be built
the way a server is, including that it should not need to be restarted
even when there's new code to be loaded in; but that's not what makes
Gypsum useful.

The theory behind an ergonomic keyboard is that it should hurt your
hands less than a classic keyboard does, but that's not what makes it
useful. Actually, in that instance, it might be what makes it
useless...

 Using Python at the design stage would be what Steven's talking about
 - actually using it to build the theory of programming. I have about
 as much experience in the area as he has, so we can't speak to the
 lack of examples, but that's the sort of example it would take.

 !Parse Error! What are you saying -- I don get :-)

What I'm saying is that I - and, if my reading is correct, similarly
with Steven - am looking for is a prominent example of someone using
Python as the very basis for a discussion on the future of computer
science *as a field*. So, not here's what can be done with Python,
and not here's something about hydraulics, with some Python code
showing how my theory adds up. If you're developing a cryptography
algorithm, it might well be convenient to support it with Python code
(although I mostly see reference implementations in C), but that's
still using Python as a tool, rather than as a language for
fundamental development of comp sci theories.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:

 On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:
 Python, BTW, is perfectly suitable for computer science. 

 I don't think it is. Python is not a pure functional language, so it's 
 very difficult to prove anything about the code apart from running it. 

Many classic CS ideas are expressed in terms of an Algol-like language.
Nothing would prevent you from framing those ideas in a Python-like
(pseudo)language. The question is mostly whether you prefer begin/end,
braces or indentation.

  * combinatory birds in forests

 I don't believe that came from academia. If I've understood correctly, 
 that was from a non-academic book on applying the lambda calculus to 
 solve practical applications.

It is academic because the author, Raymond Smullyan, was a professor of
philosophy and, more importantly, my professor selected that as a
textbook for us graduate students.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

Chris Angelico ros...@gmail.com:

  * unfaithful husbands on an island ruled by female logicians

 I don't know that one.

 Me neither, although I can see elements of classic logic analysis
 elements. Islands ruled by logicians, people who always tell the truth
 / always tell exact falsehoods, etc, etc. I don't know of any that
 involve unfaithful husbands, but it wouldn't surprise me. Would like
 to hear it though.

Here's how I remember it:

  There was a tiny matriarchal island ruled by a queen. The women were
  capable logicians and that was common knowledge. The idyllic island had
  a problem, though: faithless husbands. The queen decided to solve the
  problem and summoned all women to the market square. She said:

We need to solve the problem of unfaithful husbands once and for
all. Now, we all know which men are cheating on their wives except
our own. I hereby ban you from talking about this matter with each
other ever again. However, if one day you should come to know your
husband has been unfaithful, I am ordering you to show no mercy but
shoot him to death the following night while he is asleep.

  The women left and went back to their business. The night after 40
  days, shots were heard throughout the island.

  How many husbands were unfaithful? How did they find out?

It was a variation of numerous similar puzzles and was the topic of a
dissertation on knowledge logic, IIRC.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-06 Thread Mark Lawrence


On 06/04/2014 21:10, Marko Rauhamaa wrote:


Many classic CS ideas are expressed in terms of an Algol-like language.
Nothing would prevent you from framing those ideas in a Python-like
(pseudo)language. The question is mostly whether you prefer begin/end,
braces or indentation.



Of course whilst all this work in the fields of languages, algorithms 
and such like has been going on, in parallel engineers have been working 
on the hardware side of things.  My understanding is that some abacuses 
now have as many as ten strings on them.  Although this scale was at 
first difficult for the users to grasp, the designers came up with the 
fantastic idea of using different coloured beads on different strings to 
simplify the user experience.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-06 Thread Steven D'Aprano

On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote:

 Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
 
 On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:
 Python, BTW, is perfectly suitable for computer science.

 I don't think it is. Python is not a pure functional language, so it's
 very difficult to prove anything about the code apart from running it.
 
 Many classic CS ideas are expressed in terms of an Algol-like language.
 Nothing would prevent you from framing those ideas in a Python-like
 (pseudo)language. The question is mostly whether you prefer begin/end,
 braces or indentation.

Okay, I made an error in stating that it's because Python is not a pure 
functional language. It's because Python is so dynamic that it is very 
difficult to prove anything about the code apart from running it. Take 
this code-snippet of Python:

n = len([1, 2, 3])

What can we say about it? Almost nothing!

All we know is that the name len will be looked up, it may or may not 
find something, that thing may or may not be callable, calling it with a 
list may or may not succeed, and it may or may not return 3 when given 
that specific list as input. From the perspective of wanting to prove 
things about the code, there's not a lot of certainty there.

If we replace Python with a Python-like language which is closer to the 
traditional Algol mode of built-in functions being keywords (and hence 
unable to be shadowed or deleted) then we can reason about the behaviour 
more successfully. Alas, a Python-like language is not Python, and our 
discussion is about whether or not *Python* is suitable for this use.


  * combinatory birds in forests

 I don't believe that came from academia. If I've understood correctly,
 that was from a non-academic book on applying the lambda calculus to
 solve practical applications.
 
 It is academic because the author, Raymond Smullyan, was a professor of
 philosophy and, more importantly, my professor selected that as a
 textbook for us graduate students.

Ah. Well they do that, don't they? I've always consider the ability of 
professors to select their own book as text to be a classic case of 
conflict of interest. They're supposed to pick the best book, not 
necessarily the one that earns them money.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-06 Thread Terry Reedy


On 4/6/2014 7:48 PM, Steven D'Aprano wrote:

On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote:


Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:


On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:

Python, BTW, is perfectly suitable for computer science.


I don't think it is. Python is not a pure functional language, so it's
very difficult to prove anything about the code apart from running it.


Many classic CS ideas are expressed in terms of an Algol-like language.
Nothing would prevent you from framing those ideas in a Python-like
(pseudo)language. The question is mostly whether you prefer begin/end,
braces or indentation.


Okay, I made an error in stating that it's because Python is not a pure
functional language. It's because Python is so dynamic that it is very
difficult to prove anything about the code apart from running it. Take
this code-snippet of Python:

n = len([1, 2, 3])

What can we say about it? Almost nothing!


One merely needs to stipulate that builtin names have not been rebound 
to give the answer: n is bound to 3. In the absence of code or text 
specifying otherwise, that is the reasonable default assumption and the 
one that most makes when reading code.


Restricting the usage of Python's flexibility does not make it another 
language. It makes it the actual language that the vast majority of 
programs are written in and that people assume when reading code.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Monday, April 7, 2014 6:15:47 AM UTC+5:30, Terry Reedy wrote:
 On 4/6/2014 7:48 PM, Steven D'Aprano wrote:
  On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote:
  Steven D'Aprano :
  On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:
  Python, BTW, is perfectly suitable for computer science.
  I don't think it is. Python is not a pure functional language, so it's
  very difficult to prove anything about the code apart from running it.
  Many classic CS ideas are expressed in terms of an Algol-like language.
  Nothing would prevent you from framing those ideas in a Python-like
  (pseudo)language. The question is mostly whether you prefer begin/end,
  braces or indentation.
  Okay, I made an error in stating that it's because Python is not a pure
  functional language. It's because Python is so dynamic that it is very
  difficult to prove anything about the code apart from running it. Take
  this code-snippet of Python:
  n = len([1, 2, 3])
  What can we say about it? Almost nothing!

 One merely needs to stipulate that builtin names have not been rebound 
 to give the answer: n is bound to 3. In the absence of code or text 
 specifying otherwise, that is the reasonable default assumption and the 
 one that most makes when reading code.

 Restricting the usage of Python's flexibility does not make it another 
 language. It makes it the actual language that the vast majority of 
 programs are written in and that people assume when reading code.

Well what Steven is saying (I think!) amounts to pointing out a gap:
- the actual language that the vast majority of programs are written in 
- python as in the Cpython (say) implementation

To close this gap requires trying to do what Brett Canon tried and more
generally PyPy tries.

Some small rarely used features which humans can invoke with with a
wave-fo-hands when reasoning about programs, end up being a
show-stopper in an implementation.

Every language has such: Fortran remains better for scientific computing
than C (leave aside C++) because among other things alias analysis for
Fortran arrays is more straightforward.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Monday, April 7, 2014 12:16:54 AM UTC+5:30, Chris Angelico wrote:

On Mon, Apr 7, 2014 at 4:13 AM, Rustom Mody wrote:
Using Python at the design stage would be what Steven's talking about
- actually using it to build the theory of programming. I have about
as much experience in the area as he has, so we can't speak to the
lack of examples, but that's the sort of example it would take.

!Parse Error! What are you saying -- I don get :-)

What I'm saying is that I - and, if my reading is correct, similarly
with Steven - am looking for is a prominent example of someone using
Python as the very basis for a discussion on the future of computer
science *as a field*. So, not here's what can be done with Python,
and not here's something about hydraulics, with some Python code
showing how my theory adds up. If you're developing a cryptography
algorithm, it might well be convenient to support it with Python code
(although I mostly see reference implementations in C), but that's
still using Python as a tool, rather than as a language for
fundamental development of comp sci theories.

Nice example

10 years ago Nicholas Carr wrote an article: Does IT matter?
http://hbr.org/2003/05/it-doesnt-matter/ar/1

| Twenty years ago, most executives looked down on computers as
| proletarian tools—glorified typewriters and calculators—best relegated
| to low level employees like secretaries, analysts, and technicians. It
| was the rare executive who would let his fingers touch a keyboard,
| much less incorporate information technology into his strategic
| thinking. Today, that has changed completely. Chief executives now
| routinely talk about the strategic value of information technology...
|
| Behind the change in thinking lies a simple assumption: that as IT’s
| potency and ubiquity have increased, so too has its strategic
| value. It’s a reasonable assumption, even an intuitive one. But it’s
| mistaken. What makes a resource truly strategic—what gives it the
| capacity to be the basis for a sustained competitive advantage—is not
| ubiquity but scarcity. You only gain an edge over rivals by having or
| doing something that they can’t have or do. By now, the core functions
| of IT—data storage, data processing, and data transport—have become
| available and affordable to all.1 Their very power and presence have
| begun to transform them from potentially strategic resources into
| commodity factors of production. They are becoming costs of doing
| business that must be paid by all but provide distinction to none.

Now replace IT by CS.

CS matters because it has stopped being visible -- entered the woodword.
This is the underlying principle of python replacing scheme for programming
at MIT. Its not that python is a better language. Its rather that
doing the job and getting out of the way is more crucial today than 1980.
http://cemerick.com/2009/03/24/why-mit-now-uses-python-instead-of-scheme-for-its-undergraduate-cs-program/

So cryptographic algos need (typically)
1. An algorithmic language
2. Fast implementations
Python only provides 1, C provides both.So C is more useful (ignoring the
marginal effects of inertia)

Is the diff between cvs/svn and git just one vcs or another?

The theory of version control, or source control, or whatever you want
to call it, can be found in some of the docs for those systems (git
goes into some depth about the Directed Acyclic Graph that underpins
everything), but that theory isn't what makes git or cvs/svn useful.

The theory behind my MUD client Gypsum is that it should be built
the way a server is, including that it should not need to be restarted
even when there's new code to be loaded in; but that's not what makes
Gypsum useful.

The theory behind an ergonomic keyboard is that it should hurt your
hands less than a classic keyboard does, but that's not what makes it
useful. Actually, in that instance, it might be what makes it
useless...

These examples are very different:
1. MUD I dont know
2. Ergonomic keyboard is a good example.
For a ergonomic keyboard to be useful it has to satisfy the precondition
Not more than a δ neighborhood away from QWERTY
3. Git: We differ on whats the underlying theory. For me crucial is
a. Peer-to-peer replacing client-server -- this gives the D in DVCS
b. Branching as central to software (more generally any material) development
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:

 On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote:
 It is academic because the author, Raymond Smullyan, was a professor
 of philosophy and, more importantly, my professor selected that as a
 textbook for us graduate students.

 Ah. Well they do that, don't they? I've always consider the ability of
 professors to select their own book as text to be a classic case of
 conflict of interest. They're supposed to pick the best book, not
 necessarily the one that earns them money.

Note that my professor above was not Raymond Smullyan.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-06 Thread Steven D'Aprano

On Sun, 06 Apr 2014 20:45:47 -0400, Terry Reedy wrote:

 On 4/6/2014 7:48 PM, Steven D'Aprano wrote:
 On Sun, 06 Apr 2014 23:10:47 +0300, Marko Rauhamaa wrote:

 Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:

 On Sun, 06 Apr 2014 12:05:16 +0300, Marko Rauhamaa wrote:
 Python, BTW, is perfectly suitable for computer science.

 I don't think it is. Python is not a pure functional language, so
 it's very difficult to prove anything about the code apart from
 running it.

 Many classic CS ideas are expressed in terms of an Algol-like
 language. Nothing would prevent you from framing those ideas in a
 Python-like (pseudo)language. The question is mostly whether you
 prefer begin/end, braces or indentation.

 Okay, I made an error in stating that it's because Python is not a pure
 functional language. It's because Python is so dynamic that it is very
 difficult to prove anything about the code apart from running it. Take
 this code-snippet of Python:

 n = len([1, 2, 3])

 What can we say about it? Almost nothing!
 
 One merely needs to stipulate that builtin names have not been rebound
 to give the answer: n is bound to 3. 

But if I can do that, I can also stipulate that len() has been rebound to 
a function that ignores its argument and always returns the string 
Surprise!. In that case, n is bound to the string Surprise!. I can 
prove that this code snippet does almost *anything*, just be making some 
assumption about len.

The point is that one cannot derive much about the behaviour of Python 
code except by analysing the whole program, which is a very difficult 
problem, and often not even then. The only way to be sure what value is 
bound to len at the time that code snippet is executed is to actually run 
the code up to that code snippet and then look. In practical terms, 
things are not quite as bleak as I've made out: a little bit of runtime 
analysis goes a long way, as the success of PyPy, Numba, Cython and Psyco 
prove. That's why optimizers like PyPy generally produce code like this:

if some guard condition is true:
run fast optimized branch
else:
fall back on standard Python 

where the guard condition is generally checked at runtime, not at compile 
time.

But *in isolation*, you can't tell what len will be bound to unless you 
wait until runtime and look. A peephole optimizer that replaced a call 
like len([1,2,3]) with the constant 3 every time it sees it would be 
*wrong*.


 In the absence of code or text
 specifying otherwise, that is the reasonable default assumption and the
 one that most makes when reading code.

Well of course, but the requirements of an optimizer or correctness 
prover or similar is much higher than just this is a reasonable default 
assumption. 


 Restricting the usage of Python's flexibility does not make it another
 language. It makes it the actual language that the vast majority of
 programs are written in and that people assume when reading code.

That's incorrect. If len were a keyword, and couldn't be shadowed or 
replaced, it would be another language. It is not an accident that you 
can replace len in builtins, it is a deliberate feature of the language.



-- 
Steven
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

Steven D'Aprano st...@pearwood.info:

 That's why optimizers like PyPy generally produce code like this:

 if some guard condition is true:
 run fast optimized branch
 else:
 fall back on standard Python 

There you go! You are using Python-esque syntax to communicate a CS
idea.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Chris Angelico

On Sat, Apr 5, 2014 at 4:29 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Chris Angelico ros...@gmail.com writes:

 I would suggest that the more prolific posters are going to be those
 who use Python more (and thus it's worth investing more time in),
 which is going to skew the post stats towards the professional end of
 the spectrum.

 It's also plausible that the more prolific posters are those who spend
 *less* time actually coding, and instead spend their free time being
 prolific in this forum.

Heh. Very true.

 Other explanations are plausible. Any of them could be contributing
 factors in any mixture.

 Without actual data – which neither of us has on this matter – all of
 these hypotheses are unfounded speculation. Let's not draw any
 conclusions in the absence of evidence.

Not to mention that there's not a lot of difference between an
unemployed professional coder and a serious hobbyist. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Ben Finney

Mark H Harris harrismh...@gmail.com writes:

 On 4/5/14 12:02 AM, Ian Kelly wrote:
  A fork is undesirable because it fragments the community.  I don't
  think fear or panic are the right words for it.

Yes. I get that.

So, you get that “fear” and “panic” are not the right words to
characterise the undesirability Ian describes.

Did you use those words anyway, despite knowing they're not the right
words to use?

Or did you think they were the right words to use, and now you've
changed your position? I don't see where that happened, so I'm confused.

Or do you still think they are the correct words to use, but now wish to
distance yourself from that position?

This may seem trivial, but I'm trying to get a handle on what it is you
mean to communicate, when your stated position in one message conflicts
with your stated position only a few messages earlier.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, but |
  `\  where will we find an open tattoo parlor at this time of |
_o__)   night?” —_Pinky and The Brain_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Mark H Harris


On 4/5/14 1:01 AM, Ben Finney wrote:

Mark H Harris harrismh...@gmail.com writes:


On 4/5/14 12:02 AM, Ian Kelly wrote:

A fork is undesirable because it fragments the community.  I don't
think fear or panic are the right words for it.


Yes. I get that.


So, you get that “fear” and “panic” are not the right words to
characterise the undesirability Ian describes.


   Not so much. I 'get' his point about community fragmentation. I 
disagree that 'fear' is not the correct word. Its semantics, really, but 
the root is 'fear' of community fragmentation. This is something less 
than 'fear' as in terror, or fear as in irrational, or fear as in 
childish (or something like that).



Did you use those words anyway, despite knowing they're not the right
words to use?


   Often decisions are made within tension (fear) that the price of 
consequences will not warrant the effort, nor heroism. I believe that 
decisions should be made because its the right thing to do, and not 
because, if we force this too soon there will be a fork, kinda thing. 
Decision out of fear is not good. Conservative posturing within tension 
might be good, as long as its not carried out too far.



Or did you think they were the right words to use, and now you've
changed your position? I don't see where that happened, so I'm confused.


   You might be confused because you expect me to have a position. My 
opinions are often also floating on a continuum (just like everything 
else).  I try to keep an open mind, consider all views, allow for the 
fact that I'm constantly learning and don't know everything, humble 
enough to know that others can teach me, and above all else willing to 
hold truth gently and humbly.



Or do you still think they are the correct words to use, but now wish to
distance yourself from that position?


   In Ian's case he may, in point of fact, be concerned for the 
fragmentation of the community and he might not be fearful; in which 
case fear would not be the right word for his concern. On the other 
hand, in point of fact, if Ian (or anyone else) fears the fragmentation 
of the community that he sees as the consequence of forking C python, 
then 'fear' would be the right word to use. Just say'n.
   I don't really have a position (as it were) to distance myself from, 
but I do have a concern about the perceived awkward conservative snail 
pace with regard to C python 3.x migration. I mean, its not about being 
slothful (nor anything like that) but it appears to be 'concern' for 
constituents (of one kind and another). That 'appearance' is in my view 
the 'fear' of consequence with a too-quick migration plan (its been way 
drawn out so far).
   I personally want python 3.3+ on my android devices. Well, QPython 
is stuck on 2.7.2 because why? Twisted does not fully work on 3.x yet. 
What's the solution? Get Twisted up to speed. (gevent is similar).
   Now, I don't think QPython will want to maintain a fork. I also 
don't think they will want to stay on 2.7.2 forever, because they will 
want security patches. They will eventually get up to speed when Twisted 
is ready. What I wish the C python community would do is to apply just a 
little pressure here so that the Twisted community is motivated to move 
a little faster.  This is taking too long, and yes, I think the core 
devs are afraid of offending (or fragmenting) constituents.  I might be 
wrong.



This may seem trivial, but I'm trying to get a handle on what it is you
mean to communicate, when your stated position in one message conflicts
with your stated position only a few messages earlier.


   Very seldom is anything black  white. Always we entertain shades of 
grey and a panacea of color and multiple hues. Sometimes when we are 
thinking out loud (which is itself more than vulnerable) we may be 
interpreted as being contradictory. Often the contradiction is more or 
less a nuance as we're wrestling with our mental heuristics. Often my 
categories overlap, and sometimes those categories have weights that 
shift (or morph) as the discussion continues. Never are we thinking in a 
vacuum, and always we are being influenced and challenged by others 
viewpoints and nuanced opinions. *What position?*  Its a little like 
quantum mechanics and the Heisenberg uncertainty principle--- the more 
you know about my position, the less you know about how I arrived at it; 
and the more you know about how I arrived at my position the less you 
will know about the locus of the position itself.


   Of course, being able to parse intention with nothing to go on 
except typed English words and without non verbals (oh the pain of it 
all) is at best a quandary fraught with foil and frustration; but none 
the less we persist.  {shrug}



marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Rustom Mody

On Saturday, April 5, 2014 11:27:08 AM UTC+5:30, Chris Angelico wrote:
 On Sat, Apr 5, 2014 at 4:29 PM, Ben Finney wrote:
  Without actual data - which neither of us has on this matter - all of
  these hypotheses are unfounded speculation. Let's not draw any
  conclusions in the absence of evidence.
 
 Not to mention that there's not a lot of difference between an
 unemployed professional coder and a serious hobbyist. :)

Since I started this distinction, I would like to clarify that I dont take it
too seriously.
My impressions:
1. The number of people who read (lurk (on GG!!)) is significantly higher than 
those who post. 3 times? 10 times? Dunno

2. And they fall into an in-between limbo region: ie students -- some formal, 
some informal -- who would like to become python 'professionals' but
dont see themselves as that right now

And in case you missed it, I was suggesting that the idea that python 2
support should be cavalierly dropped implied a completely hobbyist viewpoint.

Professionalism implies at bottom that a client is God even if
he is being an asshole.  Intel, Microsoft, IBM and any successful brick-n-mortar
corp of your choice, will be seen to follow this principle scrupulously
Of course you are free to prefer the '90%'
[Run your favorite search engine on 90 percent of startups...

Of course that does not mean that I find the 'conservatism' of python's choices 
happy.
Here is a recent thread 
https://mail.python.org/pipermail/python-list/2014-February/667169.html
and its contained link http://bugs.python.org/issue2506
I am too far removed from the details to comment on the technical merit of it
However reading it suggests that decisions are being made on 
conservatism is good, change is not basis
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Chris Angelico

On Sat, Apr 5, 2014 at 5:48 PM, Mark H Harris harrismh...@gmail.com wrote:
 On 4/5/14 1:01 AM, Ben Finney wrote:

 Mark H Harris harrismh...@gmail.com writes:

 On 4/5/14 12:02 AM, Ian Kelly wrote:

 A fork is undesirable because it fragments the community.  I don't
 think fear or panic are the right words for it.


 Yes. I get that.


 So, you get that “fear” and “panic” are not the right words to
 characterise the undesirability Ian describes.


Not so much. I 'get' his point about community fragmentation. I disagree
 that 'fear' is not the correct word. Its semantics, really, but the root is
 'fear' of community fragmentation. This is something less than 'fear' as in
 terror, or fear as in irrational, or fear as in childish (or something like
 that).

In that case, don't quote both sentences and say I get that, because
people will interpret that to mean that you get both of them. You do
have the power to edit quoted text and insert your responses in the
exact right places.

Often decisions are made within tension (fear) that the price of
 consequences will not warrant the effort, nor heroism. I believe that
 decisions should be made because its the right thing to do, and not
 because, if we force this too soon there will be a fork, kinda thing.
 Decision out of fear is not good. Conservative posturing within tension
 might be good, as long as its not carried out too far.

I avoid stepping out onto the road in front of a truck, out of fear
that the truck will hit me and break the screen on my laptop. (And
secondarily, because getting hit will hurt. Priorities.) Is that a bad
decision? At what point does something stop being conservative
posturing or sane decision-making and start being a decision out of
fear?

I personally want python 3.3+ on my android devices. Well, QPython is
 stuck on 2.7.2 because why? Twisted does not fully work on 3.x yet. What's
 the solution? Get Twisted up to speed. (gevent is similar).
Now, I don't think QPython will want to maintain a fork. I also don't
 think they will want to stay on 2.7.2 forever, because they will want
 security patches. They will eventually get up to speed when Twisted is
 ready. What I wish the C python community would do is to apply just a little
 pressure here so that the Twisted community is motivated to move a little
 faster.  This is taking too long, and yes, I think the core devs are afraid
 of offending (or fragmenting) constituents.  I might be wrong.

Why 2.7.2? That can't be because of Twisted. There must be some other
reason for not upgrading within 2.7.

Very seldom is anything black  white. Always we entertain shades of grey
 and a panacea of color and multiple hues.

(You may mean a rainbow of color or something, but not a panacea,
which is a quite different thing. According to the Baroness von
Krakenfeldt, old wine is a panacea - as long as someone else pays the
bill.)

And yet ultimately, many things *are* black and white. There is truth,
and there is falsehood. Something may be accurate to a greater or
lesser degree (if I say that the human body is mostly water, then
I'm correct; if I say the human body is about 60% water then I'm
more correct, but if I say the human body is 95.2423% water, then
I'm flat out wrong), but correctness is absolute. It's impossible to
conduct a sane debate if those participating do not at least attempt
to maintain a position, and acknowledge when that position changes.
There's nothing wrong with shifting, if done graciously and without
trying to pretend that you haven't shifted. (After all, that's usually
the point of a debate - to have two extreme positions progressively
clarified and shifted until they come into agreement.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Chris Angelico

On Sat, Apr 5, 2014 at 5:59 PM, Rustom Mody rustompm...@gmail.com wrote:
 Professionalism implies at bottom that a client is God even if
 he is being an asshole.

Not really :) Sometimes, your employer or client just has to go jump.
Professionalism implies that you treat your client at least as well as
s/he deserves, and try to solve his/her problems. If that becomes
impractical, your client can find a new Charlie. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Steven D'Aprano

On Sat, 05 Apr 2014 00:02:58 -0500, Mark H Harris wrote:

 Having said that, I do believe that the migration to C python3 has
 been too conservative. 

Why? Is it a race? Does Python 2.x turn into PHP at midnight?

Some people think the move to Python 3 has been too radical and too fast 
for them. Are they wrong?


 Nobody wants to maintain a fork, not really.

There will be no serious fork of Python 2.7.

Oh, I dare say that when the core developers finally announce Python 2.7 
is end-of-lifed, probably in another five or so years, there will be a 
flurry of cheap talk about forking Python, and maybe even a few 
Python2.8 projects on Github. But nobody will use them, and they will 
fade away into obscurity. I can't see *anyone* with the necessary  
resources taking on the job and gathering enough community support for a 
successful fork.

With perhaps one exception. Twisted has apparently said they cannot 
migrate to 3.x. They might, I suppose, take up maintenance of Python 2.7. 
But I doubt it. I expect that when push comes to shove in 4 or 5 years 
time, they'll find a way to migrate.

Python 2.7 will continue to get paid-for support from RedHat until 2024, 
and I expect that there will be companies like Activestate that will 
offer extended support for Python 2.7 for a few years too. But that's it.


 I don't think its something anyone should be afraid of.

Nobody is *afraid* of a fork. But forks do split the community, and 
introduce FUD (Fear, Uncertainty, Doubt), except for the rare occasions 
like the XFree86 to X.Org fork where the entire community moved almost 
overnight to the fork. That was a HUGE vote of no confidence to the 
original maintainer, and (so I'm told) deservedly so.

Nothing like that is plausible with Python. There simply isn't anywhere 
near that level of dissatisfaction with the way the language is being 
managed, mild grumbling from a few people aside. Most importantly, the 
core devs have been *very* responsive to people's complaints.


 Somebody should
 put a date on C python 3.4+ migration and cut off support for 2.7.x/

2045-04-01. If you're not migrated to Python 3.4 by then, no cake for you.

A date will be set when the time is right, but rushing to set a date now 
when we don't know the state of the language in five years time is just 
silly. It is expected to be five years from now, but if there is a flurry 
of migration activity it may be brought forward, and if five years is not 
long enough it may be delayed. *May* be delayed. 

It's fine if people don't migrate to 3.4. Waiting until 3.5 or even 3.6 
is perfectly acceptable too. Leaving it to 3.7 (expected about 5 years 
from now) is probably okay too. The longer you wait to migrate, the 
easier it will be: migrate when the benefit of migrating exceeds the cost.

(I'm talking about application-level projects here. Libraries and 
frameworks are somewhat different.)

Each point release of 3.x has added not just new features to entice 
users, but new features (and sometimes old features) to aid in porting. 
For example, some things that had been dropped, like the callable() built-
in, were re-added in 3.2. 3.3 re-added the u'' syntax solely to aid in 
porting from 2.x. There is a lot of discussion going on to make it easier 
to deal with mixed bytes and ASCII text, which is a very important use-
case which by accident was suited well to the Python 2.x byte-string 
model, but not well suited to the Python 3.x unicode-text versus bytes 
model. You should expect that to come into production in 3.5.


 Its
 just an opinion. If 'Twisted' isn't ready for 3.x, well, they need to
 get ready. 


Are you volunteering to do the work for them?


 That's also just an opinion.

Ah, but is it an *informed* opinion? Do you know why Twisted say they 
cannot migrate to 3.x?




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Terry Reedy


On 4/5/2014 6:19 AM, Steven D'Aprano wrote:


Oh, I dare say that when the core developers finally announce Python 2.7
is end-of-lifed, probably in another five or so years,


Bug fixing will end in May/June 2015 with 2.7.8, maybe 2.7.9. It will 
probably start tapering off before that on the basis that fixes may 
break working code that has worked around bugs. I am not sure how long I 
will backport Idle patches.


Code-only security patches after that? Undecided. I think PEP 466 
defines what the focus will be -- keeping 2.7 web apps from becoming bad 
internet citizens.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-05 Thread Roy Smith

In article 533fd894$0$29993$c3e8da3$54964...@news.astraweb.com,
 Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:

 Twisted has apparently said they cannot migrate to 3.x. They might, I 
 suppose, take up maintenance of Python 2.7. But I doubt it. I expect 
 that when push comes to shove in 4 or 5 years time, they'll find a 
 way to migrate.

Is Twisted really that relevant?  I know they've been around for a long 
time, and there are a few high-profile projects using them, but I get 
the impression they've become a bit of a legacy product by now, and 5 
years from now, I suspect that will be even more true.

Their big claim to fame was the ability to do asynchronous I/O in 
Python.  There's other ways to do that now.

 Nobody is *afraid* of a fork. But forks do split the community, and 
 introduce FUD 

A classic example would be the BSD world (Free, Net, Open, Dragonfly, 
and a host of minor players).  There's a lot of really smart people 
working on those projects, but they're all pushing in different 
directions.  Meanwhile, Linux ate their lunch.

 Somebody should
 put a date on C python 3.4+ migration and cut off support for 2.7.x/
 
 2045-04-01. If you're not migrated to Python 3.4 by then, no cake for you.

But, somewhere, somebody will still be running XP on their desktop, and 
haggling with Microsoft over another deadline extension.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, 04 Apr 2014 09:43:15 +1100, Chris Angelico wrote:

 While I am interested in seeing a Decimal literal syntax in Python, and
 I would support a shift to have 1.2 evaluate as a Decimal (but not
 soon - it'd break backward compat *hugely*)

I used to think the same thing, but have since learned that it's not a 
coincidence or accident that people seriously interested in numerical 
computation nearly always stick to binary floats. I think it's a little 
harsh to say that only dilettantes and amateurs use base-10 floats, but 
only a little. Base-10 has one, and only one, thing going for it: the 
number you type (in decimal) is the number you get (within the limits of 
precision). Apart from that, in every way IEEE-754 binary floats are as 
good or better than any other choice of base, including decimal. The same 
floating-point complications that plague binary floats also plague 
decimal ones, only worse.

I really should stop being shocked by anything I learn about floating 
point numbers, but something that knocked my socks off when I learned it 
was that as simple an operation as taking the average of two floats is 
problematic in decimal. In base-2, and given round-to-nearest division, 
(x+y)/2 is always within the range x...y. But that's not necessarily the 
case in base-10 floats: sometimes the average of two numbers is not 
between those two numbers. Contrast binary floats:

py x = 0.77787516
py y = 0.77787518
py (x + y) / 2
0.77787517


with decimal:

py from decimal import *
py getcontext().prec = 16
py x = Decimal(0.77787516)
py y = Decimal(0.77787518)
py (x + y) / 2
Decimal('0.77787515')

Guido, why can't Python do maths???

(Oh lordy, can you imagine Ranting Rick getting onto that???)

I've changed my mind about Python using Decimal as the default numeric 
type. I think that would send a very strong message that Python is not 
for serious numeric work.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, Apr 4, 2014 at 6:52 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 py x = Decimal(0.77787516)
 py y = Decimal(0.77787518)
 py (x + y) / 2
 Decimal('0.77787515')

 I've changed my mind about Python using Decimal as the default numeric
 type. I think that would send a very strong message that Python is not
 for serious numeric work.

Hmm. Good point. (I'm not familiar with your notation, by the way;
assuming x...y includes both endpoints? The first thing that comes to
mind is git's revision syntax, in which x and y would be
tags/commits/branches and that would give you everything that's in
those branches but not in their common parent. And I doubt very much
that's what you mean!) So I go back to a previous form of the
request/desire: that the AST store numeric literals as their original
strings (maybe as well as the parsed version), such that an AST
transform can replace all float literals with Decimal literals (if
they exist, or calls to Decimal and string args if they don't).

 print(ast.dump(ast.parse(print(0.1 + 0.2
Module(body=[Expr(value=Call(func=Name(id='print', ctx=Load()),
args=[BinOp(left=Num(n=0.1), op=Add(), right=Num(n=0.2))],
keywords=[], starargs=None, kwargs=None))])

Possibly the easiest way - and maybe I should shift this part of the
discussion to -ideas - would be to have Num nodes retain additional
meta-information, in the same way that nodes retain line/column info.
Then it would be relatively simple to write a Decimal-mode hook for
IDLE that would turn it into a Decimal calculator instead of a binary
float calculator. Adding Decimal as a supported type (which would have
to happen if Python gets Decimal literals, but could be done in other
ways too) would help, though it's not strictly necessary.

 mod=ast.parse(print(0.1 + 0.2))
 exec(compile(mod,-,exec))
0.30004

 mod.body[0].value.args[0].left.n=Decimal(0.1)
 mod.body[0].value.args[0].right.n=Decimal(0.2)
 exec(compile(mod,-,exec))
Traceback (most recent call last):
  File pyshell#28, line 1, in module
exec(compile(mod,-,exec))
TypeError: non-numeric type in Num

But it can still be done, as long as it's possible to go back to the
original string - which currently it's not, short of parsing the
entire Python program manually.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 py from decimal import *
 py getcontext().prec = 16
 py x = Decimal(0.77787516)
 py y = Decimal(0.77787518)
 py (x + y) / 2
 Decimal('0.77787515')

 Guido, why can't Python do maths???

Well, you need to work within the system:

 (5*x + 5*y) / 10
Decimal('0.77787517')

Actually, I have no idea whether that formula can be relied upon or
the correctness of the above was just luck.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Mark Lawrence


On 04/04/2014 03:29, Mark H Harris wrote:


Now, about Python2.  It has not died.  It appears to be 'useful'.
The perceived reality is that Python2 is 'useful'.  Or, is it as I
perceive it, python2 is embedded in so many places that it must be
maintained for a long time because so many code(s) will break otherwise?
Not so much 'useful' as 'used,' so that it is never sacked.
Or, is it really that python2 is so much more 'suitable for a particular
purpose' ('useful') that certain folks just don't want to use python3?
Beats me; the community will have to decide.



For a lot of people, if it ain't broke, don't fix it.

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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Thu, 03 Apr 2014 11:38:13 -0500, Mark H Harris wrote:

 On 4/1/14 5:33 PM, Terry Reedy wrote:
 
 hi Terry, hope you are well today, despite gmane difficulties;
 
 If you narrowly meant The python interpreter only starting using
 unicode as the default text class in 3.0, then you are, in that narrow
 sense, correct.
 
 Yes. When I speak of 'python' I am almost always speaking about the
 interpreter.

Which interpreter? PyPy, Numba, Nuitka, or perhaps even the newest in the 
family, Pyston?

https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-
python-implementation/

Wait, all of those are compilers! Nuitka is a static compiler, the others 
are JIT compilers. Perhaps you meant Jython, IronPython, or Stackless? 
They're all interpreters.

Ah, they're compilers too! Specifically, byte-code compilers. There's 
even a compile() built-in function.

I'm not just being pedantic for the sake of being annoying[1], there's an 
important point here. Namely, that we shouldn't conflate Python the 
language with any one specific compiler or interpreter. Not even -- 
*especially* not even -- CPython the reference implementation.

So we have Python *the language*, and any of a number of implementations. 
By my count, including experimental, obsolete and abandoned versions, I 
know of at least 50 different implementations, at least 10 of which might 
count as the Python interpreter for somebody. So the question is, when 
you speak of Python, do you mean *a specific implementation*, or do you 
mean *the language*?



 If I speak of the python community, and I rarely do, I
 explicitly use the word 'community'. I am concerned with backward
 compatibility in my own stuff, but I am primarily interested in python3,
 and I have made the conscious decision to use only python3 moving
 forward, except in those cases (like QPython 2.7.2 on the Android
 platform ). So, python(3)'s use of unicode is exciting, not only as a
 step forward for the python interpreter, but also as a leadership step
 forward in computer science around the world.

I appreciate your enthusiasm, but let's not get too excited. Python is 
neither the first, nor the most influential, language to include Unicode. 
And as for it being a leadership step in computer science, that's 
rather like me proclaiming that my local take-away Italian restaurant 
shifting to gluten-free pasta is a revolution in chemistry.

Python is not a computer-science-ey language. It is of little or no 
interest to computer scientists involved in the mathematics of 
computation, or compiler-theory, or type-theory, or any of the other 
academic disciplines under comp-sci. It's true that you might get a 
semester or two of learning Python in a comp-sci course (but more likely 
to be Java), but that's only because students have to be taught 
*something*. Comp-sci researchers are far more likely to be using 
something like Mercury or Haskell, not Python.

Unicode is completely uninteresting to comp-sci. Whether strings contain 
127 symbols or 1114112 or 2 is just a boring detail.


[...]
 On the python unicode continuum version (3) is more useful than
 version (2). ( this is of course relative and debatable, so the
 statement is rhetorical ) 


Now that's funny. You make a completely non-controversial statement, that 
Python 3's Unicode implementation is more useful (i.e. more functionally 
complete, fewer design flaws, more efficient) than Python 2's, and *that* 
is the claim that you smother to death in disclaimers. Whereas other 
statements you make, which sometimes have been as wrong as an utterly 
wrong thing, you've been prepared to go to the battlements and fight to 
the death over.




[1] Although that's a bonus *wink*


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, 04 Apr 2014 02:13:13 -0600, Ian Kelly wrote:

 On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 py from decimal import *
 py getcontext().prec = 16
 py x = Decimal(0.77787516) py y =
 Decimal(0.77787518) py (x + y) / 2
 Decimal('0.77787515')

 Guido, why can't Python do maths???
 
 Well, you need to work within the system:
 
 (5*x + 5*y) / 10
 Decimal('0.77787517')
 
 Actually, I have no idea whether that formula can be relied upon or the
 correctness of the above was just luck.


And what happens when x+y would have been calculated correctly, but one, 
or both, of 5*x or 5*y loses catastrophically loses accuracy due to 
overflow?

py x = 3.1e307
py y = 3.3e307
py (x+y)/2
3.2e+307
py (5*x+5*y)/10
inf

(I've used regular floats here out of laziness, the same principle 
applies to Decimals -- there will be *some* number x which is finite, but 
5*x overflows to infinity.)



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Rustom Mody

On Friday, April 4, 2014 3:23:31 PM UTC+5:30, Steven D'Aprano wrote:
 On Thu, 03 Apr 2014 11:38:13 -0500, Mark H Harris wrote:
 
  On 4/1/14 5:33 PM, Terry Reedy wrote:
  
  hi Terry, hope you are well today, despite gmane difficulties;
  
  If you narrowly meant The python interpreter only starting using
  unicode as the default text class in 3.0, then you are, in that narrow
  sense, correct.
  
  Yes. When I speak of 'python' I am almost always speaking about the
  interpreter.
 
 
 
 Which interpreter? PyPy, Numba, Nuitka, or perhaps even the newest in the 
 family, Pyston?
 
 
 
 https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-
 python-implementation/
 
 Wait, all of those are compilers! Nuitka is a static compiler, the others 
 are JIT compilers. Perhaps you meant Jython, IronPython, or Stackless? 
 They're all interpreters.
 
 Ah, they're compilers too! Specifically, byte-code compilers. There's 
 even a compile() built-in function.
 
 
 I'm not just being pedantic for the sake of being annoying[1], 

I thought you were being statistic... Now who was the chap with the
new statistics module?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Terry Reedy


On 4/4/2014 5:53 AM, Steven D'Aprano wrote:

On Thu, 03 Apr 2014 11:38:13 -0500, Mark H Harris wrote:


On 4/1/14 5:33 PM, Terry Reedy wrote:

If you narrowly meant The python interpreter only starting using
unicode as the default text class in 3.0, then you are, in that narrow
sense, correct.


I really should have said 3.0 was the first version of Python (the 
language) to specify that code and strings are unicode



 Yes. When I speak of 'python' I am almost always speaking about the
interpreter.


Which interpreter?


Since the unicode change is a language and not an interpreter issue, it 
does not matter.


 Unicode is completely uninteresting to comp-sci. Whether strings
 contain 127 symbols or 1114112 or 2 is just a boring detail.

Until CS researchers want to write academic papers with non-ascii 
symbols ;-).



On the python unicode continuum version (3) is more useful than
version (2). ( this is of course relative and debatable, so the
statement is rhetorical )


Now that's funny.


I agree.

 You make a completely non-controversial statement, that

Python 3's Unicode implementation is more useful (i.e. more functionally
complete, fewer design flaws, more efficient) than Python 2's, and *that*
is the claim that you smother to death in disclaimers.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, Apr 4, 2014 at 4:08 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 On Fri, 04 Apr 2014 02:13:13 -0600, Ian Kelly wrote:

 On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 py from decimal import *
 py getcontext().prec = 16
 py x = Decimal(0.77787516) py y =
 Decimal(0.77787518) py (x + y) / 2
 Decimal('0.77787515')

 Guido, why can't Python do maths???

 Well, you need to work within the system:

 (5*x + 5*y) / 10
 Decimal('0.77787517')

 Actually, I have no idea whether that formula can be relied upon or the
 correctness of the above was just luck.


 And what happens when x+y would have been calculated correctly, but one,
 or both, of 5*x or 5*y loses catastrophically loses accuracy due to
 overflow?

 py x = 3.1e307
 py y = 3.3e307
 py (x+y)/2
 3.2e+307
 py (5*x+5*y)/10
 inf

 (I've used regular floats here out of laziness, the same principle
 applies to Decimals -- there will be *some* number x which is finite, but
 5*x overflows to infinity.)

I thought that Decimals had arbitrary-precision exponents, at least in
the pure Python version.  Turns out that's wrong; although the
context.Emax can be set to any int in the pure Python version, it
can't be removed entirely.  One could just temporarily upgrade the
Emax for the above calculation, but the pure Python version was made
inconvenient to use voluntarily in CPython 3.3, and the C version has
strict limits.

In any event, the exponent limits for decimals are much higher than
for floats (the default Emax is 99, and it can be set roughly
within the limits of C integer precision), so any case where you'll
get overflow with a Decimal is already far beyond the point where
you'd have gotten overflow with a float.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 3:20 AM, Mark Lawrence wrote:

On 04/04/2014 03:29, Mark H Harris wrote:


Now, about Python2.  It has not died.  It appears to be 'useful'.
{snip}



For a lot of people, if it ain't broke, don't fix it.



hi Mark, yes that's my point. I have heard rumors of python2.8? At some 
point I would expect that the Cpython interpreter would 'freeze' and no 
one would fix it any longer. I have a serious question, namely, why does 
the Cpython community continue to suppport two interpreters rather than 
asking the Cpython user-base to migrate to Cpython3?


Oh, I have another serious question about implementations. I'm not sure 
about (50) implementations, but I know that Jython and IronPython are 
serious contenders (although, I have not, nor probably will, use them).


Are the other implementation communities *also* supporting two versions 
of the language?   Is there a Jython2 also a Jython3 ?


marcus
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, Apr 4, 2014 at 2:58 PM, Mark H Harris harrismh...@gmail.com wrote:
 On 4/4/14 3:20 AM, Mark Lawrence wrote:

 On 04/04/2014 03:29, Mark H Harris wrote:


 Now, about Python2.  It has not died.  It appears to be 'useful'.
 {snip}


 For a lot of people, if it ain't broke, don't fix it.


 hi Mark, yes that's my point. I have heard rumors of python2.8?

The Python 2.8 release schedule is documented in PEP 404:

http://legacy.python.org/dev/peps/pep-0404/

 At some
 point I would expect that the Cpython interpreter would 'freeze' and no one
 would fix it any longer. I have a serious question, namely, why does the
 Cpython community continue to suppport two interpreters rather than asking
 the Cpython user-base to migrate to Cpython3?

2.6 and 2.7 exist to ease the pain of migration, which is far from
trivial.  Eventually users still on 2.x will need to upgrade, but you
can't force them to do it on your own schedule.  That path will just
end up driving them to another language, or to a fork of 2.7.

 Oh, I have another serious question about implementations. I'm not sure
 about (50) implementations, but I know that Jython and IronPython are
 serious contenders (although, I have not, nor probably will, use them).

 Are the other implementation communities *also* supporting two versions of
 the language?   Is there a Jython2 also a Jython3 ?

There is no Jython3 or IronPython3 yet.  PyPy is currently supporting
both 2.7 and 3.2.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Mark Lawrence


On 04/04/2014 21:58, Mark H Harris wrote:

On 4/4/14 3:20 AM, Mark Lawrence wrote:

On 04/04/2014 03:29, Mark H Harris wrote:


Now, about Python2.  It has not died.  It appears to be 'useful'.
{snip}



For a lot of people, if it ain't broke, don't fix it.



hi Mark, yes that's my point. I have heard rumors of python2.8? At some
point I would expect that the Cpython interpreter would 'freeze' and no
one would fix it any longer. I have a serious question, namely, why does
the Cpython community continue to suppport two interpreters rather than
asking the Cpython user-base to migrate to Cpython3?

Oh, I have another serious question about implementations. I'm not sure
about (50) implementations, but I know that Jython and IronPython are
serious contenders (although, I have not, nor probably will, use them).

Are the other implementation communities *also* supporting two versions
of the language?   Is there a Jython2 also a Jython3 ?

marcus


You could answer all of the above for yourself if you were to use your 
favourite search engine.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 4:50 PM, Mark Lawrence wrote:


You could answer all of the above for yourself if you were to use your
favourite search engine.


hi Mark, yeah, condescending as that is, been there done that.

See this link as just one example:

http://blog.startifact.com/posts/python28-discussion-channel-on-freenode.html


   Follow the nextpost- links for a while... at least the first two. 
You'll get a flavor for what I'm asking about.


   Its always better to get a straight answer from the core people than 
to rely on rumors and fork discussions found on google.


   PEP 404 is hilarious; I missed that one.


marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 9:07 AM, Mark H Harris harrismh...@gmail.com wrote:
 On 4/4/14 4:50 PM, Mark Lawrence wrote:

 You could answer all of the above for yourself if you were to use your
 favourite search engine.


 hi Mark, yeah, condescending as that is, been there done that.

Its always better to get a straight answer from the core people than to
 rely on rumors and fork discussions found on google.

Yes, because python-list responses are *so* much more reliable than
official statements on python.org, which are easily found with a
Google search. Or a DuckDuckGo search. Or a Bing search. Or probably
even gopher, we're not partisan here.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 5:39 PM, Chris Angelico wrote:

Yes, because python-list responses are *so* much more reliable than
official statements on python.org,


{/sarcasm off}

... from some responders. The discussion following such posts is also 
*much* more valuable, too.  IMHO


Python.org is the political place to start; but its not much good after 
that, in regards the forking of 2.7 -- 2.8


As Ian points out, you can't expect a complete migration on the PSF 
schedule (2-3), because of the fear|panic  of a fork. So, 
comp.lang.python is the best place to find out where the Cpython 
community is, and where they expect to go (for that discussion).


I realize that many of Cpython's user-base will never read 
comp.lang.python, and then the Internet is an open field for trying to 
discern where 'they' are at, and where 'they' want to go.


What I'm trying to say is that I tap many resources (comp.lang.python is 
just one of them) and I'm going to tap that source even though I also 
tap the Internet with a google search (and others).


Eeyore doesn't like to be bugged, by double line spaces, nor by 
questions. What's the point of having a comp.lang.python news list if 
its not open for simple questions of opinion?  Yes, I know google is my 
friend.   Comp.lang.python should be my friend too.


(and others)


marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 9:52 AM, Mark H Harris harrismh...@gmail.com wrote:
 On 4/4/14 5:39 PM, Chris Angelico wrote:

 Yes, because python-list responses are *so* much more reliable than
 official statements on python.org,


 {/sarcasm off}

 ... from some responders. The discussion following such posts is also *much*
 more valuable, too.  IMHO

 Python.org is the political place to start; but its not much good after
 that, in regards the forking of 2.7 -- 2.8

Official statements on python.org are the perfect place to find out
whether or not there'll be a 2.8. And that's exactly what PEP 404
details.

 As Ian points out, you can't expect a complete migration on the PSF schedule
 (2-3), because of the fear|panic  of a fork. So, comp.lang.python is the
 best place to find out where the Cpython community is, and where they expect
 to go (for that discussion).

What *is* the PSF schedule? Have you read that? Do you know when the
PSF expects all code to transition from Py2 to Py3? Because you can
find that on python.org too (at least some estimates).

 What I'm trying to say is that I tap many resources (comp.lang.python is
 just one of them) and I'm going to tap that source even though I also tap
 the Internet with a google search (and others).

 Eeyore doesn't like to be bugged, by double line spaces, nor by questions.
 What's the point of having a comp.lang.python news list if its not open for
 simple questions of opinion?  Yes, I know google is my friend.
 Comp.lang.python should be my friend too.

You're certainly free to ask. And we're free to tell you to use a
search engine to find authoritative responses :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Mark Lawrence


On 04/04/2014 23:52, Mark H Harris wrote:


As Ian points out, you can't expect a complete migration on the PSF
schedule (2-3), because of the fear|panic  of a fork. So,
comp.lang.python is the best place to find out where the Cpython
community is, and where they expect to go (for that discussion).



Fear/panic of a fork, where did that come from?  It's certainly the 
first I've ever heard of it.


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


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, 04 Apr 2014 15:58:29 -0500, Mark H Harris wrote:

 Oh, I have another serious question about implementations. I'm not sure
 about (50) implementations, 

Here's a list. Which ones you count as actual implementations of Python 
and which are not may be a matter of opinion. (Do translators count? 
Supersets and subsets of the language? How many changes can one make 
before you have a completely different language? I haven't included 
obviously different languages like Cobra and Delight.)

Berp, Brython, CLPython, CPython, CapPython, ChinesePython, Compyler, 
Copperhead, Cython, HoPe, HotPy, IronPython, Jython, Kivy, Mypy, Mython, 
Nuitka, Numba, Parakeet, Parallel Python, Perthon, Pippy, Psyco, Py4A, 
PyMite, PyMT, PyPad, PyPy, PyQNX, PyVM, Pycorn, Pyjamas, Pynie, 
Pystachio, Pyston, Python for .NET, Python for OS/2, Python for S60, 
Python-iPod, Python2C, Pythonce, Pythonium Core, Pythran, QPython, 
RapydScript, Shedskin, Skulpt, Stackless, TinyPy, Typhon, UnPython, 
Unladen Swallow, Vyper, WPython

As I said, some of these may be abandoned, obsolete, experimental, or 
even vapourware. Some are probably just ports of CPython to another 
platform rather than completely independent implementations. The big 
four are CPython, IronPython, Jython and PyPy, although Stackless is 
still maintained and in active use as part of the EVE Online game. 
Stackless is older than all of them except CPython itself. Cython is a 
superset of Python, but it is capable of running pure Python code, so it 
counts as a Python compiler, and is in very active development and use. 
Nuitika is a static compiler written by a developer willing to go against 
the conventional wisdom that JIT compilers are the way to go for dynamic 
languages like Python, and he claims to have impressive speedups.


 but I know that Jython and IronPython are
 serious contenders (although, I have not, nor probably will, use them).

If you are using a Debian-based system, it is trivial to install them via 
apt-get or aptitude:

sudo aptitude install jython ironpython


 Are the other implementation communities *also* supporting two versions
 of the language?   Is there a Jython2 also a Jython3 ?

Not Jython or IronPython yet. As far as I know, the implementations which 
support Python 3 are CPython, Cython, Kivy, Nuitika and PyPy.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, 04 Apr 2014 11:01:48 -0600, Ian Kelly wrote:

 On Fri, Apr 4, 2014 at 4:08 AM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 On Fri, 04 Apr 2014 02:13:13 -0600, Ian Kelly wrote:

 On Fri, Apr 4, 2014 at 1:52 AM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 py from decimal import *
 py getcontext().prec = 16
 py x = Decimal(0.77787516) py y =
 Decimal(0.77787518) py (x + y) / 2
 Decimal('0.77787515')

 Guido, why can't Python do maths???

 Well, you need to work within the system:

 (5*x + 5*y) / 10
 Decimal('0.77787517')

 Actually, I have no idea whether that formula can be relied upon or
 the correctness of the above was just luck.


 And what happens when x+y would have been calculated correctly, but
 one, or both, of 5*x or 5*y loses catastrophically loses accuracy due
 to overflow?

 py x = 3.1e307
 py y = 3.3e307
 py (x+y)/2
 3.2e+307
 py (5*x+5*y)/10
 inf

 (I've used regular floats here out of laziness, the same principle
 applies to Decimals -- there will be *some* number x which is finite,
 but 5*x overflows to infinity.)
 
 I thought that Decimals had arbitrary-precision exponents, at least in
 the pure Python version.  Turns out that's wrong; although the
 context.Emax can be set to any int in the pure Python version, it can't
 be removed entirely.  One could just temporarily upgrade the Emax for
 the above calculation, but the pure Python version was made inconvenient
 to use voluntarily in CPython 3.3, and the C version has strict limits.
 
 In any event, the exponent limits for decimals are much higher than for
 floats (the default Emax is 99, and it can be set roughly within the
 limits of C integer precision), so any case where you'll get overflow
 with a Decimal is already far beyond the point where you'd have gotten
 overflow with a float.

If you write the most obvious code that works -- usually a good thing in 
computing, but not always so in numeric computing -- and calculate 
(x+y)/2, with Decimal, most of the time the result will be correct but 
sometimes it won't be. In addition to that problem, if the addition 
overflows you will get an inf instead of the correct answer.

But if you write the tricky code (5*x+5*y)/10, you may eliminate the 
failure cases, but at the cost that while it will still overflow to inf 
in the same cases as before, now it will also overflow in a whole lot of 
cases that *would have worked correctly* if only you had written the 
obvious code. There's no free lunch here.

You might argue that this doesn't matter, since the problem values for x 
and y have been moved from scattered values everywhere to only(?) 
values so huge that surely nobody will care. Apart, of course, those 
people who do care. Still, I'm sympathetic to the idea that swapping 
average doesn't work right for really humongous numbers overflow 
sooner than they otherwise would have counts as a win.

But of course, neither of us know what other problems this tricky code 
will introduce. Perhaps it fixes the failures for *some* values of x and 
y, but introduces a different set of failures for *other* values of x and 
y. I'm not quite good enough at numeric analysis to rule that out, 
although I haven't tried very hard. (The division by 10 is obviously just 
a shift, so its error is at most 0.5 ULP. But I'm not sure about the 
multiplications by 5.)

But all of this is missing the really important point. Isn't the 
(supposed) move to Decimal-by-default supposed to *simplify* numeric 
calculations, not complicate them? Do we really expect the average non-
expert to write (5*x+5*y)/10 instead of the obvious (x+y)/2?

There's no doubt that binary floating point calculations are tricky 
beasts, and while IEEE-754 semantics mean that they just about always do 
the right thing, still, serious numeric work is half advanced mathematics 
and half voodoo. Base-10 floats don't improve that situation, they make 
it worse.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 11:00 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 As I said, some of these may be abandoned, obsolete, experimental, or
 even vapourware. Some are probably just ports of CPython to another
 platform rather than completely independent implementations.

Python for OS/2 is definitely just a port. It's built from as close to
unmodified sources as possible, and doesn't (deliberately) add/remove
any features or anything. On the other hand, there's a Python for
Android which may be a separate project. (Or is that the Py4A you
referred to?)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Terry Reedy


On 4/4/2014 6:07 PM, Mark H Harris wrote:

On 4/4/14 4:50 PM, Mark Lawrence wrote:


You could answer all of the above for yourself if you were to use your
favourite search engine.


hi Mark, yeah, condescending as that is, been there done that.


Since there *are* people who use python-list as a substitute, it does 
not hurt to mention searches done, the result, along with what you still 
want to know.



Its always better to get a straight answer from the core people than
to rely on rumors and fork discussions found on google.


I am a core developer and I am 99.99% sure that the core developers will 
not produce a CPython 2.8. For one thing we will likely do instead, see

http://legacy.python.org/dev/peps/pep-0466/

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 2:04 PM, Terry Reedy tjre...@udel.edu wrote:
 I am a core developer and I am 99.99% sure that the core developers will not
 produce a CPython 2.8. For one thing we will likely do instead, see
 http://legacy.python.org/dev/peps/pep-0466/

There's also been talk of a potential compiler change for the Windows
builds, which otherwise only ever happens at minor releases. Is there
a PEP to link people to about that?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Rustom Mody

On Saturday, April 5, 2014 2:28:29 AM UTC+5:30, Mark H. Harris wrote:
 hi Mark, yes that's my point. I have heard rumors of python2.8? At some 
 point I would expect that the Cpython interpreter would 'freeze' and no 
 one would fix it any longer. I have a serious question, namely, why does 
 the Cpython community continue to suppport two interpreters rather than 
 asking the Cpython user-base to migrate to Cpython3?

Computer-hobbyists and computer-professionals are quite different sets of 
people.

Are you aware 
That people FORTRAN, COBOL, mainframes are still in use?
That people deep in those would not be amused if their systems suddenly stopped 
working?
That some of the above people have not clue that the world around is not 
exactly in the same state they see it?
And that YOU would not be amused if your credit card suddenly stopped working?
(very likely running in some cloistered COBOL mainframe env).


IOW: 
1. Python is a fun language; its also a serious language
2. Python is not as old as FORTRAN and COBOL but at 20 years its not exactly 
young either
3. Its reached so far because core-devs behave responsibly towards different 
constituencies
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Terry Reedy


On 4/4/2014 11:22 PM, Chris Angelico wrote:

On Sat, Apr 5, 2014 at 2:04 PM, Terry Reedy tjre...@udel.edu wrote:

I am a core developer and I am 99.99% sure that the core developers will not
produce a CPython 2.8. For one thing we will likely do instead, see
http://legacy.python.org/dev/peps/pep-0466/


There's also been talk of a potential compiler change for the Windows
builds, which otherwise only ever happens at minor releases. Is there
a PEP to link people to about that?


Not that I know of.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 6:16 PM, Mark Lawrence wrote:

Fear/panic of a fork, where did that come from?  It's certainly the
first I've ever heard of it.



hi Mark, it came from Ian; or, my interpretation of Ian. It comes out on 
the net too (from various places). Here is Ian's quote, then my comment:



Eventually users still on 2.x will need to upgrade, but you
can't force them to do it on your own schedule.  That path will just
end up driving them to another language, or to a fork of 2.7.


The sentiment behind this last quote is essentially fear (and that is 
natural). Its basically the tension between (I'm speaking as the royal 
we here) we don't want folks to be driven away from Cpython as a 
language, and we don't want them to fork the Cpython interpreter, so 
we'll take a very casual and methodically conservative approach to 
nudging people towards a Cpython3 migration route ( I am speaking not 
for the community, just hypothetically trying to get at the gist of 
Ian's quote);  please forgive me if I didn't quite get it.


I spent most of the afternoon reading this:


http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html


This doc is long, thorough in detail, and mostly complete. Its a great 
read. The migration is not trivial, and it can't happen in one fell 
swoop, either.



marcus
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 10:04 PM, Terry Reedy wrote:

I am a core developer and I am 99.99% sure that the core developers will
not produce a CPython 2.8. For one thing we will likely do instead, see
http://legacy.python.org/dev/peps/pep-0466/



Thanks Terry. The back-port sounds great; I find the Rejected 
alternatives interesting. I think this must be where I was getting the 
gist that 2.8 might be an option--- just all the discussion that went on 
trying to figure out what to do with the security issues.


I notice a good bit on unicode there too.


marcus
--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 7:00 PM, Steven D'Aprano wrote:


Berp, Brython, CLPython, CPython, CapPython, ChinesePython, Compyler,
Copperhead, Cython, HoPe, HotPy, IronPython, Jython, Kivy, Mypy, Mython,
Nuitka, Numba, Parakeet, Parallel Python, Perthon, Pippy, Psyco, Py4A,
PyMite, PyMT, PyPad, PyPy, PyQNX, PyVM, Pycorn, Pyjamas, Pynie,
Pystachio, Pyston, Python for .NET, Python for OS/2, Python for S60,
Python-iPod, Python2C, Pythonce, Pythonium Core, Pythran, QPython,
RapydScript, Shedskin, Skulpt, Stackless, TinyPy, Typhon, UnPython,
Unladen Swallow, Vyper, WPython


   Thanks for this list.


As I said, some of these may be abandoned, obsolete, experimental, or
even vapourware. Some are probably just ports of CPython to another
platform rather than completely independent implementations.


   The only one I've used regularly is QPython (on Android) which is 
apparently a 2.7.2 port. Its relatively slow but 'useful' because its 
obviously highly mobile, which gives me the opportunity to 
code-on-the-go, or try a new idea in those awkward times when only a 
cell-phone is convenient for the venue.



but I know that Jython and IronPython are
serious contenders (although, I have not, nor probably will, use them).


If you are using a Debian-based system, it is trivial to install them via
apt-get or aptitude:

 sudo aptitude install jython ironpython


   Its has always seemed to me that Java or C++ would be better suited 
to creating python. I wonder will C always be the standard canonical PSF 
python interpreter base language? Has the C python community considered 
making the standard base language Java or C++ ?



marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 3:10 PM, Mark H Harris harrismh...@gmail.com wrote:
 we don't want folks to be driven away from Cpython as a language, and we
 don't want them to fork the Cpython interpreter, so we'll take a very casual
 and methodically conservative approach to nudging people towards a Cpython3
 migration route

If it's too much work to make the changes to move something from
Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite
it in a different language. There would have to be some strong other
reason for shifting, especially since there's a 2to3 but not a
PytoRuby. And forking is a pretty huge job; someone's gotta maintain
it. What's more likely is that, once python.org stops maintaining
Python 2.x at all, people will just stay on 2.7.9 or whatever the last
version is, without any bugfixes. Companies like Red Hat will be
looking at security patches (which is what PEP 466 is all about), but
only to the extent that they have people willing to put in the work to
make and test them. After that, it'll be like running old versions of
anything else: you weigh the cost of migrating to the new version
against the risk of exploits if you don't move. It's that simple.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 3:31 PM, Mark H Harris harrismh...@gmail.com wrote:
Its has always seemed to me that Java or C++ would be better suited to
 creating python. I wonder will C always be the standard canonical PSF python
 interpreter base language? Has the C python community considered making the
 standard base language Java or C++ ?

Java you know about (Jython); what's the advantage of C++ over C? A
Python interpreter needs to do broadly this:

1) Parse a text file into an abstract syntax tree
2) Compile the AST into bytecode
3) Execute the bytecode:
3a) Manage object lifetimes and garbage collection
3b) Perform lower-level calls
3c) Efficiently handle namespaces etc

Java has an advantage over C in that 3a can be done by the JVM. (At
least, I believe that's how Jython does it; a Python object is backed
by a Java object, and every Python object that references another
Python object is backed by a corresponding reference to the
corresponding Java object, so the JVM knows about all object
lifetimes.) C++ doesn't have that, at least not normally (and I've
never really liked most C++ garbage collectors - maybe there's a good
one that I've not yet met), so all you'd really gain is 3b, in that
you could conveniently pass jobs down to a lower-level C++ library.
(Java also gains this advantage - or maybe disadvantage, as you can
easily interface to other Java code but not so easily to C code.) Most
programming languages make it easy to talk to C code, ergo most
libraries are written for C interfaces, ergo most programming
languages don't need C++. The only case I can think of is Google's V8
interpreter (ECMAScript), which uses C++ bindings to handle scoping;
it's nice and easy as long as you embed V8 in a C++ program, and not
so easy if you're going back and forth between the two languages; at
that point, it basically reverts to a C-like interface, so there's no
advantage.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, Apr 4, 2014 at 10:10 PM, Mark H Harris harrismh...@gmail.com wrote:
 On 4/4/14 6:16 PM, Mark Lawrence wrote:

 Fear/panic of a fork, where did that come from?  It's certainly the
 first I've ever heard of it.


 hi Mark, it came from Ian; or, my interpretation of Ian. It comes out on the
 net too (from various places). Here is Ian's quote, then my comment:


 Eventually users still on 2.x will need to upgrade, but you
 can't force them to do it on your own schedule.  That path will just
 end up driving them to another language, or to a fork of 2.7.


 The sentiment behind this last quote is essentially fear (and that is
 natural). Its basically the tension between (I'm speaking as the royal we
 here) we don't want folks to be driven away from Cpython as a language, and
 we don't want them to fork the Cpython interpreter, so we'll take a very
 casual and methodically conservative approach to nudging people towards a
 Cpython3 migration route ( I am speaking not for the community, just
 hypothetically trying to get at the gist of Ian's quote);  please forgive me
 if I didn't quite get it.

A fork is undesirable because it fragments the community.  I don't
think fear or panic are the right words for it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 10:42 PM, Rustom Mody wrote:


Computer-hobbyists and computer-professionals are quite different sets of 
people.

   I know its just a gut feel, and I know there are a lot of lurkers 
here too, but it seems that there are *way* more folks from the 
professional camp on comp.lang.python than otherwise. Do you have a gut 
feel for the % of hobbyists vs. professionals participating here?



Are you aware
That [people?] FORTRAN, COBOL, mainframes are still in use?


Well, the S390 is still in use (running gnu/linux these days) and 
the z series machines from IBM. FORTRAN and COBOL have government 
(military) niche. I remember during the Y2K problem COBOL coders were 
working their butts off.  There is a 2014 standard doc replacing the 
2002 standard, believe.
The last time I used FORTRAN IV was in about 1977, on the 
System360-44, but GNU still supports it, and as far as I know it still 
has a wide user group (mostly academic). I have it on my system here, 
but I don't use it.



1. Python is a fun language; its also a serious language


   A very serious language;  yes, its fun too.


2. Python is not as old as FORTRAN and COBOL but at 20 years its not exactly 
young either


   It won't have its day until it becomes ubiquitous... and its coming! 
 As the gnu/linux numbers continue to climb, more everyday is C python 
becoming ubiquitous. I'm hoping the ubiquitous version is C python 3.4+



3. Its reached far because core-devs behave responsibly
towards different constituencies


   I think its because the language is flexible, extensible, powerful 
(batteries included), and is supported by a world-wide community of 
software engineers (both amateur and professional) who are committed to 
its development and adoption world-wide. The PEP process has had a lot 
to due with this (and not to ape the BDFL) it has had a lot to due with 
some Dutch genius.;-)
   However, knowing your user-base is certainly important. Its always a 
problem (any venue, any environment) to try to please everyone. Tough 
choices have to be made. The C python community does a pretty good job 
of this. Python-ideas and the PEP process are a unique and unparalleled 
strategy for enhancement. Very nice.
   Having said that, I do believe that the migration to C python3 has 
been too conservative. Nobody wants to maintain a fork, not really. I 
don't think its something anyone should be afraid of. Somebody should 
put a date on C python 3.4+ migration and cut off support for 2.7.x/ 
Its just an opinion. If 'Twisted' isn't ready for 3.x, well, they need 
to get ready. That's also just an opinion.



marcus


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Fri, Apr 4, 2014 at 10:40 PM, Chris Angelico ros...@gmail.com wrote:
 On Sat, Apr 5, 2014 at 3:10 PM, Mark H Harris harrismh...@gmail.com wrote:
 we don't want folks to be driven away from Cpython as a language, and we
 don't want them to fork the Cpython interpreter, so we'll take a very casual
 and methodically conservative approach to nudging people towards a Cpython3
 migration route

 If it's too much work to make the changes to move something from
 Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite
 it in a different language. There would have to be some strong other
 reason for shifting, especially since there's a 2to3 but not a
 PytoRuby.

For whatever the current project is, yes -- if there's no route to
Python 3 then they will simply be stuck on Python 2.7 indefinitely.
However, if Python is perceived as a language that doesn't provide
backward compatibility and long-term maintainability via some
migration path, then users will be less likely to pick Python for
their *next* project.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 11:40 PM, Chris Angelico wrote:

If it's too much work to make the changes to move something from
Python 2.7 to Python 3.3, it's *definitely* too much work to rewrite
it in a different language.


   Totally, no doubt.


There would have to be some strong other
reason for shifting, especially since there's a 2to3 but not a
PytoRuby. And forking is a pretty huge job; someone's gotta maintain
it.


   I agree there, too. That's why I don't think anyone should worry 
about a new program, nor about a fork. Nobody really wants to fork a 
programming language, esp one like python. It takes an entire team of 
dedicated people to support it--- jut not worth trying to do that.



What's more likely is that, once python.org stops maintaining
Python 2.x at all, people will just stay on 2.7.9 or {snip}

 After that, it'll be like running old versions of

anything else: you weigh the cost of migrating to the new version
against the risk of exploits if you don't move. It's that simple.


   Yup, totally agree.  So, just do it.  Probably after 3.4 will be the 
right time. Beats me.



marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 4:02 PM, Mark H Harris harrismh...@gmail.com wrote:
I know its just a gut feel, and I know there are a lot of lurkers here
 too, but it seems that there are *way* more folks from the professional camp
 on comp.lang.python than otherwise. Do you have a gut feel for the % of
 hobbyists vs. professionals participating here?

Impossible to say. However, I would suggest that the more prolific
posters are going to be those who use Python more (and thus it's worth
investing more time in), which is going to skew the post stats towards
the professional end of the spectrum.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/4/14 11:49 PM, Chris Angelico wrote:

On Sat, Apr 5, 2014 at 3:31 PM, Mark H Harris harrismh...@gmail.com wrote:

Its has always seemed to me that Java or C++ would be better suited to
creating python. I wonder will C always be the standard canonical PSF python
interpreter base language? Has the C python community considered making the
standard base language Java or C++ ?


what's the advantage of C++ over C?
A Python interpreter needs to do broadly this:

1) Parse a text file into an abstract syntax tree
2) Compile the AST into bytecode
3) Execute the bytecode:
3a) Manage object lifetimes and garbage collection
3b) Perform lower-level calls
3c) Efficiently handle namespaces etc



The only advantage of C++ over C is polymorphism, really. There are in 
my view only three reasons to even use C++: 1) the iostream library, and 
2) polymorphism, and 3) operator overloading. If you need to do all 
three, then C++ is a really good candidate.


I am still thinking about the concept of unifying Number; Number as a 
C++ abstract base class, and an entire Class hierarchy which carries 
through making *any* Number just work. The ability of the C++ compiler 
to construct and maintain the virtual function tables would be an 
advantage. Operator overloading (and maybe templates) would make C++ 
advantageous also.


Guido told me that the modern C python is object oriented. Operator 
overloading is a big part of this. It seems to me that a modern object 
oriented language would best be implemented with a true object oriented 
base language, C++ rather than C.  I have always questioned this, just 
curious why the decision for C was made--- historically, 
methodologically, and maybe scientifically.


It would be tons of work, but maybe not as much as one might think, 
initially.



marcus


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-04 Thread Ben Finney

Chris Angelico ros...@gmail.com writes:

 I would suggest that the more prolific posters are going to be those
 who use Python more (and thus it's worth investing more time in),
 which is going to skew the post stats towards the professional end of
 the spectrum.

It's also plausible that the more prolific posters are those who spend
*less* time actually coding, and instead spend their free time being
prolific in this forum.

Other explanations are plausible. Any of them could be contributing
factors in any mixture.

Without actual data – which neither of us has on this matter – all of
these hypotheses are unfounded speculation. Let's not draw any
conclusions in the absence of evidence.

-- 
 \ “I went to the cinema, it said ‘Adults: $5.00, Children $2.50’. |
  `\  So I said ‘Give me two boys and a girl.’” —Steven Wright |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/5/14 12:02 AM, Ian Kelly wrote:

A fork is undesirable because it fragments the community.  I don't
think fear or panic are the right words for it.



   Yes. I get that. I think what is desired (just thinking out loud 
from my own vantage point) is a unified community, but also a foundation 
of perceived permanence. The PSF establishes this to a certain extend, 
as well the PEP process, and to some extent the communities willingness 
to support two interpreters. It looks like C python is here to stay; I 
can count on it for my projects years into the future.


--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

On Sat, Apr 5, 2014 at 4:23 PM, Mark H Harris harrismh...@gmail.com wrote:
 The only advantage of C++ over C is polymorphism, really. There are in my
 view only three reasons to even use C++: 1) the iostream library, and 2)
 polymorphism, and 3) operator overloading. If you need to do all three, then
 C++ is a really good candidate.

The iostream library actually gives you very little over the stdio
functions (printf, FILE*, etc), beyond that they're arguably easier to
use. (I say arguably because there've been plenty of times when I've
been writing C++ code and just not bothered with cout, finding printf
the better option. Sometimes you find yourself arguing with cout and
it's not worth arguing with.)

Operator overloading, ultimately, is just this:

x + y
// becomes
x.operator+(y)
// or
operator+(x,y)

When you're actually writing C++ code, that's a huge advantage in
readability. But if you're writing an interpreter for another
language, there's no benefit; you may as well not bother. Maybe it'd
be of value if you want to write a Python-to-C++ translator that then
lets you compile the resulting C++ code, but only if you want the C++
code to be readable.

So all you're left with is polymorphism. Well, big problem: Python and
C++ have distinctly different semantics for multiple inheritance. It
wouldn't be possible, much less practical, to try to implement
Python's MRO on top of a C++ class structure, other than by basically
ignoring the whole structure and using it much the same way PyObject *
is used in the existing C code.

 I am still thinking about the concept of unifying Number; Number as a C++
 abstract base class, and an entire Class hierarchy which carries through
 making *any* Number just work. The ability of the C++ compiler to construct
 and maintain the virtual function tables would be an advantage. Operator
 overloading (and maybe templates) would make C++ advantageous also.

The virtual function tables don't cater for the MRO, see above. But
even with simple single inheritance, the effort of creating a new
class at run-time would be quite a problem; remember, 'class' in C++
is a declaration to the compiler, but 'class' in Python is an
executable statement.

 Guido told me that the modern C python is object oriented. Operator
 overloading is a big part of this. It seems to me that a modern object
 oriented language would best be implemented with a true object oriented base
 language, C++ rather than C.  I have always questioned this, just curious
 why the decision for C was made--- historically, methodologically, and maybe
 scientifically.

Python is object oriented, and it has operator overloading. But it's
possible to implement operator overloading in a language that doesn't
have it - it's not OOPs all the way down, turtle-style - so somewhere
there has to be that boundary, and building one object oriented
language on top of another doesn't necessarily actually give many
benefits.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-03 Thread Terry Reedy


On 4/1/2014 5:26 PM, Mark H Harris wrote:


 I didn't really start using unicode
until about 5 years ago; python has only really used it since python3.
right?


If you narrowly meant The python interpreter only starting using 
unicode as the default text class in 3.0, then you are, in that narrow 
sense, correct. If you meant something broader, if by 'python' you meant 
'the python community' or 'python programmers', then you are wrong.



 No. Python 2.2 introduced Unicode.


2.0, as someone else corrected.


 I didn't ask when it was introduced, I asked when it became useful?


It was useful immediately when introduced. Do you really think we would 
add something useless, and that no one wanted to use?  Core developers 
constantly ask 'What is the practical use case?' in response to 
suggested additions.


For either question, your original answer is wrong.


No you didn't.


Does not matter. The answer he gave to the question he claims he asked, 
and the elaboration below, is wrong.



Yes, I did.


Fine. You asked 'When did unicode in Python become useful.'
Answer: 2.0, not 3.0. Most unicode use in Python is still running on 
Python 2. It works well enough that people are reluctant to migrate 
working and tested production code. End of discussion?


 Our common English is apparently getting in the way.

Well, I speak American English, and you don't, apparently; U.K.?


I hear, speak, read, and write standard American English.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/1/14 5:33 PM, Terry Reedy wrote:

   hi Terry, hope you are well today, despite gmane difficulties;


If you narrowly meant The python interpreter only starting using
unicode as the default text class in 3.0, then you are, in that narrow
sense, correct.


   Yes. When I speak of 'python' I am almost always speaking about the 
interpreter. If I speak of the python community, and I rarely do, I 
explicitly use the word 'community'. I am concerned with backward 
compatibility in my own stuff, but I am primarily interested in python3, 
and I have made the conscious decision to use only python3 moving 
forward, except in those cases (like QPython 2.7.2 on the Android 
platform ). So, python(3)'s use of unicode is exciting, not only as a 
step forward for the python interpreter, but also as a leadership step 
forward in computer science around the world.



 I didn't ask when it was introduced, I asked when it became useful?


It was useful immediately when introduced. Do you really think we would
add something useless, and that no one wanted to use?  Core developers
constantly ask 'What is the practical use case?' in response to
suggested additions.


   'Useful' must always be taken in context, and also contextually 
evaluated with an on-going methodology which constantly informs 
'usefulness' on a continuum. I admire and encourage the core devs, in 
their pursuit of excellence. Asking 'what is the practical use case?' is 
essential. Not always is the answer complete.
   On the python unicode continuum version (3) is more useful than 
version (2). ( this is of course relative and debatable, so the 
statement is rhetorical ) The commitment and dedicated effort to move 
forward with a unicode default is not only commendable, but also admits 
to the 'usefulness' of same. Its not that version 2 was useless, its 
just that version 3 is so much more useful that people are 'using' it 
and dedicating their resources moving forward with python3.
   This is similar to the decimal module. Of course it had limited 
usefulness in version(2) thru 3.2/  but now, python3.3+ the decimal 
module is truly useful! Why? Glad you asked... because it is now fast 
enough for use cases previously reserved for floats. I found limited 
usefulness for decimal prior to 3.3, but now we're finding decimal so 
useful that some of us are wanting decimal to be the default. ( all of 
this is also relative and debatable )



Fine. You asked 'When did unicode in Python become useful.'
Answer: 2.0, not 3.0. Most unicode use in Python is still running on
Python 2. It works well enough that people are reluctant to migrate
working and tested production code. End of discussion?


   Sure. Yes, this is sad. Python2 works. Python2 is inconsistent, and 
troublesome. ( I do not mean that to be insulting, not in the least, its 
just true )
   I've been studying python3 now for several years; cross referencing 
between python2 and python3 has been fun and illuminating, from a 
practical programming standpoint as well as from a standpoint of general 
interest in computer science, and the science of language design. Its 
been a magnificent journey for me (thanks to all of you who provided the 
food for thought, as it were )
   Python3 is not perfect; but python3 is *way* more consistent than 
python2 and consequently *way* more useful than python2. ( this is 
relative, debatable, or even certainly one of those discussions of 
personal preference and taste perhaps ) As we move forward with use 
cases we grow and consequently our language evolves. This is true of the 
spoken word, also true of the comp sci word. In this sense, at this 
time, I would call python2 a 'mess'. Python3 straightened up the 'mess' 
pep after pep.  At what point does do we arrive at 'elegant'?  Beats me.
Maybe when number is unified, decimal is default, scientists are free to 
mix literals of all types in a convenient and intelligent way. But, for 
the moment, python3 is elegant---and very useful.  No doubt Python4 will 
build upon that; perhaps we will come to think of python3 as a mess?



I hear, speak, read, and write standard American English.



   ~nice.   Trouble is, as we've stated before, most of our comm in 
life is non verbal.  So, even in the best (E)scale effectiveness we are 
at a loss because mailing lists and news servers lose the non verbals, 
the smiles, and shrugs, the waves, and the handshakes. rats()


Enjoy your day Terry.


PS   I just thought of another example along the lines of continual 
usefulness: IDLE. (you've worked on IDLE, right?) IDLE is now useful ! 
---a few years back, not so much.  That is not to say that IDLE was 
*never* useful back in the day (it always has been, to some extent), but 
since it has matured over the years it is at a point now where it really 
can be the default (very useful) development interface for code and 
test. Its now stable, does what it advertises, and provides a clean 
simple environment that is pleasant to work

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-03 Thread Marko Rauhamaa

Mark H Harris harrismh...@gmail.com:

 So, python(3)'s use of unicode is exciting, not only as a step forward
 for the python interpreter, but also as a leadership step forward in
 computer science around the world.

Big words. I don't think computer science has experienced major steps
forward since the 1930's: combinatory logic, the Turing machine, the
Entscheidungsproblem, the halting problem,...

The one major latter-day addition is complexity theory (1960's).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-03 Thread Rustom Mody

On Thursday, April 3, 2014 10:44:16 PM UTC+5:30, Marko Rauhamaa wrote:
 Mark H Harris:

  So, python(3)'s use of unicode is exciting, not only as a step forward
  for the python interpreter, but also as a leadership step forward in
  computer science around the world.

 Big words. I don't think computer science has experienced major steps
 forward since the 1930's: combinatory logic, the Turing machine, the
 Entscheidungsproblem, the halting problem,...

 The one major latter-day addition is complexity theory (1960's).

 Marko

Umm...
There is science and there is science
Those who think Einstein the greatest are not likely to consider Edison.

And vice versa :D
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/3/14 12:14 PM, Marko Rauhamaa wrote:

Mark H Harris harrismh...@gmail.com:


So, python(3)'s use of unicode is exciting, not only as a step forward
for the python interpreter, but also as a leadership step forward in
computer science around the world.


Big words. I don't think computer science has experienced major steps
forward since the 1930's: combinatory logic, the Turing machine, the
Entscheidungsproblem, the halting problem,...

The one major latter-day addition is complexity theory (1960's).


hi Marko,  computer science covers everything from a linked list to 
virtual reality, from cpu pipe lining to flash memory, from punched tape 
i/o to plasma displays--- to led back-lit flat panels. Computer science 
also includes theory, and most of what you mention actually had its 
beginnings in mathematics, not computer science. And yet, most of what 
you mention as fundamental to computer science is only the beginning.


The Turning a-machines together (and parallel to) Alonzo Church's lambda 
calculus (diverse methodologies on computability) brought a negative 
answer on the Entscheidungsproblem; so much so that one might even think 
that artificial intelligence were impossible. Alan Turning proved 
(before computers ever existed) that one a-machine may not determine 
whether another a-machine configuration will loop or halt. So what? Do 
we cease to work towards artificial intelligence? Do you believe that 
the AI work at MIT (using lisp) was a non step forwards for artificial 
intelligence; for computer science?


Did not David Hilbert get a kick-in-the-pants? You might have thought 
that mathematics at IAS would have folded its tents and blown away after 
Kurt Gődel proved (mostly as consequence of self-reference) that if an 
axiomatic system is complete it is also inconsistent, and if consistent 
assuredly incomplete!  There are true statements which cannot be proven! 
 Oh, crap. There must be systems of computation for which there is no 
proof, yet function non-the-less. Does this impact computer science 
today; does this impact AI studies today?


We as human beings have only just begun. The human mind is a quantum 
computer. Can a bit be 1 and 0 at the same time??  It most certainly 
can; entanglement is a computational reality that we have only just 
begun to think about let alone comprehend, nor code for (whatever we 
might mean by that).


Mathematicians hate this, but, computers are the way forward for 
mathematics. Computer proofs are increasing; we are discovering that 
proofs of import are requiring computers and computation algorithms. We 
don't through our straight edges and compasses away; nor do we toss out 
our BIC pens and paper. Algorithm is what is needed because the 
mathematics is too complicated. Computer science is moving understanding 
forward with algorithm.


Beyond all of that is communication. That is where unicode comes in. 
Computer science is going to handle the problem of Universal 
Translation. Great strides have been taken towards this already. More 
are sure to come.


שלם

marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-03 Thread Marko Rauhamaa

Mark H Harris harrismh...@gmail.com:

 computer science covers everything from a linked list to virtual
 reality, from cpu pipe lining to flash memory, from punched tape i/o
 to plasma displays--- to led back-lit flat panels.

From the point of view of computer science, those barely register. We
have had a revolution in hardware and software engineering, not computer
science.

 Computer science also includes theory, and most of what you mention
 actually had its beginnings in mathematics, not computer science. And
 yet, most of what you mention as fundamental to computer science is
 only the beginning.

Yes, but not much has taken place since in computer science. Even
virtualization was well covered before WWII from the scientific point of
view.

 Do we cease to work towards artificial intelligence? Do you believe
 that the AI work at MIT (using lisp) was a non step forwards for
 artificial intelligence; for computer science?

Little to write home about so far. Well, having Fritz beat the best
human chess players is impressive, to be sure. A testament to the power
of brute force. Similarly with Google and Big Data. But again, those are
not scientific advances.

 Did not David Hilbert get a kick-in-the-pants? You might have thought
 that mathematics at IAS would have folded its tents and blown away
 after Kurt Gődel proved (mostly as consequence of self-reference) that
 if an axiomatic system is complete it is also inconsistent, and if
 consistent assuredly incomplete! There are true statements which
 cannot be proven! Oh, crap. There must be systems of computation for
 which there is no proof, yet function non-the-less. Does this impact
 computer science today; does this impact AI studies today?

True, the mathematicians gave up on justifying their existence and went
back to counting beads. The foundational excitement still remains in
physics.

What does computer science have to show of late? A better mutual
exclusion algorithm? Dancing trees?

Ok, cryptography has been pretty exciting. The back and forth between
feasibility and unfeasibility. The ongoing cat and mouse.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-03 Thread Chris Angelico

On Fri, Apr 4, 2014 at 3:38 AM, Mark H Harris harrismh...@gmail.com wrote:
'Useful' must always be taken in context, and also contextually evaluated
 with an on-going methodology which constantly informs 'usefulness' on a
 continuum. I admire and encourage the core devs, in their pursuit of
 excellence. Asking 'what is the practical use case?' is essential. Not
 always is the answer complete.
On the python unicode continuum version (3) is more useful than version
 (2). ( this is of course relative and debatable, so the statement is
 rhetorical ) The commitment and dedicated effort to move forward with a
 unicode default is not only commendable, but also admits to the 'usefulness'
 of same. Its not that version 2 was useless, its just that version 3 is so
 much more useful that people are 'using' it and dedicating their resources
 moving forward with python3.
This is similar to the decimal module. Of course it had limited
 usefulness in version(2) thru 3.2/  but now, python3.3+ the decimal module
 is truly useful! Why? Glad you asked... because it is now fast enough for
 use cases previously reserved for floats. I found limited usefulness for
 decimal prior to 3.3, but now we're finding decimal so useful that some of
 us are wanting decimal to be the default. ( all of this is also relative and
 debatable )

So your definition of useful for the Decimal module is fast and
your definition of useful for Unicode is mandated into use.
Neither of those is how any dictionary I know defines that word, and
you're not even consistent (since you said Unicode became useful at
3.0, which didn't - AFAIK - improve its performance any, while 3.3 did
(PEP 393)).

Here's one definition: able to be used for a practical purpose or in
several ways. Does not say anything about performance. Python is
useful in that I am able to wield it to solve my problems. I don't
care that it's slower than C; in fact, a lot of the problems I solve
with Python are interactive, and run to completion faster than I can
notice them. If I use decimal.Decimal or fractions.Fraction in my
code, it is not because it's fast or slow or anything, it is because
that type matches what I want to do with it. Those types are useful to
me because there are situations in which they match my problem. While
I am interested in seeing a Decimal literal syntax in Python, and I
would support a shift to have 1.2 evaluate as a Decimal (but not
soon - it'd break backward compat *hugely*), I do not by any means
believe that Decimal will only become useful when it's the default
non-integer type in source code.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

2014-04-03 Thread alex23


On 4/04/2014 2:38 AM, Mark H Harris wrote:

If I speak of the python community, and I rarely do


Maybe you speak of them rarely but you claim to speak for them 
fairly often.



Python3 is not perfect; but python3 is *way* more consistent than
python2 and consequently *way* more useful than python2.


It's possible for something to become more useful and for the original 
to *also* be useful: Py2 old-style classes were useful even though 
new-style classes were more so. Plone uses Py2's unicode extensively and 
at no point have I thought it useless.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/3/14 5:43 PM, Chris Angelico wrote:


So your definition of useful for the Decimal module is fast and
your definition of useful for Unicode is mandated into use.


   No. I did not define 'useful'.  I placed 'useful' on a continuum 
whereby 'useful' is non definitive  relative. Go read it again. Decimal 
became practical (due to performance enhancement) and therefore 'bumped 
up' on the 'useful' continuum. Unicode in python3 is more 'useful' than 
in python2; yet, useful for a given purpose in *both* (based on user 
preference and suitability for a particular purpose)


   One of the reasons that many of us include a boiler plate legal 
disclaimer about useability in our open source is that suitable for a 
particular purpose, ehem 'useful,' is entirely in the eye(s) of the 
beholder.



Python is
useful in that I am able to wield it to solve my problems.


   Python is 'useful' because I am able to solve my computational 
problems with it. Python3 is *more* 'useful' than Python2 for my 
purposes of computability and computational problem solving--- don't 
look for it in the dictionary.  'Useful' is as 'useful' does. 'Useful' 
is as I perceive it.  'Useful' is also as you perceive it.
   Immanuel kant said, Perception is reality. 'Useful' is perceived 
reality--- a continuum between to extremes--- useless on the one hand, 
and flexible and all-powerful on the other.
   Oh, and by the by, my perceived continuum will 'look' different than 
your perceived continuum. In fact, they might be overlapping but 
probably will be non intersecting (all depending upon our own perceptions).


marcus

--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)


On 4/3/14 9:07 PM, alex23 wrote:

On 4/04/2014 2:38 AM, Mark H Harris wrote:

If I speak of the python community, and I rarely do


Maybe you speak of them rarely but you claim to speak for them
fairly often.


   I am sorry, and I do apologize (genuinely). I knowingly speak for my 
users, because I have their input (positive and negative) and because I 
have a list of likes|dislikes.
   I don't knowingly speak 'for' the python community; except that I 
can see that speaking about|for 'python' the interpreter might get 
interpreted as speaking of|for the 'python community'.  If that occurs I 
assure you that its not intentional (mostly).



Python3 is not perfect; but python3 is *way* more consistent than
python2 and consequently *way* more useful than python2.



It's possible for something to become more useful and for the original
to *also* be useful: Py2 old-style classes were useful even though
new-style classes were more so. Plone uses Py2's unicode extensively and
at no point have I thought it useless.


   Oh, I agree. Again, think of 'useful' on a continuum where 
comparison and contrast is king and queen, and where 'more useful' does 
not make 'less useful' obsolete. Again, prior to the C accelerated 
decimal module for python3.3 I did not use decimal (too slow). That does 
not mean that decimal was 'useless' (I am using it on 2.7.2 with QPython 
on Android with pdeclib). But something happened, decimal became fast 
enough that it is truly 'useful' enough (on the continuum) to be used 
IMHO as default. (that is all rhetorical; no need to argue it)


   Now, about Python2.  It has not died.  It appears to be 'useful'. 
The perceived reality is that Python2 is 'useful'.  Or, is it as I 
perceive it, python2 is embedded in so many places that it must be 
maintained for a long time because so many code(s) will break otherwise?

Not so much 'useful' as 'used,' so that it is never sacked.
Or, is it really that python2 is so much more 'suitable for a particular 
purpose' ('useful') that certain folks just don't want to use python3? 
Beats me; the community will have to decide.


marcus



--
https://mail.python.org/mailman/listinfo/python-list

Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)