Re: code review

[Chris Angelico]

On Sun, Jul 1, 2012 at 4:54 PM, Steven D'Aprano
 wrote:
> Not in English-speaking countries with a culture of writing chained
> comparisons in mathematics and allowing them in natural language:
>
> "Rock is beaten by Paper, is beaten by Scissors".

I would write that as:

Rock is beaten by Paper, and beats Scissors.

That's natural language. Unless you put a "which" in the middle, the
grammar of English demands that the subject be common, not a promoted
object.

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

Re: Re: code review

[Thomas 'PointedEars' Lahn]

Evan Driscoll wrote:

> On 6/30/2012 19:37, Chris Angelico wrote:
>> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney 
>> wrote:
>>> I know of no programming language that
>>> would give a newcomer to Python that expectation. So where is the norm
>>> you're referring to?
>> 
>> C, SQL, REXX, and many other languages.
> 
> Some others: Lua, Javascript, Ruby, O'Caml.

JFTR: Contrary to popular belief there is no programming language named 
"Javascript".  In your second point, you are talking about ECMAScript 
implementations; one of which is _JavaScript_, Netscape's and later 
Mozilla.org's ECMAScript implementation.  Other implementations include that 
of Microsoft, JScript.



-- 
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Thomas 'PointedEars' Lahn]

Evan Driscoll wrote:

> On 6/30/2012 23:45, Evan Driscoll wrote:
>> You may also
>> want to put Java in there as well, as < is effectively not commutative
>> in that language. (I didn't try C#.)
> 
> I guess you could actually put Lua and Ruby into the roughly same
> category as Java too.
> 
> But things get a little nastier in ==, as 'false == false == false'
> evaluates as '(false == false) == false' to 'false' in Java and Lua.
> (Ruby produces a syntax error for this, roughly the Haskell approach.)
> 
> But we have Javascript:

s/Javascript/ECMAScript (implementations)/g

>   1 < 1 < 2
>   => true
>   false == false == false
>   => false

Correct, because

  0. 1 < 1 < 2
  1. (1 < 1) < 2
  2. false < 2
  3. 0 < 2
  4. true

and

  0. false == false == false
  1. (false == false) == false
  2. true == false
  3. false

See also the ECMAScript Language Specification, 5.1 Edition, section 11.9:



-- 
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Ben Finney]

Chris Angelico  writes:

> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney  
> wrote:
> > Thomas Jollans  writes:
> >
> >> My sole point, really, is that "normally", one would expect these two
> >> expressions to be equivalent:
> >>
> >> a < b < c
> >> (a < b) < c
> >
> > What norm gives you that expectation? That's not how those operators
> > work in mathematical notation. I know of no programming language
> > that would give a newcomer to Python that expectation. So where is
> > the norm you're referring to?
>
> C, SQL, REXX, and many other languages.

So, languages without strong typing then. In that case, I revise my
statement: I know of no programming language with strong typing that
would give a newcomer to Python the above expectation.

Since Python does have strong typing, norms about operations from
weakly-typed languages should not be expected to apply.

(Incidentally, PostgreSQL was the SQL implementation I went to, and::

postgres=# SELECT (1 < 2) < 3;
ERROR:  operator does not exist: boolean < integer
LINE 1: SELECT (1 < 2) < 3;
   ^
HINT:  No operator matches the given name and argument type(s). You might 
need to add explicit type casts.

So not all SQL implementations make the mistake of weak typing.)

-- 
 \ “Try adding “as long as you don't breach the terms of service – |
  `\  according to our sole judgement” to the end of any cloud |
_o__)  computing pitch.” —Simon Phipps, 2010-12-11 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Thomas Jollans]

On 07/01/2012 04:06 AM, Steven D'Aprano wrote:
> On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote:
> 
>> As soon as you read it as a ternary operator, 
> 
> Well that's your problem. Why are you reading it as a ternary operator? 
> It isn't one. It is a pair of chained binary operator.
> 
> How can you tell that it is a pair of binary operators, rather than a 
> single ternary operator?
> 
> 1) There are TWO operators, hence a pair, not a single ternary operator;
> 
> 2) each operator takes TWO arguments, not three.

This is simply wrong. The comparisons are not acting as binary operators.

> You can't just arbitrarily stick parentheses around parts of expressions
> and expect the result to remain unchanged. Order of evaluation matters:
>
> 2**3**4 != (2**3)**4
>
> Comparisons are no different. You can't just toss in some arbitrary
> brackets and expect the result to be the same. In the second case, the
> parentheses explicitly turn the comparison into the equivalent of this:

As Chris points out, 2**3**4 == 2**(3**4)

For any chain of actual binary operators, it is possible to place
brackets around binary sub-expressions such that the meaning of the
total expression stays the same. This is true of ALL infix-notated
strictly binary operators. This is not true of Python comparison operators.

If you're inclined to look at operators in terms of how many arguments
they take, then the inescapable conclusion is that a chain of N
comparison operators forms one single (N+1)-term operator because it
cannot be grouped into binary expressions without rephrasing the
expression using "and".

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

Re: code review

[Thomas Jollans]

On 07/01/2012 09:28 AM, Ben Finney wrote:
> Chris Angelico  writes:
> 
>> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney  
>> wrote:
>>> Thomas Jollans  writes:
>>>
 My sole point, really, is that "normally", one would expect these two
 expressions to be equivalent:

 a < b < c
 (a < b) < c
>>>
>>> What norm gives you that expectation? That's not how those operators
>>> work in mathematical notation. I know of no programming language
>>> that would give a newcomer to Python that expectation. So where is
>>> the norm you're referring to?
>>
>> C, SQL, REXX, and many other languages.
> 
> So, languages without strong typing then. In that case, I revise my
> statement: I know of no programming language with strong typing that
> would give a newcomer to Python the above expectation.
> 
> Since Python does have strong typing, norms about operations from
> weakly-typed languages should not be expected to apply.
> 
> (Incidentally, PostgreSQL was the SQL implementation I went to, and::
> 
> postgres=# SELECT (1 < 2) < 3;
> ERROR:  operator does not exist: boolean < integer
> LINE 1: SELECT (1 < 2) < 3;
>^
> HINT:  No operator matches the given name and argument type(s). You might 
> need to add explicit type casts.
> 
> So not all SQL implementations make the mistake of weak typing.)

I don't have PostgeSQL handy just now - what is the result of
(1 < 2 < 3) ? I bet it's the same error, which means the two are still
equivalent.

Look through the part of this thread about languages, and you will see
how unique Python is in this regard. You argument about strong typing
doesn't really hold: in Python, as in some other languages, bool is an
integer type, so it can actually be compared to numbers, so even if
Python used the same rules as Java, chaining comparison operators would
still be valid syntax (if a little silly in most cases)


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

Re: code review

[Devin Jeanpierre]

On Sun, Jul 1, 2012 at 3:28 AM, Ben Finney  wrote:
> Chris Angelico  writes:
>> C, SQL, REXX, and many other languages.
>
> So, languages without strong typing then. In that case, I revise my
> statement: I know of no programming language with strong typing that
> would give a newcomer to Python the above expectation.

OCaml is a language with absurdly strong typing, where a < b < c is
equivalent to (a < b) < c.

Obviously, this only works if c is a boolean, and if a and b are the
same type. Otherwise it is a type error.

Also, you claimed earlier that the notion of associative "<" is not
founded in mathematical notation. It really depends on whose
mathematical notation you use -- there's more than one, you know. For
example, it's reasonable to expect < to be left- or right-associative
in a system like Rick Hehner's Unified Algebra:
http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't
specify it as being one or the other, so by default one would assume
'a < b < c' to be nonsensical.)

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: changes made to my python coded com servers are not taking effect

[Alister]

On Sun, 01 Jul 2012 02:13:23 -0700, Panceisto wrote:

> I assume the old code keeps running in some process somewhere. How to
> fix this?

stop & restart the servers after making the changes



-- 
  Smoking is the leading cause of statistics.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alister]

On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote:

> On 6/30/2012 19:37, Chris Angelico wrote:
>> On Sun, Jul 1, 2012 at 10:08 AM, Ben Finney
>>  wrote:
>>> I know of no programming language that would give a newcomer to Python
>>> that expectation. So where is the norm you're referring to?
>> 
>> C, SQL, REXX, and many other languages.
> 
> Some others: Lua, Javascript, Ruby, O'Caml.
> 
> In fact, the only language I can find that uses infix notation (i.e. no
> Lisp) where it's *not* true that "a < b < c" is equivalent to "(a < b) <
> c" is Haskell -- and that's because < is not associative and "a < b < c"
> is a syntax error. (FWIW this is my favorite approach.) You may also
> want to put Java in there as well, as < is effectively not commutative
> in that language. (I didn't try C#.)
> 
> I've been programming in Python for a few years and this is the first
> time I've seen this. If I had seen that in a program, I'd have assumed
> it was a bug.
> 
> Evan

You would?
I have only been using python for 6 - 12 months but in my past I 
programmed microcontrollers in assembly.

as soon as i saw it i understood it & thought great, like a light bulb 
going on.

I suppose I have the advantage that it is only the taint of BASIC (in the 
home computer era) that I have had to overcome and my programming style 
has not been unduly influenced by c & others.

it is easy to write C, or Pascal or even BASIC in python but why bother, 
why not just use C, Pascal or BASIC in that case?

-- 
I respect faith, but doubt is what gives you an education.
-- Wilson Mizner
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Terry Reedy]

On 7/1/2012 2:54 AM, Steven D'Aprano wrote:


So no, Python has always included chained comparisons, and yes, it is
shameful that a language would force you to unlearn standard notation in
favour of a foolish consistency with other operators. Comparisons aren't
special because they return bools. They are special because of the way
they are used.

C treats comparison operators as if they were arithmetic operators, and
so the behaviour of a chained comparison is the same as the behaviour as
a sequence of arithmetic operators: a foolish consistency. Python treats
comparison operators as comparison operators, and gives them behaviour
appropriate to comparisons.


I considered this a great feature of Python when I first learned it. 
Reading about how rare it is among programming languages to treat 
comparisons in the standard way in mathematics reinforces that.


--
Terry Jan Reedy



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

Re: [ANN] IPython 0.13 is officially out!

[Leo]

On 2012-07-01 01:55 +0800, Fernando Perez wrote:
> - ~6 months of work.
> - 373 pull requests merged.
> - 742 issues closed (non-pull requests).
> - contributions from 62 authors.
> - 1760 commits.
> - a diff of 114226 lines.

Thank you for the hard work.

Leo
-- 
http://mail.python.org/mailman/listinfo/python-list

Fwd: Python-list Digest, Vol 106, Issue 1

[Fabian Doerfler]

(a2 + b2 = c2) = (e < | > P a  P b P c)
Beschreibt eine Disonanz in Genese.
-- Weitergeleitete Nachricht --
Von: 
Datum: 30.06.2012 23:09
Betreff: Python-list Digest, Vol 106, Issue 1
An: 

Send Python-list mailing list submissions to
python-list@python.org

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-list
or, via email, send a message with subject or body 'help' to
python-list-requ...@python.org

You can reach the person managing the list at
python-list-ow...@python.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-list digest..."

Today's Topics:

   1. Re: code review (Alister)
   2. Re: code review (Alister)
   3. Re: code review (Thomas Jollans)
   4. Re: code review (Alain Ketterlin)
   5. Re: code review (Thomas Jollans)
   6. Re: tiffany 0.6.1 released (Christian Heimes)
   7. Re: code review (Terry Reedy)
   8. Re: code review (Martin P. Hellwig)
   9. Re: code review (Thomas Jollans)
  10. Re: code review (Alain Ketterlin)


-- Weitergeleitete Nachricht --
From: Alister 
To: python-list@python.org
Cc:
Date: Sat, 30 Jun 2012 20:25:39 GMT
Subject: Re: code review
On Sat, 30 Jun 2012 12:29:31 +0200, Peter Otten wrote:

> Alister wrote:
>
>> I think I may be on firmer grounds with the next few:
>>
>> isValidPassword can be simplified to
>>
>> def isValidPassword(password:
>> count=len(password)
>> return count>= mud.minpass and count<= mud.maxpass
>>
>> ( I used count to save finding the length of password twice although it
>> probably makes no difference in this scenario)
>
> If you spell it
>
> def is_valid_password(password):
> return mud.minpass <= len(password) <= mud.maxpass
>
> it is even easier to see that you are performing an interval check.

I realise that was possible, that is brilliant! it is exactly how you
would write it ass a mathematical definition.




--
"The only real way to look younger is not to be born so soon."
-- Charles Schulz, "Things I've Had to Learn Over and
   Over and Over"



-- Weitergeleitete Nachricht --
From: Alister 
To: python-list@python.org
Cc:
Date: Sat, 30 Jun 2012 20:30:45 GMT
Subject: Re: code review
On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote:

> On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote:
>> Peter Otten wrote:
>>
>>> If you spell it
>>>
>>> def is_valid_password(password):
>>> return mud.minpass <= len(password) <= mud.maxpass
>>>
>>> it is even easier to see that you are performing an interval check.
>>
>> This is probably a tautology around here, but *what* *a* *great*
>> *programming* *language*.
>>
>>
> Personally, I don't like this feature of the language. I find a ternary
> operator that uses symbols that can also be binary operators confusing
> and inconsistent with the way operators usually work/the way terms are
> usually associated.
>
> It has the charm of being something you'd "naturally" write in the
> context of non-programming mathematics, at the cost of being very odd
> indeed in the context of programming in general and Python in
> particular.

Surely this fits perfectly with the lines 1 & 7 in the zen of python
(import this)
"Beautifull is better than ugly" and "Readability counts"

I find that construct both beautiful and readable, if it cannot be used
in the languages then that is their loss.



--
Removing the straw that broke the camel's back does not necessarily
allow the camel to walk again.



-- Weitergeleitete Nachricht --
From: Thomas Jollans 
To: python-list@python.org
Cc:
Date: Sat, 30 Jun 2012 22:50:43 +0200
Subject: Re: code review
On 06/30/2012 10:30 PM, Alister wrote:
> On Sat, 30 Jun 2012 21:38:58 +0200, Thomas Jollans wrote:
>
>> On 06/30/2012 08:39 PM, Thomas 'PointedEars' Lahn wrote:
>>> Peter Otten wrote:
>>>
 If you spell it

 def is_valid_password(password):
 return mud.minpass <= len(password) <= mud.maxpass

 it is even easier to see that you are performing an interval check.
>>>
>>> This is probably a tautology around here, but *what* *a* *great*
>>> *programming* *language*.
>>>
>>>
>> Personally, I don't like this feature of the language. I find a ternary
>> operator that uses symbols that can also be binary operators confusing
>> and inconsistent with the way operators usually work/the way terms are
>> usually associated.
>>
>> It has the charm of being something you'd "naturally" write in the
>> context of non-programming mathematics, at the cost of being very odd
>> indeed in the context of programming in general and Python in
>> particular.
>
> Surely this fits perfectly with the lines 1 & 7 in the zen of python
> (import this)
> "Beautifull is better than ugly" and "Readability counts"
>
> I find that construct both beautiful and readable, if it cannot be used
> in the languages then that is 

Re: how to use tkinter in python3.2?

[Serhiy Storchaka]

On 01.07.12 07:25, contro opinion wrote:

i have installed  tk  ,how to use tkinker in python3.2?


You must install tk-dev (or whatever it's called on your system) before 
Python building (don't forget to rerun configure).


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

Re: [ANN] IPython 0.13 is officially out!

[Virgil Stokes]

On 01-Jul-2012 13:56, Leo wrote:

On 2012-07-01 01:55 +0800, Fernando Perez wrote:

- ~6 months of work.
- 373 pull requests merged.
- 742 issues closed (non-pull requests).
- contributions from 62 authors.
- 1760 commits.
- a diff of 114226 lines.

Thank you for the hard work.

Leo
I have tried to update 0.12 in Ubuntu 12.04 but as of now it can not find 0.13. 
Any suggestions on how to get it into Ubuntu 12.04 would be appreciated.



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

Re: Re: code review

[Evan Driscoll]

On 7/1/2012 4:54, Alister wrote:
> On Sat, 30 Jun 2012 23:45:25 -0500, Evan Driscoll wrote:
>> If I had seen that in a program, I'd have assumed it was a bug.
> 
> You would?
> I have only been using python for 6 - 12 months but in my past I 
> programmed microcontrollers in assembly.
> 
> as soon as i saw it i understood it & thought great, like a light bulb 
> going on.

It's not a matter of "I wouldn't have understood what the author was
trying to do" (with a small caveat), it's a matter of "I'd have assumed
that the author didn't understand the language semantics."

I'm pretty sure it goes contrary to *every other programming language
I've ever used* (and a couple that I haven't).

I understand why Python does it, and it certainly is nice in that it
matches typical mathematical notation, but the surprise quotient is
*very* high in the PL world IMO.

Evan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [ANN] IPython 0.13 is officially out!

[Dave Cook]

On 2012-07-01, Virgil Stokes  wrote:
> I have tried to update 0.12 in Ubuntu 12.04 but as of now it can not find 
> 0.13. 
> Any suggestions on how to get it into Ubuntu 12.04 would be appreciated.

Install pip and use it to upgrade ipython:

sudo apt-get install python-pip
sudo pip install --upgrade ipython

Dave Cook
-- 
http://mail.python.org/mailman/listinfo/python-list

when "normal" parallel computations in CPython will be implemented at last?

[dmitrey]

hi all,
are there any information about upcoming availability of parallel
computations in CPython without modules like  multiprocessing? I mean
something like parallel "for" loops, or, at least, something without
forking with copying huge amounts of RAM each time and possibility to
involve unpiclable data (vfork would be ok, but AFAIK it doesn't work
with CPython due to GIL).

AFAIK in PyPy some progress have been done (
http://morepypy.blogspot.com/2012/06/stm-with-threads.html )

Thank you in advance, D.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Dan Stromberg]

If something happens with this for CPython, it'll likely come from Pypy
developers first.  They seem to be interested in doing things in a way that
is (or can be made) compatible with CPython.  If you want to help them
along, they're taking donations to fund the work, or you could donate your
own time.

Bear in mind that CPython threads fine for I/O-heavy workloads.  It's
CPU-bound workloads that CPython doesn't thread super well.

Last I heard, both Jython and IronPython thread well today, and there's
little reason not to try them if you have a (rather rare) application that
truly needs Java-like threading.  Granted, they don't run C extension
modules, but there's quite a bit of portability synergy to be had from
coming up with Pure Python alternatives; it's quite feasible to run the
same code on CPython 2.x, CPython 3.x, Pypy and Jython.  IronPython, sadly,
lacks a python standard library.

If CPython has trouble with CoW, it's probably because of reference
counting, not the GIL.  Last I heard, CPython used both reference counting
and garbage collection.  Also, vfork is a bit of a hack...  just plain fork
is often a better way to go.

On Sun, Jul 1, 2012 at 10:51 AM, dmitrey  wrote:

> hi all,
> are there any information about upcoming availability of parallel
> computations in CPython without modules like  multiprocessing? I mean
> something like parallel "for" loops, or, at least, something without
> forking with copying huge amounts of RAM each time and possibility to
> involve unpiclable data (vfork would be ok, but AFAIK it doesn't work
> with CPython due to GIL).
>
> AFAIK in PyPy some progress have been done (
> http://morepypy.blogspot.com/2012/06/stm-with-threads.html )
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Thomas Jollans]

On 07/01/2012 07:51 PM, dmitrey wrote:
> hi all,
> are there any information about upcoming availability of parallel
> computations in CPython without modules like  multiprocessing? I mean
> something like parallel "for" loops, or, at least, something without
> forking with copying huge amounts of RAM each time and possibility to
> involve unpiclable data (vfork would be ok, but AFAIK it doesn't work
> with CPython due to GIL).
> 
> AFAIK in PyPy some progress have been done (
> http://morepypy.blogspot.com/2012/06/stm-with-threads.html )

As far as I can tell, there are no concrete plans to integrate
concurrency better, or get rid of the GIL, at the moment. To quote
http://wiki.python.org/moin/GlobalInterpreterLock

  """Getting rid of the GIL is an occasional topic on the python-dev
mailing list. No one has managed it yet."""

There are currently no open or accepted PEPs on the subject of concurrency.
http://www.python.org/dev/peps/

There is, of course, Stackless Python.
http://stackless.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Thomas Jollans]

On 07/01/2012 08:44 PM, Dan Stromberg wrote:
> IronPython, sadly, lacks a python standard library.


Beg pardon?

https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Andrew Berg]

On 7/1/2012 1:53 PM, Thomas Jollans wrote:
> As far as I can tell, there are no concrete plans to integrate
> concurrency better, or get rid of the GIL, at the moment. To quote
> http://wiki.python.org/moin/GlobalInterpreterLock
> 
>   """Getting rid of the GIL is an occasional topic on the python-dev
> mailing list. No one has managed it yet."""
There's also this, recently written by one of CPython's core devs:
http://python-notes.boredomandlaziness.org/en/latest/python3/questions_and_answers.html#but-but-surely-fixing-the-gil-is-more-important-than-fixing-unicode
-- 
CPython 3.3.0a4 | Windows NT 6.1.7601.17803
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Dan Stromberg]

On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans  wrote:

> On 07/01/2012 08:44 PM, Dan Stromberg wrote:
> > IronPython, sadly, lacks a python standard library.
>
>
> Beg pardon?
>
>
> https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib
>
Perhaps things have changed.

When I last checked the situation, IronPython came with no standard
library, but you could bolt one on that hadn't been tested well - IIRC,
just a simple "import os" gave a traceback.  FePy was IronPython with a
standard library and some degree of testing, but their emphasis was
windows-only.

I'd be open to using FePy instead, and I might even call it IronPython, but
I'm not in the habit of happily using software that is Windows only.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Thomas Jollans]

On 07/01/2012 09:28 PM, Dan Stromberg wrote:
> 
> 
> On Sun, Jul 1, 2012 at 11:58 AM, Thomas Jollans  > wrote:
> 
> On 07/01/2012 08:44 PM, Dan Stromberg wrote:
> > IronPython, sadly, lacks a python standard library.
> 
> 
> Beg pardon?
> 
> 
> https://github.com/IronLanguages/main/tree/master/External.LCA_RESTRICTED/Languages/IronPython/27/Lib
> 
> Perhaps things have changed.
> 
> When I last checked the situation, IronPython came with no standard
> library, but you could bolt one on that hadn't been tested well - IIRC,
> just a simple "import os" gave a traceback.  FePy was IronPython with a
> standard library and some degree of testing, but their emphasis was
> windows-only.
> 
> I'd be open to using FePy instead, and I might even call it IronPython,
> but I'm not in the habit of happily using software that is Windows only.
> 

That must have been quite a while ago?

I haven't tested it recently, but I'm fairly sure that IronPython
includes a Python standard library which works reasonably well, and it's
not Windows-only. (it works with Mono)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: when "normal" parallel computations in CPython will be implemented at last?

[Ross Ridge]

Thomas Jollans   wrote:
>There is, of course, Stackless Python.
>http://stackless.com/

Stackless Python doesn't really address the original poster's problem
as the GIL still effectively limits Python code running in one thread
at a time.

Ross Ridge

-- 
 l/  //   Ross Ridge -- The Great HTMU
[oo][oo]  rri...@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[HoneyMonster]

On Sun, 01 Jul 2012 09:46:56 +0200, Thomas Jollans wrote:

> I don't have PostgeSQL handy just now - what is the result of (1 < 2 <
> 3) ? I bet it's the same error, which means the two are still
> equivalent.

$ psql misc

psql (9.1.4)

Type "help" for help.

misc=# select (1 < 2);

 ?column? 

--

 t

(1 row)

misc=# select (1 < 2 < 3);

ERROR:  syntax error at or near "<"

LINE 1: select (1 < 2 < 3);
  ^
misc=#

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

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote:

> Also, you claimed earlier that the notion of associative "<" is not
> founded in mathematical notation. It really depends on whose
> mathematical notation you use -- there's more than one, you know. For
> example, it's reasonable to expect < to be left- or right-associative in
> a system like Rick Hehner's Unified Algebra:
> http://www.cs.toronto.edu/~hehner/UA.pdf (although, he himself doesn't
> specify it as being one or the other, so by default one would assume 'a
> < b < c' to be nonsensical.)

Sheesh guys. Don't go hunting through the most obscure corners of 
mathematics for examples of computer scientists who have invented their 
own maths notation. (Which, by your own admission, is under-specified and 
therefore incomplete.) Who uses Hehner's "Unified Algebra" notation? 
Apart from Hehner, if he even uses it himself.

Pick up any standard maths book and you will see chained comparisons used 
with exactly the meaning that Python gives them.

For example, Wolfram MathWorld uses it:

http://mathworld.wolfram.com/Inequality.html


Chained comparisons in the Python sense may be rare in computer 
languages, but it is the standard in mathematics and hardly needs to be 
explained to anyone over the age of twelve. That is a terrible indictment 
on the state of programming language design.



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

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 09:35:40 +0200, Thomas Jollans wrote:

> On 07/01/2012 04:06 AM, Steven D'Aprano wrote:
>> On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote:
>> 
>>> As soon as you read it as a ternary operator,
>> 
>> Well that's your problem. Why are you reading it as a ternary operator?
>> It isn't one. It is a pair of chained binary operator.
>> 
>> How can you tell that it is a pair of binary operators, rather than a
>> single ternary operator?
>> 
>> 1) There are TWO operators, hence a pair, not a single ternary
>> operator;
>> 
>> 2) each operator takes TWO arguments, not three.
> 
> This is simply wrong. The comparisons are not acting as binary
> operators.

Of course they are. Take this chained comparison:

a < b == c

There are exactly TWO operators. Each one takes TWO arguments.

The < operator takes a and b as arguments. That's TWO, not three.

The == operator takes b and c arguments. Again, that's TWO, not three.

If you want to claim that this is a ternary operator, you need to explain:

1) What is the operator in this expression? Is it < or == or something 
else?

2) What double-underscore special method does it call? Where is this 
mysterious, secret, undocumented method implemented?

3) Why do the Python docs lie that a < b == c is exactly equivalent to 
the short-circuit expression (a < b) and (b == c) with b evaluated once?

4) And how do you explain that the compiled byte code actually calls the 
regular two-argument binary operators instead of your imaginary three-
argument ternary operator?

py> from dis import dis
py> dis(compile("a < b == c", "", "single"))
  1   0 LOAD_NAME0 (a)
  3 LOAD_NAME1 (b)
  6 DUP_TOP
  7 ROT_THREE
  8 COMPARE_OP   0 (<)
 11 JUMP_IF_FALSE_OR_POP23
 14 LOAD_NAME2 (c)
 17 COMPARE_OP   2 (==)
 20 JUMP_FORWARD 2 (to 25)
>>   23 ROT_TWO
 24 POP_TOP
>>   25 PRINT_EXPR
 26 LOAD_CONST   0 (None)
 29 RETURN_VALUE




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

Re: changes made to my python coded com servers are not taking effect

[Mark Hammond]

On 1/07/2012 7:13 PM, Panceisto wrote:

I assume the old code keeps running in some process somewhere. How to
fix this?



The client of your server still has a reference to the old server.  The 
simplest solution is to restart those clients.


Mark
--
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 05:55:24 -0400, Terry Reedy wrote:

> On 7/1/2012 2:54 AM, Steven D'Aprano wrote:
> 
>> So no, Python has always included chained comparisons, and yes, it is
>> shameful that a language would force you to unlearn standard notation
>> in favour of a foolish consistency with other operators. Comparisons
>> aren't special because they return bools. They are special because of
>> the way they are used.
>>
>> C treats comparison operators as if they were arithmetic operators, and
>> so the behaviour of a chained comparison is the same as the behaviour
>> as a sequence of arithmetic operators: a foolish consistency. Python
>> treats comparison operators as comparison operators, and gives them
>> behaviour appropriate to comparisons.
> 
> I considered this a great feature of Python when I first learned it.
> Reading about how rare it is among programming languages to treat
> comparisons in the standard way in mathematics reinforces that.

Apart from Python, Mathematica, Perl 6, CoffeeScript, Cobra and Clay give 
chained comparisons the standard meaning. It is, or was, a feature 
request for Boo, but I can't tell whether it has been implemented or not.


C-like semantics are next to useless, except perhaps for obfuscation:

http://stackoverflow.com/questions/4089284/why-does-0-5-3-return-true/

And surprising:

http://answers.yahoo.com/question/index?qid=20090923172909AA4O9Hx

C-like semantics are a clear case of purity of implementation overruling 
functional usefulness.

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

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 16:33:15 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano
>  wrote:
>> Yes, you can find specially crafted examples where adding parentheses
>> in certain places, but not others, doesn't change the overall
>> evaluation of the expression.
> 
> My point was that adding parentheses around the tightest-binding
> operator is a common, clear, and usually insignificant, way of
> demonstrating operator precedence. So FOR THAT USE they must not change
> evaluation of the expression. Obviously if you put them anywhere else,
> they change evaluation. Nice job knocking down a straw man.

We *really did have* somebody arguing that chained comparisons are Bad 
because you can't stick parentheses around bits of it without changing 
the semantics. That was an actual argument, not a straw-man.

It's a stupid argument, but don't blame me for pointing out it's 
stupidity. The author *assumed* that a chain of < must be left-
associative in the same way that a chain of + operators is left-
associative, but it isn't. That's an invalid and unsafe assumption -- 
even in C-like languages, there are operators which aren't left-
associative, e.g. exponentiation ** which is usually right-associative. 
(For the record, C itself doesn't have an exponentiation operator.)

When you make unsafe assumptions about an operator, and get bitten by it, 
the *correct* conclusion should be that the assumption was wrong, not 
that the language is wrong.

Technically, < in Python is left-associative: a < b < c first evaluates 
a, not b or c. But it is left-associative under the rules of comparison 
operator chaining, not arithmetic operator chaining.


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

Re: code review

[Devin Jeanpierre]

On Sun, Jul 1, 2012 at 8:41 PM, Steven D'Aprano
 wrote:
> On Sun, 01 Jul 2012 05:18:09 -0400, Devin Jeanpierre wrote:
> Sheesh guys. Don't go hunting through the most obscure corners of
> mathematics for examples of computer scientists who have invented their
> own maths notation. (Which, by your own admission, is under-specified and
> therefore incomplete.) Who uses Hehner's "Unified Algebra" notation?
> Apart from Hehner, if he even uses it himself.

I didn't hunt, I was taught it in university.

-- Devin

(Of course, it shouldn't be hard to guess who the professor was :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Devin Jeanpierre]

On Sun, Jul 1, 2012 at 9:28 PM, Steven D'Aprano
 wrote:
> Technically, < in Python is left-associative: a < b < c first evaluates
> a, not b or c. But it is left-associative under the rules of comparison
> operator chaining, not arithmetic operator chaining.

Left-associativity is when a < b < c is equivalent to (a < b) < c.

You're talking about evaluation order, which can be different. For
example, hypothetically, (a < b) < c could evaluate c first, then b,
then a. However, Python always evaluates operands left-to-right.

A particular case where this comes into play is the ** operator, which
is right-associative but still has a left-to-right evaluation order.

-- Devin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Chris Angelico]

On Mon, Jul 2, 2012 at 11:28 AM, Steven D'Aprano
 wrote:
> On Sun, 01 Jul 2012 16:33:15 +1000, Chris Angelico wrote:
>
>> On Sun, Jul 1, 2012 at 4:27 PM, Steven D'Aprano
>>  wrote:
>>> Yes, you can find specially crafted examples where adding parentheses
>>> in certain places, but not others, doesn't change the overall
>>> evaluation of the expression.
>>
>> My point was that adding parentheses around the tightest-binding
>> operator is a common, clear, and usually insignificant, way of
>> demonstrating operator precedence. So FOR THAT USE they must not change
>> evaluation of the expression. Obviously if you put them anywhere else,
>> they change evaluation. Nice job knocking down a straw man.
>
> We *really did have* somebody arguing that chained comparisons are Bad
> because you can't stick parentheses around bits of it without changing
> the semantics. That was an actual argument, not a straw-man.

Okay, I take back the "straw man" accusation, and apologize for it.
But you were quoting my text at the time, so I thought you were aiming
at my argument - which, not being that, was what led me to think you
were answering what you weren't answering.

> Chained comparisons in the Python sense may be rare in computer
> languages, but it is the standard in mathematics and hardly needs to be
> explained to anyone over the age of twelve. That is a terrible indictment
> on the state of programming language design.

I'd say that proves that Python is a good language for expressing
mathematics in, then. That's all. Doesn't necessarily mean it's good
for any other task (doesn't mean it's bad either of course). Python
does not, meanwhile, have inbuilt operators for calculus, nor does it
have an equation solver. Do we absolutely need them? Empirically no.
Python can be an excellent language without making every bit of
mathematical notation executable. There are, I am sure, plenty of
cases where it would be nice to go:

x = y+2
x*3 = y*4+7
print("x = %d, y = %d",x,y)

You can argue that Python ought to have more-different operators for
comparison and assignment, but the fact of algebra is that it has
neither - the equals sign is more of a declaration of truth. Algebra
simply isn't imperative. It's fine (and fits the Eliza principle) to
evaluate expressions algebraically, but equations aren't assignment.

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

Re: IPython 0.13 is officially out!

[rusi]

On Jul 1, 9:03 pm, Dave Cook  wrote:
> On 2012-07-01, Virgil Stokes  wrote:
>
> > I have tried to update 0.12 in Ubuntu 12.04 but as of now it can not find 
> > 0.13.
> > Any suggestions on how to get it into Ubuntu 12.04 would be appreciated.
>
> Install pip and use it to upgrade ipython:
>
> sudo apt-get install python-pip
> sudo pip install --upgrade ipython
>
> Dave Cook

Would that not cause path-problems if the earlier one were not pip-
installed??
Better to remove the earlier one first
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: distutils that supports msvc10 and that can be backfitted into Python 2.6

[Mero]

On 26/06/2012 23:24, KACVINSKY Tom wrote:
> I have need for a distutils that supports msvc10, and which can be
> back-fitted into Python 2.6.  Is there such a beast?

One trick I found was to define an environment variable *VS90COMNTOOLS*
that points to the actual VS2010 location:

VS90COMNTOOLS=%VS100COMNTOOLS%

This is because distutils looks for VS2008 in the registry and falls
back to the env. var. above, hence we trick it to detect VS2010 and call
`vcvarsall.bat` when compiling extensions:

python setup.py build --compiler=msvc

Just keep in mind that it is recommended that "extension modules be
compiled with the same compiler that was used to compile Python" which
is still VS2008 to this day..

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

Re: code review

[John O'Hagan]

On Sun, 01 Jul 2012 13:41:20 -0400
Dennis Lee Bieber  wrote:


>   I'd think a true newcomer (to programming) would have NO
> expectations... And if they'd had any complex math classes may actually
> consider 
>   if 1 < x < 10:
> to be the norm 
[...]

+1

I've only ever known Python (well, I've almost forgotten Bash), and when I
first needed a range test, I guessed at the above form and was pleasantly
surprised that it worked: it seemed too good to be true that Python was smart
enough to know I wanted the same "x" to be an operand in two comparisons at
once.

John

P.S. I know I'm not helping, but I'm starting to feel sorry for the guy who
wanted his code reviewed!

John
-- 
http://mail.python.org/mailman/listinfo/python-list