Re: why cannot assign to function call

[Joe Strout]

Mark Wooding wrote:


As an aside, I don't notice anywhere near as much confusion in Lisp and
Scheme groups, which might be surprising since Lisp and Scheme have
precisely the same data model, argument passing convention, and
assignment semantics, as Python has.


Nor is there anywhere near as much confusion in the REALbasic community 
(with which I'm most familiar), which also has the same semantics for 
reference types (which in RB is everything except numbers, colors, and 
Boolean).


Apparently there is occasionally a little confusion in the Java 
community, but it rarely reaches the sillyness proportions seen here:




  * The Lisp and Scheme communities are smaller.  This is certainly
true.  But it wouldn't explain what appears to be a disproportionate
level of confusion on the topic among Python beginners.

  * Individuals in the Lisp and Scheme communities are cleverer and/or
more widely experienced.  One might make an argument that this is
true and a result of the relative community sizes -- basically a
result of self-selection.  But instead I'll reject this as an
explanation.  It's arrogant and unproven.

  * The Lisp and Scheme communities make a concerted effort to explain
their data model clearly and precisely.  They accept that it's
actually quite complicated and, rather than pretend that it isn't,
explain the complexity and the benefits it brings that make the
complexity worthwhile.  I think this is the likely one.


That's a nice way of putting it.  I might go a step further and say that 
there is a small but vocal portion of the Python community that insists 
on confounding the issue by claiming that Python's assignment and 
parameter-passing conventions are different from other languages. 
(Which, of course, requires one's head to be firmly in the sand with 
regard to the basic fact that Python variables contain references, not 
objects.)



But it's not just assignment that deals with references.  It's argument
passing and storage of compound data as well.  (See PLR 3.1.)

They expect that assignment copies stuff, because that's what assignment
does.  Everywhere that I can think of -- except C++, which leaves
assignment semantics in hands of the programmer.  What they're confused
about is what, precisely, it is that gets copied.  And that, really, is
a result of an inadequate understanding of the data model.


I have nothing to add to this.  It just seem well worth quoting.  :)


I agree that most of the time, when one is using large (memory)
composite "objects", and one needs to pass, or access them by
different names, one will often use references to do so in order to
avoid expensive copies or to get desired "shared" behavior.  But (with
the exception of C arrays [*1]), doing so requires some special syntax
in all the languages I mentioned (AFAIK).


Ummm... you mentioned C, C++, `Python, Java, REALbasic, .NET'.


No, actually, that was me.  rurpy's list was something like C, FORTRAN, 
Perl, and VBA.



Well, C we've dealt with.  C++ is weird.  Python we all know, and is the
main subject of the argument.  REALbasic I don't know at all, but BASICs
traditionally represent data fairly directly (rather than via
references) so will largely be like C.


Not REALbasic.  It's a very modern language with semantics pretty much 
identical to Java.  Simple types (numbers, colors, Booleans) are stored 
directly; all other types (including strings, objects, and arrays) are 
stored on the heap and accessed via references.



.NET isn't a language at all:
rather, it's a virtual machine, runtime system, class library and family
of languages each of which may have idiosyncratic semantics.


But they don't, AFAIK -- they all have the same semantics; only the 
surface syntax differs.  And those semantics are the same as REALbasic 
and Java.


See  for some side-by-side 
comparisons.



Which leaves Java.  Java divides the world into `primitive' and
`reference' types (4.1).  The former are represented directly; the
latter have a pointer to the true data as immediate representation.


Right -- a very common pattern among modern languages.


So it still seems to me that this is a likely explanation to why there
is frequent misunderstanding of Python's assignments, and why
responding to such misunderstandings with, "Python's assignments are
the same as other languages'", is at best not helpful.


That's why I'm not just saying that assignment is the same.  I'm also
saying that the data model is most definitely not the same as C.


Technically true, in that pointers in C require some special syntax, but 
the common idiom is to hide this away by defining a new type:


 typedef Foo* FooPtr;

Now, for any code using the "FooPtr" type, the data model is the same as 
Python (or as Java, RB, .NET, etc., again for code that's using only 
reference types).


Best,
- Joe



--
http:/

Re: why cannot assign to function call

[Joe Strout]

ru...@yahoo.com wrote:


What is the observable difference between converting an
array to a reference (pointer) to that array and passing
the reference by value, and passing the array by reference?


The difference is whether an assignment to the formal parameter (within 
the function) affects the actual parameter (in the calling code).  If it 
does, then that's pass by reference.  If it does not, then that's pass 
by value.



That is, given a C-like compiler that is the same as
C except that it passes arrays by reference, how would
it differ from an ordinary C compiler?


Such a compiler is available: it's called C++, and it gives the 
programmer the choice to pass by value or pass by reference (the latter 
indicated by adding "&" to the parameter in the function declaration, 
just like you would add "ByRef" in RB or VB.NET).


If the parameter is called "foo", and you pass in "bar", then

  foo = SomeNewArray();

would change bar if it were passed by reference; it would not affect bar 
at all if it were passed by value.


The two are quite distinct.

Best,
- Joe

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

Re: why cannot assign to function call

[Joe Strout]

Aaron Brady wrote:


Aaron Brady wrote:

Possible compromise.  You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name.  The old
name doesn't go in.  

That's correct.  The reference itself is passed in, not the variable (or
expression) that held or generated the reference in the calling code.


This is very odd, and I see it quite a bit.
Me: "You pass the object."
Joe: "That's correct.  You pass the reference."

What was wrong with my original?


I'm saying that I believe your idea was correct, but worded imprecisely 
(IMHO of course).  So I restated what I believed you were saying, using 
terminology which I believe to be more precise.  If nothing else, this 
gives you the opportunity to say "No, that's not what I meant at all."



This is true.  (Technically, instead of variable, we should say "LValue"
here -- there are things slightly more complex than simple variables
that can serve as the left-hand side of an assignment.  So replace
"variable" with "lvalue" above if you prefer.)


This is a point worth making.  I want to penny-pinch every term in an
introductory text, though, so, it's a tough call.


Agreed.


M2: If 'fun()' returned a reference, you might be able to mutate the
object that refers to.
m2: You can sometimes mutate the object it refers to.
C2: 'fun()' returns a reference.


This is horrendous.
http://en.wikipedia.org/wiki/Formal_fallacy
http://en.wikipedia.org/wiki/Affirming_the_consequent


I did point out that the logic was incorrect (even though the 
conclusion, in this case, happens to be true).



A question: Are you Joe and you Mark certain that the simplest
possible introductory explanation makes use of the term 'reference'?


I am.


Perhaps we can have a contest for shortest/simplest/best description
of Python's data/variable/argument model.


Sure -- but it judging it might be difficult, requiring some newbies and 
a test to check their comprehension (as you and I pondered once before).



Lastly, I don't see any reason why we couldn't make both explanations
available.  'For those coming from Java/etc; for those coming from
C++/etc.'  They would both get read.


Yes, except that the reference explanation applies equally well to 
anyone coming from Java, C/C++, RB, VB.NET, and probably others... I'm 
not sure to whom the other explanation would appeal, unless perhaps it's 
LISP programmers (just a guess, since those on that side of the aisle 
seem to invoke LISP more frequently).



Best,
- Joe


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

function to find the modification date of the project

[Joe Strout]

This isn't a question, but something I thought others may find useful 
(and if somebody can spot any errors with it, I'll be grateful).


We had a case recently where the client was running an older version of 
our app, and didn't realize it.  In other languages I've avoided this by 
displaying the compile date in the About box, but of course Python 
doesn't really have a meaningful compile date.  So, instead we're now 
displaying the latest modification date of any .py file in the project. 
 Here's the function that finds that:



def lastModDate():
"Get the latest modification date (as a string) of any .py file in 
this project."

import os, time
latest = 0
dir = os.path.dirname(__file__)
if dir == '': dir = '.'  # HACK, but appears necessary
for fname in os.listdir(dir):
if fname.endswith('.py'):
modtime = os.stat(os.path.join(dir, fname)).st_mtime
if modtime > latest: latest = modtime
out = time.strftime('%Y-%m-%d', time.localtime(latest))
return out


The intent of this code is to find any .py files in the same directory 
as the module containing the above code, and return (as a date string in 
SQL/ISO format) the latest modification date thereof.  Then, this is 
displayed to the user in the about box like so:


dlg = wx.MessageDialog(self,
  "etown unified database system\nRevision: %s" \
  % lastModDate(),
  "About etown Central", wx.OK | wx.ICON_INFORMATION)
dlg.ShowModal()
dlg.Destroy()

(That's wxPython, of course.)

I haven't yet tested this in a packaged app or on Windows, but it seems 
to work in our OS X test environment.


One odd thing was the need to employ the HACK identified above, where if 
__file__ happens to already be in the current directory, then 
os.path.dirname of it returns the empty-string -- yet the empty-string 
is not a valid argument to os.listdir().  Is there a better way to a 
list of files in the same directory as a given file?


Cheers,
- Joe

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

Re: function to find the modification date of the project

[Joe Strout]

James Mills wrote:


You know you could just store a __version__
attribute in your main library (__init__.py). :)


What, and update it manually?  I don't trust myself to remember to do 
that every time!


Best,
- Joe


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

Re: function to find the modification date of the project

[Joe Strout]

James Mills wrote:


Also I'd like to point out that your method is not
very reliable as the modification time of those
files could change at any moment. Consider
unix systems for instnace where you could do:

touch *

And poof, you're modification times are now
the current time!


Yes, and presumably if some power user did this, then that would be the 
intended effect.  Not sure why they'd do that, but they must have a good 
reason -- who am I to stop them?


Cheers,
- Joe

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

Re: function to find the modification date of the project

[Joe Strout]

Terry Reedy wrote:

Yes, and presumably if some power user did this, then that would be 
the intended effect.  Not sure why they'd do that, but they must have 
a good reason -- who am I to stop them?


What if a curious user simple looks at a file with an editor and saves 
it without change?


You can't do that, on the Mac at least...

Or changes it inconsequentially? Or makes copy to 
x.py.orig, edits and plays with original, and when done renames 
x.py.orig to x.py.  Or any such thing (which I have done in 
Pythonxy/Lib) without any intention of changing version date?


Then the About box will show, quite correctly, that the app was mucked 
with at that date, and when they call me up and complain, and I ask them 
to read me the contents of the About box, I can know right away that 
they've probably broken something (no matter how inconsequential they 
believed their change to be), and tell them to re-download it.


But really, this is NOT going to happen.  These users wouldn't even know 
how to open the app bundle to find the Python files.


Any comments on the functioning and platform-independence of the code?

Thanks,
- Joe


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

Re: English-like Python

[Joe Strout]

Aaron Brady wrote:


I think it would be a good step if you could make some sensible
interpretation of a typical statement without its parentheses.

f "abc" 123
-->
f( "abc", 123 )

It would be just the thing in a couple of situations...


Such a language is possible -- take a look at REALbasic sometime.  RB 
certainly has its problems (mainly bugs), but the language syntax is 
beautiful.  To your point, parentheses are not required around any 
method call that (1) has no return value, or (2) requires no parameters. 
 Example:


 LogError "Walk has gotten too silly", CurrentTime

Here, LogError is a method call that takes two arguments, and 
CurrentTime is a method call that takes none.


Your "f" example above works fine in RB too, though with such an 
abstract example it's a little hard to see why it's so cool.


Eliminating unnecessary parentheses does a lot to improve the 
readability of the code IMHO.


Cheers,
- Joe

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

Re: English-like Python

[Joe Strout]

Aaron Brady wrote:


Unambiguity and readability are two different things.  (This should be
a quasi-tangent, neither agreed, nor opposed, nor unrelated to what
you said.)

If you have

f "abc" 123

it's unambiguous, but, if you have

g f "abc" 123 "def"

there's no sure way to determine where the call to 'f' stopped, and
the one to 'g' resumed (or, as in Python, if 'f' was even to be called
at all, as opposed to 4 parameters to 'g').


Right -- that's exactly why (in RB) parentheses are required around 
arguments to a method call if that method returns a value (in RB terms, 
if it is a function rather than a subroutine).  Then there is no 
ambiguity, because only such a function can be used as an argument to 
another method call (or otherwise be part of an expression).  The above 
would have to be written something like:


 g f("abc", 123), "def"

I'm not saying I know how to translate this into Python -- some of 
Python's other language features make this difficult.  Just pointing out 
that your original wish is possible in at least some languages.


Best,
- Joe


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

Re: English-like Python

[Joe Strout]

Steven D'Aprano wrote:


  LogError "Walk has gotten too silly", CurrentTime

Here, LogError is a method call that takes two arguments, and
CurrentTime is a method call that takes none.


That seems ambiguous to me. As a non-RealBasic programmer, I can see at 
least four meanings it could have. Translated into Python, they are:


LogError("Walk has gotten too silly", CurrentTime)
LogError("Walk has gotten too silly"), CurrentTime
LogError("Walk has gotten too silly", CurrentTime())
LogError("Walk has gotten too silly"), CurrentTime()


It's not ambiguous because RB doesn't have a tuple syntax that looks the 
same as arguments to a function call.  You also can't get a reference to 
a method simply by naming it; naming it invokes it (when you want a 
reference to it instead, you use the "AddressOf" keyword).  So, the 
first and third of your lines above mean the same thing, and are the 
correct (and only possible) interpretation.  The second and fourth are 
also equivalent, but would require the parentheses around the LogError 
parameter since in that case it is a function (i.e. returns a result).


As I said before, I'm not sure how you would apply this to Python, where 
other syntax choices (tuples, function references, etc.) get in the way 
of this idea.  I'm merely pointing out that what Aaron asked for is 
possible without ambiguity, and actually used in at least one real-world 
language.


But even if RB doesn't have these things, I question that the syntax is 
"beautiful". Consider some arbitrary method Foo. If you see this:


Foo

Is that legal RB syntax?


You betcha!  For example, the built-in method to play the standard 
system alert sound is:


Beep

Doesn't get much more readable and syntax-free than that.  Suppose now 
that a beep isn't eloquent enough, and you want the computer to speak 
something out loud instead.  Also easy:


Speak "Spam, spam, spam, baked beans and spam."

If you're writing a console app, then there's a built in "Print" 
subroutine that puts a string to stdout.  Its usage is:


Print "Spam, spam, spam, baked beans and spam."

Note that this syntax is exactly like Python's "print" syntax prior to 
3.0, but in RB, it's not a special case -- it's just another method 
call, and you can define your own methods that you invoke exactly the 
same way.


Maybe yes, maybe no. It all depends on what Foo 
does. If it returns no result, then it's legal. If it returns a result, 
it isn't.


Right.  In other words, you can tell just by looking at the call that it 
doesn't return a result.  This is often handy.


So the question of whether syntax is legal depends, not on the 
syntactic elements involved, but on the *semantics* of the method 
(whether or not it returns a result).


But of course.  Any method call is legal only if the form of the call 
matches the method prototype -- if you try to call a function that 
requires 4 parameters, and give it only 3, that's an error too.  I don't 
see how this is different in any important way.



Eliminating unnecessary parentheses does a lot to improve the
readability of the code IMHO.


But they're not unnecessary, at least not in Python, they're useful for 
distinguishing between calling the function and the function itself. 


Yes, quite true in Python.  If there were some other way to distinguish 
between those -- and if tuple syntax didn't look the same as method call 
arguments -- THEN they would be unnecessary.  But those would be very 
substantial changes to Python syntax, and I'm not seriously proposing them.


Best,
- Joe

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

Re: English-like Python

[Joe Strout]

Aaron Brady wrote:


Where functions are first-class objects, a bare function object isn't
distinguishable either from its call.


That depends not on whether functions are first-class objects, but on 
the *syntax* of function invocation vs. function reference.  It just so 
happens than in Python, the syntax for the latter is the bare function 
identifier.  But it wouldn't have to be -- you could use "@foo" or 
"{foo}" or "ref foo" or (as in RB) "AddressOf foo" or any number of 
other alternatives to accomplish the same thing, and functions would 
still be first-class objects.


I'll grant that having any such syntax makes them *odd* first-class 
objects, since all other objects are referred to with a naked 
identifier, and invoked (if they are callable) with some other syntax. 
It'd be weird and inconsistent to have functions turn that around.  But, 
despite being inconsistent, it might still be sensible, based on the 
observation that we generally need to invoke methods a lot more often 
than we need to get a reference to them.


> I'm granting that it's useful

to return values a lot.  For example:

a= f

could mean either, 'a= f' or 'a= f()'.  Once again the return values
save the day.


I think I agree (if I follow you correctly).  But then some other syntax 
would be needed for when you really mean "a=f" (i.e., make 'a' refer to 
the same function as 'f').


Best,
- Joe

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

Re: English-like Python

[Joe Strout]

Steven D'Aprano wrote:


Foo

Is that legal RB syntax?
You betcha!  


How do you know? I haven't specified what Foo does.


You haven't specified whether "Foo" is a valid identifier at all, so I'm 
assuming that it is both valid and used correctly here.  The syntax is 
certainly valid -- it matches the language grammar -- but whether the 
programmer was smoking something while typing it is another matter.


You can't tell the difference between a syntax error and a valid call 
without knowing what Foo does. In Python, you can always recognise a 
syntax error without needing to worry about the semantics of the call. 
This is not the case with RealBasic.


If "Foo" is undefined or not a subroutine with no required parameters, 
then it's not a syntax error; it's an undefined-identifier error, a 
you-must-use-the-result-of-this-function-call error, or a 
invalid-arguments error.  It is NOT a syntax error in any case.


This is no different in Python, where:

  Foo()

may be valid or not, depending on whether there actually exists a Foo 
method in an accessible scope that has no required parameters.  If so, 
it's valid Python code; if not, it is some sort of error.


The only difference is that RB will detect any of those errors at 
compile time, while Python will not detect them until this line of code 
is executed.


Given code that compiles/runs without error, the other difference 
between the two is that in RB, you can tell that Foo has no return 
value, whereas in Python you can't tell -- and if it does return a 
value, you can't tell whether the author of the line above is 
intentionally ignoring it, or was just ignorant.



 Beep

Doesn't get much more readable and syntax-free than that.


readable doesn't mean smallest amount of syntax possible sometimes syntax 
increases the readability of a text as you would see if we for example 
dropped all punctuation but you probably already knew that but perhaps 
you didnt draw the connection with programming language wink


Cute.  But I stand by my contention that "Beep" is about the most 
readable way imaginable to express the "make a beep sound now please" 
command, and any additional punctuation (parentheses, semicolons, etc.) 
only get in the way.



Suppose now
that a beep isn't eloquent enough, and you want the computer to speak
something out loud instead.  Also easy:


I've programmed in Hypertalk, which is full of constructs like:

get the value of field "Bar"
put it into x
put x+37 into x
ask "Eat " & x " pies?" with "Yes please", "No thanks"
if it is "Yes please" then go to card "PieCard"


Yes, AppleScript is like this to.  Beastly.  I consider those to be 
read-only languages -- easy to read, maddeningly difficult to write, as 
you often have to guess exactly which English-like construct is going to 
actually work.


so I understand the principle of leaving out parentheses to make things 
look kinda-sorta vaguely English-like.


That wasn't really my point here.  REALbasic isn't much more 
English-like than any other language; it's just much lighter on all the 
extra punctuation that seems to plague many other languages.  One Yuma 
(which uses the same language as RB) user put it this way:


"I'm so freaking excited about Yuma that I can barely write about it. 
It's an HTML preprocessor like PHP, but with clean syntax. This is good 
because PHP is nasty. It's powerful and ubiquitous, but it looks like 
someone with a mouthful of punctuation sneezed all over my screen."


The same comment would apply to any other C-derived language, such as 
ActionScript, Java[Script], C++, Obj-C, and so on.  Python is better 
than these, but still not as clean as Python.



But of course.  Any method call is legal only if the form of the call
matches the method prototype -- if you try to call a function that
requires 4 parameters, and give it only 3, that's an error too.  I don't
see how this is different in any important way.


But it isn't (presumably) a syntax error.


Right, thanks for confirming my point above.  :)

I accept that in practice, it isn't a big deal once you get used to the 
convention. But it's a special case -- why treat functions of zero 
arguments as a special case just to save two characters?


It's not a special case.  It's an example of the general case, "only 
require parentheses where necessary to avoid ambiguity".  Pretty much 
all modern languages (i.e. please don't drag out LISP again) apply this 
principle in expressions, where "2+(3*5)" is the same as "2+3*5" -- 
parentheses here are optional because operator precedence already groups 
the terms unambiguously.


This is the same thing: if you want to multiply 10 by the result of a 
Rnd call and add 5, you can write "10*Rnd()+5" -- but the parentheses 
here aren't contributing anything.  They're not disambiguating anything 
or grouping anything or otherwise doing a job.  So you can instead write 
"10*Rnd+5" by the general principle above.


Similarly, if you have a subroutine 

Re: New to python, open source Mac OS X IDE?

[Joe Strout]

joseph.a.mar...@gmail.com wrote:

Greetings! I've heard enough raving about Python, I'm going to see for
myself what all the praise is for!

I'm on a Mac. I use Netbeans for Java, PHP, and C if needed. Do you
even use an IDE for Python?


I don't -- I just use TextWrangler and a Terminal window.  I tried 
several IDEs and didn't really find any of them stable and feature-rich 
enough to be worth the bother (though Editra came close).


Lack of a really top-notch IDE is one of the primary drags harshing on 
my Python buzz (as the young people say).


Best,
- Joe

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

Re: how to dynamically instantiate an object inheriting from several classes?

[Joe Strout]

On Nov 21, 2008, at 7:02 PM, Steven D'Aprano wrote:


I have a function that takes a reference to a class,


Hmmm... how do you do that from Python code? The simplest way I can  
think

of is to extract the name of the class, and then pass the name as a
reference to the class, and hope it hasn't been renamed in the  
meantime...


Please quit trying to confuse the kids at home.  Classes in Python are  
first-class objects, and any time you refer to a class or any other  
object in Python, what you have is a reference to it.


   

Cheers,
- Joe

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

Re: Official definition of call-by-value (Re: Finding the instance reference...)

[Joe Strout]

On Nov 22, 2008, at 4:08 AM, Aaron Brady wrote:


Furthermore, to apply c-b-v to Python, you have to
introduce the concept of pointers, which is ostensibly non-native for
human programmers.


Not necessarily "pointers" per se -- any type of object references  
will do, and yes, Python has those in spades.


 You'd have a pretty hard time making the case that c-b-v is 'round  
peg, round hole' for Python.


I didn't find it all that hard: 



 Just describe it and give it a name.


OK: "Python variables contain object references, which are copied from  
the actual parameter expression to the formal parameter.  This  
evaluation strategy is named 'call-by-value,' though some authors use  
the term 'call-by-sharing' to indicate the specific case of call-by- 
value where the values passed are object references."


(I should add that last bit to my web page -- I'll try to do that this  
weekend.)


Cheers,
- Joe

P.S. I've pretty well tired of this thread, but I can't let Greg stand  
up for truth and clarity all by himself...


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

Re: how to dynamically instantiate an object inheriting from several classes?

[Joe Strout]

On Nov 24, 2008, at 11:10 AM, Matimus wrote:


I wrote this a while ago. I sort of regret it though. Mixins could
(and I will argue should) be avoided most of the time by delegating to
other objects with less functionality. Utilizing many mixin classes
tends to just make gigantic classes. This is a huge violation of the
"Single Responsibility Principle".


I see your point, but in this case, I'm building a layout/config tool  
for use with wxPython, and wx uses a fair number of mixins (especially  
for the list control).



That isn't to say that I don't
think there is a place for multiple inheritance. Multiple inheritance
to the point where it is easier to write a metaclass to automatically
generate your __init__ method than it is to write it yourself is a
good indicator that you have gone too far. Which is what I did.


I appreciate the sample code, and the thoughtful comments.  You do  
yourself credit.


Best,
- Joe

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

recommended __future__ imports for 2.5?

[Joe Strout]

OK, this will probably be placed into the "stupid question" category  
by some, but I really am in need of a bit of guidance here.


I just rediscovered the "gotcha" of integer division in 2.5 and below,  
and found (to my delight) that this is fixed in 3.0, and fixable in  
older versions of Python with "from __future__ import division".  Once  
I stumbled across that, I was able to find the relevant PEP (#238) and  
read more about it.  So now that import has become part of our  
standard boilerplate at the top of each file, along with the path to  
Python and the UTF-8 encoding declaration.


Now I'm wondering what other boilerplate I should be using.  I'm not  
yet ready to upgrade to Python 2.6 -- parts of our business model rely  
on using the standard Python installed with Mac OS X (which is  
currently 2.5.1).  But I would like our code to be as future-proof as  
possible, especially in cases like this where we're talking about  
changes to existing behavior, rather than the introduction of entirely  
new features (like the "with" statement).


I found , which lists  
the available future imports, but doesn't link to any documentation on  
them.  Searching for each one on google turns up some probably- 
relevant PEPs, but it's hard for a relative newbie to tell for sure  
exactly what was implemented when and which is merely a summary of  
discussion.


So... besides "division", are there any other imports you would  
recommend as standard for any new code written in 2.5?  And what else  
do you experienced gurus put at the top of every Python file?


Thanks,
- Joe



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

simplest way to strip a comment from the end of a line?

[Joe Strout]

I have lines in a config file which can end with a comment (delimited  
by # as in Python), but which may also contain string literals  
(delimited by double quotes).  A comment delimiter within a string  
literal doesn't count.  Is there any easy way to strip off such a  
comment, or do I need to use a loop to find each # and then count the  
quotation marks to its left?


Thanks,
- Joe


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

Re: Python 3.0 automatic decoding of UTF16

[Joe Strout]

On Dec 5, 2008, at 11:36 AM, Johannes Bauer wrote:


I suspect that '?' after \n (\u0a00) is indicates not 'question-mark'
but 'uninterpretable as a utf16 character'.  The traceback below
confirms that.  It should be an end-of-file marker and should not be
passed to Python.  I strongly suspect that whatever wrote the file
screwed up the (OS-specific) end-of-file marker.  I have seen this
occasionally on Dos/Windows with ascii byte files, with the same  
symptom

of reading random garbage pass the end of the file.  Or perhaps
end-of-file does not work right with utf16.


So UTF-16 has an explicit EOF marker within the text?


No, it does not.  I don't know what Terry's thinking of there, but  
text files do not have any EOF marker.  They start at the beginning  
(sometimes including a byte-order mark), and go till the end of the  
file, period.


I cannot find one in original file, only some kind of starting  
sequence I suppose

(0xfeff).


That's your byte-order mark (BOM).


The last characters of the file are 0x00 0x0d 0x00 0x0a,
simple \r\n line ending.


Sounds like a perfectly normal file to me.

It's hard to imagine, but it looks to me like you've found a bug.

Best,
- Joe

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

Re: how to get a beep, OS independent ?

[Joe Strout]

On Dec 7, 2008, at 6:36 AM, Duncan Booth wrote:

Python is just printing the ascii bell character: some environments  
will

interpret that as a request to make a beep, some will do things like
flashing the whole screen, others just output a graphic character.  
Python

doesn't know what your environment will do.


Agreed.

But invoking the standard system beep is such a basic function that it  
ought to be easier than this.  I'm pretty sure it's a single OS call  
on all platforms.  On OS X, for example, it's


  void NSBeep(void);

declared in NSGraphics.h.  I'm sure it's something similarly simple on  
other platforms.


Where's the standard place for this sort of OS-abstraction function,  
outside the standard Python library?  I'm talking about something more  
light-weight than wx, QT, or TK; something that just wraps standard  
functions (like the system beep) and works in console apps or in any  
flavor of GUI app.  Is there such a module out there somewhere?


Best,
- Joe


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

Re: how to get a beep, OS independent ?

[Joe Strout]

On Dec 7, 2008, at 8:48 AM, Grant Edwards wrote:


On 2008-12-07, Joe Strout <[EMAIL PROTECTED]> wrote:


But invoking the standard system beep


What makes you think there is such a thing as "the standard system  
beep"?


Because OS X (the platform with which I'm most familiar) certainly has  
one, and REALbasic has had a "Beep" method for years which works on  
all platforms.  If RB can do it, we can do it too.


Best,
- Joe

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

Re: how to get a beep, OS independent ?

[Joe Strout]

On Dec 7, 2008, at 4:43 PM, Steven D'Aprano wrote:


Of course, if you're volunteering to write such a standard system beep
for Python, I for one would be grateful.


I am.  But where should I put it?  Assuming we don't want to wait for  
the (understandably) lengthy and contentious process required to add  
something to the Python system libraries, where would be the next best  
place for this sort of simple OS abstraction layer?


Thanks,
- Joe

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

Re: A question about reference in Python.

[Joe Strout]

On Dec 7, 2008, at 10:26 PM, Group wrote:

Now, I want to write a Red-Black Tree, and a List structure. In C/C+ 
+, I can
use pointers to refer to  children  notes (or next notes). But, in  
Python, how

can I do it? Except the sequence, I know not any way.


Any variable in Python is a reference, which is roughly analogous to a  
pointer type in C/C++.  For details and examples, see:  


Best,
- Joe


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

Re: A question about reference in Python.

[Joe Strout]

On Dec 8, 2008, at 7:43 PM, Steven D'Aprano wrote:


On Mon, 08 Dec 2008 08:18:27 -0700, Joe Strout wrote:


On Dec 7, 2008, at 10:26 PM, Group wrote:

Now, I want to write a Red-Black Tree, and a List structure. In C/C 
+ +,

I can
use pointers to refer to  children  notes (or next notes). But, in
Python, how
can I do it? Except the sequence, I know not any way.


Any variable in Python is a reference


Except that they don't behave like references in languages that have
explicit reference parameters.


I didn't say anything about reference parameters (by which I believe  
you mean parameters passed by reference).  I say a variable in Python  
IS a reference.  And it is *exactly* like a reference parameter in any  
other modern OOP language, as I've clearly shown (http://www.strout.net/info/coding/valref/ 
).


That page also explains that Python's references are always passed by  
value; Python doesn't have a pass-by-reference mechanism, unlike (say)  
RB, C++, or .NET.


This stuff really isn't that hard.

Did you not see the thread asking how to create reference parameters  
in
Python? Subject "var or inout parm?". I noticed you were conspicuous  
by

your absence in that little discussion.


No, sorry, I missed that one.  The volume of this group (plus the  
several other Python lists I subscribe to) requires me to skim a lot,  
and often choose not to read a thread at all.


In this case, the subject caught my attention, and I saw that I could  
help clear up some confusion.  Now that I've done that, I'll probably  
cease to read this thread any further, since as you say, we've been  
over this to death.  Go ahead and try to confuse him if you insist.   
Hopefully he'll ignore that and see that Python is simple, and  
identical in its semantics to the languages he already knows.


Best,
- Joe

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

Re: How to initialize a class variable once

[Joe Strout]

On Dec 9, 2008, at 4:31 AM, Brian Allen Vanderburg II wrote:

There is one situation where a module can be imported/executed  
twice, if it is the __main__ module.


That's an excellent point -- this is something I've run into, and it  
always feels a bit awkward to code around it. What's the standard  
idiom for avoiding this issue in a complex app?  Have a "main" file  
that is not imported by anything else, and which does little but  
launch stuff from some other module?


As I say it, that seems obvious, but somehow I keep getting urges to  
put global stuff (like my Application subclass) in the main file, and  
then I find I need to reference it from some other module, and get  
into trouble.  This is probably just bias from my last programming  
environment, though.  I can adapt.


Anyway, thanks for pointing this out; I bet it's the root cause of the  
OP's observation.


Best,
- Joe

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

Re: var or inout parm?

[Joe Strout]

On Dec 10, 2008, at 4:29 PM, J. Clifford Dyer wrote:


[EMAIL PROTECTED] wrote:


How can I make a "var" parm, where the called function can modify
the value of the parameter in the caller?


See Also: the earlier heated debate thread over what evaluation
strategy Python uses (Survey says!: call-by-object).



Oh dear God.  PLEASE don't see also that thread.  That way lies  
madness.
Just google for call-by-object, and ignore the hell out of that  
thread.


Agreed on that point!

Anyway, to the OP, see  for  
a detailed explanation of why you can't do quite what you're asking  
for in Python (or Java, for that matter).


Best,
- Joe

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

Re: Call by reference in SWIG?

[Joe Strout]

On Dec 10, 2008, at 10:19 PM, Nok wrote:


I can't get call-by-reference functions to work in SWIG...


Python doesn't have any call-by-reference support at all [1], so I'm  
not surprised that a straight translation of the call-by-reference C  
function doesn't work.


Unfortunately I don't know enough about SWIG to suggest a work- 
around.  Hopefully someone more versed in SWIG will have a bright  
idea.  If you don't find anything in the Python space, you might try  
poking around in Java references, since Java has the same call  
semantics as Python.


Best wishes,
- Joe

[1] http://www.strout.net/info/coding/valref/

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

Re: list organization question

[Joe Strout]

On Dec 11, 2008, at 4:12 PM, Robocop wrote:


I have a list of objects, each object having two relevant attributes:
date and id.  I'd like not only organize by id, but also by date.
I.e. i would like to parse my list into smaller lists such that each
new mini-list has a unique date, but consists of only objects with a
specific id.


I'm not quite following you here.  What are the inputs and outputs  
you're after?


For the sake of argument let's say you want: given the list of objects  
(let's call it mylist), and a desired ID (desired_id), return a  
smaller list of all the objects with that ID.  That would be simply:


  return [item for item in mylist if item.id=desired_id]

Look up "list comprehensions" for an explanation of what's going on  
here.


If you want a list for a given date, then just change the "if" part.

You seem to want both at once, but I can't understand what that means.

HTH,
- Joe


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

any Python developers available in the Denver area?

[Joe Strout]

My company is considering a contract job that would require some  
development staff on the client site in Denver.  We'd like to  
subcontract some of that work.  If you're a good Python coder in the  
Denver area, and would be available at least three days a week  
starting in January, please send me email privately.


Thanks,
- Joe


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

Re: concept of creating structures in python

[Joe Strout]

On Dec 11, 2008, at 10:52 PM, navneet khanna wrote:

I want to create a structure within a structure i.e. nested  
structures in python.

I tried with everything but its not working.
my code is like this:

class L(Structure):

def __init__(self,Name='ND',Addr=0,ds_obj = D()):


Change the default value of ds_obj here to None.  Otherwise, you will  
certainly confuse yourself (there would be just one default object  
shared among all instances).



self.Name = Name
self.Addr = Addr
self.ds_obj = ds_obj


class D(Structure):

def  __init__(self,dataName='ND',index = 0,ele_obj=E()):

self.dataName = dataName
self.index = index
self.ele_obj = ele_obj


Same thing here with ele_obj -- have it default to None to save  
yourself grief.


Otherwise, these look fine.


these are two structures. I want to refer D structure in L one and  
use it. I want to access the value of D structure like L.D.index = 0.


But you didn't name it "D" -- if you have an L object, say "foo", then  
you'd get to it's D object as foo.ds_obj (since that's what you named  
it in L.__init__).  If you then wanted to get to that thing's E  
object, it'd be foo.ds_obj.ele_obj.


Best,
- Joe

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

Re: concept of creating structures in python

[Joe Strout]

On Dec 12, 2008, at 9:00 AM, Steve Holden wrote:


Change the default value of ds_obj here to None.  Otherwise, you will
certainly confuse yourself (there would be just one default object
shared among all instances).


Joe missed a piece out here. If you change the signature of your
D.__init__() to read

def  __init__(self, dataName='ND', index = 0, ele_obj=None):

then you need to insert the following code at the top of the method:

   if ele_obj is None:
   ele_obj = E()


Yes, if you really need to guarantee that ele_obj is not None, then  
this is the way to do it.


Of course this would mean that you can't get a None ele_obj even by  
passing it in explicitly as the parameter value -- if you need to  
support that as well, then the solution is a little more complex.   
Perhaps best in that case would be to just not give ele_obj any  
default value at all, so it becomes a required parameter.


Best,
- Joe

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

Re: %s place holder does not let me insert ' in an sql query with python.

[Joe Strout]

On Dec 15, 2008, at 6:46 AM, Krishnakant wrote:


in this case, I get a problem when there is ' in any of the values
during insert or update.


That's because ' is the SQL string literal delimiter.  But any SQL- 
compliant database allows you to "escape" an apostrophe within a  
string literal by doubling it.  So for each of your values, just do:


  value = value.replace("'", "''")

before stuffing them into your INSERT or UPDATE statement.  (If these  
values come from the user, and especially if they come over the  
network, then you probably want to do a few other replacements; google  
"SQL injection" for details.)


Note that I'm not familiar with the cursor.execute binding that RDM  
pointed out, so that may provide a better solution... but the above  
should work.


Best,
- Joe

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

AIM client code for Python?

[Joe Strout]

I'd like to write an AIM bot in Python.  I found and tried
, but it doesn't work for me:

Connecting...
Traceback (most recent call last):
  File "aimbot-1.py", line 17, in 
bot.go()
  File "/Users/jstrout/Documents/Python-Dev/AIMbot/toc.py", line 62,  
in go

self.process_loop()
  File "/Users/jstrout/Documents/Python-Dev/AIMbot/toc.py", line 156,  
in process_loop

event = self.recv_event()
  File "/Users/jstrout/Documents/Python-Dev/AIMbot/toc.py", line 230,  
in recv_event

dtemp = self._socket.recv(buflen - len(data))
socket.error: (54, 'Connection reset by peer')


I wrote to the author a week ago, but never got a reply.  It could be  
as simple as changing the server addresses in toc.py, currently:


TOC_SERV_AUTH = ("login.oscar.aol.com", 2 )
TOC_SERV = ( "toc.oscar.aol.com", 9898 )

...but I don't understand AIM well enough to know the correct values  
(and was rather hoping that I wouldn't have to).


Does anyone know how to get Py-TOC to work, or have another Python TOC  
implementation to suggest?


Thanks,
- Joe



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

How to modify a program while it's running?

[Joe Strout]

Here's my situation: I'm making an AIM bot, but the AIM server will  
get annoyed if you log in too frequently (and then lock you out for a  
while).  So my usual build-a-little, test-a-little methodology doesn't  
work too well.


So I'd like to restructure my app so that it can stay running and stay  
logged in, yet I can still update and reload at least most of the  
code.  But I'm not sure what's the best way to do this.  Should I move  
the reloadable code into its own module, and then when I give my bot a  
"reload" command, have it call reload on that module?  Will that work,  
and is there a better way?


Thanks,
- Joe



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

Re: encoding problem

[Joe Strout]

Marc 'BlackJack' Rintsch wrote:


The question is why the Python interpreter use the default encoding
instead of "utf-8", which I explicitly declared in the source.


Because the declaration is only for decoding unicode literals in that 
very source file.


And because strings in Python, unlike in (say) REALbasic, do not know 
their encoding -- they're just a string of bytes.  If they were a string 
of bytes PLUS an encoding, then every string would know what it is, and 
things like conversion to another encoding, or concatenation of two 
strings that may differ in encoding, could be handled automatically.


I consider this one of the great shortcomings of Python, but it's mostly 
just a temporary inconvenience -- the world is moving to Unicode, and 
with Python 3, we won't have to worry about it so much.


Best,
- Joe




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

Re: How to parsing a sequence of integers

[Joe Strout]

Peter Otten wrote:


If you are using Python 2.x:
...
So you better throw in a float(...):


Or, add

  from __future__ import division

at the top of the file.  I put this at the top of all my Python files, 
whether I expect to be dividing or not.  It just saves grief.


Cheers,
- Joe

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

Re: How to parsing a sequence of integers

[Joe Strout]

Mensanator wrote:


from __future__ import division

at the top of the file. I put this at the top of all my Python files,
whether I expect to be dividing or not. It just saves grief.


If you want division to be floating point.
If, like me, you rarely do floating point
division and want the "/" to mean integer
division as God intended, then you don't
put from __future__ import division in your
source files.

That's one of the good things about Python,
you can have it either way.


Until you someday move up to Python 3, at which point you'll have to go 
back and change all your code to use the unambiguous // operator when 
you mean integer division.  Better to do it now, I think, at least in 
any new code you write, to save you the hassle later.


For those not familiar with the topic:

   

Best,
- Joe

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

Re: encoding problem

[Joe Strout]

Marc 'BlackJack' Rintsch wrote:


And because strings in Python, unlike in (say) REALbasic, do not know
their encoding -- they're just a string of bytes.  If they were a string
of bytes PLUS an encoding, then every string would know what it is, and
things like conversion to another encoding, or concatenation of two
strings that may differ in encoding, could be handled automatically.

I consider this one of the great shortcomings of Python, but it's mostly
just a temporary inconvenience -- the world is moving to Unicode, and
with Python 3, we won't have to worry about it so much.


I don't see the shortcoming in Python <3.0.  If you want real strings 
with characters instead of just a bunch of bytes simply use `unicode` 
objects instead of `str`.


Fair enough -- that certainly is the best policy.  But working with any 
other encoding (sometimes necessary when interfacing with any other 
software), it's still a bit of a PITA.



And does REALbasic really use byte strings plus an encoding!?


You betcha!  Works like a dream.


Sounds strange.  When concatenating which encoding "wins"?


The one that is a superset of the other, or if neither is, then both are 
converted to UTF-8 (which is the "standard" encoding in RB, though it 
works comfily with any other too).


Cheers,
- Joe

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

Re: encoding problem

[Joe Strout]

Marc 'BlackJack' Rintsch wrote:


I don't see the shortcoming in Python <3.0.  If you want real strings
with characters instead of just a bunch of bytes simply use `unicode`
objects instead of `str`.

Fair enough -- that certainly is the best policy.  But working with any
other encoding (sometimes necessary when interfacing with any other
software), it's still a bit of a PITA.


But it has to be.  There is no automagic guessing possible.


Automagic guessing isn't possible if strings keep track of what encoding 
their data is.  And why shouldn't they?  We're a long way from the day 
when a "string" was nothing more than an array of bytes.  Adding a teeny 
bit of metadata makes life much easier.



And does REALbasic really use byte strings plus an encoding!?

You betcha!  Works like a dream.


IMHO a strange design decision.


I get that you don't grok it, but I think that's because you haven't 
worked with it.  RB added encoding data to its strings years ago, and 
changed the default string encoding to UTF-8 at about the same time, and 
life has been delightful since then.  The only time you ever have to 
think about it is when you're importing a string from some unknown 
source (e.g. a socket), at which point you need to tell RB what encoding 
it is.  From that point on, you can pass that string around, extract 
substrings, split it into words, concatenate it with other strings, 
etc., and it all Just Works (tm).


In comparison, Python requires a lot more thought on the part of the 
programmer to keep track of what's what (unless, as you point out, you 
convert everything into unicode strings as soon as you get them, but 
that can be a very expensive operation to do on, say, a 500MB UTF-8 text 
file).


A lot more hassle compared to an opaque 
unicode string type which uses some internal encoding that makes 
operations like getting a character at a given index easy or 
concatenating without the need to reencode.


No.  RB supports UCS-2 encoding, too, and is smart enough to take 
advantage of the fixed character width of any encoding when that's what 
a string happens to be.  And no reencoding is used when it's not 
necessary (e.g., concatenating two strings of the same encoding, or 
adding an ASCII string to a string using any ASCII superset, such as 
UTF-8).  There's nothing stopping you from converting all your strings 
to UCS-2 when you get them, if that's your preference.


But saying that having only one string type that knows it's Unicode, and 
another string type that hasn't the foggiest clue how to interpret its 
data as text, is somehow easier than every string knowing what it is and 
doing the right thing -- well, that's just silly.


Best,
- Joe

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

Re: Python's popularity

[Joe Strout]

Alvin ONeal wrote:


Also worthy of mention:
I've seen python pre-installed on consumer HP desktops (I think as
part of a backup/restore script, but I'm not sure)


It's pre-installed on every Mac (both desktop and laptop), too.

Cheers,
- Joe

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

Re: embedding python in wxpython

[Joe Strout]

Steve Holden wrote:


I'd like the console to be a bidirectional representation of what's
going on in the gui, plus a general purpose evaluation environment
where you can manipulate application data via some api which is
automatically exposed to the console when the application opens up.

I'm looking for high-level hints/strategies/directions.


I seem to remember you can create your wxApp with an argument of True or
False. One of those settings creates a window containing any output to
sys.stderr, if I remember rightly.


You do -- True (the default) redirects standard output to a window, 
while False does not redirect it.


However, neither setting will create a bidirectional console or 
evaluation environment as the OP was asking for.  (But other wx widgets 
do provide that, as other replies have pointed out.)


Best,
- Joe


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

Re: why cannot assign to function call

[Joe Strout]

Mark Wooding wrote:


Derek Martin  wrote:


I think I have though, not that it matters, since that was never
really my point.  Python's assignment model requires more explanation
than the traditional one, simply to state what it does.  That alone is
evidence (but not proof).


Hmm.  Actually, it's not the assignment model which is strange at all.
It's the data model.  What does an expression like

  [1, 2, 3]

denote?  Is it the list itself, or a /reference/ to the list?  If you
answer the first, you'll want Tcl/C/Fortran semantics.  If you answer
the second, you'll want Lisp/Python/Javascript semantics.  If you answer
`it depends', you'll want to be confused.


Well said!

You can easily see that assignment in Python is perfectly ordinary, by 
comparing it to languages that have both values and references (such as 
C++, Java, or REALbasic).  Those languages have only one assignment 
model, that operates on both values and references just fine.


Python has only references, and I think it's for this reason that some 
people here try to pretend that it doesn't have them at all, thus 
leading them to weird explanations of strange assignment and 
argument-passing behavior.



Python decided that all values are passed around as and manipulated
through references.  (There are no locatives: references are not values,
and you can't have a reference to a reference.)


Also very clearly put.

If you don't mind, I may crib some of your verbage for 
, as it may be clearer than 
my own.


Best,
- Joe



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

Re: python is great

[Joe Strout]

I've actually been rather frustrated by Python lately.  It's great at 
some things, but rather poor at others.  In the latter category is 
building a neatly packaged executable that can be shipped to users and 
run reliably on their machine.  On the Mac in particular, if you want 
your app to run on any PowerPC or Intel machine runing 10.4 or later, 
and you're using anything not in the standard framework (such as 
MySQLdb), it's a bit of a nightmare.


Compare this to, say, REALbasic, where you just check "Mac OS X 
Universal" in the Build Settings, click Build, and you're done.  (RB has 
its own issues, of course.)


So I would say that Python as a language is great, and its standard 
framework is great.  But its (many) IDEs are pretty poor, and the 
process of building a polished, packaged app is abysmal.  And there are 
some things (such as Flash-style web applets) that you still can't do at 
all in Python, even after all these years.


But of course, the nice thing about an open-source environment is that, 
with enough motivation, time, and expertise, one can fix the most 
annoying limitations oneself.  And if I stick with Python over the 
upcoming years, I'll certainly do my part.


Best,
- Joe



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

Re: If your were going to program a game...

[Joe Strout]

Kay Schluehr wrote:


There is no solution to this problem from a Python perspective. Do
what everyone does right now: use Flash for the game and manage your
site with Python if you like the language.


I know this has been discussed before, and the difficulties are many, 
yadda yadda etc...  But suppose we reduce the scope: just the core 
Python language, maybe a VERY few of the standard modules (e.g. math and 
string), plus some pygame-like classes to move sprites around, play 
sounds, and check keyboard and mouse state.


Or to look at it another way: Python is used as the scripting language 
in many commercial games.  Why couldn't we make a browser plugin (in 
C++, for example) that implements a "generic" game, i.e. moving of 
sprites and playing of sounds and so on -- and that uses Python as its 
scripting language?


Not that I have anything against Flash; I've started learning it just 
last week, and apart from the nasty C-derived syntax, it's quite nice. 
It has a good IDE, good performance, great portability, and it's easy to 
use.  It just surprises me that after all these years, the Python 
community hasn't done something similar.


Best,
- Joe



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

Re: python is great

[Joe Strout]

M.-A. Lemburg wrote:


On the Mac in particular, if you want
your app to run on any PowerPC or Intel machine runing 10.4 or later,
and you're using anything not in the standard framework (such as
MySQLdb), it's a bit of a nightmare.



You're looking for py2app:

http://undefined.org/python/py2app.html


No, I'm *using* py2app.  I've been trying to use it for a couple of 
weeks now, with the generous help of such people as Robin Dunn, and I 
still don't have it quite working properly.  (I'd be happy to send you 
my notes on what was required to get as far as I've gotten, but it's 
several pages, a bit long to post here.)


(py2exe works a little more easily, thank goodness.)


So I would say that Python as a language is great, and its standard
framework is great.  But its (many) IDEs are pretty poor, and the
process of building a polished, packaged app is abysmal. 


It's certainly work, but that's always the case for nicely polished
apps :-)


In Python, yes.  :)  Not in all environments.


For packaging, you can choose from a multitude of installer builders -
none of which are really Python specific.


I'm not even talking about that level of packaging -- I'm just talking 
about making something that appears to the user like a normal 
executable, which they can double-click on their system and have it 
actually run, rather than aborting with something unhelpful like "No 
module named MySQLdb".



And there are
some things (such as Flash-style web applets) that you still can't do at
all in Python, even after all these years.


You're looking for Silverlight:
http://www.voidspace.org.uk/ironpython/silverlight/index.shtml


Maybe.  I'm not a big fan of anything so Microsoftian, but I'll admit 
that this does mostly fit the bill I described above (or has the 
potential to, anyway).


Thanks,
- Joe


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

Re: image recogniton?

[Joe Strout]

Li Han wrote:


Sorry, I oversimplified the question because of my poor english. It is
an analog compass whose value we need to read  into the computer every
second. We use a video camera keep shooting it, and the compass and
camera are  fixed.


If you have any choice about it, it would be greatly simpler, cheaper, 
and more effective to throw out the camera and analog compass, and use 
an electronic compass instead.  These are affordable and work quite well 
provided you keep them level (the same constraint you have with an 
old-fashioned compass too).  You can make some simple interface 
hardware, or spend a bit more for something with a USB or serial 
interface built in, like this: 



Best,
- Joe



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

Re: why cannot assign to function call

[Joe Strout]

Dan Esch wrote:

In essence, the implication of immutability for Python is that there is 
only one "parrot", one "spam,"in fact one anything. (This seems like it 
must hold for data primitives - does it hold for complex objects as 
well? It seems it must...) In addition there is only one 1, and one 2 
etc.


That's not necessarily true.  If you have

  a = "par" + "rot"
  b = "parrot"

then, most likely (though it depends on how clever the compiler 
optimizations are), there are two different string objects containing 
the data "parrot".  In this case, "a == b" is true because string 
equality testing compares the data, but "a is b" is false because a and 
b refer to different objects.


And by the way, don't let the people claiming that Python's assignment 
model is bizarre confuse you.  Assignment and parameter-passing in 
Python is exactly the same as in any other modern OOP language; it just 
so happens that in Python, all variables are references, while in most 
other languages, some variables are references and others are primitive 
types.  But it should be obvious (though apparently isn't, to some) that 
this restricted, uniform data model does not fundamentally change 
anything; it just makes Python a little more restricted and uniform. 
For details, see: 


Best,
- Joe


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

Re: why cannot assign to function call

[Joe Strout]

Mark Wooding wrote:


The `they're just objects' model is very simple, but gets tied up in
knots explaining things.  The `it's all references' model is only a
little more complicated, but explains everything.

But it *over* explains, because it implies things that "everybody knows"
about references in other languages that aren't true for Python.


I addressed this elsewhere.  Summary: `pass-by-reference' is a different
thing to `all you manipulate are references': Python does pass-by-value,
but the things it passes -- by value -- are references.


Quite right.  It's easy to see this in languages where some types are 
references and others are simple values; and even easier in such a 
language that supports both pass-by-value and pass-by-reference (such as 
REALbasic or VB.NET).  Then you can easily see, in one language, all 
combinations of [value type, reference type] * [pass by ref, pass by val].


In Python, we only have reference types, and we only have pass by value, 
so out of the four combinations above, there is only one: references 
passed by value.  You'd think this would make it easier, but from the 
raging debates and repeated obfuscation on this point, it apparently 
makes Python MORE difficult to understand and explain (at least for some).



I agree with the comment about Pascal, but C is actually pretty similar
to Python here.  C only does pass-by-value.  If you want a function to
modify your variable, you have to pass a pointer value which points to
it.


Right -- a C/C++ pointer is (or at least, can be in normal usage) pretty 
similar to a reference (though of course you can do more low-level and 
hackish things with them too).  In C, such a reference is always passed 
by value, as in Python or Java, and just like the default mode in RB or 
.NET.  In C++, you can also choose to pass such a parameter by 
reference, like the ByRef mode in RB and .NET.  This parameter passing 
mode is unavailable in Python or Java.



Okay, the abstraction has leaked again... are the paperweights references
to the objects, or the names we've bound objects to? I'm confused...


They're the references to the objects.  You don't bind names to
objects.  You bind names slots in which you store references.


Well put (again).  This is technically the correct description, though 
in casual usage, I think it's fine to occasionally gloss over some of 
these layers as long as everyone involved understands what is meant. 
(This is especially true when the references are to immutable objects, 
which are functionally very similar to simple values.)



How do we decide what is best for newcomers to Python, depending on
background?


That I really don't know.  I'm not good at teaching total beginners
(does it show?) because I'm too enmired in the theory. ...


FWIW, I've spent a fair amount of time teaching beginners, though not so 
much in Python yet.  But plenty of time in other languages where the 
same questions come up.  In my experience, pointing out that a variable 
of any object type contains a *reference* to that object, rather than 
the object data itself, and then illustrating with a couple of examples, 
quickly clears up any confusion.  I've never had a newbie require more 
than a couple of exchanges on this topic before they get it.  (And 
before I joined the Python community, I never even felt the need to 
actually draw a picture [1] to make it clearer.)



What I am pretty sure of is that references are going to have to enter
the picture at some point, because other models get too complicated.


I agree completely.  I can barely understand the other models myself.

Best,
- Joe

[1] http://www.strout.net/info/coding/valref/


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

Re: why cannot assign to function call

[Joe Strout]

ru...@yahoo.com wrote:


"the same as anyone else's" only if [Python's] "idea
of assignment" does not include producing the same
results.

  a = array (1,2,3)
  b = a
  a[1] = 4
  print b

C, C++, VBA, Fortran, Perl:  1, 2, 3
Python:  1, 4, 3


You are mistaken (except perhaps in the Fortran case, which is an 
oddball by modern standards, and I don't know Perl well enough to judge).


C/C++ code:

 int* a = malloc(3);
 a[0] = 1;
 a[1] = 2;
 a[2] = 3;
 int* b = a;
 a[1] = 4;
 print_array(b)
 ---> Result: 1, 4, 3

REALbasic code:

 Dim a() As Integer = Array(1,2,3)
 Dim b() As Integer = a
 a(1) = 4
 PrintArray b
 --> Result: 1, 4, 3

VB.NET code would be very similar in syntax, and identical in behavior, 
to the REALbasic code.  Java would also have the same semantics, though 
my Java is too rusty to get the syntax right without actually trying it.


If you can find a language where an array variable is NOT a reference 
(and thus does not behave exactly as in Python, Java, REALbasic, C++, 
etc.), then that language is either a dinosaur or some weird academic 
oddity.


Best,
- Joe


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

Re: why cannot assign to function call

[Joe Strout]

ru...@yahoo.com wrote:


  a = array (1,2,3)
  b = a
  a[1] = 4
  print b

C, C++, VBA, Fortran, Perl:  1, 2, 3
Python:  1, 4, 3

You are mistaken


I don't think so.
See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f869b96
The code I quoted there was tested.
In the C/C++ case, array-to-pointer coercion confuses
the issue so I embedded the array in a struct which
is more like an "object".


No, that's cheating (IMHO).  Structs used directly (rather than via
pointers) are the odd beast, and while they're certainly possible in C,
they are far from the normal idiom.  And certainly embedding an array in
a struct just to force it to be copied, avoiding the standard reference
semantics, is an arbitrary trick.

I never claimed that you *couldn't* have copy semantics in C; you can do
almost anything you want in C (or C++).  But the *normal* usage of an
array is via a pointer, in which case the semantics are exactly the same
as in Python, Java, REALbasic, .NET, etc.


(Keep in mind
my point was not to show the behavior of arrays, but to
show that several common languages *do not* use Python's
"*all* names are references" model -- though of course
this does not preclude their having some Python-like
assignments since they all have some way of doing
references.)


Ah.  OK then, I guess I missed you're point.  You're absolutely right;
many languages have both reference types and value types.  Python is a
bit unusual in that it has only reference types.  I would have picked a
different example to illustrate that, but it's true nonetheless.

Best,
- Joe



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

Re: why cannot assign to function call

[Joe Strout]

Aaron Brady wrote:


Possible compromise.  You can think of functions as mutation-only.
You pass the object, and it gets a new (additional) name.  The old
name doesn't go in.  


That's correct.  The reference itself is passed in, not the variable (or 
expression) that held or generated the reference in the calling code.


This is no different from, in C, passing an integer:

void foo(int bar) {
   bar = 42;
}
int baz = 0;
foo(baz);

This doesn't change baz because, speaking precisely, baz wasn't passed 
to foo -- only the *value* of baz (i.e. 0) was passed to foo.  Within 
foo, that value was stored in bar.  Assigning a new value to bar does 
not affect foo.


It's the exact same thing when the value happens to be a reference to an 
object:


typedef SomeClass* SomeClassPtr;
void foo(SomeClassPtr bar) {
   bar = new SomeClass();
}
SomeClassPtr baz = NULL;
foo(baz);

Again, we're not passing baz into foo; we're passing the *value* of baz 
(i.e. NULL) into foo.  That value is stored in bar within foo, and when 
we assign a new value (a reference to a freshly minted SomeClass object) 
into bar, of course it doesn't affect baz.



Regardless, IMO, references don't add any explanatory power; they just
make you feel cocky that you know what they are.


Nonsense.  They are the simple and clear explanation of what's going on.


M: If 'fun()' returned a reference, you would be able to assign to it.
m: You can't assign to it.
C: It doesn't return a reference.


C is false because M is false (at least, in the way I believe you mean 
it).  Or, more precisely, both M and m are nonsensical; what does it 
mean to "assign to a reference"?  It makes no sense.  What would it mean 
to assign to 42?


You don't assign to references any more than you assign to integers or 
assign to strings or assign to None.  Those are all values, and you 
don't assign to values -- you assign to variables.  "Assign" means to 
give a new value to a variable, i.e. to let (or cause) a variable to 
have a new value.  (Ye olde BASIC even used the LET keyword to indicate 
this, e.g. LET X = 42.)  Speaking casually, we don't always make this 
distinction, but I think precision is needed here.


So, I see two ways to make sense of your argument:

M1: If 'fun()' returned a variable, you would be able to assign to it.
m1: You can't assign to it.
C1: It doesn't return a variable.

This is true.  (Technically, instead of variable, we should say "LValue" 
here -- there are things slightly more complex than simple variables 
that can serve as the left-hand side of an assignment.  So replace 
"variable" with "lvalue" above if you prefer.)


Or, the other way some may see it is:

M2: If 'fun()' returned a reference, you might be able to mutate the 
object that refers to.

m2: You can sometimes mutate the object it refers to.
C2: 'fun()' returns a reference.

This is true (though the logic is flawed, but fixable).


-- Why can't I assign to a function call?
-- Python variables are references only.
-- Ok, why can't I assign to a function call?


You're right, "Python variables are references only" has nothing to do 
with it.  In a language where the only data type were "integer", you 
wouldn't be able to assign to a function call either.


You can't assign to a function call because a function call is not 
itself an lvalue, and it doesn't return an lvalue.  That's just not 
something you can get for free from the type model; it's an extra 
feature that would have to be built into the language somehow, and 
Python doesn't have it.


If assignment were an operator rather than a statement, and could be 
overridden in a class via some specially-named method -- or, for that 
matter, if the assignment statement looked for such a method when it 
finds an object reference on the left-hand side -- then any object could 
be an lvalue, and you COULD (in some cases) assign to the result of a 
function.  But it's not and it doesn't.


Best,
- Joe


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

Re: why cannot assign to function call

[Joe Strout]

ru...@yahoo.com wrote:


I never claimed that you *couldn't* have copy semantics in C; you can do
almost anything you want in C (or C++).  But the *normal* usage of an
array is via a pointer, in which case the semantics are exactly the same
as in Python, Java, REALbasic, .NET, etc.


Arrays are the only datatype in C that don't use
copy-like assignment.  Everything else does.


No, arrays are just one reference type; pointers are another (and in 
most ways, these are the same thing).  When dealing with objects in C++, 
one routinely handles them with pointers, so that's the use case which 
is analogous to Python -- all the value types can be ignored for the 
sake of comparison.  (C is not an OOP language, of course, but even 
there, all but the most trivial of structs are usually allocated on the 
heap and passed around via pointers, just like in C++, Java, .NET, RB, 
and Python.)



Ah.  OK then, I guess I missed you're point.  You're absolutely right;
many languages have both reference types and value types.  Python is a
bit unusual in that it has only reference types.  I would have picked a
different example to illustrate that, but it's true nonetheless.


If one accepts that there are a "lot" of people
who post in here that clearly are surprised by
Python's assignment semantics, and further appear
to expect assignment to have copy-like semantics,
then where is that expectation coming from?


I think it comes from people stumbling across posts in this forum 
claiming that Python has unusual assignment semantics.  I wish people 
would stop saying that, as it causes a lot of confusion.



How would anyone develop that expectation if (from
a different post in this thread), "[Python's] idea
of assignment is the same as anyone else's."


I can think of two ways:

1. They're new to programming in general, and would have had the same 
expectation for any other language.  OR,


2. They already understand some other language, and then they come here 
and read wild claims that Python's assignment and parameter-passing 
semantics are different from other languages.  Duped by this claim, they 
 conclude that, if it's unlike other languages, then Python must have 
copy semantics.



If you maintain that reference-like assignment
is very common and something every programmer is
accustomed to, then where are they getting the
copy-like assignment expectations from?


Reference-like assignment IS very common (see 
).  So, see above.



I agree that most of the time, when one is using
large (memory) composite "objects", and one needs
to pass, or access them by different names, one will
often use references to do so in order to avoid
expensive copies or to get desired "shared" behavior.


Right.


But (with the exception of C arrays [*1]), doing so
requires some special syntax in all the languages I
mentioned (AFAIK).


Whether you consider it "special" or not, pointers are extremely common 
in C.  Even more so in C++, which is the closest thing to an OOP 
language in the list of moldy languages you mentioned.


You also mentioned VBA -- if that's anything like VB, it does NOT 
require any special syntax; a variable is a reference type if its 
declared type is a class or string, and a simple type if it's anything 
else (just like in .NET, Java, and REALbasic).



So it still seems to me that this is a likely
explanation to why there is frequent misunderstanding
of Python's assignments, and why responding to such
misunderstandings with, "Python's assignments are
the same as other languages'", is at best not helpful.


I don't think so.  More likely, people are being confused by the claim 
that Python's assignments are NOT like other languages, when in fact 
they are.


Best,
- Joe


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

type-checking support in Python?

[Joe Strout]

I'm just re-learning Python after nearly a decade away.  I've learned  
a good healthy paranoia about my code in that time, and so one thing  
I'd like to add to my Python habits is a way to both (a) make intended  
types clear to the human reader of the code, in a uniform manner; and  
(b) catch any type errors as early and automatically as possible.


I found the "typecheck" module (http://oakwinter.com/code/typecheck/),  
but I notice that it hasn't been updated since 2006, and it's not  
included with the Python distribution.  Are there other modules  
providing similar functionality that I should consider instead?


Also, I'll probably be considering a lint-like tool at some point...  
are there any that allow you to declare some extra type information,  
and have that checked at lint time?


Finally, one thing I've considered is adopting some identifier  
prefixes indicating type.  Maybe "iFoo" for integer, "fFoo" for  
floating-point numbers, "d" for dictionary, "l" for list, "t" for  
tuple, "o" for object, and "v" for variable types that may be more  
than one of the above.  I gather (from just a couple days of browsing)  
that such a naming convention isn't common in the Python community,  
but is there anyone else here who does it?  I'd rather adopt an  
existing standard (even if it's not widely used) than make one up.


Many thanks,
- Joe


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

Re: equivalent of py2exe in other os

[Joe Strout]

On Oct 7, 2008, at 8:43 AM, Benjamin Kaplan wrote:

I believe that all (or nearly all) Unix variants come with Python  
preinstalled. Ubuntu, at least, has a lot of system programs written  
in Python. Even Mac OS X requires Python.


Yes, but with significant differences between different Python  
distributions, you might be safer bundling whatever version of Python  
your app requires with the app itself.  Otherwise, you risk your app  
failing (and probably puking up runtime exceptions all over the poor  
user's lap) on some distros or versions.


(My Mac OS X machine comes with Python 2.5.1, for example, which is  
hardly the latest.)


Best,
- Joe

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

distributing apps without the Python source?

[Joe Strout]

We have a client who's paranoid about distributing the Python source  
to his commercial app.  Is there some way I can distribute and use  
just the .pyc files, so as to not give away the source?


Thanks,
- Joe



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

Re: template strings for matching?

[Joe Strout]

On Oct 9, 2008, at 7:05 AM, [EMAIL PROTECTED] wrote:


   Tino> 
http://docs.python.org/library/stdtypes.html#string-formatting-operations

That shows how to use the template formatting as it currently  
exists.  To my
knowledge there is no support for the inverse operation, which is  
what Joe
asked about.  Given a string and a format string assign the elements  
of the
string which correspond to the template elements to key/value pairs  
in a

dictionary.


Right.

Well, what do y'all think?  It wouldn't be too hard to write this for  
myself, but it seems like the sort of thing Python ought to have built  
in.  Right on the Template class, so it doesn't add anything new to  
the global namespace; it just makes this class more useful.


I took a look at PEP 3101, which is more of a high-powered string  
formatter (as the title says, Advanced String Formatting), and will be  
considerably more intimidating for a beginner than Template.  So, even  
if that goes through, perhaps Template will stick around, and being  
able to use it in both directions could be quite handy.


Oh boy!  Could this be my very first PEP?  :)

Thanks for any opinions,
- Joe


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

template strings for matching?

[Joe Strout]

Catching up on what's new in Python since I last used it a decade ago,  
I've just been reading up on template strings.  These are pretty  
cool!  However, just as a template string has some advantages over %  
substitution for building a string, it seems like it would have  
advantages over manually constructing a regex for string matching.


So... is there any way to use a template string for matching?  I  
expected something like:


 templ = Template("The $object in $location falls mainly in the  
$subloc.")

 d = templ.match(s)

and then d would either by None (if s doesn't match), or a dictionary  
with values for 'object', 'location', and 'subloc'.


But I couldn't find anything like that in the docs.  Am I overlooking  
something?


Thanks,
- Joe

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

Re: template strings for matching?

[Joe Strout]

Wow, this was harder than I thought (at least for a rusty Pythoneer  
like myself).  Here's my stab at an implementation.  Remember, the  
goal is to add a "match" method to Template which works like  
Template.substitute, but in reverse: given a string, if that string  
matches the template, then it should return a dictionary mapping each  
template field to the corresponding value in the given string.


Oh, and as one extra feature, I want to support a ".greedy" attribute  
on the Template object, which determines whether the matching of  
fields should be done in a greedy or non-greedy manner.



#!/usr/bin/python

from string import Template
import re

def templateMatch(self, s):
# start by finding the fields in our template, and building a map
# from field position (index) to field name.
posToName = {}
pos = 1
for item in self.pattern.findall(self.template):
# each item is a tuple where item 1 is the field name
posToName[pos] = item[1]
pos += 1

# determine if we should match greedy or non-greedy
greedy = False
if self.__dict__.has_key('greedy'):
greedy = self.greedy

# now, build a regex pattern to compare against s
# (taking care to escape any characters in our template that
# would have special meaning in regex)
pat = self.template.replace('.', '\\.')
pat = pat.replace('(', '\\(')
pat = pat.replace(')', '\\)') # there must be a better way...

if greedy:
pat = self.pattern.sub('(.*)', pat)
else:
pat = self.pattern.sub('(.*?)', pat)
p = re.compile(pat)

# try to match this to the given string
match = p.match(s)
if match is None: return None
out = {}
for i in posToName.keys():
out[posToName[i]] = match.group(i)
return out


Template.match = templateMatch

t = Template("The $object in $location falls mainly in the $subloc.")
print t.match( "The rain in Spain falls mainly in the train." )


This sort-of works, but it won't properly handle $$ in the template,  
and I'm not too sure whether it handles the ${fieldname} form,  
either.  Also, it only escapes '.', '(', and ')' in the template...  
there must be a better way of escaping all characters that have  
special meaning to RegEx, except for '$' (which is why I can't use  
re.escape).


Probably the rest of the code could be improved too.  I'm eager to  
hear your feedback.


Thanks,
- Joe


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

book recommendation for Python newbie?

[Joe Strout]

I'm trying to (gently) convince my business partner that we should be  
adding Python to our core toolset.  He's never used it before, apart  
from poking around in the tutorial a bit at my urging.  But he's got a  
birthday coming up, and I'd like to get him a book that will help him  
make the transition more smoothly and enjoyably.


In case it matters: his background is mainly in databases (originally  
4D, more recently MySQL), and his current primary tools are REALbasic  
(which is a statically typed language with semantics similar to Java)  
and PHP.  He's primarily a Mac user, but occasionally has to dabble in  
Linux or Windows.  If we do make this change, he'll be using Python in  
a professional capacity to develop commercial apps.


There are a lot of Python books out there... which one would you  
recommend in this case?


Thanks,
- Joe


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

Where/how to propose an addition to a standard module?

[Joe Strout]

I would like to propose a new method for the string.Template class.   
What's the proper procedure for doing this?  I've joined the python- 
ideas list, but that seems to be only for proposed language changes,  
and my idea doesn't require any change to the language at all.


From , it sounds like the  
PEP process is appropriate here, though other PEPs (like  make it sound as though these are meant for proposals for "Python  
3000", which is not necessarily my intent.


Here's a brief sketch of my proposal, in case it helps:

Add a "match" function to string.Template, which takes a text string  
as a parameter.  If this text string can be matched to the template,  
by substituting some portion of the given string for each field of the  
template, then .match returns a dictionary, where each key is a field  
name and the value is the corresponding text from the input.  If the  
text string cannot be matched to the template, then .match returns None.


I understand that if I'm to write a PEP, I'll need to flesh this out  
considerably as per PEP 0001.  But that document also suggests first  
discussing it here.  I'm still a newbie (or actually, oldbie-turned- 
nonbie-turned-newbie-again), so I could use some advice.  What's the  
next step in advocating for this idea?


Thanks,
- Joe



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

Re: docpicture

[Joe Strout]

On Oct 13, 2008, at 2:43 PM, Benjamin Kaplan wrote:

I mean what happens when you type help() into the interactive  
console on the command line? You will see the docstrings, and there  
will be a whole bunch of random hex characters there.



Good point.  It might be better put in a specially-tagged comment,  
rather than in the docstring.


I still think it's a nifty idea though.

Best,
- Joe

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

recommendations for a web CMS (content management system)?

[Joe Strout]

We need to set up a content management system that allows nontechnical  
users to manage the content of their web site.  Rather than starting  
from scratch, I'd prefer to start with an existing CMS that we can  
extend as needed.  So, I'd prefer something with nice clean, easy-to- 
follow code over something that includes everything but the kitchen  
sink.


Any suggestions?

Thanks,
- Joe


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

Python equivalent to SharePoint?

[Joe Strout]

We've got a client who has been planning to use SharePoint for  
managing their organization documents, but has recently dropped that  
idea and is looking for an alternative.  Is there any Python package  
with similar functionality?


I confess that I've never used SharePoint myself, and what I know  
about is mainly from these sources:


  http://en.wikipedia.org/wiki/SharePoint
  http://discuss.joelonsoftware.com/default.asp?joel.3.66103.7

I found a reference to CPS, but its developers have dropped the Python  
source to rewrite it in Java.  That's disturbing, and I don't want to  
recommend an abandoned platform.  Anything else I should consider?


Thanks,
- Joe

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

Re: Loosely-coupled development environment (was: IDE Question)

[Joe Strout]

On Oct 15, 2008, at 2:47 PM, Ben Finney wrote:


Because of the inescapable central role in our craft of manipulating
text files, essential in this development environment is a
highly-customisable text editor with a broad *and* deep library of
existing customisations, to maximise the amount of work already done
for you when embarking on work in an area that is, to you, new.

It happens that the text editors which meet these criteria are limited
to Emacs and Vim, with a sharp decline in suitability (by these
criteria) beyond those two.


You've never used BBEdit?  (Perhaps because of the platform you use --  
that's a Mac-only text editor, but it meets your criteria nicely.  The  
free version "TextWrangler" does a pretty darn good job too, though of  
course has some limitations.)


Not that vim and emacs aren't powerful, of course, but I think it goes  
too far to say that ONLY those can do the job.


Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 16, 2008, at 10:59 AM, Larry Bates wrote:


how do i find that the name is 'bob'


Short answer is that you can't.  This because Python's names (bob)  
are bound to objects (modulename.objectname()).  They are NOT  
variables as they are in "other" programming languages.


Which other programming languages?  I've never seen an OOP language  
that didn't work the same way as Python.


However, 'bob' here really is a variable.  It's a variable whose value  
(at the moment) is a reference to some object.


It is perfectly legal in Python to bind multiple names to a single  
object:


a=b=c=modulename.objectname()


Right -- three variables (a, b, and c) that all have the same value,  
i.e. all refer to the same object.  There's nothing more mysterious  
here than


i=j=k=42

where i, j, and k all have the same value.  (The OP's question would  
be like asking "what is the name of the variable referring to 42?  And  
while you might, in theory, be able to produce a list of all such  
variables by trolling through the Python's internals, it's a bit of a  
silly thing to do.)


a, b, and c all point to the same object.  An object can have an  
unlimited number of names bound to it.  This is one of the most  
difficult concepts for many beginning Python programmers to  
understand (I know I had a difficult time at first).  It is just not  
how we taught ourselves to think about "variables" and you can write  
quite a lot of Python treating the names you bind to objects like  
they were "variables".


Well, they are variables.  I'm not quite grasping the difficulty  
here... unless perhaps you were (at first) thinking of the variables  
as holding the object values, rather than the object references.  That  
is indeed something important to grasp, since it explains why if you do


 a = b   # where b was some object with an attribute 'foo'...
 a.foo = 42

...you now find that b.foo is 42 too.  Nothing mysterious once you  
realize that the value of a and b is a reference to some object that  
has a "foo" attribute.


Not sure if all this was helpful to anyone, but I hope so!

Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 16, 2008, at 7:30 PM, Steven D'Aprano wrote:

However, 'bob' here really is a variable.  It's a variable whose  
value

(at the moment) is a reference to some object.


Traditionally, a "variable" is a named memory location.


Agreed.


The main objection I have to using "variable" to describe Python name/
value bindings is that it has connotations that will confuse  
programmers

who are familiar with C-like languages. For example:

def inc(x):
   x += 1

n = 1
inc(n)
assert n == 2

Why doesn't that work? This is completely mysterious to anyone  
expecting

C-like variables.


Hmm... I'm not following you.  That wouldn't work in C, either.  'x'  
in 'inc' is a local variable; its value is just a copy of whatever  
value you pass in.  You can increment it all you want, and it won't  
affect the original variable (if indeed it was a variable that the  
value came from; it could be a literal or an expression or who knows  
what else).



At this point people will often start confusing the issue by claiming
that "all Python variables are pointers", which is an *implementation
detail* in CPython but not in other implementations, like PyPy or  
Jython.


I'm not claiming that -- and I'm trying to clarify, rather than  
confuse the issue.  (Of course if it turns out that my understanding  
of Python is incorrect, then I'm hoping to uncover and correct that,  
too.)


Or people will imagine that Python makes a copy of the variable when  
you
call a function. That's not true, and in fact Python explicitly  
promises

never to copy a value unless you explicitly tell it to


Now that IS mysterious.  Doesn't calling a function add a frame to a  
stack?  And doesn't that necessitate copying in values for the  
variables in that stack frame (such as 'x' above)?  Of course we're  
now delving into internal implementation details... but it sure  
behaves as though this is exactly what it's doing (and is the same  
thing every other language does, AFAIK).


but it seems to explain the above, at least until the programmer  
starts *assuming* call-

by-value behaviour and discovers this:

def inc(alist):
   alist += [1]  # or alist.append(1) if you prefer
   return alist


It's still call-by-value behavior.  The value in this case is a list  
reference.  Using .append, or the += operator, modifies the list  
referred to by that list reference.  Compare that to:


 def inc(alist):
alist = alist + [1]
return alist

where you are not modifying the list passed in, but instead creating a  
new list, and storing a reference to that in local variable 'alist'.


The semantics here appear to be exactly the same as Java or REALbasic  
or any other modern language: variables are variables, and parameters  
are local variables with called by value, and it just so happens that  
some values may be references to data on the heap.



Are functions call by value or call by reference???

(Answer: neither. They are call by name.)


I have no idea what that means.  They're call by value as far as I can  
tell.  (Even if the value may happen to be a reference.)


Side question, for my own education: *does* Python have a "ByRef"  
parameter mode?


I myself often talk about variables as shorthand. But it's a bad  
habit,

because it is misleading to anyone who thinks they know how variables
behave, so when I catch myself doing it I fix it and talk about name
bindings.


Perhaps you have a funny idea of what people think about how variables  
behave.  I suspect that making up new terminology for perfectly  
ordinary things (like Python variables) makes them more mysterious,  
not less.



Of course, you're entitled to define "variable" any way you like, and
then insist that Python variables don't behave like variables in other
languages. Personally, I don't think that's helpful to anyone.


No, but if we define them in the standard way, and point out that  
Python variables behave exactly like variables in other languages,  
then that IS helpful.


Well, they are variables.  I'm not quite grasping the difficulty  
here...
unless perhaps you were (at first) thinking of the variables as  
holding

the object values, rather than the object references.


But that surely is what almost everyone will think, almost all the  
time.

Consider:

x = 5
y = x + 3

I'm pretty sure that nearly everyone will read it as "assign 5 to x,  
then

add 3 to x and assign the result to y" instead of:

"assign a reference to the object 5 to x, then dereference x to get  
the

object 5, add it to the object 3 giving the object 8, and assign a
reference to that result to y".


True.  I have no reason to believe that, in the case of a number, the  
value isn't the number itself.  (Except for occasional claims that  
"everything in Python is an object," but if that's literally true,  
what are the observable implications?)



Of course that's what's really happening under the hood, and you can't
*properly* understand how Python behaves without understanding

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 16, 2008, at 11:23 PM, Dennis Lee Bieber wrote:


On Thu, 16 Oct 2008 21:19:28 -0600, Joe Strout <[EMAIL PROTECTED]>
declaimed the following in comp.lang.python:


Now that IS mysterious.  Doesn't calling a function add a frame to a
stack?  And doesn't that necessitate copying in values for the
variables in that stack frame (such as 'x' above)?  Of course we're


No -- it copies the /reference/ to the object containing the value.


The reference to the object IS the value of an object reference  
variable.  So good, parameters are passed ByVal in Python as they  
appear to be, and as is the default in every other modern language.


Just as assignment transfers the reference to the RHS object to the  
name

shown on the LHS.


Assignment copies the RHS value to the LHS variable.  In the case of  
an object reference, the value copied is, er, an object reference.



The semantics here appear to be exactly the same as Java or REALbasic
or any other modern language: variables are variables, and parameters
are local variables with called by value, and it just so happens that
some values may be references to data on the heap.


ALL "values" are references to data in Python -- but some of those
values are immutable objects so any operation performed on them  
creates

new objects, and the assignment is of a new reference.


OK, that part is a little different from most languages -- not in the  
way objects are treated, but in the fact that even simple values like  
integers are wrapped in objects.  But since those are immutable  
objects, this is mostly an internal implementation detail.


For object references (including the mutable ones that may treat  
people up), Python's behavior is no different from any other language.



(Answer: neither. They are call by name.)


I have no idea what that means.  They're call by value as far as I  
can

tell.  (Even if the value may happen to be a reference.)


Technically, as I recall the definition of "call by name", they
aren't that either. ...
Call by name, then, acted as a macro expansion wherever the argument
was referenced in the called function.


Thanks for that explanation.  Clearly that's not what's going on in  
Python.



Side question, for my own education: *does* Python have a "ByRef"
parameter mode?


As far as I'm concerned -- everything is "by ref" in Python...


No, a "by ref" parameter would mean that this:

def foo(ByRef x):
 x = x + [42]

a = [1,2,3]
foo(a)

...would result in a = [1,2,3,42].  You would only be able to pass a  
simple variable (not an expression or literal) to foo, and the 'x'  
inside foo would not be a local variable, but an alias of whatever  
variable was passed in.  Thus any assignments to it would affect the  
original variable that was passed in.


But if Python has any such feature, I'm not aware of it.  Certainly  
the default behavior is to pass everything (even object references) by  
value.  Assignments made to them don't affect anything else.



Mutation of an object is never a bare LHS... It is either a method
call of the name

alist.append()

or a drill-down going inside the object

alist[2] = something
anobject.attribute = something
adict["key"] = something


Or, use of one of the compound operators like +=.  That's the only  
real "gotcha" in Python to somebody coming from another language; you  
might naively expect that x += y is the same as x = x+y, but in Python  
this is not generally the case; instead += is a mutation operator,  
like the examples you show above.



But every language I've used (many: FORTRAN, C, C++, BASIC, VB,
Assembly, COBOL, Ada...) treats "variable" as "name of fixed  
location in

memory" and assignment to the variable means "replace the contents of
the location of memory associated with this name with the contents of
memory to which that name (may be anonymous in the case of an
expression) is associated by copying the contents from there to here"


That's what Python does too.  It just so happens that the fixed  
location in memory contains an object reference.  No difference here  
between Python's object references VB.NET's object references, C++  
pointers, Java object references, etc. etc.



Python, OTOH, ALWAYS handles assignment as "change the memory
association of this name to be the same as that name".


What does that mean, exactly?  It means: "replace the contents (i.e.  
object reference) of the memory location associated with this name  
with the contents (i.e. object reference)  of the memory to which that  
name is associated by copying the contents from there to here."


It's the exact same thing.  (And exactly the same as in any other  
language.)

Re: 'Hidden Features of Python'

[Joe Strout]

On Oct 17, 2008, at 10:00 AM, coldpizza wrote:


http://stackoverflow.com/questions/101268/hidden-features-of-python


Thanks, there are a lot of useful nuggets there.  However, can anybody  
explain the "Main messages" one?  It doesn't include any explanatory  
text at all, just a code snippet:


import this
# btw look at this module's source :)

I don't see what I'm supposed to get from that.  If I'm supposed to  
see the magic (and explanation) be examining the source for the 'this'  
module, well, I don't see how I can do that either.  Can someone who  
gets this share a clue?


Thanks,
- Joe

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

Re: 'Hidden Features of Python'

[Joe Strout]

On Oct 17, 2008, at 10:35 AM, coldpizza wrote:


If you are using and IDE, such as Eclipse, PyScripter, etc, then CTR
+click on 'this' should do the trick.
In ipython you can do 'import this' and then type 'this??' Or if you
are *not* lazy, you could try locating the file in the Python tree.


Oh!  They're actually talking about a module literally called 'this'!   
I thought that was just a placeholder, like "foo".


Interesting (and useful).

As for examining the source though, it seems like it could be  
shortened up quite a bit now -- in fact all the source except the  
assignment to s could be replaced with the one-liner


  print s.encode('rot13')

Though the existing source is interesting in its own way too.

Thanks,
- Joe


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

Re: inserting Unicode character in dictionary - Python

[Joe Strout]

On Oct 17, 2008, at 11:24 AM, Marc 'BlackJack' Rintsch wrote:


kw = 'генских'


What do you mean by "does not work"?  And you are aware that the above
snipped doesn't involve any unicode characters!?  You have a byte  
string

there -- type `str` not `unicode`.


Just checking my understanding here -- are the following all true:

1. If you had prefixed that literal with a "u", then you'd have Unicode.

2. Exactly what Unicode you get would be dependent on Python properly  
interpreting the bytes in the source file -- which you can make it do  
by adding something like "-*- coding: utf-8 -*-" in a comment at the  
top of the file.


3. Without the "u" prefix, you'll have some 8-bit string, whose  
interpretation is... er... here's where I get a bit fuzzy.  What if  
your source file is set to utf-8?  Do you then have a proper UTF-8  
string, but the problem is that none of the standard Python library  
methods know how to properly interpret UTF-8?


4. In Python 3.0, this silliness goes away, because all strings are  
Unicode by default.


Thanks for any answers/corrections,
- Joe






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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 17, 2008, at 1:03 PM, Aaron Castironpi Brady wrote:


I'm not fluent in Java so you'll have to be the judge.

In Python:

b= 0
f( b )

No matter what, b == 0.  C doesn't guarantee this.


It does, unless f's parameter has been declared a reference  
parameter.  (In C++, you'd do this with '&'; I didn't think it was  
possible in C, but it's been a long time since I've used C so maybe it  
is possible nowadays.)



 Does Java?


Same in Java, and in RB, and in .NET too.  If f's parameter is a by- 
value parameter, then it acts exactly like Python.  (Those languages  
also allow a by-reference parameter declaration, which I think Python  
doesn't allow, but by-value is the default.)



Further:

b= {}
c= b
f( b )

No matter what, 'c is b' is true.


Right, again, this just demonstrates that Python passes values by  
reference.



 C doesn't have an 'is' operator.


Well, that's literally true, but only because it doesn't have a deep  
equality operator like modern languages.  In C, b and c would be  
pointers, and 'c == b' would be the equivalent of Python's 'c is  
b' (and would be true after the call to f, again assuming you didn't  
go out of your way to declare f with a by-reference parameter).



Does Java?


Yes.  The behavior's the same.  Same also in every other OOP language,  
as far as I know.


I think all we've established here is that Python always passes  
parameters by value, and in most other languages, passing by value is  
the default (but there's an option to pass by reference if you want).


Python lacks the ByRef-parameter feature, so when that's what you need  
to do, you'd have to wrap your value in some mutable type (like a  
list) and pass that instead.  A little awkward, but no big deal, as  
there are darn few valid reasons to ever pass something by reference  
anyway, especially in a language with tuple packing and unpacking.


Best,
- Joe


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

Re: inserting Unicode character in dictionary - Python

[Joe Strout]

Thanks for the answers.  That clears things up quite a bit.


What if your source file is set to utf-8?  Do you then have a proper
UTF-8 string, but the problem is that none of the standard Python
library methods know how to properly interpret UTF-8?


Well, the decode method knows how to decode that bytes into a  
`unicode`

object if you call it with 'utf-8' as argument.


OK, good to know.


4. In Python 3.0, this silliness goes away, because all strings are
Unicode by default.


Yes and no.  The problem just shifts because at some point you get  
into
similar troubles, just in the other direction.  Data enters the  
program

as bytes and must leave it as bytes again, so you have to deal with
encodings at those points.


Yes, but that's still much better than having to litter your code with  
'u' prefixes and .decode calls and so on.  If I'm using a UTF-8-savvy  
text editor (as we all should be doing in the 21st century!), and type  
"foo = '2π'", I should get a string containing a '2' and a pi  
character, and all the text operations (like counting characters,  
etc.) should Just Work.


When I read and write files or sockets or whatever, of course I'll  
have to think about what encoding the text should be... but internal  
to my own source code, I shouldn't have to.


I understand the need for a transition strategy, which is what we have  
in 2.x, and that's working well enough.  But I'll be glad when it's  
over.  :)


Cheers,
- Joe


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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 17, 2008, at 2:36 PM, Steve Holden wrote:


No, a "by ref" parameter would mean that this:

def foo(ByRef x):
x = x + [42]

a = [1,2,3]
foo(a)

...would result in a = [1,2,3,42].


In [8]: def foo(x):
  ...: x += [42]
  ...:

In [9]: a = [1, 2, 3]

In [10]: foo(a)

In [11]: a
Out[11]: [1, 2, 3, 42]


This demonstrates that lists are mutable, and that += is a mutating  
operator (and NOT an assignment).



In [12]: def ffoo(x):
  : x.append(43)
  :

In [13]: ffoo(a)

In [14]: a
Out[14]: [1, 2, 3, 42, 43]


Ditto (but for the .append method).


In [15]: def fffoo(a):
  : a = a + [42]
  :

In [16]: fffoo(a)

In [17]: a
Out[17]: [1, 2, 3, 42, 43]


And here, you're doing an assignment -- this is the only test of the  
three that tests whether the parameter is passed by reference or by  
value.  The result: it's by value.



So, is it call by reference or not?


Not.


Does that depend on the implementation of specific operators?


No.


You problem seems to be that you ar still stuck with the notion of a
name as a reference to a specific area of memory. Which it's not,
excepting only if you want to consider the area of memory that holds a
reference to some value.


Which is exactly what it is, so that's what you should consider.

And my real point is that this is exactly the same as in every other  
modern language.  Nothing unusual here at all (except that some of us  
here seem to want to make up new terminology for standard behavior,  
perhaps in order to make Python seem more exotic).



In the case of lists,

a = a + [something]

rebinds a


In standard terminology, it assigns a new value to a.


while

a += [something]

doesn't.


Correct.


So where does that leave you?


In exactly the same happy boat as Java, RB, .NET, etc. (even C++ if  
you consider an object pointer to be the equivalent of an object  
reference).


Or, use of one of the compound operators like +=.  That's the only  
real
"gotcha" in Python to somebody coming from another language; you  
might
naively expect that x += y is the same as x = x+y, but in Python  
this is

not generally the case; instead += is a mutation operator, like the
examples you show above.


Be careful though:

In [18]: a = 42

In [19]: id(a)
Out[19]: 14237932

In [20]: a += 1

In [21]: id(a)
Out[21]: 14237920


Good point -- obviously += can't mutate an immutable type.  In those  
cases it IS equivalent to an assignment.  I can certainly see why  
these operators can trip people up at first.



It's the exact same thing.  (And exactly the same as in any other
language.)

If you mean it's a reference assigment, of course it is. That's what  
he

was trying to say (I believe). But in C, for example,

 int i;
 i = 42;

actually stores the value 42 in the location associated with the  
name c.


Yes, but let's get away from numbers, since those are a bit of a  
special case, and not where the argument is revolving.  (Since  
Python's number-wrappers are immutable, they are behaviorally  
equivalent to raw values, and so it really doesn't matter whether you  
know that they're actually objects or not).


The discussion at hand is how best to explain and understand mutable  
types.  I don't remember C too well, but in C++ that'd be something  
like:


  Foo *x;
  x = FooFactory();

This stores the address of the object FooFactory builds into x.  It's  
equivalent to what Python does with


  x = FooFactory()

...except, of course, that Python's syntax is cleaner, and you don't  
have all the rope that C/C++ gives you with which to shoot yourself in  
the foot.


Hey, I remember Pascal... that was the language used on the Apple  
IIGS,

back when I was in junior high.  I also remember spending $800 for a
40MB hard drive for it.  Ah, those were the days!


40 Mb! You were lucky! Etc., etc., [drools into beard.]


:)


Python's assignment semantics (as opposed to its "object handling, a
term for which I have no referent) are not the same as those of, say  
C.


They are, though.  The only difference you've pointed out is that  
*numbers* are different in Python vs. C, and that's an internal  
implementation detail I was blissfully unaware of until this  
discussion.  (I'm grateful to know it, but it really doesn't matter in  
day-to-day coding.)



I believe they are pretty much the same ass those of Icon, another
non-standard interpreted language.


They're also the same as RB, Java, .NET... I'm hoping somebody who  
knows some other modern OOP language (e.g. Ruby) will weigh in,  
because I bet it's the same as those too.


Comparing it to C isn't really fair, because C isn't even an OOP  
language.  C++ would at least be in the same ballpark.



There are close similarities between Python's names and C reference
variables, but the semantics are not exactly parallel.


I agree; reference variables are an odd beast, most commonly used (and  
most similar to) a ByRef parameter in modern languages.  And it seems  
that Python simply do

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote:


And my real point is that this is exactly the same as in every
other modern language.


No, it isn't.  In many other languages (C, Pascal, etc.), a
"variable" is commonly thought of as a fixed location in memory
into which one can put values.  Those values may be references
to objects.


Right, though not in languages like C and Pascal that don't HAVE the  
notion of objects.  We really ought to stop bringing up those  
dinosaurs and instead compare Python to any modern OOP language.



 In Python, that's not how it works.  There is no
"location in memory" that corresponds to a variable with a
particular name the way there is in C or Pascal or Fortran or
many other languages.


No?  Is there any way to prove that, without delving into the Python  
source itself?


If not, then I think you're talking about an internal implementation  
detail.



All that exists in Python is a name->object mapping.


And what does that name->object mapping consist of?  At some level,  
there has to be a memory location that stores the reference to the  
object, right?



Nothing unusual here at all (except that some of us here seem
to want to make up new terminology for standard behavior,
perhaps in order to make Python seem more exotic).


That's because it is fundamentally different from what happens
in languages like C.


What happens in a modern OOP language is just as fundamentally  
different (which is to say, not really very much) from what happens in  
C or FORTRAN or COBOL, too.


But if there's any demonstrable difference between Python and any  
other modern OOP language, I'd love to hear about it.



a = a + [something]

rebinds a


In standard terminology, it assigns a new value to a.


The problem is that listeners from a C or FORTRAN background
will infer that there is a fixed region of memory named "a" and
"assigning a value to a" means writing that new value into the
region of memory named "a".


And they'd be correct.  The value being written, in this case, as a  
reference to some data that lives somewhere on the heap.  Point that  
out, and now their understanding is correct.


But if you instead say something like "all parameters are passed by  
reference in Python," then the user gets the wrong idea.  That  
statement has a specific meaning which is, quite demonstrably, not true.


If you make up new terms like "rebinds," well, I guess at least that  
avoids giving the listener the wrong idea.  Instead it gives them no  
idea at all, which may be better, but not as good as giving them the  
right idea.  It still leaves them to investigate what actually  
happens, and ultimately they will find that the parameters are always  
passed by value in Python.  May as well save them the trouble and  
point that out up front.


And how many recovering FORTRAN or C programmers do we get around  
here, anyway?  Java is what they've been teaching in school for the  
last several years, and it was C++ for a good decade before that.  The  
semantics of Python (insofar as objects, assignments, and parameters  
are concerned) are exactly the same as Java, and Java is just a  
cleaned-up and streamlined C++.  Even old-timers (like me) who learned  
FORTRAN and COBOL way back in the day have long since moved on.


Best,
- Joe

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

Re: inserting Unicode character in dictionary - Python

[Joe Strout]

On Oct 18, 2008, at 1:20 AM, Martin v. Löwis wrote:


Do you then have a proper UTF-8 string,
but the problem is that none of the standard Python library methods  
know

how to properly interpret UTF-8?


There is (probably) no such thing as a "proper UTF-8 string" (in the
sense in which you probably mean it).


To be clear, I mean a string that is valid UTF-8 (not all strings of  
bytes are, of course).



Python doesn't have a data type
for "UTF-8 string". It only has a data type "byte string". It's up to
the application whether it gets interpreted in a consistent manner.
Libraries are (typically) encoding-agnostic, i.e. they work for UTF-8
encoded strings the same way as for, say, Big-5 encoded strings.


Oi -- so if I ask for length, I get the number of bytes, not the  
number of characters.  If I slice and dice, I could end up splitting  
characters in half.  It is, as you say, just a string of bytes, not a  
string of characters.



4. In Python 3.0, this silliness goes away, because all strings are
Unicode by default.


You still need to make sure that the editor's encoding and the  
declared

encoding match.


Well, the if no encoding is declared, it (quite sensibly) assumes  
UTF-8, so for my purposes this boils down to using a UTF-8 editor --  
which I always do anyway.  But do I still have to put a "u" before my  
string literals in order to have it treated as characters rather than  
bytes?


I'm hoping that the answer is "no" -- most string literals in a source  
file are text (which should be Unicode text, these days); a raw byte  
string would be the exceptional case, and I'd be happy to use the "r"  
prefix for those.


Best,
- Joe

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

Re: Unicode (UTF8) in dbhas on 2.5

[Joe Strout]

On Oct 21, 2008, at 2:39 PM, Martin v. Löwis wrote:

It's not possible to "fix" this - it isn't even broken. The *db  
modules,
by design, support storing of arbitrary bytes, not just character  
data.


Many database engines are encoding-aware, and distinguish between  
'text' columns and 'blob' columns -- the latter are arbitrary bags of  
bytes, but text columns store text, and a good database (with a  
sensibly designed database) will be aware of this and handle encoding  
and decoding of text responsibly.


I can tell you that in REALbasic, if your database is properly  
configured to use UTF-8 encoding, the rest is all handled seamlessly  
-- you just store and retrieve text, and don't have to worry about  
encoding and decoding things all over the place.


So the OP's request is quite valid.  Python's handling of encodings is  
currently primitive compared to some other environments, and I see  
that this extends to the database modules.  Fine, fair enough, it is  
what it is, but there is no harm in asking about (or even yearning  
for) a more intelligent system that does more of the grunt work for us.


Best,
- Joe

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

Re: What's the perfect (OS independent) way of storing filepaths ?

[Joe Strout]

On Oct 22, 2008, at 10:00 PM, Steven D'Aprano wrote:


It would have been easy to avoid this: just copy the relevant bits of
the / directory hierarchy in the user's home directory. Global  
settings
go in /etc and per user settings go in ~/etc. Global temp files go  
into /
tmp and per user temp files go into ~/tmp. And so forth. Nice, neat  
and

perfectly easy to implement and easy to deal with.


I agree with you wholeheartedly on this one.

FYI, I think what you're looking for is a Mac.  It's a Unix system,  
and has /etc, but that's pretty much only there for compatibility with  
other Unices -- well-behaved Mac apps put global settings (and so on)  
in the appropriate subfolder under /Library, with per user data in the  
appropriate subfolder under ~/Library.


Cheers,
- Joe





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

Re: ANN: gui_support, a convenience library for wxPython

[Joe Strout]

On Oct 23, 2008, at 11:50 AM, Stef Mientki wrote:


gui_support is library for easy creation of GUI designs in wxPython.
 ...
Brief documentation can be found here
http://oase.uci.kun.nl/~mientki/data_www/pylab_works/pw_gui_support.html


That's neat -- thank you for making it available.  I've just recently  
been working through some wxPython tutorials, and wondered if there  
was a simple text-based layout definition format that would let me  
define my interfaces in a simpler manner.


Your page says that the layout is defined in a docstring, but in the  
sample code, it's actually just in a regular string literal.  That's  
nice -- it means that we could read the layout from a file, for  
example, or even make a dynamic editor where we edit the layout string  
in one window, and view the result in real time in another window.


Is this layout format -- where indentation shows containment, and with  
the name/type/attributes  for each item on a line -- any sort of  
standard, or just something you guys made up?


Thanks very much,
- Joe




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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 27, 2008, at 12:19 PM, [EMAIL PROTECTED] wrote:


I think this "uncontrived" example addresses the C/Python difference
fairly directly (both were tested):


That's correct, but of course, C is a decades-old language barely a  
step above assembler.  For a fair comparison, pick any modern OOP  
language, including the C derivatives (C++, Objective-C, Java), and  
compare a Python object to an object in that language, rather than to  
a struct.



In Python, variables are just names/aliases for *references* to
objects, not names for the objects/values themselves. The variable
names themselves do not correspond directly to the objects' memory
locations.


Exactly!  In C++, this would be like a pointer variable.  In Java, RB,  
or .NET, it's like an object reference.



While yes, technically, it is true that those reference
values must be stored somewhere in memory, *that* is the
implementation detail.


Agreed.  (And this was my point in response to someone arguing that no  
such location exists.)



But is is not the *locations* of these
references (i.e., the locations of the Python *variables*) that are
copied around, it is the references themselves (the locations of the
Python *objects*) that are copied.


Right.  The variables contain object references; these object  
references are copied (not referenced!) when you pass them into a  
function.  That's call by value.  In the case of an assignment, the  
reference is copied.



All that exists in Python is a name->object mapping.


And what does that name->object mapping consist of?  At some level,
there has to be a memory location that stores the reference to the
object, right?


I think this is answered above, but just to drive it home, in Python
the memory locations of the variables themselves (an implementation
detail), which hold the references to the objects, are inaccessible .


Right.  So too in Java, RB, .NET, etc.  Pointers are nasty.  But lack  
of pointers does not change the calling semantics.



In C/C++, by contrast, variable names correspond directly to memory
locations and objects, and you can easily find the addresses of
variables.


Hmm, no, the C++ equivalent of an object reference would be:

 SomeClass* foo;

In fact, many C++ programmers prefer to typedef a pointer to each  
class, since it's the pointer (which is rough equivalent of a  
reference in newer languages) that you almost always want, rather than  
the class itself.  So it would actually be:


 SomeClassPtr foo;

Now, when you do:

 foo2 = foo;

you are copying the object reference from foo to foo2, just as in  
Python.  When you pass it into a function:


 void NiftyMethod(SomeClassPtr arg) {...}
 ...
 NiftyMethod(foo);

You are copying the object reference right onto the call stack.  This  
is pass by value, plain and simple.  And because it is pass by value,  
you know that nothing NiftyMethod does can possibly change the value  
of foo -- that is, can make it point at something else.  (It may well  
change the data that the object it points to contains, if SomeClass  
objects are mutable, but it can't change foo itself.)  This is, again,  
just like Python and every other OOP language.


Call by reference would be this:

 void NiftyMethod2(SomeClassPtr &arg) {...}
 ...
 NiftyMethod2(foo);

Now, arg here is passed by reference (just like a ByRef parameter in  
RB or .NET).  That means that NiftyMethod2 could very well change the  
value that is passed in.  It could actually make foo point to  
something else.


No Python method can do that, because Python arguments are ALWAYS  
passed by value.  There is no call by reference in Python.  Period,  
end of story, nothing to see here.


Cheers,
- Joe
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to get an object's name as a string?

[Joe Strout]

On Oct 28, 2008, at 8:41 AM, Shannon Mayne wrote:


I would like to create objects with algorithmically determined names
based on other object names and use object names for general algorithm
input.


What do you mean by the "name" of an object?  Objects don't generally  
have names, unless you explicitly define a .name property and assign  
them names.


(Variables have names, of course, but a variable isn't an object --  
it's just a reference to an object.  Many variables may refer to the  
same object, so it doesn't make any sense to ask for the name of THE  
variable which may be referring to an object at the moment.)



How would one extract the name of an object from an object instance as
a string.  I would think that it is stored as an attribute of the
object but successive 'dir()' calles haven't found me the attribute
with the namestring.


As noted above, there is no built-in name attribute.  Define one,  
perhaps like this:


class Foo():
 def __init__(name):
   self.name = name

Now your Foo objects have a name attribute, and if "x" is a reference  
to such an object, you would access that as "x.name".


It's still unclear what you intend to do with these, but if at some  
point you want to access objects by their names (from user input or  
whatever), then you'll also need a dictionary to map names to  
objects.  So to your __init__ function, you might add something like  
this:


   name_map[name] = self

where name_map was initialized to {} at the top of the file.  Then you  
can use name_map to look up any object of this class by name.   
Remember that this will keep these objects from automatically  
disappearing when there are no other references (other than the map)  
to them.  If that's a problem, explicitly remove them from the map  
when you know you're done with them, or use weak references.


Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 27, 2008, at 11:28 PM, Gabriel Genellina wrote:

En Tue, 28 Oct 2008 00:58:10 -0200, greg  
<[EMAIL PROTECTED]> escribió:



Let's look at the definitions of the terms:

(1) Call by value: The actual parameter is an expression. It is
   evaluated and the result is assigned to the formal parameter.
   Subsequent assignments to the formal parameter do not affect
   the actual parameter.

(2) Call by reference: The actual parameter is an lvalue. The
   formal parameter becomes an alias for the actual parameter,
   so that assigning to the formal parameter has the same
   effect as assigning to the actual parameter.

Seems to me that (1) describes exactly how parameter passing
works in Python. So why insist that it's *not* call by value?


Greg is right on the money here.  It really is as simple as that.

Those definitions are only applicable to unstructured, primitive  
types, where the only relevant operations are "get value" and  
"assign value".


Nonsense.  They apply to any type.  See here for an introduction to  
the topic in VB.NET:


  http://www.homeandlearn.co.uk/net/nets9p4.html

The example shown uses an Integer, but guess what -- you can pass ANY  
type either ByRef or ByVal, including object references (which are, of  
course, quite common in VB.NET).  The default is ByVal, which means  
that (as in Python) the actual parameter is an expression, and no  
assignments to it can affect the actual parameter.  It DOES NOT MATTER  
that both the formal parameter and the actual parameter may refer to  
the same object, and if that object is mutable, you can mutate that  
object.


But ByRef is another option, and if you pass an object reference  
ByRef, then the formal parameter is an alias for the actual parameter,  
and assignments to it change the actual parameter.  Python doesn't  
have this feature (nor much need for it, given its other features,  
like tuple packing/unpacking).  So, parameter passing in ByRef is  
clearly exactly the same as the default "ByVal" parameter passing in  
VB.NET... as well as Java, RB, C++ (when you remember that an object  
reference in modern languages is like a pointer in C++), and every  
other OOP language I've looked into.


Some of those languages, like Python, don't have different modes, and  
so the language designers had no call to give their one mode a name.   
So let's look at those that did have such a need, like VB.NET and  
REALbasic.  What's the default mode called?  Why, it's "ByVal".  Even  
when that value is an object reference.  This is short for "by value"  
-- it's not short for "by sharing" or "by object" or any other such  
silliness.  No such terms are needed.


There are only the two cases, which Greg quite succinctly and  
accurately described above.  One is by value, the other is by  
reference.  Python quite clearly uses by value.  Parameters are  
expressions that are evaluated, and the resulting value copied into  
the formal parameter, pure and simple.  The continued attempts to  
obfuscate this is pointless and wrong.


Best,
- Joe


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

explanation of values, references, assignment, and method calls

[Joe Strout]

I've tried to write up this topic in a clear, step-by-step manner,  
with the help of diagrams and short examples from several different  
OOP languages.  I hope it will help clear up the confusion that seems  
to be pervading the Python community (and which is far more rare in  
the other language communities, despite them having the very same  
semantics).


   

It's still a bit rough around the edges, and probably contains some  
typos, as I finished it late last night and haven't even had a chance  
to proof-read it yet.  But I may not get another chance to work on it  
for a few days, so I wanted to get it out there now.  I welcome your  
feedback.


Best,
- Joe


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

Re: How to get an object's name as a string?

[Joe Strout]

On Oct 28, 2008, at 4:45 PM, Steven D'Aprano wrote:


What do you mean by the "name" of an object?  Objects don't generally
have names, unless you explicitly define a .name property and assign
them names.

(Variables have names, of course, but a variable isn't an object --  
it's

just a reference to an object.  Many variables may refer to the same
object, so it doesn't make any sense to ask for the name of THE  
variable

which may be referring to an object at the moment.)


That explanation makes no sense. Given the assignment:

x = 57

if the name of x isn't 'x', then what on earth can it possibly mean to
ask for the name of a variable?


Perhaps you're skimming rather than reading carefully?  Variables do  
have names, as I pointed out, and the name of x is indeed 'x'.  But  
that's not what the OP was asking for -- in your example, he'd be  
asking for the name of 57 (expecting it to be 'x').  Numbers don't  
have names; objects don't have names; variables have names, and may  
refer to numbers or objects.



In languages like Python, the term "variable" is misleading and
confusing.


Oh good grief.  Now you're going to try to discard the standard term  
"variable" as well?


All right then, if you really insist on making Python more mysterious  
by making up new terms for perfectly ordinary and standard programming  
concepts, then I suggest the following:


variable: "ariablevay"
value: "aluvay"
reference: "eferencevay"
call-by-value: "allcay-ibay-aluvay"
call-by-reference: (no term needed, since Python doesn't have it)

There.  Now we've got a simple mapping from standard terminology to  
properly mystical Python-culture terms that are nonetheless easy to  
learn.  Agreed?


Best,
- Joe

P.S. Shannon: don't listen to Steven.  He's out to confuse you and  
make Python seem much harder and complex than it really is.


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

Re: How to get an object's name as a string?

[Joe Strout]

On Oct 28, 2008, at 6:58 PM, Steve Holden wrote:


Objects in Python *don't* have names. Period. In Python we don't
normally talk about variables anyway, except when speaking loosely, we
talk about binding names. But please don't let this start another  
round

of "Python programmers don't know how to describe the language". You
have already made your opinions on that score more than clear.


As have I, I suppose, and I'll try to quit engaging in that argument  
in the future.



l = []
l.append(l)
del l

What's the name of the list formerly known as "l"?


Hey, that's a very nice little demonstration of an orphaned object.   
Thanks for sharing it!


Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:


You're pretty straightforwardly wrong. In Python the 'value' of a
variable is not the reference itself.


That's the misconception that is leading some folks around here into  
tangled nots of twisty mislogic, ultimately causing them to make up  
new terms for what every other modern language is perfectly happy  
calling Call-By-Value.


I've thought a lot about why this misconception is so widespread here,  
and I think it must be one of the following:


1. There was one community leader with this idea, who has been  
successful at promoting it widely, much to the detriment of all; or,


2. Because everything in Python is an object, you're not forced to  
think clearly (and more generally) about references as values as you  
are in languages (such as Java, VB.NET, etc.) which have both simple  
types and object types.


Either way, it's wrong (or at least, a needlessly complicated way of  
looking at things).



.NET does draw a distinction between 'value types' and reference types
- where using reference types are called by reference (the reference
is passed) and value types are called by value (the value itself is
copied).


Quite right.  Now, note that "ByRef" and "ByVal" apply to both.   
Generalize to Python.  There you go.


Best,
- Joe

P.S. I really am trying to quit responding to this thread.  Sometimes  
the urge is too strong.  But I'll keep trying!


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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 30, 2008, at 7:56 AM, Dale Roberts wrote:


That's the misconception that is leading some folks around here into
tangled nots of twisty mislogic, ultimately causing them to make up
new terms for what every other modern language is perfectly happy
calling Call-By-Value.


Doesn't this logic also apply to Call By Reference? Isn't that term
redundant too? (see my 3 C++ examples above). If not, why not?


It's not.  Wikipedia explains the difference pretty well.

Are you saying that C++ is capable of using the Call By Reference  
idiom,
but C is not, because C does not have a reference designation for  
formal

function parameters?


It's been a LONG time since I did anything in C, but yes, I believe  
that reference parameters were an addition that came with C++.



"Call By Object Reference" is an idiom, just like Call By Reference.
It is not a physical description of what is going on internally at the
register/stack level (which is always just shuffling values around -
or flipping bits, as Steven points out), it is a higher level concept
that helps people understand the *intention* (not necessarily the
implementation) of the mechanism.


Right.  And you can easily tell the difference, by whether an  
assignment to the formal parameter causes any change to the actual  
parameter that was passed in.  If it does, that's call-by-reference.   
If it doesn't, it's call-by-value.  In Python, it doesn't.  In VB.NET  
(and relatives), it doesn't if the parameter is declared (explicitly  
or implicitly) "ByVal", and does if it's declared "ByRef".  (Whether  
the parameter is a reference type or a simple value type makes no  
difference.)


Python's behavior is exactly and always equivalent to the "ByVal"  
behavior of languages that have both behaviors.  It also matches the  
definition of call-by-value.  I quite agree that it's not helpful to  
delve into the physical flipping of transistor states.  We're talking  
about the behavior, and the behavior, very clearly, is call-by-value.   
To call it something else only clouds the issue and results in  
confusion.  (Perhaps explaining why there appears to be far more  
confusion about call semantics in the Python community than in the  
community of other languages where the default semantics are exactly  
the same.)


Best,
- Joe


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

Re: Single string vs list of strings

[Joe Strout]

On Oct 30, 2008, at 8:55 AM, Grant Edwards wrote:


The question you might want to asked is whether the parameter
is a single string or a sequence of strings.  That way your
code will also work with an iterator that returns strings.


type('asdf') is str

True


I agree with the general approach, but this test will fail for Unicode  
strings, and so is probably bad mojo moving forward.  Instead I suggest:


   isinstance(x, basestring)

which will work whether x='asdf' or x=u'asdf'.

Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 30, 2008, at 6:38 PM, greg wrote:


The distinction isn't about parameter passing, though, it's
about the semantics of *assignment*. Once you understand
how assigment works in Python, all you need to know then
is that parameters are passed by assigning the actual
parameter to the formal parameter. All else follows from
that.

This holds for *all* languages that I know about, both
static and dynamic.


Just to be complete, it only holds in "ByVal" mode (for languages that  
have both ByVal and ByRef modes, like VB.NET).  A call-by-value  
parameter pass is equivalent to an assignment to the formal parameter,  
as you say.  A call-by-reference parameter is not.


This is yet another simple way to see what type of parameter passing  
Python uses.



Once you know how assignment works in
the language concerned, then you know how parameter
passing works as well. There is no need for new terms.


Agreed.

Best,
- Joe


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

Re: Finding the instance reference of an object

[Joe Strout]

On Oct 30, 2008, at 6:58 PM, greg wrote:


For what it's worth, I happen to agree that telling
someone that Python passes parameters "by value" without
being sure they understand exactly what "by value"
means, is not a good idea -- not because the term
isn't well-defined, but because of the widespread
confusion out there about it.

But equally I wouldn't tell someone that it's *not*
by value, because if they do happen to correctly
understand what it means, that will confuse them just
as much.

So my recommendation is just to tell them that it
works by assigning the result of evaluating the actual
parameter to the formal parameter.

If they understand how assignment works in Python, that
tells them all they need to know.

If they don't understand how assignment works, then they
have a more fundamental knowledge gap that needs to be
corrected first.


That's a very sensible stance.  +1!

Best,
- Joe






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

Testing dictionary results with doctest

[Joe Strout]

I love doctest -- the way it combines documentation with verification  
seems elegant and useful, and most of the time it's simple and easy to  
use.


But I've run into a bit of a snag trying to test a method that returns  
a dictionary, because (of course) the order in which the dictionary  
pairs are printed may not match what I wrote as the expected result.   
For example, my doctest string is:


"""
	>>> t = Template("The $object in $location falls mainly on the  
$subloc.")

>>> t.match( "The rain in Spain falls mainly on the train." )
{'object': 'rain', 'location': 'Spain', 'subloc': 'train'}
"""

But when I run it, I get:


Failed example:
t.match( "The rain in Spain falls mainly on the train." )
Expected:
{'object': 'rain', 'location': 'Spain', 'subloc': 'train'}
Got:
{'subloc': 'train', 'object': 'rain', 'location': 'Spain'}


Now, you and I can see that the obtained results really do match the  
expected results, considered as a dictionary rather than as a string.   
But doctest doesn't see it that way.


What's the standard solution for this?  Should I iterate over the  
sorted keys and print those out instead?  Is there some built-in  
method somewhere that will print a dictionary in a reliable order?   
Does doctest have some special way to tell it to consider the result  
as a dictionary rather than a string?  Or something else?


Thanks,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Nov 3, 2008, at 12:00 PM, Aaron Brady wrote:


I think we can conclude that Python passes by reference, since a
function can modify objects that were passed in to it.


Then please write the Python equivalent of the "Swap" methods shown at  
 (or at , for that matter).


And no fair wrapping the two parameters up in an object or using tuple  
packing/unpacking -- the point is to demonstrate that you can change  
the two parameters themselves, not some object that contains them or  
return them a different order.


And by the way, if mutating an object a parameter refers to qualifies  
as pass by reference, then Java, VB.NET/REALbasic (in ByVal mode), and  
C/C++ all pass by reference too.  That'll be quite a surprise to their  
compiler authors!  (I should know, as I'm one of them.)


Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Nov 3, 2008, at 2:36 PM, Aaron Brady wrote:

Then please write the Python equivalent of the "Swap" methods shown  
at
 (or at , for that matter).


And no fair wrapping the two parameters up in an object or using  
tuple

packing/unpacking -- the point is to demonstrate that you can change
the two parameters themselves, not some object that contains them or
return them a different order.


Python can do the swap operation on mutable types, for example.


That's in the "no fair" category.  C can do a swap operation on  
mutable types, too, though it also has only pass-by-value.  Same for  
Java, or for REALbasic or VB.NET using "ByVal" mode.  The fact that  
you can mutate mutable types has absolutely nothing to do with whether  
the parameter was passed by reference or value.  If was by reference,  
you can change it (the parameter itself, not something the parameter  
may refer to).  If it's by value, you can't.


In Python, you can't.  That's because parameters are passed by value.


By-Value and By-Reference are not the only passing methods.  True or
False?


True, but the others are rarely used and don't apply to any of the  
languages we've been discussing.


Best,
- Joe

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

Re: Structures

[Joe Strout]

On Nov 3, 2008, at 4:38 PM, Paulo J. Matos wrote:


However, I wouldn't dare to say Python needs structures to be a good
language, or anything similar. My question was more directed to : if
there aren't structures in Python, what do Pythonists use instead?


Classes.

Best,
- Joe


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

Re: Finding the instance reference of an object

[Joe Strout]

On Nov 3, 2008, at 5:27 PM, Marc 'BlackJack' Rintsch wrote:


Maybe this is a surprise for you, because we haven't discussed this in
much detail in this group lately, but it applies to Python which does
call-by-object or call-by-sharing.  ;-)


There's no such thing.  Those are just terms made up by the Python  
community to in place of the more standard "call-by-value" terminology  
to make Python seem more mysterious than it really is.  I guess you  
can call it "purple bananas" if you want, but the behavior is exactly  
the same as what every other language calls call-by-value.


But I really am trying not to continue this debate.  So that's my last  
reply about it for tonight, I promise.  :)


Cheers,
- Joe



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

locating the chorus in a MIDI song?

[Joe Strout]

We've got a need to generate short "samples" of songs that are in MIDI  
format, to provide a preview function in a web app.  We'd like to do  
something more clever than just taking the middle 20 seconds (or  
whatever) of the song -- ideally, we'd like to find the chorus, since  
that's likely to be the most easily recognized part of the song.


I believe this could be done fairly reliably by looking for patterns  
in the MIDI file, though I'm sure there are plenty of complications to  
this simple idea.


So:

1. I see at  there are  
quite a few MIDI libraries for Python.  Are any of them particularly  
well suited to this task?


2. Anybody have an interest in music theory, as well as mad Python  
skills?  Want a paying contract job?  If so, please contact me off- 
list.  I'd enjoy pursuing this myself, but if you think you can do a  
better job at a reasonable rate, I'm happy to let you do so.


Thanks,
- Joe


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

Re: Which was the best Lib of GUI for python

[Joe Strout]

On Nov 3, 2008, at 10:53 PM, 3000 billg wrote:

I am a leaner. for your experience. Which GUI Lib will be the best  
for Python? wxpython, Tkinter or...


I'm sure you'll get as many opinions on this as there are libraries.   
However, I recently faced the same choice, and settled on wxPython.   
I've been very impressed with the quality and "nativeness" that's  
achievable with wx apps.  You'll find a number of demos with the  
wxPython distribution (already installed on your machine, if you're  
using OS X 10.5), and it's well worth running them to give you a feel  
for what it can do.


In addition to the quality apparent to the end-user (which I think is  
the most important thing), I find the wx API to be quite sensible and  
easy to work with too.


HTH,
- Joe


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

Re: Finding the instance reference of an object

[Joe Strout]

On Nov 4, 2008, at 7:42 AM, Craig Allen wrote:


coming from C/C++ Python seemed to me call by reference, for the
pragmatic reason you said, modificaitons to function arguments do
affect the variable in the caller.  The confusing part of this then
comes when immutable objects are passed in.


Yes, you stepped in the wrong direction right away and led yourself  
into a morass of contradictions.


The correct way to look at it is that a Python reference is like a C++  
pointer.  C++ pointers are passed by value (unless you add & to  
explicitly make a parameter by-reference), yet you can still use them  
to mutate the objects they point to, right?  Same thing in Python.   
Nothing at all mysterious going on here.  Compare this:


typedef Spam* SpamPtr;   // (where Spam is some class)
// ...
void foo(SpamPtr spam)
{
spam->count = 4;
}

When you call foo, it modifies the spam object passed in, even though  
the parameter is by-value.  How?  Because (looking more carefully),  
you didn't actually pass in a Spam object; you passed in a POINTER TO  
a Spam object.  That pointer remained unchanged.  You just used the  
pointer to change some other data living on the heap.  This is the  
case exactly equivalent to Python:


def foo(spam):
spam.count = 4;

Same thing here; the variable you pass in is a reference to a Spam  
object, and while that reference remains unchanged by the call, it is  
used to change some other data that lives on the heap.


Here's a C++ example that has no analog in Python, because it uses  
call-by-reference:


void throwOut(SpamPtr &spam)
{
printf("throwing out %s\n", spam->brand);
delete spam;
spam = nil;
}

Now here, when you invoke throwOut on a SpamPtr, your own SpamPtr  
variable (the one that you pass in) actually gets set to nil.  That's  
because the formal parameter here is just an alias of the actual  
parameter.  You can't do that in Python; this attempt:


def throwOut(spam):
print "throwing out %s\n", spam.brand
spam = nil

would entirely fail to have any effect whatsoever on the Spam  
reference you pass in.  "spam" here is just a local variable within  
the throwOut function, which has no connection to the variable passed  
in other than it gets a copy of its value (i.e., it initially refers  
to the same object as the actual parameter).  This doesn't work, and  
the C++ throwOut function has no analog in Python, because Python has  
no call-by-reference.


Here's another C++ example that has no analog in Python, because it  
passes an object directly on the stack rather than a reference to it:


void bar(Spam spam)
{
spam.count = 5;
}

This is the one that I know particularly confuses some users, because  
it LOOKS like what you could do in Python, and has the same behavior  
on the surface.  But it's not analogous at all, because the "spam"  
local variable here (and presumably the one in the calling context) is  
an object stored directly on the stack, rather than a reference to an  
object on the heap.  Python can't do that (nor can Java, nor  
REALbasic, etc.).  This example is also call-by-value, but the value  
in this case is a type that has no analog in Python.  Python object  
variables are references to objects on the heap, just like pointers in  
C++ to objects created with "new".  So this example is a red herring.


I'd be very interested in hearing whether, as a C/C++ user, the above  
explanation is clear and makes sense to you.


Thanks,
- Joe


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

Re: Python on iPhone actually rather good

[Joe Strout]

On Nov 4, 2008, at 10:33 AM, Michael Torrie wrote:

Are there any good books on python and objc?  I doubt you'll be able  
to

make any decent iPhone apps without having a good working knowledge of
Objective C and the python-objc bridge.  In my mind that's one of the
cool parts of doing cocoa development in python, but also the biggest
curse of cocoa.


I've found "Cocoa Programming for Mac OS X", in combination with the  
PyObjC tutorials on the web, to be a very accessible combination.   
I've gone about halfway through the book, just translating the  
tutorials from ObjC to PyObjC as I go, and it's worked out fine.


When I need help, I post to the pythonmac-sig list, which is a  
friendly and helpful bunch.  (I would think that iPhone development  
would be welcome there as well, since the iPhone is more or less a  
tiny Mac, at least from a development point of view).


Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Nov 4, 2008, at 3:42 PM, Steven D'Aprano wrote:

This example is also call-by-value, but the value in this case is a  
type

that has no analog in Python.


I'm disappointed to see that my prediction that Joe would, yet again,
utterly ignore all the arguments against his pet theory was correct.


I'm not doing that, but the folks on the other side are.  (Well, I  
don't know if you are in particular, as I've been deleting your  
messages to save my blood pressure... this one caught my eye though,  
alas.)


For example: we have arguments that you can "modify" a parameter  
passed to a function in Python.  These ignore the fact that you can  
only use (dereference) that parameter to modify something else, no  
different from a pointer passed by-value in C/C++.  And, when a very  
simple test for by-reference is brought up (i.e. writing a Swap  
method), this gets ignored again and again, by the otherwise perfectly  
nice fellow I've been discussing this with privately for days.  There  
are many other examples.


It boils down to this: Python's behavior is demonstrably the same as  
any other modern OOP language, INCLUDING those that have both by- 
reference and by-value parameter modes, except that in Python (as well  
as Java), only the by-value mode is available.


This is easily shown, and I've done exactly that at .


But I predict that you'll ignore all this evidence that goes against  
your pet theory, and continue to cause confusion and obfuscation on  
the topic.


When we're talking about the value of a variable in Python, why on  
earth
would you drag entities that do not exist in Python into the  
discussion?


I don't, but others do, for example bringing up C structs or C++  
objects on the stack, which don't exist in Python (Python objects live  
on the heap, and all you have on the stack are references to them; the  
proper C/C++ analogy is an object created with "new" and referenced  
entirely via pointers).



That is too low a level. It's analogous to my earlier tongue-in-cheek
suggestion that all languages are in fact call-by-bit-flipping:
technically true at some level of explanation, but not at the level of
the Python virtual machine.


I agree that we don't need to talk about bits.  But we do need to  
understand whether code such as:


  a = SomeClass()
  b = a

creates two objects, or merely two references to the same object.   
Once we know whether we're dealing with values or references, then  
everything else becomes simple and clear, no matter what language  
we're building in.


I know you really want Python to be unique and special -- and it is,  
in many ways, but this isn't one of them.  Python is an OOP language  
whose variables contain references to objects, and where such  
references are passed (by value) to methods, just like Java, and like  
the default parameter mode in VB.NET, REALbasic, and C++ (though those  
languages also offer a by-reference mode that Python and Java do not).


Your continued attempts to obfuscate this simple behavior does no  
credit to you or Python.


Best,
- Joe

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

Re: Finding the instance reference of an object

[Joe Strout]

On Nov 4, 2008, at 3:54 PM, Steven D'Aprano wrote:

At the level of Python code, Python operates on *objects*. When you  
call
a function with an argument, the argument (an object) is NOT copied,  
it

is passed to the function. If you mutate the argument inside the
function, you are changing the object and the caller will see the
mutation: this is just like call-by-reference, and unlike call-by- 
value.


And here is the key bit that you are missing.

When you pass a reference to an object to a function, and then mutate  
the object, then OF COURSE the caller (as well as any other holders of  
a reference to that object) will see the mutation.  This is true in  
ANY language.  Pick your language, and I will demonstrate it.  Here  
are a few to get us started (assume a class "Person" with an attribute  
"zipcode"):


C++:
void foo(PersonPtr who) {
who->zipcode = 12345;
}

Java:
void foo(Person who) {
who.zipcode = 12345;
}

REALbasic/VB.Net:
Sub foo(ByVal who as Person)
who.zipcode = 12345
End Sub

Python:
def foo(who):
who.zipcode = 12345


So please clarify your position by identifying which statement applies:

1. You don't believe that these languages are actually passing by value.
2. You don't believe these examples are mutating an object.
3. You don't believe these mutations can be seen by the caller after  
the call.
4. You now see how a mutating an object within a function tells you  
NOTHING about how the reference to that object was passed.
5. You see that the first three languages above are passing a  
reference by value and using that to mutate and object, yet for  
reasons still mysterious, the Python example (which has exactly the  
same behavior) must be doing something different.


I hate being confrontational, but you're the one accusing me of  
ignoring evidence against my "pet theory" (by which you mean the  
standard definitions of c-b-v and c-b-r).  Let's see what you do with  
this evidence that directly contradicts yours.


Sigh.


But if you assign a different object to the argument name, the caller
does NOT see the change, which is just like call-by-value.


This at least you have correct.


So depending
on what type of object the argument is, and depending on what you do
inside the function, you get something that looks rather like call-by-
value or call-by-reference semantics.


But no, you don't, as I just demonstrated above (and explained a week  
ago at ).  You always have  
call-by-value semantics.  The semantics are exactly the same as in any  
other language with anything resembling an object reference, including  
those with both "ByVal" and "ByRef" modes (except that there is no  
equivalent to the "ByRef" mode in Python).



But what the Python VM does is the
same no matter what you do: Python's calling model is different from
either byval or byref.


No, it's exactly byval.  No.  Different.  In.  Any.  Way.

Let's tackle it this way: one of the following must be true for your  
belief system to prop itself up at all:


1. Python's behavior is different from Java, REALbasic, VB.NET, and C++.
...or...
2. None of those languages mentioned use call-by-value.

In fact both of these statements are false, but we can cut our time  
and effort in half if you will just select the one that you believe to  
be true, so we can focus on that.  Which is it?


Thanks,
- Joe

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