Re: code review

[Serhiy Storchaka]

On 29.06.12 17:44, Littlefield, Tyler wrote:

On 6/29/2012 2:14 AM, Serhiy Storchaka wrote:

The project page is at:
http://code.google.com/p/pymud
Any information is greatly appreciated.


Do you mean 
No, I mean http://code.google.com/p/pymud


Then you probably should choose another name.

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

Re: code review

[Alister]

On Sat, 30 Jun 2012 02:28:52 +, Steven D'Aprano wrote:

> On Fri, 29 Jun 2012 19:41:11 +, Alister wrote:
> 
>> also this section in main strikes me as a bit odd and convoluted
>> 
>> w = world()
>> serv = server(client)
>> w.server = serv serv.world = w
>> 
>> I think you are cross referencing classes & would be better to
>> investigate inheritance.
> 
> What you show above is composition, and is a perfectly valid technique,
> and in fact should often be *preferred* to inheritance.
> 
> The only slightly dubious part, and I stress *slightly*, is that there
> is a circular reference: w refers to serv, and serv refers back to w.
> While legitimate, it is a very slight "code smell" that should be
> investigated.
> If there is a way to get the same result without the circular reference,
> that would be preferred.
> 
> For example, perhaps server methods that need to know the world could
> take it as an explicit argument, rather than fetching it implicitly from
> server.world.
> 
> Or, a moderately advanced technique, use a weak-ref instead.
> 
> Inheritance should only be used to model "is-a" relationships. For
> example, Herbie the Love Bug is a Volkswagen Beetle, so inheritance is
> appropriate.
> 
> http://en.wikipedia.org/wiki/Herbie
> 
> 
> class Vehicle(object):
> pass
> 
> class Car(Vehicle):
> pass
> 
> class Beetle(Car):
> pass
> 
> herbie = Beetle()
> 
> Composition should be used to model "has-a" relationships. For example,
> a car has an engine, it is not a kind of engine, and so inheritance is
> inappropriate and composition should be used. I would re-write the Car
> class as follows:
> 
> class Engine(object):
> pass
> 
> class Car(Vehicle):
> def __init__(self):
> self.engine = Engine()
> 
> So now we can talk about Herbie's engine:
> 
> herbie.engine  # Herbie, being a car, has an engine, he is not an engine

I probably was not to clear (due to my own inexperience) it was the 
circular references that grabbed my attention, it may be OK but suggests 
to me there may be a better approach.




-- 
((lambda (foo) (bar foo)) (baz))
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alister]

On Fri, 29 Jun 2012 14:49:11 -0600, Littlefield, Tyler wrote:

> I am no expert but from what have picked up so far from x import is
> frowned upon in most cases also this section in main strikes me as a bit
> odd and convoluted w = world() serv = server(client) w.server = serv
> serv.world = w I think you are cross referencing classes & would be
> better to investigate inheritance.
> 
>  From what I understand and how I've always employed it, inheritance is
> ment when you wish to give a class characteristics of another class. All
> I'm doing here is setting the world and server classes on each other, so
> they can call one another. This probably isn't needed in case of
> serv.server = w, but for sure the other way around.

I was not too sure of exactly why the code looked odd.
as mentioned in another post I should really have referred to the 
circular references.

I am new to python (about 6 months of home hacking), I looked at the code 
to see if it could improve my knowledge & my responses have been intended 
to spark a 2 way discussion of the pro's & cons of the approach.
So far that seems to be working, I expect by the end of this I will have 
learnt much about real world python apps.







-- 
Nobody ever died from oven crude poisoning.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alister]

On Sat, 30 Jun 2012 09:31:53 +, Alister wrote:

> On Fri, 29 Jun 2012 14:49:11 -0600, Littlefield, Tyler wrote:
> 
>> I am no expert but from what have picked up so far from x import is
>> frowned upon in most cases also this section in main strikes me as a
>> bit odd and convoluted w = world() serv = server(client) w.server =
>> serv serv.world = w I think you are cross referencing classes & would
>> be better to investigate inheritance.
>> 
>>  From what I understand and how I've always employed it, inheritance is
>> ment when you wish to give a class characteristics of another class.
>> All I'm doing here is setting the world and server classes on each
>> other, so they can call one another. This probably isn't needed in case
>> of serv.server = w, but for sure the other way around.
> 
> I was not too sure of exactly why the code looked odd.
> as mentioned in another post I should really have referred to the
> circular references.
> 
> I am new to python (about 6 months of home hacking), I looked at the
> code to see if it could improve my knowledge & my responses have been
> intended to spark a 2 way discussion of the pro's & cons of the
> approach.
> So far that seems to be working, I expect by the end of this I will have
> learnt much about real world python apps.

perhaps now is a good time for me to look at the rest of the modules to 
see if i can work out exactly what these circular references do.
btw where or what is pants.py? 



-- 
If the path be beautiful, let us not ask where it leads.
-- Anatole France
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alister]

On Fri, 29 Jun 2012 09:03:22 -0600, Littlefield, Tyler wrote:

> On 6/29/2012 1:31 AM, Steven D'Aprano wrote:
>> On Thu, 28 Jun 2012 20:58:15 -0700, alex23 wrote:
>>
>>> On Jun 29, 12:57 pm, "Littlefield, Tyler"  wrote:
 I was curious if someone wouldn't mind poking at some code. The
 project page is at:http://code.google.com/p/pymud Any information is
 greatly appreciated.
>>> I couldn't find any actual code at that site, the git repository is
>>> currently empty.
> 
> OOPS, sorry. Apparently I'm not as good with git as I thought.
> Everything's in the repo now.

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)

similar construct can be used for isValidUser

def isValidUser(name):
if name.isalpha():
count=len(name)
return count>=mud.minname and count >mud.maxname
return False


-- 
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Peter Otten]

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.


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

tiffany 0.6.1 released

[Christian Tismer]

Tiffany - Read/Write Multipage-Tiff with PIL without PIL


Tiffany stands for any tiff. The tiny module solves a large set of
problems, has no dependencies and just works wherever Python works.
Tiffany was developed in the course of the *DiDoCa* project and will
always appear on PyPi.


Version 0.6.1
-

This version uses the new int.from_bytes/to_bytes methods from
python3.2 and emulates them on python2.6/2.7 . This migration
was tested using pytest.

Tiffany is quite unlikely to change anymore until user requests come,
or I get better test data:


Testing with larger tiff files
--

The implementation right now copies data in one big chunk. I would
like to make that better/not limited by memory. For that, I need
a tiff file that is a few megabytes big.
Can somebody please send me one?


Extending Tiffany?
--

I'm also thinking of

- an interface to Qt (without adding a dependency)

- a command line interface, to make tiffany into a new tiff tool,

- support for other toolkits that need to handle tiff files.

Ideas about this are most welcome.

Please let me know if this stuff works for you, and send requests to
 or use the links in the bitbucket website:

https://bitbucket.org/didoca/tiffany

cheers -- Chris

--
Christian Tismer :^)
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key ->  http://pgp.uni-mainz.de
work +49 173 24 18 776  mobile +49 173 24 18 776  fax n.a.
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list

Re: PyDev IPython Confusion

[Fabio Zadrozny]

On Wed, May 23, 2012 at 5:06 PM, Wanderer  wrote:
> I have two versions of Python and Ipython; Python 2.6.6 with Ipython
> 0.11 and Python 2.7.3 with Ipython 0.12.  When I run the Eclipse PyDev
> console for the Python 2.7.3 it says it is using Ipython 0.11 as the
> interpreter. Ipython 0.11 should not be in the Path for Python 2.7.3.
> Is this a bug in Ipython 0.12? Is there a command to check the Ipython
> version to verify it is Ipython 0.11 and not Ipython 0.12? Could this
> be something in the Windows registry that Ipython 0.11 is the
> 'registered' version of Ipython?
>

Please check on the latest PyDev 2.6.0  release (there was an issue
related PYTHONPATH ordering inside PyDev which could potentially lead
to that).

If it doesn't solve it for you, check if your PYTHONPATH is what you
expected inside the shell: import sys;
print('\n'.join(sorted(sys.path))) and compare that with your
configuration... ( note that the recommended place to ask PyDev
questions is at stackoverflow with a PyDev tag... see:
http://pydev.org/about.html )

Cheers,

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

Re: tiffany 0.6.1 released

[Anthon van der Neut]

Christian,

I should have several larger Tiff files, but I would have to search a 
bi. I used tilded tiffs ack in the early 90-s as a solution to mapping 
large images onto raytraced surfaces on machines with only 20Mb of memory.
I will have to search though and I am now travelling. If I fail to come 
back to you after I return home (in a week time), drop me an email.


Are you going to be at Europython again (we once shared a taxi in 
Birmingham). I will drive down there tomoorw.


Regards
Anthon

On 2012-06-30 12:41, Christian Tismer wrote:

Tiffany - Read/Write Multipage-Tiff with PIL without PIL


Tiffany stands for any tiff. The tiny module solves a large set of
problems, has no dependencies and just works wherever Python works.
Tiffany was developed in the course of the *DiDoCa* project and will
always appear on PyPi.


Version 0.6.1
-

This version uses the new int.from_bytes/to_bytes methods from
python3.2 and emulates them on python2.6/2.7 . This migration
was tested using pytest.

Tiffany is quite unlikely to change anymore until user requests come,
or I get better test data:


Testing with larger tiff files
--

The implementation right now copies data in one big chunk. I would
like to make that better/not limited by memory. For that, I need
a tiff file that is a few megabytes big.
Can somebody please send me one?


Extending Tiffany?
--

I'm also thinking of

- an interface to Qt (without adding a dependency)

- a command line interface, to make tiffany into a new tiff tool,

- support for other toolkits that need to handle tiff files.

Ideas about this are most welcome.

Please let me know if this stuff works for you, and send requests to
 or use the links in the bitbucket website:

https://bitbucket.org/didoca/tiffany

cheers -- Chris

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

Re: tiffany 0.6.1 released

[Paul Rubin]

Christian Tismer  writes:
> Tiffany stands for any tiff. The tiny module solves a large set of
> problems, has no dependencies and just works wherever Python works.
> Tiffany was developed in the course of the *DiDoCa* project and will
> always appear on PyPi.

This sounds pretty neat.  I didn't comment on it earlier because I
haven't tried it out, since I haven't had occasion to deal with tiff
files anytime recently.  But I've had to process them for some projects
in the past, and tiffany would have been useful then.  It's good to know
that it's out there.
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] IPython 0.13 is officially out!

[Fernando Perez]

Hi all,

on behalf of the IPython development team, and just in time for the
imminent Debian freeze and SciPy 2012, I'm thrilled to announce, after
an intense 6 months of work, the official release of IPython 0.13.

This version contains several major new features, as well as a large
amount of bug and regression fixes. The previous version (0.12) was
released on December 19 2011, so in this development cycle we had:

- ~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.

This means that we closed a total of 1115 issues over 6 months, for a
rate of almost 200 issues closed and 300 commits per month. We are very 
grateful to all of you who have contributed so enthusiastically to the 
project and have had the patience of pushing your contributions through 
our often lengthy review process.

We've also welcomed several new members to the core IPython
development group: Jörgen Stenarson (@jstenar - this really was an
omission as Jörgen has been our Windows expert for a long time) and
Matthias Bussonier (@Carreau), who has been very active on all fronts
of the project.


*Highlights*

There is too much new work to write up here, so we refer you to our" 
What's New" document
(http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html)
for the full details. But the main highlights of this release are:

* Brand new UI for the notebook, with major usability improvements
(real menus, toolbar, and much more)

* Manage all your parallel cluster configurations from the notebook
with push-button simplicity (cluster start/stop with one button).

* Cell magics: commands prefixed with %% apply to an entire cell. We
ship with many cell magics by default, including timing, profiling,
running cells under bash, Perl and Ruby as well as magics to interface
seamlessly with Cython, R and Octave.

* The IPython.parallel tools have received many fixes, optimizations,
and a number of API improvements to make writing, profiling and
debugging parallel codes with IPython much easier.

* We have unified our interactive kernels (the basic ipython object
you know and love) with the engines running in parallel, so that you
can now use all IPython special tricks in parallel too. And you can
connect a console or qtconsole to any parallel engine for direct,
interactive execution, plotting and debugging in a cluster.


*Downloads*

Downloads can be found on:

- Github: http://github.com/ipython/ipython/downloads
- PyPI: http://pypi.python.org/pypi/ipython

More download/install details: http://ipython.org/download.html.

Please see our release notes for the full details on everything about
this release:
http://ipython.org/ipython-doc/rel-0.13/whatsnew/version0.13.html

As usual, if you find any other problem, please file a ticket --or
even better, a pull request fixing it-- on our github issues site
(https://github.com/ipython/ipython/issues).

Many thanks to all who contributed!

Fernando, on behalf of the IPython development team.

http://ipython.org

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

Re: code review

[Thomas 'PointedEars' Lahn]

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*.

-- 
PointedEars

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

Re: code review

[Thomas Jollans]

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alister]

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"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alister]

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Thomas Jollans]

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 their loss.

Are we quoting the Zen now?

Contra:

In re usual operator rules:
"Special cases aren't special enough to break the rules."

Which of the two comparisons is done first anyway?
"In the face of ambiguity, refuse the temptation to guess."

Speaking of two comparisons, no "and"!
"Explicit is better than implicit."

Then again, pro:

"Beautiful is better than ugly."
"Readability counts."
"[Although] practicality beats purity."


I can see the appeal. It's quite elegant in and of itself. However, I
find that in the context of the whole Python language, it's a bit of a
glitch and reduces elegance. (I'm probably in the minority on this one)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Alain Ketterlin]

Thomas Jollans  writes:

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

> Which of the two comparisons is done first anyway?
> "In the face of ambiguity, refuse the temptation to guess."

There is no ambiguity. See the language reference:

"Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN
are comparison operators, then a op1 b op2 c ... y opN z is equivalent
to a op1 b and b op2 c and ... y opN z, except that each expression is
evaluated at most once."

The last restriction (single evaluation of involved expressions) makes
this a bit more than raw syntactic sugar.

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

Re: code review

[Thomas Jollans]

On 06/30/2012 11:07 PM, Alain Ketterlin wrote:
> Thomas Jollans  writes:
> 
>> def is_valid_password(password):
>> return mud.minpass <= len(password) <= mud.maxpass
> 
>> Which of the two comparisons is done first anyway?
>> "In the face of ambiguity, refuse the temptation to guess."
> 
> There is no ambiguity. See the language reference:

Of course it's technically clearly defined, but the syntax isn't
explicit. To know what the order is (or whether there is an order!) one
has to consult the language reference (which shouldn't be necessary), or
make an educated guess, which would almost certainly be correct, but
we're supposed to refuse the temptation to guess, right?

> "Formally, if a, b, c, ..., y, z are expressions and op1, op2, ..., opN
> are comparison operators, then a op1 b op2 c ... y opN z is equivalent
> to a op1 b and b op2 c and ... y opN z, except that each expression is
> evaluated at most once."
> 
> The last restriction (single evaluation of involved expressions) makes
> this a bit more than raw syntactic sugar.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: tiffany 0.6.1 released

[Christian Heimes]

Am 30.06.2012 18:25, schrieb Paul Rubin:
> Christian Tismer  writes:
>> Tiffany stands for any tiff. The tiny module solves a large set of
>> problems, has no dependencies and just works wherever Python works.
>> Tiffany was developed in the course of the *DiDoCa* project and will
>> always appear on PyPi.
> 
> This sounds pretty neat.  I didn't comment on it earlier because I
> haven't tried it out, since I haven't had occasion to deal with tiff
> files anytime recently.  But I've had to process them for some projects
> in the past, and tiffany would have been useful then.  It's good to know
> that it's out there.

I've developed smc.freeimage exclusively to process large amounts of
TIFF images. I estimate that we have processed more than twelve million
unique TIFF images with about half a petabyte of data. The packages uses
Cython to wrap FreeImage (containing libtiff, libpng, libjpeg, libraw
and more) and LittleCMS2.

The package is mostly fitted to our needs, a bit limited (e.g. no
conversion of CMYK to RGB with color management) and doesn't follow
recent best practices for Cython code, but it does it job well. I need
to clean up the code base some day when more people get interested in
the lib.

Christian

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

Re: code review

[Terry Reedy]

On 6/30/2012 5:35 PM, Thomas Jollans wrote:

On 06/30/2012 11:07 PM, Alain Ketterlin wrote:

Thomas Jollans  writes:


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



Which of the two comparisons is done first anyway?
"In the face of ambiguity, refuse the temptation to guess."


There is no ambiguity. See the language reference:


Of course it's technically clearly defined, but the syntax isn't
explicit. To know what the order is (or whether there is an order!) one
has to consult the language reference (which shouldn't be necessary), or
make an educated guess, which would almost certainly be correct, but
we're supposed to refuse the temptation to guess, right?


Python pretty consistently evaluates expressions and equal precedence 
operators left to right. One really should learn that. No 
'implementation defined' ambiguity.



--
Terry Jan Reedy



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

Re: code review

[Martin P. Hellwig]

On Saturday, 30 June 2012 21:30:45 UTC+1, 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
> >>>

> Surely this fits perfectly with the lines 1 & 7 in the zen of python 
> (import this)
> "Beautifull is better than ugly" and "Readability counts"
> 
Agree, however I like to stress the "don't make me unnecessary read with care" 
rule. Meaning if I read that line, I have to read it carefully to make sure I 
understand what is happening, the following would not do that although syntax 
wise equal:

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

def is_valid_password(password):
   valid = True

   if not length_between_max_min(password):
  valid = False

   if some_other_test(password):
  valid = False


  return(valid)

This I can read, typically I would not even read what the function 
length_beteen_max_min does as long as there is no bug in it because, it is 
perfectly english clear what the intention is.

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

Re: code review

[Thomas Jollans]

On 06/30/2012 11:47 PM, Terry Reedy wrote:
> On 6/30/2012 5:35 PM, Thomas Jollans wrote:
>> On 06/30/2012 11:07 PM, Alain Ketterlin wrote:
>>> Thomas Jollans  writes:
>>>
 def is_valid_password(password):
  return mud.minpass <= len(password) <= mud.maxpass
>>>
 Which of the two comparisons is done first anyway?
 "In the face of ambiguity, refuse the temptation to guess."
>>>
>>> There is no ambiguity. See the language reference:
>>
>> Of course it's technically clearly defined, but the syntax isn't
>> explicit. To know what the order is (or whether there is an order!) one
>> has to consult the language reference (which shouldn't be necessary), or
>> make an educated guess, which would almost certainly be correct, but
>> we're supposed to refuse the temptation to guess, right?
> 
> Python pretty consistently evaluates expressions and equal precedence
> operators left to right. 

Yes. My sole point, really, is that "normally", one would expect these
two expressions to be equivalent:

a < b < c
(a < b) < c

This is clearly not true. That's the inconsistency here with the rest of
the language. As soon as you read it as a ternary operator, the two
comparisons are logically simultaneous. Doing the left hand comparison
first is clearly the intuitive thing to do, but it's still, strictly
speaking, arbitrary. Intuitive, clearly defined, but arbitrary.

The ternary conditional operator is a different beast because its
sub-operators "if" and "else" aren't also binary operators, so it's
obvious that it's parsed differently.

> One really should learn that. No
> 'implementation defined' ambiguity.

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

Re: code review

[Alain Ketterlin]

Thomas Jollans  writes:

> On 06/30/2012 11:47 PM, Terry Reedy wrote:

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

> Which of the two comparisons is done first anyway?
> "In the face of ambiguity, refuse the temptation to guess."

 There is no ambiguity. See the language reference:

>>> Of course it's technically clearly defined, but the syntax isn't
>>> explicit.

>> Python pretty consistently evaluates expressions and equal precedence
>> operators left to right. 
>
> Yes. My sole point, really, is that "normally", one would expect these
> two expressions to be equivalent:
>
> a < b < c
> (a < b) < c
>
> This is clearly not true. That's the inconsistency here with the rest of
> the language.

No, comparison operators are different from arithmetic operators in that
they always evaluate to a boolean. There are only rare cases where it
makes sense to compare comparisons.

> As soon as you read it as a ternary operator, the two comparisons are
> logically simultaneous.

There is no ternary operator, you can chain as many as you want, using
whatever operators:

  if a <= b < c > d >= e:
  ...

Once you view this as a conjonction of conditions, you find back the
semantics of "and": short-circuit, left to right evaluation. I find this
consistent.

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

Re: code review

[Chris Angelico]

On Sun, Jul 1, 2012 at 8:05 AM, Thomas Jollans  wrote:
> Yes. My sole point, really, is that "normally", one would expect these
> two expressions to be equivalent:
>
> a < b < c
> (a < b) < c
>
> This is clearly not true.

Python has quite a few things like that, actually. The most noticeable
for C programmers is:

a = b = c = d = e = 0

which in C is identical to

a = (b = (c = (d = (e = 0

because assignment is an expression, but in Python is equivalent to
nothing because assignment is simply allowed to do multiple. Downside:
*Only* simple assignment can be chained. Augmented assignment cannot:

>>> a+=10# That's fine.
>>> a+=b+=10
  File "", line 1
a+=b+=10
 ^
SyntaxError: invalid syntax
>>> a=b+=10
  File "", line 1
a=b+=10
^
SyntaxError: invalid syntax
>>> a+=b=10
  File "", line 1
a+=b=10
^
SyntaxError: invalid syntax


In C, these are all well-defined and valid, and are evaluated
right-to-left, and do what you would expect. (And yes, it's handy at
times to do this sort of thing.)

So it's not a special case for the comparison operators; it's a more
general case that Python handles certain chains of operators as single
entities, rather than breaking everything down into "OPERAND OPERATOR
OPERAND" and evaluating one at a time. Is it better than/worse than C?
Not really. It's a design choice and we code within it. (My personal
preference is for the C style, as it makes for a more expressive
language with less mental glitching, but as I say, that's personal
preference.)

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

Re: code review

[Thomas Jollans]

On 07/01/2012 01:25 AM, Chris Angelico wrote:
> On Sun, Jul 1, 2012 at 8:05 AM, Thomas Jollans  wrote:
>> Yes. My sole point, really, is that "normally", one would expect these
>> two expressions to be equivalent:
>>
>> a < b < c
>> (a < b) < c
>>
>> This is clearly not true.
> 
> Python has quite a few things like that, actually. The most noticeable
> for C programmers is:
> 
> a = b = c = d = e = 0
> 
> which in C is identical to
> 
> a = (b = (c = (d = (e = 0
> 
> because assignment is an expression, but in Python is equivalent to
> nothing because assignment is simply allowed to do multiple. Downside:
> *Only* simple assignment can be chained. Augmented assignment cannot:
> 
 a+=10# That's fine.
 a+=b+=10
>   File "", line 1
> a+=b+=10
>  ^
> SyntaxError: invalid syntax
 a=b+=10
>   File "", line 1
> a=b+=10
> ^
> SyntaxError: invalid syntax
 a+=b=10
>   File "", line 1
> a+=b=10
> ^
> SyntaxError: invalid syntax
> 
> 
> In C, these are all well-defined and valid, and are evaluated
> right-to-left, and do what you would expect. (And yes, it's handy at
> times to do this sort of thing.)
> 
> So it's not a special case for the comparison operators; it's a more
> general case that Python handles certain chains of operators as single
> entities, rather than breaking everything down into "OPERAND OPERATOR
> OPERAND" and evaluating one at a time. Is it better than/worse than C?
> Not really. It's a design choice and we code within it. (My personal
> preference is for the C style, as it makes for a more expressive
> language with less mental glitching, but as I say, that's personal
> preference.)

Nicely put. Of course it's not catastrophic, it's just a feature of
Python that I'm not particularly fond of.

Another operator with special chaining behaviour that occurred to me is
the tuple-building "," operator. This is a particularly interesting one
since the "," symbol is also used in other contexts where it is not an
operator, and the symbol can be considered an operator in the way it can
be in Python only in very few (if any) other programming languages.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Ben Finney]

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?

The operator symbols are not chosen arbitrarily for Python; they are, in
the case of ‘<’ and ‘>’, chosen because of semantic meaning those
symbols already have. That's the norm informing this meaning, and I
think it negates the point you're making.

> This is clearly not true. That's the inconsistency here with the rest
> of the language.

There is inconsistency already in the symbols people see and the
semantics already associated with those symbols. Expecting that any
symbol, before Python defines it, will be devoid of any normal meaning
is a delusion.

-- 
 \ “The Vatican is not a state.… a state must have territory. This |
  `\ is a palace with gardens, about as big as an average golf |
_o__) course.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Chris Angelico]

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.

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

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 00:05:26 +0200, Thomas Jollans wrote:

> Yes. My sole point, really, is that "normally", one would expect these
> two expressions to be equivalent:
> 
> a < b < c
> (a < b) < c

Good grief. Why would you expect that?

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:

temporary_flag = a < b
temporary_flag < c

which is not the same as a < b < c.

This has nothing to do with chained comparisons. You can write the same 
thing without chaining:

a < b and b < c
(a < b) < c

Is it not obvious that the second case is completely different from the 
first? Chaining is irrelevant here.


> This is clearly not true. That's the inconsistency here with the rest of
> the language.

Nonsense. Your expectation that parentheses should not affect the order 
of evaluation is at odds with the entire Python language, to say nothing 
of almost every programming language in existence.


> 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.



Chained comparisons is a standard mathematical notation with an obvious 
meaning that is familiar to anyone with even a passing familiarity to 
mathematics. They have straight-forward and simple semantics. If other 
languages don't allow them, so much the worse for other languages.

You seem to be inventing arguments to support an irrational dislike to 
the feature, but the arguments don't stand up. By all means say that you 
don't like chained comparisons, that is your right, but your attempts to 
rationalise that dislike simply do not work.


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

Re: code review

[Chris Angelico]

On Sun, Jul 1, 2012 at 12:06 PM, Steven D'Aprano
 wrote:
> 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

But that's because ** binds right to left. It _is_ valid to say:

2**3**4 = 2**(3**4)

That's the usual way of depicting order of evaluation: putting in the
implicit parentheses.

1+2*3 = 1+(2*3)

Everyone who knows algebra knows that the parens are optional, but
nobody would expect them to change the evaluation of the expression.
It's like adding whitespace:

1+2*3 = 1 + 2 * 3 = 1 + 2*3

where the latter is another way of showing order of evaluation (the
asterisk "binds more tightly" than the plus). With comparisons, it's
not the same.

(ahttp://mail.python.org/mailman/listinfo/python-list

Re: code review

[rusi]

On Jul 1, 3:05 am, Thomas Jollans  wrote:
> Yes. My sole point, really, is that "normally", one would expect these
> two expressions to be equivalent:
>
> a < b < c
> (a < b) < c
>
> This is clearly not true. That's the inconsistency here

I dont see the inconsistency with the specific example as you've
given.  However if we consider the argument in general, there is
something to be said for being (more) careful to distinguish
associative and conjunctive interpretation of operators. IOW for an
arbitrary operator * (not standard multiply):

If * : t x t -> t,   the only meaningful semantics of a*b*c is (a*b)*c
or a*(b*c)
If * : t x t -> Bool the only meaningful semantics of a*b*c is a*b +
b*c
where the most reasonable instance of '+' is 'and'

What happens when t = Bool?

Both cases match.  And there is something to be said for notationally
allowing for both cases
Dijkstra/Scholten and David Gries books on logic in computer science
expand on this.

A short net-reachable paper is 
http://wwwhome.ewi.utwente.nl/~fokkinga/mmf2001a.pdf
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 10:37:05 +1000, Chris Angelico wrote:

> 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.

All the worse for those languages, since they violate the semantics of 
mathematical notation.

The more I learn about C, the less I want to know about C. What sort of 
crazy language designer thought that having

2 == 2 == 2

return 0 (false) was a good idea? At least Pascal gives an error, since 
you can't compare bools with longints, and forces you to write:

(2 = 2) and (2 = 2)

Sheer craziness for C to abuse mathematical notation like that. But what 
is one to expect from a language where

(unsigned)-1 == -1

apparently is true.

http://nitoprograms.blogspot.com.au/2011/05/signed-and-unsigned-
comparisons-in-c-c.html


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

Re: code review

[Chris Angelico]

On Sun, Jul 1, 2012 at 1:23 PM, Steven D'Aprano
 wrote:
> All the worse for those languages, since they violate the semantics of
> mathematical notation.

Not so. It simply means that booleans are nothing special. In REXX,
there are no data types at all, and "1" and "0" are your booleans. In
C, boolean and comparison operations return integers, either 1 or 0.
Same was true of Python early on, if I understand correctly. It's not
shameful.

> The more I learn about C, the less I want to know about C. What sort of
> crazy language designer thought that having
>
> 2 == 2 == 2
>
> return 0 (false) was a good idea?

It makes perfect sense though; your comparisons simply return
integers, so you can legally index using them. A simple binary tree
can work thus:

node child[2];

next_node = child[search_value>current_value];

> Sheer craziness for C to abuse mathematical notation like that. But what
> is one to expect from a language where
>
> (unsigned)-1 == -1
>
> apparently is true.

Of course it's true. When you compare an unsigned value to a signed
one, the signed value is automatically up-cast to unsigned, in the
same way that comparing 32-bit and 64-bit integers will do. So
whatever rule the compiler uses to cast your first -1 to unsigned will
be used to cast the second to unsigned, and they'll be equal.

As to "2 == 2 == 2": I don't see it as a problem that:

x = (2 == 2)
y = (x == 2)
z = (2 == 2 == 2)

leave y and z as the same. There are different ways of interpreting
the z statement, but having it identical to y is certainly a plausible
one.

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

Re: code review

[rusi]

On Jul 1, 8:23 am, Steven D'Aprano  wrote:
> On Sun, 01 Jul 2012 10:37:05 +1000, Chris Angelico wrote:
> > 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.
>
> All the worse for those languages, since they violate the semantics of
> mathematical notation.
>
> The more I learn about C, the less I want to know about C. What sort of
> crazy language designer thought that having
>
> 2 == 2 == 2
>
> return 0 (false) was a good idea?

Kernighan and Ritchie admit they made a design mistake with their
operator precedences:

http://en.wikipedia.org/wiki/C_%28programming_language%29#Criticism

That those mistakes are repeated and replicated is more unfortunate.
The second bullet above to be read along with
http://en.wikipedia.org/wiki/Assignment_%28computer_science%29#Assignment_versus_equality
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 12:20:52 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 12:06 PM, Steven D'Aprano
>  wrote:
>> 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
> 
> But that's because ** binds right to left. It _is_ valid to say:
> 
> 2**3**4 = 2**(3**4)

Yes, but my point is that you can't just add parentheses arbitrarily 
without understanding what you're doing.

If you're used to some feeble $2 calculator that doesn't implement 
operator precedence, you might expect that you could do this too:

1+2*3
(1+2)*3

But you can't. It's your expectations that are skewed, not Python.

If you (generic you) are used to some feeble $2 language that doesn't 
implement chained comparisons, it is your expectations that are skewed, 
not Python.

Comparisons were invented long before C, or even computers, and they have 
had chained semantics long before Python. Languages like C force you to 
unlearn the standard semantics of comparisons, and substitute something 
that is less expressive, less powerful, less efficient, and more likely 
to contain a bug.

This is almost always wrong in languages without chained comparisons:

a < func(x) < b


This is inefficient, and still wrong, if x has side-effects or isn't 
reentrant:

a < func(x) and func(x) < b


This is too verbose for such a simple comparison:

tmp = func(x)
(a < tmp) and (tmp < b)


[...]
> Everyone who knows algebra knows that the parens are optional, but
> nobody would expect them to change the evaluation of the expression.

Nonsense. Of course parens change the evaluation of the expression. 
That's what parens are for!

There may be some specific cases where they don't, because you have 
happened to put them in a specially crafted position where they don't 
actually change the order of evaluation. E.g. putting parens around the 
entire expression, or putting them around a single atom, or around 
another pair of parentheses:

2*(3+4)
=> (2*(3+4))  # unchanged
=> (2)*(3+4)
=> 2*((3+4))


but just because there are *some* places you can add redundant parens 
doesn't mean that you can add them *anywhere*. You have to understand the 
semantics of expression, including the precedence rules. If you don't 
understand them, you might as well be just adding parens in random 
positions, in which case you should expect the semantics to change.


[...]
> (a 
> is, incidentally, a valid expression, as long as you accept that False
> is less than True. 

Right. I'm not saying that there's never any need to evaluate a 
comparison, and then compare it to the result of another comparison. 
That's a perfectly valid thing to do.

And you know what? You can do it, using parens, exactly as shown.

Chained comparisons is the common case, it should have the simple syntax. 
That's why mathematicians write {x : a < x < b} instead of 
{x: a < x} ∩ {x: x < b}. The uncommon case, treating a bool as a value to 
be compared to another value, should be possible, which it is.



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

Re: code review

[Chris Angelico]

On Sun, Jul 1, 2012 at 2:17 PM, Steven D'Aprano
 wrote:
> Nonsense. Of course parens change the evaluation of the expression.
> That's what parens are for!

The whole point of my example was that it wouldn't.

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

Re: code review

[Chris Angelico]

On Sun, Jul 1, 2012 at 2:07 PM, rusi  wrote:
> Kernighan and Ritchie admit they made a design mistake with their
> operator precedences:
>
> http://en.wikipedia.org/wiki/C_%28programming_language%29#Criticism
>

The examples given there have nothing to do with the chaining of
comparisons and how it's to be interpreted. Yes, "x & 1 == 0" is
evaluated oddly. Doesn't affect "x == 1 == y".

Python's interpretation is more algebraic than C's. That doesn't mean
that C is wrong and Python is right, nor does it mean the converse.

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

how to use tkinter in python3.2?

[contro opinion]

tiger@ocean:~$ python3.2
Python 3.2.3 (default, Jul  1 2012, 11:07:14)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python3.2/tkinter/__init__.py", line 39, in 
import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter
>>>

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

in my computer ,i can use tkinter in python3
tiger@ocean:~$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>>
what is the matter?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re: code review

[Evan Driscoll]

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




signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: code review

[Evan Driscoll]

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:
  1 < 1 < 2
  => true
  false == false == false
  => false

O'Caml:
  # false == false == false;;
  - : bool = false
  # 1 < 2 < true;;
  - : bool = false

Java:
  System.out.println(false == false == false);
  (outputs) false

Lua:
  > print(false == false == false)
  false

C and C++:
  std::cout << (1 < 1 < 3) << "\n";
  (outputs) 1
  std::cout << (false == false == false) << "\n";
  (outputs) 0

Evan



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: how to use tkinter in python3.2?

[Terry Reedy]

On 7/1/2012 12:25 AM, contro opinion wrote:

I am on Windows, but...


tiger@ocean:~$ python3.2
Python 3.2.3 (default, Jul  1 2012, 11:07:14)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import tkinter
Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/local/lib/python3.2/tkinter/__init__.py", line 39, in 
 import _tkinter # If this fails your Python may not be configured
for Tk
ImportError: No module named _tkinter


_tkinter is the compiled C module that directly interfaces to tk. It is 
imported by the python module tkinter. For whatever reason, it was not 
compiled for your installation. Who did the compilation?



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

in my computer ,i can use tkinter in python3
tiger@ocean:~$ python3
Python 3.1.3 (r313:86834, Nov 28 2010, 11:28:10)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import tkinter


and who compiled that (correctly)?

--
Terry Jan Reedy



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

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 14:23:36 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 2:17 PM, Steven D'Aprano
>  wrote:
>> Nonsense. Of course parens change the evaluation of the expression.
>> That's what parens are for!
> 
> The whole point of my example was that it wouldn't.

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. So what? IN GENERAL, adding parentheses changes the 
evaluation of the expression -- that is what they are for.

Therefore, IN GENERAL you should expect that adding parentheses will 
change the result, unless you carefully place them where you know that 
they will have no effect.

Even in C, I can't just do this:

2+3*4
=> (2+3)*4

with the expectation that you can stick parentheses around the left-most 
term without changing the value. The fact that you can do for some 
expressions is irrelevant.

In general, if you don't know the semantics of an expression (including 
the operator precedence), you cannot just assume that adding parens is 
harmless.


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

Re: code review

[Chris Angelico]

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.

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

Re: code review

[Steven D'Aprano]

On Sun, 01 Jul 2012 13:48:04 +1000, Chris Angelico wrote:

> On Sun, Jul 1, 2012 at 1:23 PM, Steven D'Aprano
>  wrote:
>> All the worse for those languages, since they violate the semantics of
>> mathematical notation.
> 
> Not so. It simply means that booleans are nothing special. In REXX,
> there are no data types at all, and "1" and "0" are your booleans. In C,
> boolean and comparison operations return integers, either 1 or 0. 

This has nothing to do with the presence of a Boolean type or not. It is 
about syntax, not types.

Python didn't have bools until relatively recently but it still had 
chained comparisons. In Python2.1 and older, boolean and comparison 
operations return integers, either 1 or 0, precisely the same as C.

You can even use chained comparisons for types that don't interpret the 
operators as comparisons:

py> class Funny:
... def __init__(self, x):
... self.x = x
... def __lt__(self, other):
... return Funny(self.x + 3*other.x)
... def __str__(self):
... return str(self.x)
...
py> a = Funny(2)
py> b = Funny(3)
py> c = Funny(4)
py>
py> print a < b < c
15
py> print (a < b) and (b < c)
15

Although the interpretation of such may not be useful.



> Same
> was true of Python early on, if I understand correctly. It's not
> shameful.

The first public release of Python, 0.9, included chained comparisons. 
This was even before the language had == for equality tests!

steve@runes:~$ ./python0.9.1
>>> print 2 < 3 < 4
1
>>> print 2 = 2 = 2
1
>>> print (2 = 2) = 2
0


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.

The fact that so many languages do the wrong thing here, and so few 
emulate standard mathematical notation, is symptomatic of the lousy state 
of language design.

Pascal might be verbose, but at least it makes it harder to write code 
that silently does the wrong thing -- it prevents you from writing 
chained comparisons which do the wrong thing, and forces you to be 
explicit. C has the worst of both worlds:

- it allows the standard concise mathematical notation a < x < b
- but it quietly changes the semantics to something that the user 
  hardly ever wants

thus giving the maximum number of bugs with the minimum amount of 
convenience.


>> The more I learn about C, the less I want to know about C. What sort of
>> crazy language designer thought that having
>>
>> 2 == 2 == 2
>>
>> return 0 (false) was a good idea?
> 
> It makes perfect sense though; 

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".



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