Re: Counter Class -- Bag/Multiset

[Paul Rubin]

msrache...@gmail.com writes:
> how do you guys like the functionality?  Do you find it useable in
> real-world use cases?

It's interesting.  I wouldn't have thought of that API--I'm used to
populating defaultdict(int) in the obvious ways for this sort of
thing--but it is attractive and I think it will be useful.  Thanks for
implementing it.  
--
http://mail.python.org/mailman/listinfo/python-list

Re: Counter Class -- Bag/Multiset

[bearophileHUGS]

Raymond Hettinger:
> The collections module in Python 2.7 and Python 3.1 has gotten a new
> Counter class that works like bags and multisets in other languages.

Very nice. Python std lib is growing more data structures, increasing
the power of a default Python installation. I can remove more and more
modules from my bag of tricks.

I like the name Bag(), it's shorter. Names are important enough.

Are keys restricted to be long and int values only? Or are they
general (referenced) objects + a control of their integral nature?

I think you can add better explanations to this, like an example:
c += Counter() # remove zero and negative counts

Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list

Re: Counter Class -- Bag/Multiset

[bearophileHUGS]

bearophile:
> Are keys restricted to be long and int values only? Or are they
> general (referenced) objects + a control of their integral nature?

Here I meant values, sorry.
Also: what's the rationale of allowing negative values too?

Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list

Re: The First Law Of comp.lang.python Dynamics

[Kay Schluehr]

On 23 Jan., 08:13, Philip Semanchuk  wrote:
> On Jan 23, 2009, at 12:39 AM, Kay Schluehr wrote:
>
> > Whatever sufficiently sophisticated topic was initially discussed
> > it ends all up in a request for removing reference counting and the
> > GIL.
>
> Is this a variant of Godwin's Law for Python?

Definitely. It's a stable fixed point attractor. No matter how often
it was discussed to dead in the past months the likelihood that
someone mentions the GIL or ref-counting approaches 1. This is
particularly remarkable because it is inverse proportional to the
observable activity in this domain so there are really no news.

Other similarly strange phenomena: whenever Xah Lee posts one of his
infamous rants it attracts at least a dozen of newsgroup readers that
try to persuade each other not to respond which will inevitably grow
his thread and keep it alive for a long time.

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

Re: Counter Class -- Bag/Multiset

[msrachel . e]

On Jan 23, 12:27 am, bearophileh...@lycos.com wrote:
> bearophile:
>
> > Are keys restricted to be long and int values only? Or are they
> > general (referenced) objects + a control of their integral nature?
>
> Here I meant values, sorry.
> Also: what's the rationale of allowing negative values too?

The dict values can be anything, but only ints make sense in the
context of bags/multisets/counters etc.
Since it is a dict subclass, we really have no control of the
content.  It's pretty much a "consenting adults" data structure (much
like the heapq module which cannot enforce a heap condition on the
underlying list which is exposed to the user).

To block negative values, the setter methods would have to be
overridden and would dramatically slow down the major use cases for
counters (and we would not be able to let people freely convert to and
from arbitrary dicts).  Also, we would have to introduce and document
some kind of exception for attempts to set a negative value (i.e. c[x]
-= 1 could raise an exception).  This would unnecessarily complicate
the API in an attempt to limit what a user can do (perhaps barring
them from a use case they consider to be important).

So, if you don't want negative counts, I recommend that you don't
subtract more than you started off with ;-)

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

Re: Counter Class -- Bag/Multiset

[Terry Reedy]

msrache...@gmail.com wrote:


The term counter was what was originally approved.  At first, I didn't
like it but found that it had some advantages.  The main advantage is
that there are *bazillions* of programmers (including some very good
ones) who have never heard the term multiset or bag but have an
instant,
intuitive understanding of counting and counters.

Also, in the context of this implementation, "multiset" would not be a
good choice.  The mathematical entity, multiset, is defined with
elements
having a count of one or more.  In contrast, the Counter class allows
counts to go to zero or become negative.  In addition, I worried that
calling it a multiset would suggest that it has a set-like API instead
of a dict-like API.  With the former, you write c.add(elem).  With the
latter, you write c[elem] += 1.  So the name, "multiset" would be
misleading.


Agreed.  I withdraw my objection.

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

Re: Adding a field to a 'foreign' object from the outside

[Bruno Desthuilliers]

atleta a écrit :

  Hi,

I'm working with a callback API (a DBus one) and I'd need to store
some state between the calls somewhere. I know that it's possible to
extend an object with fields after creation, so I could just store my
data in the session object that is passed in with every callback.
However it stinks from OO perspective,


Why so ? And what does your API documentation says about this session 
object?



at least to me. The other
option, something that I'd do in java for example, would be to set up
a mapping (a dict) using the session object as a key.


Is this object _safely_ usable as a key somehow ? And if yes, do you 
have a way to deal with stale sessions ?



Which one is the
'pythonic' way?


The simplest. But as far as I'm concerned, I don't have enough context 
to say which one it would be here.



Do you use the first method (modifying an object that
you don't even control the source of) or do you write a bit more code
and go with the second one?


Depends - cf above. But as a guideline, unless the library provides a 
defined way to solve this problem or the library documentation clearly 
states I should *not* store my own data in the session object (but then 
what's the point of a session object ???), I'd just use it.


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

Re: Counter Class -- Bag/Multiset

[Terry Reedy]

bearophileh...@lycos.com wrote:


Also: what's the rationale of allowing negative values too?


I can guess two:
1) Nuisance to check given that Python does not have a count (0,1,2...) 
type.

2. Useful. + = items on hand; - = items back-ordered.
Bank account go negative also ;-). So does elevation.
Similarly, an app could set 0 to mean 'desired quantity on hand', so 
non-zero count is surplus or deficit.


I might not have thought to allow this, but it seems to open new 
applications.  (This definitely makes bag or multiset inappropriate as 
names.)


tjr

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

Re: Idea to support public/private.

[Bruno Desthuilliers]

Brian Allen Vanderburg II a écrit :
Okay so I don't really care about public/private but I was watching the 
lists (Does python follow its idea of readability or something like 
that) and I thought of a 'possible' way to add this support to the 
language.


It has already been done at least a couple times.
--
http://mail.python.org/mailman/listinfo/python-list

problem with special characters in filename

[fizzotti]

using:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2


Hello

I have two files (let's assume they are all in the same directory):

1) "a.dat" containing the single line "Sébastien.dat"
2) "Sébastien.dat" containing arbitraty data

I want to:

open "a.dat"
read in the single line ("Sébastien.dat")
copy the file described by the single line ("Sébastien.dat") to
another location with name "b.dat"

This is what I have started with:

import shutil

file = open('a.dat','r') #opens file for reading
for line in file:
print line
old_name = line[0:len(line)-1] #gets rid of "\n" suffix
print old_name
shutil.copy(old_name, 'b.dat') #copies file

However I get the following error:
IOError: [Errno 2] No such file or directory: 'S\xc3\xa9bastien.dat'

I'm sure this has something to do with encoding and decoding UTF-8 and
Unicode or something like that, but everything I've tried has yet to
produce any favourable results.

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

Re: A java hobbyist programmer learning python

[TheFlyingDutchman]

>
> * No getters and setters. Python takes a very permissive approach to
> class attributes, taking the philosophy "we're all adults here". It's
> easy to change a public attribute to a private attribute with a getter/
> setter if you need to, so there's nothing to be gained by writing getters
> for straight attribute access. It just makes things slow.

If adding a getter/setter made data private, then per a tenet of
Object Oriented Programming, there would be something to be gained
from it. But I don't see getter/setters would do that.

The statically typed object oriented languages, like Java, C++ and C#,
all permit member data and functions to be public - allowing a
programmer to implement a "we're all adults here" programming
philosophy if they so choose. However, they also allow a programmer to
make member data and functions private, thus allowing the
implementation one of the tenets of OOP. I don't use Ruby, a
dynamically typed language like Python, but from a web search it
appears that Ruby does allow at least data to be declared private. But
it appears that a user of a class can get around this private
declaration by writing their own methods and adding them to the class
dynamically.

In his book "Core Python Programming", noted Python expert and PyCon
speaker Wesley J. Chun makes the following statements regarding one of
the main principles of Object Oriented Programming (OOP):

"Encapsulation/Interfaces
Encapsulation describes the concept of data/information hiding and
providing interfaces or accessor functions to the data attributes.
Direct access to data by any client, bypassing the interfaces, goes
against the principles of encapsulation, but the programmer is free to
allow such access. As part of the implementation, the client should
not even know how the data attributes are architected within the
abstraction. In Python, all class attributes are public but names may
be "mangled" to discourage unauthorized access, but otherwise not
prevented. It is up to the designer to provide the appropriate
interfaces to the data so that the client programmer does not have to
resort to manipulating the encapsulated data attributes."
--
http://mail.python.org/mailman/listinfo/python-list

Re: problem with special characters in filename

[Murali Murali]

Try this:

import shutil,os

file1 = open('a.dat','r') #opens file for reading
for line in file1:
print line
##old_name = line[0:len(line)-1] #gets rid of "\n" suffix
##print old_name
line.strip() #gets rid of "\n" suffix
print line
os.rename('b.dat',line) #renames file
file1.close()






From: "fizzo...@gmail.com" 
To: python-list@python.org
Sent: Friday, January 23, 2009 2:43:24 PM
Subject: problem with special characters in filename

using:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2


Hello

I have two files (let's assume they are all in the same directory):

1) "a.dat" containing the single line "Sébastien.dat"
2) "Sébastien.dat" containing arbitraty data

I want to:

open "a.dat"
read in the single line ("Sébastien.dat")
copy the file described by the single line ("Sébastien.dat") to
another location with name "b.dat"

This is what I have started with:

import shutil

file = open('a.dat','r') #opens file for reading
for line in file:
print line
old_name = line[0:len(line)-1] #gets rid of "\n" suffix
print old_name
shutil.copy(old_name, 'b.dat') #copies file

However I get the following error:
IOError: [Errno 2] No such file or directory: 'S\xc3\xa9bastien.dat'

I'm sure this has something to do with encoding and decoding UTF-8 and
Unicode or something like that, but everything I've tried has yet to
produce any favourable results.

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



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

Re: Does Python really follow its philosophy of "Readability counts"?

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:


Steven D'Aprano  writes:


On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:

Steven D'Aprano a écrit :

But if you have free access to attributes, then *everything* is
interface.

Nope.

How could anyone fail to be convinced by an argument that detailed and
carefully reasoned?

Well, your claim /was/ just wrong.  But if you want to play dumb: the
interface is what's documented as being the interface.


But you miss my point.

We're told Python doesn't have private attributes.


Yes.

We're told that we're 
allowed to "mess with the internals",


Given that we're willing and able to cope with possible consequences.


we're *encouraged* to do so


Certainly not.

Python 
gives you the freedom to do so, and any suggestion that freedom might be 
reduced even a tiny bit is fought passionately.


Won't comment on this.

When people ask how to 
implement private attributes, they're often told not to bother even using 
single-underscore names.


"often" ? Not as far as I can tell. I think you're confusing this with 
the advice to not use getters/setters for no good reason, given Python's 
support for computed attributes - which is not exactly the same thing.


When it is suggested that Python should become 
stricter, with enforced data hiding, the objections come thick and fast: 
people vehemently say that they like Python just the way it is, that they 
want the ability to mess with the internals.


Indeed. There's no shortage of B&D languages, and well, Python is OSS, 
so if you want a B&D Python (now that's an oxymoron), please feel free 
to implement it. But by all mean, leave my favorite language alone. Thanks.


You even argued that you disliked data structures implemented in C and 
preferred those written in Python because you have more ability to mess 
with the private attributes.


In context, I had just mentioned that lists' 
internals were inaccessible from Python code. I neglected to give an 
example at the time, but a good example is the current length of the 
list. Consider the experience of Microsoft and Apple.


Yes, two great examples of freedom champions.

No matter how often 
they tell people not to mess with the internals, people do it anyway, and 
always believe that their reason is a good reason.


And who are *you* to pronounce any judgement about that ?

And Python culture encourages that behaviour (albeit the consequences are 
milder: no buffer overflows or core dumps).


Add to that the culture of Open Source that encourages reading the source 
code.


Indeed. A *very* good thing FWIW.

You don't need to buy a book called "Undocumented Tips and Tricks 
for Python" to discover the internals. You just need to read the source 
code.


Exactly.

And then you have at least two places in the standard library where 
_attributes are *explicitly* public:


http://bugs.python.org/issue3152

Given this permissive culture, any responsible


For your personal definition of "responsible".

library writer must assume 
that if he changes his so-called "private" attributes, he will break 
other people's code.


You still don't get the point. If someone's code breaks because he 
messed with my implementation code, then *he* is responsible. The 
contract is very clear : "warranty void if unsealed".


In principle it could break just as much code as if 
he didn't even bother flagging them with a leading underscore, which is 
probably why many people don't even bother with _names.

>
In other words, if you make it easy for people to mess with your 
internals, if you have a culture that allows and even encourages them to 
mess with your internals, then you don't have internals. Everything is de 
facto public.



Now that you've exposed your opinions, let's face reality (I mean, 
*facts*): Python developpers very rarely mess with implementation, 
usually do so for very good (and documented) reasons, and from what I've 
seen usually tend to get in touch with the library author to explain 
their case and find a better solution.


Funny enough, it looks that the more you treat programmers as 
responsible, normally intelligent adult person, the more they tend to 
behave as such. And the other way around, too.


Now, you comprehensively exposed your personnal distaste for Python's 
and more generally OSS philosophy. So I can only - as I already did way 
before in this thread - wonder *why* are you using Python ?


I mean, is it because your bosses forces you to do so ? If yes, then, 
I'm truly sorry for you - I sometimes have to work with languages I 
really dislike so I can feel your pain (but OTHO, I never complained on 
these languages newsgroups about how wrong they were nor how they should 
IMHO be).


Else, well, I just don't get the point. What you are fussing about are 
fundamental design choices (and philosophic points) that are well known, 
explained, advertized, etc. - and are really not likely to change 
an

Re: Does Python really follow its philosophy of "Readability counts"?

[Bruno Desthuilliers]

Russ P. a écrit :

On Jan 21, 4:04 am, Bruno Desthuilliers  wrote:

Russ P. a écrit :
(snip)


Your mistake for being a moron. But it seems to happen regularly,
doesn't it. How much more of my time are you going to waste, loser?

Calling people names is certainly not the best way to defend your
opinions here. Adios, Mr. P.


You are absolutely right, Mr. D. I regret that post, and I have since
apologized to the person I was addressing. This stuff really isn't
important enough to get that worked up about.



Ok, so welcome back then.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a database

[kt83313]

On Jan 23, 12:38 pm, "Diez B. Roggisch"  wrote:
> kt83...@gmail.com schrieb:
>
>
>
> > My company provides some services online, which now they are planning
> > to make it offline and sell to customers who can use it in their
> > networks.
>
> > One of our major moneywinners is some data which is stored in a
> > database. Now, this data inside the database was obtained after paying
> > through the nose - so the company does not want to disclose the data
> > in the DB to the outside world - not to mention the lawsuits which the
> > original providers of data will start which will sink the company if
> > the data goes out.
>
> > Now, the code is in Python - and we have a big problem. How to secure
> > the data in DB? One idea was to encrypt it and store the password in
> > the code. I dont believe security through obscurity - and python code
> > can easily be reverse-engineered too - right?
>
> > Is it even possible to secure a data in this case?
>
> No. And that has nothing to do with python. If the data is valuable, it
> will be decyphered from a compiled piece of code in no time. Believe me,
> I work for a company that sells a C++-software with protective measures
> of various kinds. It gets hacked. Fact of live.
>
> You could try and raise the bar, as e.g. skype does, with an onion-kind
> of code-encryption-scheme. But even *that* is analyzed. And it is
> nothing that is done easily and without major impact on your source, so
> you might need quite a bit of time to get it right. Is that covered by
> the expected revenues?
>
> And even if one doesn't want to hack into the system, if there is an
> interface to the data, who stops your users from exploiting that
> automatically to access all the data in the DB somehow?
>
> Diez

Thank you very much Diez.
This was my fear.
Anyways, if we can make it real hard for them to analyze also, I think
we are in the good - esp since the clients are not extremely rich
enough to go for professional analyzers --
What is the skype method? The code is not huge - less than 20K LOC so,
code encryption looks somewhat OK - would you be able to direct me to
any hints on this?

One another option that I was thinking was to automatically generate
the password for the database - re-encrypt every 1 hr - and store the
password inside the code itself. Is that possible in Python? i.e.
changing the code itself.

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

Re: problem with special characters in filename

[Diez B. Roggisch]

fizzo...@gmail.com schrieb:

using:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2


Hello

I have two files (let's assume they are all in the same directory):

1) "a.dat" containing the single line "Sébastien.dat"
2) "Sébastien.dat" containing arbitraty data

I want to:

open "a.dat"
read in the single line ("Sébastien.dat")
copy the file described by the single line ("Sébastien.dat") to
another location with name "b.dat"

This is what I have started with:

import shutil

file = open('a.dat','r') #opens file for reading
for line in file:
print line
old_name = line[0:len(line)-1] #gets rid of "\n" suffix
print old_name
shutil.copy(old_name, 'b.dat') #copies file

However I get the following error:
IOError: [Errno 2] No such file or directory: 'S\xc3\xa9bastien.dat'

I'm sure this has something to do with encoding and decoding UTF-8 and
Unicode or something like that, but everything I've tried has yet to
produce any favourable results.


You need to know two things:

 - what encoding has the a.dat-content?

 - what encoding uses your filesystem?

Then you need to decode the file's contents with the first one, and then 
encode it with the second one.


The above at least applies to Linux. I'm not sure about windows - I 
*know* they have wide-char/unicode support, but I'm not sure how exactly 
that is exposed via the python file apis


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

Re: problem with special characters in filename

[Diez B. Roggisch]

The above at least applies to Linux. I'm not sure about windows - I 
*know* they have wide-char/unicode support, but I'm not sure how exactly 
that is exposed via the python file apis


Just found this:

http://www.amk.ca/python/howto/unicode


there is a seciton about filenames and OSes in there, you should read it.

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

Re: A different kind of interface

[Eduardo O. Padoan]

On Thu, Jan 22, 2009 at 5:01 PM,   wrote:
> Eduardo O. Padoan:
>> You are almost *describing* reinteract:
>
> - Thank you for the link and the software, I have not tried it yet,
> but from the screencast it looks quite nice.
> - I am glad that there are people that don't think that Emacs is
> (despite being good) the alpha and omega of editing. There's space for
> other ideas beside Emacs.

But it is! 

> - Maybe I was describing reinteract there, but that's only the first
> part of my post :-)
> - I can see that reinteract is based on a interaction style quite
> similar to the shell of Mathematica. I was talking about something
> different, and more similar to TextCalc, but in the end I think
> reinteract may be good enough for my purposes, so I'll try to run it.
> And I may be happy enough.

I dont known TextCalc, but I guess that reinteract is flexible enough
to the general purpose of "experimenting with Live code".

> - Eventually I may find the time and will to create my "interactive
> python text" :-) I think there's space for many different solutions.
> - Despite many years of experiments, development, shells, editors, and
> the like, I am sure there are other designs not yet tried or not
> common enough yet (beside the normal editors, shells, smart object-
> oriented graphical shells like hotwire shell, Resolver One, and few
> other weird things, like one where you can zoom text and images at
> different scales, other text-based systems, etc).


Sure, thats the spirit.


> Bye,
> bearophile
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
"Distrust those in whom the desire to punish is strong." -- Goethe,
Nietzsche, Dostoevsky
--
http://mail.python.org/mailman/listinfo/python-list

Re: Securing a database

[Diez B. Roggisch]

Thank you very much Diez.
This was my fear.
Anyways, if we can make it real hard for them to analyze also, I think
we are in the good - esp since the clients are not extremely rich
enough to go for professional analyzers --
What is the skype method? The code is not huge - less than 20K LOC so,
code encryption looks somewhat OK - would you be able to direct me to
any hints on this?


20LOC of pyhon translates to the tenfold in a compiled language I'd guess.

And all I know about the skype-protection I've read from some paper of 
some french researches - I think. However, that paper was about 
*breaking* the encryption, not about how to write it.


And I'm not an expert in these matters, mind you.



One another option that I was thinking was to automatically generate
the password for the database - re-encrypt every 1 hr - and store the
password inside the code itself. Is that possible in Python? i.e.
changing the code itself.


But wherefrom do you get the *initial* password, or the one used the 
last time? What happens if the process dies unexpectedly, leaving the db 
in an undefined, half-crypted state with no way to know the new password?


Seriously - if I was assigned the task of doing this thing, I'd seek 
help from somebody who has experience in these matters. It's hard to get 
right, and easy to get wrong but think one has it right.



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

Need script to download file from a server using python script

[Murali Murali]

Hi, 
I am fairly new to python and i am looking for a python script to
download file(latest build) from the server. But, the build name changes
daily. For Ex:  today the build URL will be
"http://mybuilds/myapp_1234.exe"; and tomorrow it will be 
"http://myserver/mybuilds/myapp_3456.exe";.  So i need a script which downloads
the latest build without any knowledge of build number. 
 Can anyone  help me? 
Advance thanks, 


This is my start:

###
import os,sys,httplib,time,
Server="myserver"
Build2Download=mybuilds/myapp_3456.exe
installer=myapp_3456.exe

print "Downloading Installer... from the site:%s"%Server
connection=httplib.HTTPConnection(Server)
connection.request("GET",Build2Download)
resp = connection.getresponse()
if resp.status != 200:
print "Error getting installer.  GET response : %d %s" % (resp.status, 
resp.reason)
sys.exit(-1)   
try:
open(Installer, 'wb').write(resp.read())
time.sleep(15)
except:
pass


###
The build number keeps changing. So how can i use wildchars(?) or something 
else to handle change in the build no.?

Advance Thanks,

Murali.



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

Re: Securing a database

[kt83313]

On Jan 23, 3:19 pm, "Diez B. Roggisch"  wrote:
> > Thank you very much Diez.
> > This was my fear.
> > Anyways, if we can make it real hard for them to analyze also, I think
> > we are in the good - esp since the clients are not extremely rich
> > enough to go for professional analyzers --
> > What is the skype method? The code is not huge - less than 20K LOC so,
> > code encryption looks somewhat OK - would you be able to direct me to
> > any hints on this?
>
> 20LOC of pyhon translates to the tenfold in a compiled language I'd guess.
>
> And all I know about the skype-protection I've read from some paper of
> some french researches - I think. However, that paper was about
> *breaking* the encryption, not about how to write it.
>
> And I'm not an expert in these matters, mind you.
>
> > One another option that I was thinking was to automatically generate
> > the password for the database - re-encrypt every 1 hr - and store the
> > password inside the code itself. Is that possible in Python? i.e.
> > changing the code itself.
>
> But wherefrom do you get the *initial* password, or the one used the
> last time? What happens if the process dies unexpectedly, leaving the db
> in an undefined, half-crypted state with no way to know the new password?
>
> Seriously - if I was assigned the task of doing this thing, I'd seek
> help from somebody who has experience in these matters. It's hard to get
> right, and easy to get wrong but think one has it right.
>
> Diez

I agree Diez.
Anyways, code encryption seems to be a fun thing. I will try to see
whether some papers about Skype is running around.
If I can get it done, then maybe I will try to post the code here.

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

Re: Need script to download file from a server using python script

[Tim Chase]

The build number keeps changing. So how can i use wildchars(?)
or something else to handle change in the build no.?


Short answer:  you can't...HTTP doesn't support wild-card requests.

Longer answer:  presumably there's some method to the madness of 
naming the file.  Find the algorithm and use it.


It might be that the URL is available in some other page, so you 
have to get that page, scrape it for the URL pattern, and then 
use the resulting URL as your input.


It might be that the filename moves around because of some 
complex algorithm you may (or may not) have access too. If you 
have access to the algorithm, use it.  If not, it might be that 
the source is trying to make it hard for people to do exactly 
what you're doing by randomly moving the file around on the 
website in which case, be nice.


-tkc





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

seeking to improve Python skills

[mk]

Hello everyone,

I wrote the following program mainly for educational purpose of 
improving my Python programming skills -- would Pythonistas here please 
look at it and point out areas that could use improvement?


This thing analyzes the stored load average record file, calculates 
simple moving average and produces Gnuplot program to plot the thing.


Constructive criticism is welcome.

#!/usr/bin/python

import re
import sys
import tempfile
import subprocess
import os

class MovingAvg(object):

def __init__(self, fname):
try:
self.fo = open(fname)
except IOError, e:
print "Problem with opening file:", e
sys.exit(4)
self.reslist = []
self.smalist = []
self.maxval = 0

def extrfromfile(self):
vre = re.compile("(\d+-\d+-\d+) (\d\d:\d\d) (\d+\.\d+)")
for line in self.fo:
res = vre.search(line)
if res:
self.reslist.append({'day':res.group(1),\
'time':res.group(2),\
'val':float(res.group(3))})

def calc_sma(self, smalen=4):
if smalen == 0:
raise AssertionError, "Moving Average sample 
length cannot be 0"

if not isinstance(smalen, int):
raise AssertionError, "Moving Average sample 
length has to be integer"

total = 0
total = sum( [ x['val'] for x in self.reslist[0:smalen] ] )
sma = total / smalen
smaidx = int(smalen/2)
self.smalist.append((self.reslist[0]['day'],\
self.reslist[0]['time'],\
self.reslist[0]['val'],\
self.reslist[0]['val']))
for i in range(smalen, len(self.reslist)):
curval = self.reslist[i]['val']
self.maxval = max(self.maxval, curval)
total += curval
total -= self.reslist[i - smalen]['val']
sma = total / smalen
smaidx += 1
self.smalist.append((self.reslist[smaidx]['day'],\
self.reslist[smaidx]['time'],\
self.reslist[smaidx]['val'],\
sma))


def return_results(self):
return (self.reslist, self.smalist, self.maxval)

class GnuplotWrapper(object):
def __init__(self, smalist, maxval, outfname = "calc.png", 
graphlen=640, graphheight=480, gnuplot = '/usr/bin/gnuplot'):

self.outfname = outfname
self.smalist = smalist
self.gnuplot = gnuplot
self.gprog = None
self.gdata = None
self.graphlen = graphlen
self.graphheight = graphheight

def _writefiles(self):
self.gprog = tempfile.mkstemp()
self.gdata = tempfile.mkstemp()
self.gprogfile = open(self.gprog[1], 'wb')
self.gdatafile = open(self.gdata[1], 'wb')
labelnum = int(self.graphlen / 110)
labelstep = int(len(self.smalist) / labelnum)
labels = []
for i in range(0, len(self.smalist), labelstep):
labels.append("\"%s %s\" %d" % 
(self.smalist[i][0], self.smalist[i][1], i))

labelstr = ", ".join(labels)

self.gprogfile.write("""set terminal png size %d, %d
set style line 1 lt 1 lw 2
set style line 2 lt 2 lw 2
set output "%s"
set xtics(%s)
set yrange [0:%f]
set y2range [0:%f]
plot "%s" using 1 with lines ls 1 title "orig" axes x1y1, "%s" using 2 
with lines ls 2 title "Moving Average" axes x1y2
""" % (self.graphlen, self.graphheight, self.outfname, labelstr, 
float(maxval), float(maxval),\

self.gdata[1], self.gdata[1]) )
self.gprogfile.close()
for elem in self.smalist:
self.gdatafile.write("%f, %f\n" % (elem[2], 
elem[3]))

self.gdatafile.close()

def plot(self):
self._writefiles()
gplot = subprocess.Popen(self.gnuplot + " " + 
self.gprog[1],\
shell=True, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)

print "Plotting data (%s)..." % self.outfname
so, se = gplot.communicate()
if se:
print "Gnuplot problem output:", se
os.remove(self.gprog[1])
os.remove(self.gdata[1])



if __name__ == "__main__":
try:
fname = sys.argv[1]
except IndexError:
print "Specify filename with data as 

Re: Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 23, 1:54 am, Bruno Desthuilliers  wrote:
> Steven D'Aprano a écrit :
>
>
>
> > On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
>
> >> Steven D'Aprano  writes:
>
> >>> On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
>  Steven D'Aprano a écrit :
> > But if you have free access to attributes, then *everything* is
> > interface.
>  Nope.
> >>> How could anyone fail to be convinced by an argument that detailed and
> >>> carefully reasoned?
> >> Well, your claim /was/ just wrong.  But if you want to play dumb: the
> >> interface is what's documented as being the interface.
>
> > But you miss my point.
>
> > We're told Python doesn't have private attributes.
>
> Yes.
>
> > We're told that we're
> > allowed to "mess with the internals",
>
> Given that we're willing and able to cope with possible consequences.
>
> > we're *encouraged* to do so
>
> Certainly not.
>
> > Python
> > gives you the freedom to do so, and any suggestion that freedom might be
> > reduced even a tiny bit is fought passionately.
>
> Won't comment on this.
>
> > When people ask how to
> > implement private attributes, they're often told not to bother even using
> > single-underscore names.
>
> "often" ? Not as far as I can tell. I think you're confusing this with
> the advice to not use getters/setters for no good reason, given Python's
> support for computed attributes - which is not exactly the same thing.
>
> > When it is suggested that Python should become
> > stricter, with enforced data hiding, the objections come thick and fast:
> > people vehemently say that they like Python just the way it is, that they
> > want the ability to mess with the internals.
>
> Indeed. There's no shortage of B&D languages, and well, Python is OSS,
> so if you want a B&D Python (now that's an oxymoron), please feel free
> to implement it. But by all mean, leave my favorite language alone. Thanks.
>
> > You even argued that you disliked data structures implemented in C and
> > preferred those written in Python because you have more ability to mess
> > with the private attributes.
> > In context, I had just mentioned that lists'
> > internals were inaccessible from Python code. I neglected to give an
> > example at the time, but a good example is the current length of the
> > list. Consider the experience of Microsoft and Apple.
>
> Yes, two great examples of freedom champions.
>
> > No matter how often
> > they tell people not to mess with the internals, people do it anyway, and
> > always believe that their reason is a good reason.
>
> And who are *you* to pronounce any judgement about that ?
>
> > And Python culture encourages that behaviour (albeit the consequences are
> > milder: no buffer overflows or core dumps).
>
> > Add to that the culture of Open Source that encourages reading the source
> > code.
>
> Indeed. A *very* good thing FWIW.
>
> > You don't need to buy a book called "Undocumented Tips and Tricks
> > for Python" to discover the internals. You just need to read the source
> > code.
>
> Exactly.
>
> > And then you have at least two places in the standard library where
> > _attributes are *explicitly* public:
>
> >http://bugs.python.org/issue3152
>
> > Given this permissive culture, any responsible
>
> For your personal definition of "responsible".
>
> > library writer must assume
> > that if he changes his so-called "private" attributes, he will break
> > other people's code.
>
> You still don't get the point. If someone's code breaks because he
> messed with my implementation code, then *he* is responsible. The
> contract is very clear : "warranty void if unsealed".
>
>
>
> > In principle it could break just as much code as if
> > he didn't even bother flagging them with a leading underscore, which is
> > probably why many people don't even bother with _names.
>
> > In other words, if you make it easy for people to mess with your
> > internals, if you have a culture that allows and even encourages them to
> > mess with your internals, then you don't have internals. Everything is de
> > facto public.
>
> Now that you've exposed your opinions, let's face reality (I mean,
> *facts*): Python developpers very rarely mess with implementation,
> usually do so for very good (and documented) reasons, and from what I've
> seen usually tend to get in touch with the library author to explain
> their case and find a better solution.
>
> Funny enough, it looks that the more you treat programmers as
> responsible, normally intelligent adult person, the more they tend to
> behave as such. And the other way around, too.
>
> Now, you comprehensively exposed your personnal distaste for Python's
> and more generally OSS philosophy. So I can only - as I already did way
> before in this thread - wonder *why* are you using Python ?
>
> I mean, is it because your bosses forces you to do so ? If yes, then,
> I'm truly sorry for you - I sometimes have to work with languages I
> really dislike so I can feel your pain (but 

Re: what gives with

[Darren Dale]

On Jan 22, 10:07 pm, Benjamin Peterson  wrote:
> Darren Dale  gmail.com> writes:
>
> > Judging fromhttp://bugs.python.org/issue2400, this issue
> > was fixed back in May 2008, but it is still present with python-2.5.4,
> > which was released in December. Why wont python-2.5 allow this kind of
> > import?
>
> Allowing that would be a new feature which is disallowed in bug fix releases
> like 2.5.4.

I was talking about the behavior after doing "from __future__ import
absolute_import". I've been developing on python-2.6 using
absolute_import for weeks, knowing that I could do "from __future__
import absolute import" on python-2.5. Now when I try to use
python-2.5 I cant import my package. What is the point of providing
absolute_import in __future__ if the api is completely different than
the implementation in future python versions? Its bizarre.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 22, 9:22 pm, "Russ P."  wrote:

> code. You can play around with the internals all you want in your own
> little world, but as when you are working with a team, you need to
> adhere to the interfaces they define (if any).

The word "as" should not be there:

... but when you are working with a team, ...

Sorry, but that was bothering me. I sure wish these posts could be
edited after they are submitted.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Does Python really follow its philosophy of "Readability counts"?

[Antoon Pardon]

On 2009-01-16, Luis Zarrabeitia  wrote:
>
> Quoting "Russ P." :
>
>> On Jan 15, 12:21 pm, Bruno Desthuilliers
>>  wrote:
>> 
>> > Once again, the important point is that there's a *clear* distinction
>> > between interface and implementation, and that you *shouldn't* mess with
>> > implementation.
>> 
>> If you "*shouldn't* mess with the implementation", then what is wrong
>> with enforcing that "shouldn't" in the language itself?
>
> Because, as a library user, it should be my power to chose when and how I
> _should_ mess with the implementation, not the compiler, and definitely not 
> you.

Why should it be in your power? By messing with the implementation of a library
you risk the correctness of the code of all participant coders in that project.
I not that sure it should be your power to chose when and how to do that.

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

Executing WinXP commands using os module

[pranav]

Greetings,
I am writing a code to perform operations like checkout, check-in and
others for SS. (SS is the command line utility for Visual SafeSource,
VSS). I am familiar with all the commands for this purpose. I know
li'l python also.
What i want to learn is how do i use the command line arguments in os
(or any other call that will fulfill my purpose). I can use popen to
create a command prompt. But i need to use commands like

ss checkout $\projectName\file -Yusername,password -c'Test comment'

Please help me.

Thanks in advance,
Regards

Pranav Prakash

http://codecontrol.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Executing WinXP commands using os module

[Chris Rebert]

On Fri, Jan 23, 2009 at 3:50 AM, pranav  wrote:
> Greetings,
> I am writing a code to perform operations like checkout, check-in and
> others for SS. (SS is the command line utility for Visual SafeSource,
> VSS). I am familiar with all the commands for this purpose. I know
> li'l python also.
> What i want to learn is how do i use the command line arguments in os
> (or any other call that will fulfill my purpose). I can use popen to
> create a command prompt. But i need to use commands like
>
> ss checkout $\projectName\file -Yusername,password -c'Test comment'

You want the `subprocess` module. See
http://docs.python.org/library/subprocess.html

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Executing WinXP commands using os module

[pranav]

On Jan 23, 5:05 pm, Chris Rebert  wrote:
> On Fri, Jan 23, 2009 at 3:50 AM, pranav  wrote:
> > Greetings,
> > I am writing a code to perform operations like checkout, check-in and
> > others for SS. (SS is the command line utility for Visual SafeSource,
> > VSS). I am familiar with all the commands for this purpose. I know
> > li'l python also.
> > What i want to learn is how do i use the command line arguments in os
> > (or any other call that will fulfill my purpose). I can use popen to
> > create a command prompt. But i need to use commands like
>
> > ss checkout $\projectName\file -Yusername,password -c'Test comment'
>
> You want the `subprocess` module. 
> Seehttp://docs.python.org/library/subprocess.html
>
> Cheers,
> Chris
>
> --
> Follow the path of the Iguana...http://rebertia.com

Thanks, will try it
--
http://mail.python.org/mailman/listinfo/python-list

Re: Need script to download file from a server using python script

[Chris Rebert]

On Fri, Jan 23, 2009 at 3:00 AM, Murali Murali
 wrote:
> Hi,
>
> I am fairly new to python and i am looking for a python script to download
> file(latest build) from the server. But, the build name changes daily. For
> Ex:  today the build URL will be "http://mybuilds/myapp_1234.exe"; and
> tomorrow it will be  "http://myserver/mybuilds/myapp_3456.exe";.  So i need a
> script which downloads the latest build without any knowledge of build
> number.
>
>  Can anyone  help me?
>
> Advance thanks,
>
> This is my start:

Not directly related to your main question, but you might want to use
urllib.urlretrieve() rather than httplib for the downloading of the
file as the interface is a good bit simpler. See
http://docs.python.org/library/urllib.html#urllib.urlretrieve for the
docs on it.

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Counter Class -- Bag/Multiset

[Giovanni Bajo]

On 1/23/2009 2:49 AM, Chris Rebert wrote:

On Thu, Jan 22, 2009 at 5:41 PM, Giovanni Bajo  wrote:

On Thu, 22 Jan 2009 10:11:37 -0800, Raymond Hettinger wrote:


The collections module in Python 2.7 and Python 3.1 has gotten a new
Counter class that works like bags and multisets in other languages.

I've adapted it for Python2.5/2.6 so people can start using it right
away:
  http://docs.python.org/dev/library/collections.html#counter-objects

Here's a link to the docs for the new class:
  http://code.activestate.com/recipes/576611/

Hi Raymond,

* I'm not a native speaker, but why use the word "Counter"? A "counter"
to my ear sounds like a number that is increased each time an event
occurs; the website counter, eg, comes to mind. I can understanda its
meaning probably stretches to "an object that counts", but I really can't
think of it as a group of object, or a container of object. Moreover, I
find it a much more useful abstraction the idea of a "multi-set" (that
is, a set where elements can appear with multiple cardinality), rather
than stressing the concept of "counting" how many times each element
appears in the set.

* I find it *very* confusing c.items() vs c.elements(). Items and
elements are synonymous (again, in my understanding of English).


I concur and would like to say additionally that having Counter's
len() be the number of *unique* items as opposed to just the number of
items seems a bit counterintuitive.


In fact, I think that it makes sense when you're stressing the fact that 
it's just a dictionary of objects and their counters (which the name 
"Counter" in fact stresses).


And my main objection is exactly this: a multiset is a differnt abstract 
data structure (which is probably worth its own ABC in Python); the fact 
that can be implemented through a mapping of objects and counters is 
just its concrete implementation. This was perfectly represented by 
Raymond's previous bag class, that was *using* a dictionary instead of 
*being* a dictionary.

--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Executing WinXP commands using os module

[M�ta-MCI (MVP)]

Hi!

Try:
os.system("""start "" cmd /css checkout 
$\projectName\file -Yusername,password -c'Test comment' """)


(not tested ; it's directly from my memory)


@-salutations
--
Michel Claveau


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

Re: A different kind of interface

[Eduardo Lenz]

On Thursday 22 January 2009 08:13:49 Vic Kelson wrote:
> How about IDLE? It's a nice tool for the Python programmer. I've tried
> lots of IDEs, but when it comes down to it, on small-to-medium jobs I
> am be very productive indeed using IDLE...
>
> --v
> --
> http://mail.python.org/mailman/listinfo/python-list

How about Eric ?


-- 

 Eduardo Lenz Cardoso
 Dr.  Eng.
 Associate Professor
 
 State University of Santa Catarina
 Department of Mechanical Engineering
 89223-100 - Joinville-SC - Brasil

 Tel: +55 47 4009-7971 - Fax: +55 47 4009-7940
 E-mail: l...@joinville.udesc.br  
 -

-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.

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

Re: Securing a database

[Bryan Olson]

kt83...@gmail.com wrote:

Anyways, if we can make it real hard for them to analyze also, I think
we are in the good - esp since the clients are not extremely rich
enough to go for professional analyzers --


Sounds like you have the "digital rights management" (DRM) problem. As 
Diez pointed out, there is no robust software solution. Nevertheless, 
many clever people have worked each side, so there's now something of a 
body of practice and experience.



What is the skype method? The code is not huge - less than 20K LOC so,
code encryption looks somewhat OK - would you be able to direct me to
any hints on this?


I don't think Skype has much to offer here. They're not focused on 
selling DRM technology; they sell communication services. Third parties 
can write applications on top of those services, which can be protected 
by Skype's DRM. (If I'm wrong on that, someone please correct me.)


Diez's noted Skype's use of a layered approach, but there's nothing 
special about the notion of layered code encryption in DRM software. 
It's been used multiple times, broken multiple times, and patented 
multiple times.



One another option that I was thinking was to automatically generate
the password for the database - re-encrypt every 1 hr - and store the
password inside the code itself. Is that possible in Python? i.e.
changing the code itself.


Possible it is. Effective it is almost certainly not, at least not 
without a whopping bunch of other techniques going vastly beyond that 
description.


Look up DRM technology companies, such as CloakWare, Macrovision, and 
Cryptography Research.


If you have a modest number of customers, hardware solutions and/or 
strict contractual commitments might offer practical solutions.



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

Securing a database

[kt83313]

My company provides some services online, which now they are planning
to make it offline and sell to customers who can use it in their
networks.

One of our major moneywinners is some data which is stored in a
database. Now, this data inside the database was obtained after paying
through the nose - so the company does not want to disclose the data
in the DB to the outside world - not to mention the lawsuits which the
original providers of data will start which will sink the company if
the data goes out.

Now, the code is in Python - and we have a big problem. How to secure
the data in DB? One idea was to encrypt it and store the password in
the code. I dont believe security through obscurity - and python code
can easily be reverse-engineered too - right?

Is it even possible to secure a data in this case?

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

Dynamic methods and lambda functions

[unineuro]

Hi,
I want to add some properties dynamically to a class, and then add the
corresponding getter methods. Something resulting in this:

class Person:
def Getname(self):
return self.__name

def Getage(self):
return self.__age

I've implemented the next code, creating the properties from a list:

props = [
("name", "peter"),
("age", 31),
("wife", "mary")
]

class Person:
def __init__(self):
for prop in props:
setattr(self, "__" + prop[0], prop[1])
setattr(Person, "Get" + prop[0], lambda self: getattr
(self, "__" + prop[0]))


if __name__ == "__main__":

person = Person()

print person.__name
print person.__age
print person.__wife
print
print person.Getname()
print person.Getage()
print person.Getwife()


And the resulting execution of this program is:

peter
31
mary

mary
mary
mary

The attributes are right, but the getter are not working. The problem
is that the lambda function always execute the last parameter passed
for all instances of the methods. How could it be done the right way?

Thanks in advance
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to write a simple shell loop in python?

[Dietrich Bollmann]

[Sorry for top posting - I had a HD problem and lost the original mails]

Hi Saul, Steve, Ben, James, Scott David and James!

Thank you all very much for your help! I finally got rid of the extra
space and also understood why the space was printed :)

After using Steve's 'input = raw_input("$ ")' solution for a while -
it does exactly what I want and is the fastest fix also - I wanted
command line editing and switched to the cmd.Cmd module.

Special thanks to James Mills for writing his own solution!

I would like to use your component - but cmd.Cmd is just perfect
for my purpose and I want to run my program without the need to
install any new module (I am writing the program for somebody else).

I got interested in circuits though - but the homepage
http://trac.softcircuit.com.au/circuits/ (currently?) seems not to be
available.

Thanks again for your answers :)

Dietrich


PS: There is a little tutorial for cmd.Cmd here:

  - http://www.doughellmann.com/PyMOTW/cmd/index.html

The documentation is here:

  - http://docs.python.org/library/cmd.html

(got it from Ben Finney's post) 


On Wed, 2009-01-21 at 08:37 -0500, Steve Holden wrote:
> Dietrich Bollmann wrote:
> > Hi,
> > 
> > I am trying to write a simple shell loop in Python.
> > 
> > My simple approach works fine - but the first output line after entering
> > something is always indented by one blank.  
> > 
> > Is there any logic explanation for this?  
> > How can I get rid of the blank?
> > Is there a smarter way to write a simple shell loop which would work
> > better?
> > 
> > Thanks, Dietrich
> > 
> > 
> > Here my approach:
> > 
> > $ python
> > Python 2.5.2 (r252:60911, Jan  4 2009, 17:40:26) 
> > [GCC 4.3.2] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
>  import sys
>  while (1):
> > ... print "$ ",
> > ... input = sys.stdin.readline()
> Just replace the lines above with
> 
> input = raw_input("$ ")
> 
> and you'll be fine. The "," in the print statement causes the
> interpreter to set a flag to emit a space before the next output unless
> it has just printed a newline. The "newline", of course, is provided by
> the input, so the next print emits a space since it *hasn't* just
> emitted a newline.
> 
> regards
>  Steve
> 
> > ... input = input.strip()
> > ... print input
> > ... print input
> > ... print input
> > ... 
> > $ one
> >  one
> > one
> > one
> > $ two
> >  two
> > two
> > two
> > $ three
> >  three
> > three
> > three
> > $ 
> > Traceback (most recent call last):
> >   File "", line 3, in 
> > KeyboardInterrupt
> > 
> > 
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> > 
> 
> 

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

Re: Does Python really follow its philosophy of "Readability counts"?

[Steven D'Aprano]

On Fri, 23 Jan 2009 10:54:53 +0100, Bruno Desthuilliers wrote:

>> In context, I had just mentioned that lists' internals were
>> inaccessible from Python code. I neglected to give an example at the
>> time, but a good example is the current length of the list. Consider
>> the experience of Microsoft and Apple.
> 
> Yes, two great examples of freedom champions.

What does that little dig at Microsoft and Apple have to do with what 
we're discussing? I dare say Linux has private internals too. Let's see 
if we can find some in 30 seconds of googling.

http://forum.soft32.com/linux2/Bug-406747-linux-kernel-headers-private-
symbols-u16-u32-asm-ftopict67443.html

http://groups.google.com/group/linux.kernel/browse_thread/thread/
a08fd6423204e918

Those fascists! Private data in the kernel!!! Why can't my userland app 
mess with the kernel's private data??? It's so unfair!!!



>> No matter how often
>> they tell people not to mess with the internals, people do it anyway,
>> and always believe that their reason is a good reason.
> 
> And who are *you* to pronounce any judgement about that ?

Did I pronounce any judgement?


...
>> [Any] library writer must assume
>> that if he changes his so-called "private" attributes, he will break
>> other people's code.
> 
> You still don't get the point. If someone's code breaks because he
> messed with my implementation code, then *he* is responsible. The
> contract is very clear : "warranty void if unsealed".

You've built something full of user serviceable parts. You've insisted, 
publicly and loudly, that the ability to modify those parts is absolutely 
essential, you've rejected every effort to lock down those internals, and 
then when somebody does exactly what you encourage, you suddenly turn on 
them and say they're on their own.

That's pretty irresponsible behaviour. 

As an aside, Apple and Microsoft have opposite approaches to dealing with 
this problem. Apple hangs the developer out to dry, which is why there 
are so few developers who make Mac software, while Microsoft goes to (or 
at least did) heroic efforts to protect developers from their mistakes, 
which is why the Windows internals is a dog's breakfast but there are 
more Windows developers named "Steve" then there are Mac developers in 
total. (BTW, I'm not one of them.)

http://www.joelonsoftware.com/articles/APIWar.html



> Now that you've exposed your opinions, let's face reality (I mean,
> *facts*): Python developpers very rarely mess with implementation,
> usually do so for very good (and documented) reasons, and from what I've
> seen usually tend to get in touch with the library author to explain
> their case and find a better solution.

Facts, are they? Care to provide some reputable sources for these facts?

 
> Funny enough, it looks that the more you treat programmers as
> responsible, normally intelligent adult person, the more they tend to
> behave as such. And the other way around, too.

You're the one who repeatedly declared that programmers who modified 
internals were cretins who should be fired. I never said such a thing -- 
in fact, I defended them.


> Now, you comprehensively exposed your personnal distaste for Python's
> and more generally OSS philosophy. 

Really? I did? Fancy that.


> So I can only - as I already did way
> before in this thread - wonder *why* are you using Python ?

Ah yes, the old "if you're not 100% for us, you must be 100% against us" 
argument. Anyone who thinks that there are costs as well as benefits to 
dynamic programming must be a freedom-hater, and probably kicks puppies 
too.

 
> I mean, is it because your bosses forces you to do so ? 

Yeah, my mean old boss forces me to write Python scripts in my spare 
time, he forces me to spend my personal time on comp.lang.python, he 
forces me to write things like:

[quote]
Oh yes, it is liberating to say "I don't care if my method crashes 
(raises an exception), it's the caller's fault for messing with my class' 
internals, and he can deal with it". I'm not being sarcastic by the way. 
It really is liberating not to have to deal with unexpected input or 
broken pre-conditions. Just let the caller deal with it!
[end quote]

What a mean old boss!


> If yes, then,
> I'm truly sorry for you - I sometimes have to work with languages I
> really dislike so I can feel your pain (but OTHO, I never complained on
> these languages newsgroups about how wrong they were nor how they should
> IMHO be).

If people hadn't complained about missing features/misdesigns, would 
Python have:

generator expressions
print as a function
booleans
nested scopes
None as a keyword
ABCs
closures

to name just a few?

I am curious though... you've made a few comments that suggest that your 
in favour of more freedom, rather than less: you've made a disparaging 
comment about Microsoft and Apple, you apparently think highly of Open 
Source software, and more. Does this freedom extend to people who have 
criticisms -- even mild criticisms -

Re: Does Python really follow its philosophy of "Readability counts"?

[Mark Wooding]

Steven D'Aprano  writes:

> On Thu, 22 Jan 2009 19:10:05 +, Mark Wooding wrote:
>> Well, your claim /was/ just wrong.  But if you want to play dumb: the
>> interface is what's documented as being the interface.
>
> But you miss my point.

Evidently.

> We're told Python doesn't have private attributes. We're told that
> we're allowed to "mess with the internals", we're *encouraged* to do
> so: Python gives you the freedom to do so, and any suggestion that
> freedom might be reduced even a tiny bit is fought passionately.

Your deduction skills are faulty.

  * Python gives us the freedom to do so, and we fight to protect that
freedom -- yes.

  * But interpreting that as encouragement is wrong.  It's permission,
not encouragement.  If you don't want to, that's fine, and we won't
think less of you.

Many things are possible which aren't, as a general rule, good ideas.
Misinterpreting permission as encouragement will lead you to doing many
stupid things.

> When people ask how to implement private attributes, they're often
> told not to bother even using single-underscore names. When it is
> suggested that Python should become stricter, with enforced data
> hiding, the objections come thick and fast: people vehemently say that
> they like Python just the way it is, that they want the ability to
> mess with the internals.



> You even argued that you disliked data structures implemented in C and
> preferred those written in Python because you have more ability to
> mess with the private attributes. In context, I had just mentioned
> that lists' internals were inaccessible from Python code. I neglected
> to give an example at the time, but a good example is the current
> length of the list.

Umm... I'm pretty sure that that's available via the `len' function,
which is tied to list.__len__ (via the magic C-implemented-type mangler,
in C).  Though it's read-only -- and this is a shame, 'cos it'd be nice
to be able to adjust the length of a list in ways which are more
convenient than

  * deleting or assigning to a trailing slice, or
  * augmenting or assigning to a trailing zero-width slice

(Perl has supported assigning to $#ARRAY for a long time.  Maybe that's
a good argument against it.)

> Consider the experience of Microsoft and Apple. No matter how often
> they tell people not to mess with the internals, people do it anyway,
> and always believe that their reason is a good reason.

And Microsoft and Apple can either bend over backwards to preserve
compatibility anyway (which effectively rewards the misbehaviour) or
change the internals.  I'd prefer that they did the latter.

There are times when messing with internals is the only way to get
things done; but there's a price to be paid for doing that, and the
price is compatibility.  The internals will change in later versions,
and your code will break, in subtle and complex ways.  It's not always
an easy decision to make -- but I'm glad it's me that gets to decide,
and not some random who neither knows nor cares much about the problem
I'm trying to solve.

It's also important to bear in mind that programs' lifetimes vary.  Some
programs are expected to live for years; some programs only for a week
or so; and some for just long enough to be typed and executed once
(e.g., at the interactive prompt).  That Python is useful for all these
kinds of program lifetimes is testament to its designers' skill.
Programmers can, and should!, make different tradeoffs depending on the
expected lifetime of the program they're writing. 

If I type some hacky thing at ipython, I know it's going to be executed
there and then, and if the implementation changes tomorrow, I just don't
care.

If I'm writing a thing to solve an immediate problem, I won't need it
much past next week, and I'll still probably get away with any awful
hacking -- but there's a chance I might reuse the program in a year or
so, so I ought to put a comment in warning the reader of a possible
bitrot site.

If I'm writing a thing that's meant to last for years, I need to plan
accordingly, and it's probably no appropriate to hack with internals
without a very good reason.

Making these kinds of decisions isn't easy.  It requires experience,
subtle knowledge of how the systems one's using work, and occasionally a
little low cunning.  And sometimes one screws up.

> And Python culture encourages that behaviour (albeit the consequences
> are milder: no buffer overflows or core dumps).
>
> Add to that the culture of Open Source that encourages reading the source 
> code. You don't need to buy a book called "Undocumented Tips and Tricks 
> for Python" to discover the internals. You just need to read the source 
> code.

Indeed.  Very useful.

Example: for my cryptographic library bindings, I needed to be able to
convert between Python's `long's and my library's `mp's.  I have a
choice between doing it very slowly (using shift and masking operators
on the `long') or fast (by including Python/longintr

Re: Relax Syntax for Augmented Arithmetic?

[Mark Wooding]

a...@pythoncraft.com (Aahz) writes:

> Actually, that is not correct. 

You're right, evidently.

[snip]

 a
> (1, ['foo', 'bar'], 'xyzzy')
 a[1] += ['spam']
> Traceback (most recent call last):
>   File "", line 1, in ?
> TypeError: object doesn't support item assignment
 a
> (1, ['foo', 'bar', 'spam'], 'xyzzy')

Ugh!

-- [mdw]
--
http://mail.python.org/mailman/listinfo/python-list

Re: Relax Syntax for Augmented Arithmetic?

[Steve Holden]

Aahz wrote:
> In article <87hc3un1vn.fsf@metalzone.distorted.org.uk>,
> Mark Wooding   wrote:
>>  * Python augmented-assignment (`+=', for example) is inconsistent.
>>Depending on what type of object the left-hand side evaluates to, it
>>may /either/ mutate that object, /or/ assign a new value to the
>>expression.
> 
> Actually, that is not correct.  The augmented assignment always binds a
> new value to the name; the gotcha is that with a mutable object, the
> object returns ``self`` from the augmented assignment method rather than
> creating a new object and returning that.  IOW, the smarts are always
> with the object, not with the augmented assignment bytecode.
> 
> The best way to illustrate this:
> 
 a = (1, ['foo'], 'xyzzy')
 a[1].append('bar')
 a
> (1, ['foo', 'bar'], 'xyzzy')
 a[1] = 9
> Traceback (most recent call last):
>   File "", line 1, in ?
> TypeError: object doesn't support item assignment
 a
> (1, ['foo', 'bar'], 'xyzzy')
 a[1] += ['spam']
> Traceback (most recent call last):
>   File "", line 1, in ?
> TypeError: object doesn't support item assignment
 a
> (1, ['foo', 'bar', 'spam'], 'xyzzy')

I understand what you are saying, but if the id() associated with a name
doesn't change after augmented assignment it seems a little wrong-headed
to argue that "the augmented assignment always binds a new value to the
name".

What you are actually saying is that it's up to the method that
implements the augmented assignment whether the same (mutated) object or
a different one is returned, right? And that the left-hand side of the
assignment is always bound to the result of that method.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

DrPython and py2exe

[mk]

Hello,

I'm trying to get DrPython to edit .py file on double-click on Windows.

Sure, I can use trivial .bat file to open DrPython with file as 
argument. But the irritating thing is that DOS window stays open until 
particular instance of DrPython isn't closed.


py2exe to rescue. I have modified DrPython's setup.py:


setup(name='drpython.exe',
version=MY_VER,
description=description[0],
long_description=description[1],
classifiers = filter(None, classifiers.split('\n')),
author=AUTHOR,
author_email=AUTHOR_EMAIL,
url=URL,
platforms = "any",
license = 'GPL',
packages=[ MY_NAME ],
package_dir={ MY_NAME : '.' },
package_data={ MY_NAME : DATA },
scripts=['postinst.py'],
windows=['drpython.py'],
)

py2exe builds application, but when I start it, I get this in the log file:

Traceback (most recent call last):
  File "drpython.py", line 46, in 
  File "wxversion.pyc", line 152, in select
wxversion.VersionError: Requested version of wxPython not found

I'm guessing this is because py2exe doesn't package wxPython together 
with the app.


Since this topic is interesting for me anyway (i.e. how to transform 
wxPython app using py2exe into Windows executable), would someone please 
reply on how to do it?


Thanks,
mk


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

Re: Does Python really follow its philosophy of "Readability counts"?

[Bruno Desthuilliers]

Russ P. a écrit :
(snip)

I am curious about something. Have you ever needed to access a
"private" attribute (i.e., one named with a leading underscore) in
Python code that you did not have the source code for? For that
matter, have you ever even used a library written in Python without
having access to the source code?


No to both.


As I said before, if you have the source code you can always change
private attributes to public in a pinch if the language enforces
encapsulation.


And then have to maintain a fork. No, thanks.


But if you are working on a team project, you can't
change the code that another member of a team checks in.


Why on earth couldn't I change the code of another member of my team if 
that code needs changes ? The code is the whole team's ownership.


Now and FWIW,  in this case (our own code), I just don't need to "mess 
with internals" - I just just change what needs to be changed.



That is how
enforced data hiding helps teams of developers manage interfaces.


I totally fails to find any evidence of this assertion in the above 
"demonstration".



The
bigger the team and the bigger the project, the more it helps.


Your opinion.


Mr. D'Aprano gave an excellent example of a large banking program.
Without enforced encapsulation, anyone on the development team has
access to the entire program and could potentially sneak in fraudulent
code much more easily than if encapsulation were enforced by the
language.


My my my. If you don't trust your programmers, then indeed, don't use 
Python. What can I say (and what do I care ?). But once again, relying 
on the language's access restriction to manage *security* is, well, kind 
of funny, you know ?



I am certainly not saying that Python is useless without enforced data
hiding. It is obviously very useful for a wide range of applications
and domains already. I am only saying that it's usefulness could be
enhanced if enforced encapsulation can be added


You might have a chance to sell this to a clueless pointy haired boss - 
I mean,  that enforced access restriction will make Python more suitable 
for some big enterprizey project. As far as I'm concerned, I'm not 
buying it.



without somehow
comromising the language.


Then just forget it.


I don't know enough about the inner workings
of the Python interpreter to know if that is the case or not (I am an
aeronautical engineer), but the objections I've seen so far on this
thread have not impressed me.


I've not seen much technical objections - but anyway: learn (I mean, 
*really* learn) how Python's object model works, and you'll perhaps find 
out why this would break the whole thing.

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

Re: Why GIL? (was Re: what's the point of rpython?)

[Steve Holden]

Paul Rubin wrote:
> Carl Banks  writes:
>> 3. If you are going to use the low-level API on a mutable object, or
>> are going to access the object structure directly, you need to acquire
>> the object's mutex. Macros such as Py_LOCK(), Py_LOCK2(), Py_UNLOCK()
>> would be provided.
> 
> You mean every time you access a list or dictionary or class instance,
> you have to acquire a mutex?  That sounds like a horrible slowdown.

Indeed it would, but hey, let's not let that stop us repeating the
thinking that's gone into CPython over the last fifteen years. "Those
who cannot remember the past are condemned to repeat it".

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: Dynamic methods and lambda functions

[Steven D'Aprano]

On Fri, 23 Jan 2009 04:28:33 -0800, unineuro wrote:

> Hi,
> I want to add some properties dynamically to a class, and then add the
> corresponding getter methods. Something resulting in this:
> 
> class Person:
> def Getname(self):
> return self.__name
> 
> def Getage(self):
> return self.__age

(1) Properties don't work with classic classes. If you have setters to go 
with these getters, and you're using Python 2.x, your code will fail to 
work the way you think it should.

(2) Getters and setters are generally discouraged in Python unless you 
really need them. If all you are doing is getting/setting an attribute, 
then you're just wasting time. (Or if this is a learning exercise.)


> I've implemented the next code, creating the properties from a list:
> 
> props = [
> ("name", "peter"),
> ("age", 31),
> ("wife", "mary")
> ]
> 
> class Person:
> def __init__(self):
> for prop in props:
> setattr(self, "__" + prop[0], prop[1]) 
> setattr(Person, "Get" + prop[0], 
> lambda self: getattr(self, "__" + prop[0]))

Seems awfully complicated. I'm not even sure it will work, due to 
Python's name-mangling. And let's not even talk about how broken it is to 
get your input to a class initializer from a global variable! What 
happens when you need a second instance?


> if __name__ == "__main__":
> 
> person = Person()
> 
> print person.__name
> print person.__age
> print person.__wife
> print
> print person.Getname()
> print person.Getage()
> print person.Getwife()
> 
> 
> And the resulting execution of this program is:
> 
> peter
> 31
> mary
> 
> mary
> mary
> mary
> 
> The attributes are right, but the getter are not working. The problem is
> that the lambda function always execute the last parameter passed for
> all instances of the methods. How could it be done the right way?


class Person(object):
def __init__(self, name, age, wife):
self.name = name
self.age = age
self.wife = wife

props = {"name": "peter", "age": 31, "wife": "mary"}

if __name__ == "__main__":
person = Person(**props)
print person.name
print person.age
print person.wife


If you really want getters, for whatever reason, then do it like this:

class Person(object):
def __init__(self, name, age, wife):
self._name = name
self._age = age
self._wife = wife


for prop in ('name', 'age', 'wife'):
setattr(Person, prop, property( lambda self, prop=prop: 
getattr(self, '_'+prop) ))



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

Re: Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 23, 4:30 am, Mark Wooding  wrote:

> Suppose that you write a Python library module and release it.  I find
> that it's /almost/ the right thing for some program of mine, but it
> doesn't quite work properly unless I hack about like so... perfect!  I'm
> a happy bunny; you've gained a user (maybe that's a good thing, maybe it
> isn't!).  Now, I've hacked about in your module's internal stuff: how
> has this affected you?  Answer: not at all; you probably didn't feel a
> thing.  You release a new version with improved internal structure and
> my program breaks: how has this affected you?  Answer: still not at all.
> How did it affect me?  Quite a bit, but then again, I knew what I was
> getting into.  I gambled and lost; oh, well, that happens sometimes.

Was this library module released in source form?

If so, then why would you care that it has enforced access
restrictions? You can just take them out, then do whatever you would
have done had they not been there to start with. I don't see how that
is any more work than figuring out what internals you need to access.
Either way you need to read and understand the code.

Wait ... it wasn't released in source form? Then how would you even
know what internals you need to access? And why would you use
something that goes against your philosophy of openness anyway?
--
http://mail.python.org/mailman/listinfo/python-list

Re: what gives with

[Steve Holden]

Darren Dale wrote:
> On Jan 22, 10:07 pm, Benjamin Peterson  wrote:
>> Darren Dale  gmail.com> writes:
>>
>>> Judging fromhttp://bugs.python.org/issue2400, this issue
>>> was fixed back in May 2008, but it is still present with python-2.5.4,
>>> which was released in December. Why wont python-2.5 allow this kind of
>>> import?
>> Allowing that would be a new feature which is disallowed in bug fix releases
>> like 2.5.4.
> 
> I was talking about the behavior after doing "from __future__ import
> absolute_import". I've been developing on python-2.6 using
> absolute_import for weeks, knowing that I could do "from __future__
> import absolute import" on python-2.5. Now when I try to use
> python-2.5 I cant import my package. What is the point of providing
> absolute_import in __future__ if the api is completely different than
> the implementation in future python versions? Its bizarre.

I guess it must specify some alternate future ...

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: Does Python really follow its philosophy of "Readability counts"?

[Steven D'Aprano]

On Fri, 23 Jan 2009 13:57:52 +0100, Bruno Desthuilliers wrote:

>> As I said before, if you have the source code you can always change
>> private attributes to public in a pinch if the language enforces
>> encapsulation.
> 
> And then have to maintain a fork. No, thanks.

If you're messing with the internals, you have to do this anyway. As soon 
as the internals change, your monkey-patched solution falls apart.


>> But if you are working on a team project, you can't change the code
>> that another member of a team checks in.
> 
> Why on earth couldn't I change the code of another member of my team if
> that code needs changes ? The code is the whole team's ownership.

That's a model that works well when you have a small team of, say, a 
dozen people. It's not a model that works when you have hundreds of 
developers working on the project. The last thing I want in my projects 
is cowboys who ride all over other people's code, changing internals of 
parts they barely know at the drop of a hat, causing who knows what side-
effects.

But anyway, this is a red-herring. Data hiding isn't really about 
managing the development process, it's about ensuring that when you and 
Fred are using Barney's OrderedDict class in your code, Barney is free to 
change his the implementation without your code suddenly failing. It's 
also to ensure that any changes you make at runtime to the class don't 
suddenly make Fred's code break.


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

Re: Adding a field to a 'foreign' object from the outside

[Steve Holden]

atleta wrote:
>   Hi,
> 
> I'm working with a callback API (a DBus one) and I'd need to store
> some state between the calls somewhere. I know that it's possible to
> extend an object with fields after creation, so I could just store my
> data in the session object that is passed in with every callback.
> However it stinks from OO perspective, at least to me. The other
> option, something that I'd do in java for example, would be to set up
> a mapping (a dict) using the session object as a key. Which one is the
> 'pythonic' way? Do you use the first method (modifying an object that
> you don't even control the source of) or do you write a bit more code
> and go with the second one?
> 
Or there's a third option. Write a class that implements a __call__()
method, and use an instance of that class as your callback. Then the
data can be stored as the callback object's private instance data.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: seeking to improve Python skills

[Jean-Paul Calderone]

On Fri, 23 Jan 2009 12:17:41 +0100, mk  wrote:

Hello everyone,

I wrote the following program mainly for educational purpose of improving my 
Python programming skills -- would Pythonistas here please look at it and 
point out areas that could use improvement?


This thing analyzes the stored load average record file, calculates simple 
moving average and produces Gnuplot program to plot the thing.


Constructive criticism is welcome.

#!/usr/bin/python

import re
import sys
import tempfile
import subprocess
import os

class MovingAvg(object):


You should have a docstring here.  It should describe the overall purpose
of the MovingAvg class and it should probably document the meaning of each
attribute instances of the class have.


def __init__(self, fname):
try:
self.fo = open(fname)
except IOError, e:
print "Problem with opening file:", e
sys.exit(4)


This isn't very good.  Your MovingAvg class is otherwise relatively general-
purpose and re-usable, but this makes it unusable instead.  You shouldn't
use print to report errors in general code and you shouldn't turn specific
exceptions into SystemExit.  This kind of whole-program error handling
belongs in a different layer if your code.  Your moving average code should
just focus on computing a moving average.

Also, filenames are rather clunky.  Another improvement here would be to
pass in a file object which the calling code has already opened.  Or, better
still, just pass in an iterator of data.  Do the file handling and the
parsing in a different layer.  Then you'll be able to re-use your moving
average class with data files in a different format - all you'll have to do
is write another parser for the new format.


self.reslist = []
self.smalist = []
self.maxval = 0

def extrfromfile(self):


There should be a docstring here describing what this method does.


vre = re.compile("(\d+-\d+-\d+) (\d\d:\d\d) (\d+\.\d+)")
for line in self.fo:
res = vre.search(line)
if res:
self.reslist.append({'day':res.group(1),\
'time':res.group(2),\
'val':float(res.group(3))})


The trailing backslashes on the previous lines are superfluous.  The code
is just as valid without them.


def calc_sma(self, smalen=4):


Another missing docstring.  Make sure you also document the meaning of the
parameter the method accepts.


if smalen == 0:
raise AssertionError, "Moving Average sample length 
cannot be 0"

if not isinstance(smalen, int):
raise AssertionError, "Moving Average sample length 
has to be integer"


The conventional way to write the previous lines would be:

   assert smallen != 0, "Moving Average sample length cannot be 0"
   assert isinstance(smallen, int), "Moving Average Sample length has to be 
integer"

However, I would just leave them out.  If you document the meaning of the
smalen parameter, then callers will know it can't be 0 and must be an int.


total = 0


Superfluous line above.


total = sum( [ x['val'] for x in self.reslist[0:smalen] ] )
sma = total / smalen
smaidx = int(smalen/2)
self.smalist.append((self.reslist[0]['day'],\
self.reslist[0]['time'],\
self.reslist[0]['val'],\
self.reslist[0]['val']))


Superfluous backslashes again.


for i in range(smalen, len(self.reslist)):
curval = self.reslist[i]['val']
self.maxval = max(self.maxval, curval)
total += curval
total -= self.reslist[i - smalen]['val']
sma = total / smalen
smaidx += 1
self.smalist.append((self.reslist[smaidx]['day'],\
self.reslist[smaidx]['time'],\
self.reslist[smaidx]['val'],\
sma))


And again.



def return_results(self):


Missing docstring.  


return (self.reslist, self.smalist, self.maxval)


Generally, I wonder whether MovingAvg should just be a function rather
than a class.  The only place it maintains state it does so confusingly.
I would just make the input data a parameter to calc_sma and have it return
the results it computes.  Drop the rest of the class and make calc_sma a free
function.


class GnuplotWrapper(object):


Docstring.

def __init__(self, smalist, maxval, outfname = "calc.png", 
graphlen=640, graphheight=480, gnuplot = '/usr/bin/gnuplot'):


Again, the comment about filenames

Re: DrPython and py2exe

[imageguy]

But the irritating thing is that DOS window stays open until
> particular instance of DrPython isn't closed.


This is a relatively simple fix I think.
You can change the extension of the drPython.py to drpython.pyw and
the python windows
executable (pythonw.exe) will launch the program instead of the
traditional
executable (python.exe).


> Traceback (most recent call last):
>    File "drpython.py", line 46, in 
>    File "wxversion.pyc", line 152, in select
> wxversion.VersionError: Requested version of wxPython not found

check out the wiki on 'multi version installs'.
http://wiki.wxpython.org/MultiVersionInstalls

drPython is probably selecting a specific version of wxpython and
py2exe doesn't like it or
can't find it. Once you solve that, py2exe will work fine with
wxpython.



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

Re: Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 23, 4:57 am, Bruno Desthuilliers  wrote:
> Russ P. a écrit :

> > As I said before, if you have the source code you can always change
> > private attributes to public in a pinch if the language enforces
> > encapsulation.
>
> And then have to maintain a fork. No, thanks.

For crying out loud, how many private attributes do you need to
access? If it's a dozen, then you and your library developer are
obviously not on the same page. If it's one or two, then it's hardly a
"fork." Just take note of the one or two places where you needed to
remove the access restriction and you're done. Heck, you don't even
need to do that, because you will be warned automatically anyway when
you get the new version of the library (unless those private
attributes are changed to public).

> > But if you are working on a team project, you can't
> > change the code that another member of a team checks in.
>
> Why on earth couldn't I change the code of another member of my team if
> that code needs changes ? The code is the whole team's ownership.

OK, fine, you can change the code of another member of the team. Are
you going to check with him first, or just do it? The point is that
changing an interface requires agreement of the team members who use
that interface, whether on the calling or the implementation side of
it. If you change interfaces without getting agreement with the other
team members, you probably won't be on the team for long. And without
access restrictions, accessing _private is equivalent to changing the
interface.

> Now and FWIW,  in this case (our own code), I just don't need to "mess
> with internals" - I just just change what needs to be changed.
>
> > That is how
> > enforced data hiding helps teams of developers manage interfaces.
>
> I totally fails to find any evidence of this assertion in the above
> "demonstration".
>
> > The
> > bigger the team and the bigger the project, the more it helps.
>
> Your opinion.
>
> > Mr. D'Aprano gave an excellent example of a large banking program.
> > Without enforced encapsulation, anyone on the development team has
> > access to the entire program and could potentially sneak in fraudulent
> > code much more easily than if encapsulation were enforced by the
> > language.
>
> My my my. If you don't trust your programmers, then indeed, don't use
> Python. What can I say (and what do I care ?). But once again, relying
> on the language's access restriction to manage *security* is, well, kind
> of funny, you know ?

Are you seriously saying that if you were managing the production of a
major financial software package with hundreds of developers, you
would just "trust" them all to have free access to the most sensitive
and critical parts of the program? Now *that's*, well, kind of funny,
you know?

Would you give all those developers your password to get into the
system? No? Wait a minute ... you mean you wouldn't "trust" them with
your password? But what about "openness"? Are you some sort of fascist
or what?
--
http://mail.python.org/mailman/listinfo/python-list

Re: What is intvar?

[W. eWatson]

r wrote:

here is a good explanation of control vars:
http://infohost.nmt.edu/tcc/help/pubs/tkinter/control-variables.html

Here are 3 great Tkinter refernces in order:
http://infohost.nmt.edu/tcc/help/pubs/tkinter/
http://effbot.org/tkinterbook/
http://www.pythonware.com/library/tkinter/introduction/

Thanks to all for the reference and tips.

--
   W. eWatson

 (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
  Obz Site:  39° 15' 7" N, 121° 2' 32" W, 2700 feet

Web Page: 

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

Re: Does Python really follow its philosophy of "Readability counts"?

[Steven D'Aprano]

On Fri, 23 Jan 2009 05:42:38 -0800, Russ P. wrote:

>> My my my. If you don't trust your programmers, then indeed, don't use
>> Python. What can I say (and what do I care ?). But once again, relying
>> on the language's access restriction to manage *security* is, well,
>> kind of funny, you know ?
> 
> Are you seriously saying that if you were managing the production of a
> major financial software package with hundreds of developers, you would
> just "trust" them all to have free access to the most sensitive and
> critical parts of the program? Now *that's*, well, kind of funny, you
> know?

I think this is a red-herring. Probably my fault -- I was the first one 
to mention access controls for banking software. I meant it as an analog 
to data hiding, rather than implying that one can or should use private/
protected attributes to implement data hiding.

Private attributes are a form of data hiding, but not all data hiding can 
be implemented as private attributes. 



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

Re: Does Python really follow its philosophy of "Readability counts"?

[Steve Holden]

Bruno Desthuilliers wrote:
> Russ P. a écrit :
[...]
>> Mr. D'Aprano gave an excellent example of a large banking program.
>> Without enforced encapsulation, anyone on the development team has
>> access to the entire program and could potentially sneak in fraudulent
>> code much more easily than if encapsulation were enforced by the
>> language.
> 
> My my my. If you don't trust your programmers, then indeed, don't use
> Python. What can I say (and what do I care ?). But once again, relying
> on the language's access restriction to manage *security* is, well, kind
> of funny, you know ?
> 
I have to say that I thought the example was somewhat bogus. Any
development team that is even slightly concerned about the possibility
of logic bombs in the code will try to mitigate that possibility by the
use of code inspections.

>> I am certainly not saying that Python is useless without enforced data
>> hiding. It is obviously very useful for a wide range of applications
>> and domains already. I am only saying that it's usefulness could be
>> enhanced if enforced encapsulation can be added
> 
> You might have a chance to sell this to a clueless pointy haired boss -
> I mean,  that enforced access restriction will make Python more suitable
> for some big enterprizey project. As far as I'm concerned, I'm not
> buying it.
> 
I'm not sure that there's much to be gained by this level of dogmatism
on either side. "Enforced encapsulation" has been "implemented" in both
C++ and Java, and both have proved to be circumventable. Just the same,
talk of "clueless pointy-haired bosses" is unlikely to be convincing.
Even the pointy-haired types never recognize themselves as such.

Annotations *have* made it into 3.0, so it's possible that the might
become usable. Remember, they'll always be optional, so those who don't
want to use them won't lose anything at all.

[...]

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: Does Python really follow its philosophy of "Readability counts"?

[Divya Prakash]

Hello
thats excellant !!


On 1/23/09, Russ P.  wrote:
>
> On Jan 23, 4:57 am, Bruno Desthuilliers  42.desthuilli...@websiteburo.invalid> wrote:
> > Russ P. a écrit :
>
> > > As I said before, if you have the source code you can always change
> > > private attributes to public in a pinch if the language enforces
> > > encapsulation.
> >
> > And then have to maintain a fork. No, thanks.
>
> For crying out loud, how many private attributes do you need to
> access? If it's a dozen, then you and your library developer are
> obviously not on the same page. If it's one or two, then it's hardly a
> "fork." Just take note of the one or two places where you needed to
> remove the access restriction and you're done. Heck, you don't even
> need to do that, because you will be warned automatically anyway when
> you get the new version of the library (unless those private
> attributes are changed to public).
>
> > > But if you are working on a team project, you can't
> > > change the code that another member of a team checks in.
> >
> > Why on earth couldn't I change the code of another member of my team if
> > that code needs changes ? The code is the whole team's ownership.
>
> OK, fine, you can change the code of another member of the team. Are
> you going to check with him first, or just do it? The point is that
> changing an interface requires agreement of the team members who use
> that interface, whether on the calling or the implementation side of
> it. If you change interfaces without getting agreement with the other
> team members, you probably won't be on the team for long. And without
> access restrictions, accessing _private is equivalent to changing the
> interface.
>
> > Now and FWIW,  in this case (our own code), I just don't need to "mess
> > with internals" - I just just change what needs to be changed.
> >
> > > That is how
> > > enforced data hiding helps teams of developers manage interfaces.
> >
> > I totally fails to find any evidence of this assertion in the above
> > "demonstration".
> >
> > > The
> > > bigger the team and the bigger the project, the more it helps.
> >
> > Your opinion.
> >
> > > Mr. D'Aprano gave an excellent example of a large banking program.
> > > Without enforced encapsulation, anyone on the development team has
> > > access to the entire program and could potentially sneak in fraudulent
> > > code much more easily than if encapsulation were enforced by the
> > > language.
> >
> > My my my. If you don't trust your programmers, then indeed, don't use
> > Python. What can I say (and what do I care ?). But once again, relying
> > on the language's access restriction to manage *security* is, well, kind
> > of funny, you know ?
>
> Are you seriously saying that if you were managing the production of a
> major financial software package with hundreds of developers, you
> would just "trust" them all to have free access to the most sensitive
> and critical parts of the program? Now *that's*, well, kind of funny,
> you know?
>
> Would you give all those developers your password to get into the
> system? No? Wait a minute ... you mean you wouldn't "trust" them with
> your password? But what about "openness"? Are you some sort of fascist
> or what?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: Does Python really follow its philosophy of "Readability counts"?

[Tim Rowe]

2009/1/22 Scott David Daniels :

> Having once been a more type-A, I labored for a couple of years trying
> to build a restricted language that provably terminated for work on an
> object-oriented database research.

I was careful to say that it was the /use/ of the language that is
restricted; it's still possible to write undecidable programs, there's
just an obligation on you to show that you haven't.

> I finally gave it up as a bad idea,
> because, in practice, we don't care if a loop will terminate or not in
> database work; a transaction that takes a year to commit is equivalent
> to an infinite loop for all applications that I have interacted with
> (and yes, I have worked allowing four day transactions to commit).

True -- the really serious safety critical stuff is usually real time,
and part of the proof obligations is to show that the maximum response
time is tolerable. The loop variant can help with that, too.

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

Re: Does Python really follow its philosophy of "Readability counts"?

[Russ P.]

On Jan 23, 6:21 am, Steve Holden  wrote:

> I have to say that I thought the example was somewhat bogus. Any
> development team that is even slightly concerned about the possibility
> of logic bombs in the code will try to mitigate that possibility by the
> use of code inspections.

Of course they would, but that does not mean that access restrictions
enforced by the language are not prudent. Consider a corporation that
needs to maintain the physical security of their buildings. You can
say that locks on the doors are not sufficient. Of course they're not.
Security guards are needed too -- but that doesn't mean the locks  are
not needed too. The locks may be *insufficient* by themselves, but
they are certainly not *unnecessary*. Ditto for the enforced
encapsulation for large financial or safety-critical projects.

> I'm not sure that there's much to be gained by this level of dogmatism
> on either side. "Enforced encapsulation" has been "implemented" in both
> C++ and Java, and both have proved to be circumventable. Just the same,
> talk of "clueless pointy-haired bosses" is unlikely to be convincing.
> Even the pointy-haired types never recognize themselves as such.

Do you think the designers of C++, Java, Ada, and Scala would
eliminate the enforced encapsulation if they had it to do over again?
Of course not. The vast majority of the users of those languages
consider it a major plus. And those who don't wish to use it aren't
forced to use it except perhaps by their bosses or their customers.

Again, I am not saying that Python necessarily needs enforced access
restriction. I'm just saying it would be a plus if it can be added
without compromising the language in some way.
--
http://mail.python.org/mailman/listinfo/python-list

writing pickle function

[perfreem]

hello,

i am using nested defaultdict from collections and i would like to
write it as a pickle object to a file. when i try:

from collections import defaultdict
x = defaultdict(lambda: defaultdict(list))

and then try to write to a pickle file, it says:

TypeError: can't pickle function objects

is there a way around this? it's simply a dictionary that i want to
write to file.. this works no problems with ordinary dicts.

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

Re: The First Law Of comp.lang.python Dynamics

[Tim Rowe]

2009/1/23 Kay Schluehr :
> Whatever sufficiently sophisticated topic was the initially discussed
> it ends all up in a request for removing reference counting and the
> GIL.

Well, maybe, but it seems to me that the real issue here is that we
need to remove reference counting and the GIL.

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

Re: Implementing file reading in C/Python

[mk]

John Machin wrote:

The factor of 30 indeed does not seem right -- I have done somewhat
similar stuff (calculating Levenshtein distance [edit distance] on words
read from very large files), coded the same algorithm in pure Python and
C++ (using linked lists in C++) and Python version was 2.5 times slower.



Levenshtein distance using linked lists? That's novel. Care to
divulge?


I meant: using linked lists to store words that are compared. I found 
using vectors was slow.


Regards,
mk


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

Re: Find all available Tkinter cursor names?

[Kevin Walzer]

r wrote:

Thanks Kevin,
These are exactly the ones i already knew about. I was hoping there
where more, shucks!. I wonder how i could go about making my own
cursors and adding them to Tkinter? Have any ideas?



http://wiki.tcl.tk/8674 might offer some help in this regard.

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why GIL? (was Re: what's the point of rpython?)

[skip]

>> You mean every time you access a list or dictionary or class
>> instance, you have to acquire a mutex?  That sounds like a horrible
>> slowdown.

Steve> Indeed it would, but hey, let's not let that stop us repeating
Steve> the thinking that's gone into CPython over the last fifteen
Steve> years. "Those who cannot remember the past are condemned to
Steve> repeat it".

Also, every object is mutable at some level.  Tuples, ints and floats are
definitely mutable at creation time.  You need to hold a mutex then, so
Carl's notion of three types of objects breaks down then.

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

Re: Stalled ticket in Python bug tracker

[skip]

Steven> I'm interested in this ticket in the bug tracker:

Steven> http://bugs.python.org/issue2527

Steven> but it seems to have been stalled for nine months. Is there a
Steven> procedure for starting it up again? 

Assign it to yourself?  Add a comment with relevant updates?

Steven> Should I ask about it on the python-dev mailing list, or just
Steven> wait until somebody happens to notice it?

But you've already noticed it. ;-)

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

Re: writing pickle function

[Chris Rebert]

On Fri, Jan 23, 2009 at 6:48 AM,   wrote:
> hello,
>
> i am using nested defaultdict from collections and i would like to
> write it as a pickle object to a file. when i try:
>
> from collections import defaultdict
> x = defaultdict(lambda: defaultdict(list))
>
> and then try to write to a pickle file, it says:
>
> TypeError: can't pickle function objects
>
> is there a way around this? it's simply a dictionary that i want to
> write to file.. this works no problems with ordinary dicts.

Functions aren't pickleable because they're Python code (which is
itself not pickleable). defaultdicts contain a reference to a function
(in your case, a function defined using lambda), which they use to
create default values. Thus, this causes defaultdicts to not be
pickleable.

This is easily worked around by pickling a plain dict w/ the contents
of the defaultdict (i.e. dict(x) ) and then doing:

x = defaultdict(lambda: defaultdict(list)) #create empty defaultdict
x.update(pickle.load(the_file)) #shove contents of pickled dict into
the defaultdict

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: DrPython and py2exe

[mk]

imageguy wrote:


drPython is probably selecting a specific version of wxpython and
py2exe doesn't like it or
can't find it. Once you solve that, py2exe will work fine with
wxpython.


Thanks, drPython was indeed making use of wxversion.select. What's 
strange is that it was selecting apparently correct version:


import wxversion
wxversion.select('2.8')

I put this in setup.py:

import wxversion
wxversion.select("2.8.9.1")
import wx

..and it worked.

Regards,
mk


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

Re: seeking to improve Python skills

[mk]

Jean-Paul Calderone wrote:

The most significant thing missing from this code is unit tests.  
Developing automated tests for your code will help you learn a lot.


Thanks for all the remarks, I'll restructure my code. Probably the 
biggest mistake was not keeping "moving average" class and others 
focused on its respective jobs only.


However, unit tests are a tougher cookie, do you have any resource 
that's truly worth recommending for learning unit tests? The only 
resource I found that was talking at some length about it was "Dive into 
Python" and I was wondering if there's anything better out there...


Regards,
mk


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

Re: seeking to improve Python skills

[Jean-Paul Calderone]

On Fri, 23 Jan 2009 16:57:16 +0100, mk  wrote:

Jean-Paul Calderone wrote:

The most significant thing missing from this code is unit tests. 
Developing automated tests for your code will help you learn a lot.


Thanks for all the remarks, I'll restructure my code. Probably the biggest 
mistake was not keeping "moving average" class and others focused on its 
respective jobs only.


However, unit tests are a tougher cookie, do you have any resource that's 
truly worth recommending for learning unit tests? The only resource I found 
that was talking at some length about it was "Dive into Python" and I was 
wondering if there's anything better out there...


I haven't read it, but a skilled colleague of mine recommends
.

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

Re: The First Law Of comp.lang.python Dynamics

[Benjamin Kaplan]

On Fri, Jan 23, 2009 at 9:50 AM, Tim Rowe  wrote:

> 2009/1/23 Kay Schluehr :
> > Whatever sufficiently sophisticated topic was the initially discussed
> > it ends all up in a request for removing reference counting and the
> > GIL.
>
> Well, maybe, but it seems to me that the real issue here is that we
> need to remove reference counting and the GIL.
>

But that would be hard and require a major rewrite. ;)

BTW, he said sufficiently sophisticated topic. Since there hasn't been an
extremely long post here yet, I don't know if this counts.


>
> --
> Tim Rowe
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list

Re: The First Law Of comp.lang.python Dynamics

[J. Cliff Dyer]

I dub it Schluehr's law.


On Thu, 2009-01-22 at 21:39 -0800, Kay Schluehr wrote:
> Whatever sufficiently sophisticated topic was the initially discussed
> it ends all up in a request for removing reference counting and the
> GIL.
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

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

Where to place imports

[John [H2O]]

Hello, Im writing some modules and I am a little confused about where to
place my imports...

I don't really do any class programming yet, just defining a bunch of
functions, so presently I have something along the lines of:

import sys
import os
import traceback


def Foo1(a,b):
   import numpy
   import datetime
   return c

def Foo2(a,b):
   import datetime

   c = Foo1(a,b)
   return c

etc...

Above obviously just for the form, but the point is, in some cases I may
import modules twice, but other times I may not use them at all, so should I
import everything into the main module? Or individually import them into
functions. Is there a performance penalty either way? 

Pointers to a good reference are appreciated...


-- 
View this message in context: 
http://www.nabble.com/Where-to-place-imports-tp21627895p21627895.html
Sent from the Python - python-list mailing list archive at Nabble.com.

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

Re: ossaudiodev problem: sawtooth noise

[Peter Pearson]

On Thu, 22 Jan 2009 20:58:14 -0200, Gabriel Genellina wrote:
> En Mon, 19 Jan 2009 21:57:04 -0200, Peter Pearson  
> escribió:
>
>> The following code uses ossaudiodev to read 1000 values from
>> my sound card at a rate of 12,000 samples per second:
>>
>> When I select a sample rate that is not a power of 2 times
>> 3000 samples/second, a strong and very regular sawtooth is
>> superimposed on the signal.  At some sampling frequencies,
>> it appears as a rising sawtooth, and at other sampling
>> frequencies it is a declining sawtooth, so I'm presumably
>> lost in some aliasing wilderness.  As best I can tell,
>> it's a 48 KHz sawtooth.
>
> That could be a hardware and/or driver limitation. By example, an  
> AC97-compliant chipset may provide a fixed rate of 48000 samples/second --  
> any sample rate conversion must be done by other means, if possible at all.

Oh!  As a matter of fact, my "soundcard" *is* AC97-compliant
("VT8233/A/8235/8237", according to Sysinfo).  So . . . this
sawtooth might result from some software, somewhere in the bucket
brigade between me and the hardware, attempting to perform
sample-rate conversion?  The 48 KHz coincidence seems very
significant.

Thanks.

-- 
To email me, substitute nowhere->spamcop, invalid->net.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Where to place imports

[Diez B. Roggisch]

John [H2O] schrieb:

Hello, Im writing some modules and I am a little confused about where to
place my imports...

I don't really do any class programming yet, just defining a bunch of
functions, so presently I have something along the lines of:

import sys
import os
import traceback


def Foo1(a,b):
   import numpy
   import datetime
   return c

def Foo2(a,b):
   import datetime

   c = Foo1(a,b)
   return c

etc...

Above obviously just for the form, but the point is, in some cases I may
import modules twice, but other times I may not use them at all, so should I
import everything into the main module? Or individually import them into
functions. Is there a performance penalty either way? 


Usually, you should import on the top of the module. That's the cleanest 
way, and the most performant one.


There is a small performance penalty when doing it inside functions - 
but not too much. It boils down to a lookup if the imported module has 
already been imported before.



The only valid reason for doing imports inside functions is if you 
otherwise get into circular dependency hell, or have modules that need 
some manipulation of the sys.path before they actually can be imported. 
This is never true for system modules, and certainly to avoid if possible.


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

Re: ossaudiodev problem: sawtooth noise

[Gabriel Genellina]

En Fri, 23 Jan 2009 14:36:46 -0200, Peter Pearson  
 escribió:

On Thu, 22 Jan 2009 20:58:14 -0200, Gabriel Genellina wrote:

En Mon, 19 Jan 2009 21:57:04 -0200, Peter Pearson
 escribió:


The following code uses ossaudiodev to read 1000 values from
my sound card at a rate of 12,000 samples per second:

When I select a sample rate that is not a power of 2 times
3000 samples/second, a strong and very regular sawtooth is
superimposed on the signal.  At some sampling frequencies,
it appears as a rising sawtooth, and at other sampling
frequencies it is a declining sawtooth, so I'm presumably
lost in some aliasing wilderness.  As best I can tell,
it's a 48 KHz sawtooth.


That could be a hardware and/or driver limitation. By example, an
AC97-compliant chipset may provide a fixed rate of 48000 samples/second  
any sample rate conversion must be done by other means, if possible at  
all.


Oh!  As a matter of fact, my "soundcard" *is* AC97-compliant
("VT8233/A/8235/8237", according to Sysinfo).  So . . . this
sawtooth might result from some software, somewhere in the bucket
brigade between me and the hardware, attempting to perform
sample-rate conversion?  The 48 KHz coincidence seems very
significant.


Yep. Google found this for me:
http://mail-index.netbsd.org/port-i386/2003/02/18/0003.html

Using a sample rate that is a sub-multiple of 48000 is perhaps a safe  
approach.


--
Gabriel Genellina

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

Re: Where to place imports

[John [H2O]]

So it isn't inefficient to import a bunch of modules that may not be used,
say if only one function is used that doesn't rely on a larger module like
numpy or pylab?

Thanks.


Diez B. Roggisch-2 wrote:
> 
> John [H2O] schrieb:
>> Hello, Im writing some modules and I am a little confused about where to
>> place my imports...
>> 
>> I don't really do any class programming yet, just defining a bunch of
>> functions, so presently I have something along the lines of:
>> 
>> import sys
>> import os
>> import traceback
>> 
>> 
>> def Foo1(a,b):
>>import numpy
>>import datetime
>>return c
>> 
>> def Foo2(a,b):
>>import datetime
>> 
>>c = Foo1(a,b)
>>return c
>> 
>> etc...
>> 
>> Above obviously just for the form, but the point is, in some cases I may
>> import modules twice, but other times I may not use them at all, so
>> should I
>> import everything into the main module? Or individually import them into
>> functions. Is there a performance penalty either way? 
> 
> Usually, you should import on the top of the module. That's the cleanest 
> way, and the most performant one.
> 
> There is a small performance penalty when doing it inside functions - 
> but not too much. It boils down to a lookup if the imported module has 
> already been imported before.
> 
> 
> The only valid reason for doing imports inside functions is if you 
> otherwise get into circular dependency hell, or have modules that need 
> some manipulation of the sys.path before they actually can be imported. 
> This is never true for system modules, and certainly to avoid if possible.
> 
> Diez
> --
> http://mail.python.org/mailman/listinfo/python-list
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Where-to-place-imports-tp21627895p21628590.html
Sent from the Python - python-list mailing list archive at Nabble.com.

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

Re: Counter Class -- Bag/Multiset

[MRAB]

Terry Reedy wrote:

bearophileh...@lycos.com wrote:


Also: what's the rationale of allowing negative values too?


I can guess two:
1) Nuisance to check given that Python does not have a count
(0,1,2...) type.
2. Useful. + = items on hand; - = items back-ordered. Bank account go
negative also ;-). So does elevation.
Similarly, an app could set 0 to mean 'desired quantity on hand', so
non-zero count is surplus or deficit.

I might not have thought to allow this, but it seems to open new 
applications.  (This definitely makes bag or multiset inappropriate

as names.)


I would've limited the counts to non-negative values too, but being able
to store negative values does allow credit/debit or in-stock/on-order.
In such cases, the name 'Counter' makes more sense.
--
http://mail.python.org/mailman/listinfo/python-list

Re: The First Law Of comp.lang.python Dynamics

[Tim Rowe]

2009/1/23 Benjamin Kaplan :

> BTW, he said sufficiently sophisticated topic. Since there hasn't been an
> extremely long post here yet, I don't know if this counts.

Had I waited until the thread became long enough, somebody else would
have already raised the issue -- you must surely know about Schluehr's
Law? ;-)


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

Re: Where to place imports

[Diez B. Roggisch]

John [H2O] schrieb:

So it isn't inefficient to import a bunch of modules that may not be used,
say if only one function is used that doesn't rely on a larger module like
numpy or pylab?


Well, importing can take bit of time - but that's a short latency at 
startup-time, if anything.


And if your module gets imported inside a function, it *is* used, isn't it?

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

Re: Why GIL? (was Re: what's the point of rpython?)

[Paul Rubin]

s...@pobox.com writes:
> Also, every object is mutable at some level.  Tuples, ints and floats are
> definitely mutable at creation time.  You need to hold a mutex then, so
> Carl's notion of three types of objects breaks down then.

Hopefully, at creation time, they will usually be in a scope where
other threads can't see them.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dynamic methods and lambda functions

[Brian Allen Vanderburg II]

unine...@gmail.com wrote:

class Person:
def __init__(self):
for prop in props:
setattr(self, "__" + prop[0], prop[1])
setattr(Person, "Get" + prop[0], lambda self: getattr
(self, "__" + prop[0]))

  
I've had a similar problem here and here is best how I can explain it.  
The prop in the lambda function is a closure by 'name' to the prop in 
the containing name space (__init__), so when the lambda function 
executes, it looks for the name 'prop' in this name space and uses it's 
value.  After the 'for prop in props' loop is complete, 'prop' is left 
referring to the last item in props, so each lambda function would use 
it (mary)


One solution is to not use lambda and avoid closures by using default 
arguments:


for prop in props:
   def Getter(self=self, prop=prop):
  return getattr(self, '__' + prop[0])
   setattr(self, '__' + prop[0], prop[1])
   setattr(self, 'Get' + prop[0], Getter)

I have several problems with this though:

1. I don't think this will invoke Pythons name mangling mechanism.  The 
property will be '__name' and not '__Person_name'.


2. If you make a copy of the class, including attributes, the Getter 
will operate on the old class not new:


Person a
b = copy.copy(a)

setattr(a, '__name', bob)
setattr(b, '__name', sarah)

b.Getname() -> bob

In order to make it work, the class must support updating the Getter 
when it is copied to have a new self value.


import copy

class MethodCaller:
   def __init__(self, obj, method, name):
   self.obj = obj
   self.method = method
   self.name = name

   setattr(obj, name, self)

   def __call__(self, *args, **kwargs):
   return self.method(self.obj, *args, **kwargs)

   def copy(self, newobj):
   return MethodCaller(newobj, self.method, self.name)


props = ( ('name', 'mary'), ('age', 21), ('gender', 'female') )

class Person:
   def __init__(self):
   self._methods = []

   for prop in props:
   (name, value) = prop
   
   def getter(self, name=name):

   return getattr(self, '_' + name)

   setattr(self, '_' + name, value)
   self._methods.append(MethodCaller(self, getter, 'Get' + name))

   def copy(self,copymethods=True):
   c = copy.copy(self)
   if copymethods:
   c._methods = []
   for i in self._methods:
   c._methods.append(i.copy(c))
   return c


# Example without copying methods
p = Person()
q = p.copy(False)

p._name = 'sarah'
q._name = 'michelle'

print p.Getname()
print p.Getage()
print p.Getgender()

print q.Getname() # Still prints 'sarah', because getter still refers to 
'p' instead of 'q'

print q.Getage()
print q.Getgender()

# Example with copying methods
p = Person()
q = p.copy()

p._name = 'sarah'
q._name = 'michelle'

print p.Getname()
print p.Getage()
print p.Getgender()

print q.Getname() # Prints 'michelle'
print q.Getage()
print q.Getgender()

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

Re: Where to place imports

[Steve Holden]

Diez B. Roggisch wrote:
[...]
> The only valid reason for doing imports inside functions is if you
> otherwise get into circular dependency hell, or have modules that need
> some manipulation of the sys.path before they actually can be imported.
> This is never true for system modules, and certainly to avoid if possible.
> 
Well there is also the somewhat obscure point that an import of specific
names inside a function makes them local, which *might* make a
performance difference with tight loop nesting inside - though obviously
the need for such will best be determined by benchmarking:

>>> def f1():
...   from os.path import join
...   print join
...
>>> from os.path import join
>>> def f2():
...   print join
...
>>> dis.dis(f1)
  2   0 LOAD_CONST   1 (-1)
  3 LOAD_CONST   2 (('join',))
  6 IMPORT_NAME  0 (os.path)
  9 IMPORT_FROM  1 (join)
 12 STORE_FAST   0 (join)
 15 POP_TOP

  3  16 LOAD_FAST0 (join)
 19 PRINT_ITEM
 20 PRINT_NEWLINE
 21 LOAD_CONST   0 (None)
 24 RETURN_VALUE
>>> dis.dis(f2)
  2   0 LOAD_GLOBAL  0 (join)
  3 PRINT_ITEM
  4 PRINT_NEWLINE
  5 LOAD_CONST   0 (None)
  8 RETURN_VALUE
>>>

Not a major issue, just another aspect of the question ... and of course
the OP should take the advice already given unless and until performance
becomes a problem (since it usually won't).

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: Where to place imports

[Diez B. Roggisch]

Steve Holden schrieb:

Diez B. Roggisch wrote:
[...]

The only valid reason for doing imports inside functions is if you
otherwise get into circular dependency hell, or have modules that need
some manipulation of the sys.path before they actually can be imported.
This is never true for system modules, and certainly to avoid if possible.


Well there is also the somewhat obscure point that an import of specific
names inside a function makes them local, which *might* make a
performance difference with tight loop nesting inside - though obviously
the need for such will best be determined by benchmarking:


But that could be mitigated using aliasing, which is a more general 
optimization technique, as it works not only for imported names but also 
for e.g. bound methods, or any other chained lookups.


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

Re: Does Python really follow its philosophy of "Readability counts"?

[Luis Zarrabeitia]

On Friday 23 January 2009 06:31:50 am Antoon Pardon wrote:
> On 2009-01-16, Luis Zarrabeitia  wrote:
> > Quoting "Russ P." :
> >> If you "*shouldn't* mess with the implementation", then what is wrong
> >> with enforcing that "shouldn't" in the language itself?
> >
> > Because, as a library user, it should be my power to chose when and how I
> > _should_ mess with the implementation, not the compiler, and definitely
> > not you.
>
> Why should it be in your power? By messing with the implementation of a
> library you risk the correctness of the code of all participant coders in
> that project. I not that sure it should be your power to chose when and how
> to do that.

Ok, let me fix that.
It should be in _our_ power as the team of all participant coders on _our_ 
project to decide if we should mess with the internals or not.

What makes no sense is that it should be in the original author's power to 
decide, if he is not part of _our_ team.

Do you like it better now? Wasn't it obvious in the first place?

-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
--
http://mail.python.org/mailman/listinfo/python-list

Re: Where to place imports

[Duncan Booth]

"John [H2O]"  wrote:

> So it isn't inefficient to import a bunch of modules that may not be
> used, say if only one function is used that doesn't rely on a larger
> module like numpy or pylab?
> 
Not really. If you import it at all then you might as well import it on 
startup i.e. at the top of the module. Importing from inside a function 
doesn't free up the imported module when the function returns, so you 
aren't going to save any memory in the long run.

I would accept that if you have a function that may not be called in most 
runs of the program, and that function uses some large module that wouldn't 
otherwise be loaded, then you might have a case for importing it only 
inside the function. But that's a very rare situation; otherwise, just 
import it at module scope.

BTW, if you ever find you are starting to write multi-threaded applications 
then you'll really regret it if you reuse code which does imports from 
inside functions. If two or more threads try to import a module 
simultaneously then one of them might find it that not everything is 
defined in the module exists when it tries to use it.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Where to place imports

[Jean-Paul Calderone]

On 23 Jan 2009 18:50:00 GMT, Duncan Booth  wrote:

[snip]

BTW, if you ever find you are starting to write multi-threaded applications
then you'll really regret it if you reuse code which does imports from
inside functions. If two or more threads try to import a module
simultaneously then one of them might find it that not everything is
defined in the module exists when it tries to use it.


What makes you say this?  There is an import lock (beyond the GIL) which
should prevent a thread from ever seeing a partially initialized module.

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

Re: Why GIL? (was Re: what's the point of rpython?)

[Rhamphoryncus]

On Jan 22, 11:09 pm, Carl Banks  wrote:
> On Jan 22, 9:38 pm, Rhamphoryncus  wrote:
>
>
>
> > On Jan 22, 9:38 pm, Carl Banks  wrote:
>
> > > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote:
>
> > > > In article <7xd4ele060@ruckus.brouhaha.com>,
> > > > Paul Rubin   wrote:
>
> > > > >alex23  writes:
>
> > > > >> Here's an article by Guido talking about the last attempt to remove
> > > > >> the GIL and the performance issues that arose:
>
> > > > >> "I'd welcome a set of patches into Py3k *only if* the performance for
> > > > >> a single-threaded program (and for a multi-threaded but I/O-bound
> > > > >> program) *does not decrease*."
>
> > > > >The performance decrease is an artifact of CPython's rather primitive
> > > > >storage management (reference counts in every object).  This is
> > > > >pervasive and can't really be removed.  But a new implementation
> > > > >(e.g. PyPy) can and should have a real garbage collector that doesn't
> > > > >suffer from such effects.
>
> > > > CPython's "primitive" storage management has a lot to do with the
> > > > simplicity of interfacing CPython with external libraries.  Any solution
> > > > that proposes to get rid of the GIL needs to address that.
>
> > > I recently was on a long road trip, and was not driver, and with
> > > nothing better to do thought quite a bit about how this.
>
> > > I concluded that, aside from one major trap, it wouldn't really be
> > > more difficult to inteface Python to external libraries, just
> > > differently difficult.  Here is briefly what I came up with:
>
> > > 1. Change the singular Python type into three metatypes:
> > > immutable_type, mutable_type, and mutable_dict_type.  (In the latter
> > > case, the object itself is immutable but the dict can be modified.
> > > This, of course, would be the default metaclass in Python.)  Only
> > > mutable_types would require a mutex when accessing.
>
> > > 2. API wouldn't have to change much.  All regular API would assume
> > > that objects are unlocked (if mutable) and in a consistent state.
> > > It'll lock any mutable objects it needs to access.  There would also
> > > be a low-level API that assumes the objects are locked (if mutable)
> > > and does not require objects to be consistent.  I imagine most
> > > extensions would call the standard API most of the time.
>
> > > 3. If you are going to use the low-level API on a mutable object, or
> > > are going to access the object structure directly, you need to acquire
> > > the object's mutex. Macros such as Py_LOCK(), Py_LOCK2(), Py_UNLOCK()
> > > would be provided.
>
> > > 4. Objects would have to define a method, to be called by the GC, that
> > > marks every object it references.  This would be a lot like the
> > > current tp_visit, except it has to be defined for any object that
> > > references another object, not just objects that can participate in
> > > cycles.  (A conservative garbage collector wouldn't suffice for Python
> > > because Python quite often allocates blocks but sets the pointer to an
> > > offset within the block.  In fact, that's true of almost any Python-
> > > defined type.)  Unfortunately, references on the stack would need to
> > > be registered as well, so "PyObject* p;" might have to be replaced
> > > with something like "Py_DECLARE_REF(PyObject,p);" which magically
> > > registers it.  Ugly.
>
> > > 5. Py_INCREF and Py_DECREF are gone.
>
> > > 6. GIL is gone.
>
> > > So, you gain the complexity of a two-level API, having to lock mutable
> > > objects sometimes, and defining more visitor methods than before, but
> > > you don't have to keep INCREFs and DECREFs straight, which is no small
> > > thing.
>
> > > The major trap is the possibily of deadlock.  To help minimize the
> > > risk there would be macros to lock multiple objects at once.  Py_LOCK2
> > > (a,b), which guarantess that if in another thread is calling Py_LOCK2
> > > (b,a) at the same time, it won't result in a deadlock.  What's
> > > disappointing is that the deadlocking possibility is always with you,
> > > much like the reference counts are.
>
> > IMO, locking of the object is a secondary problem.  Python-safethread
> > provides one solution, but it's not the only conceivable one.  For the
> > sake of discussion it's easier to assume somebody else is solving it
> > for you.
>
> That assumption might be good for the sake of the discussion *you*
> want to have, but it's not for discussion I was having, which was to
> address Aahz's claim that GIL makes extension writing simple by
> presenting a vision of what Python might be like if it had a mark-and-
> sweep collector.  The details of the GC are a small part of that and
> wouldn't affect my main point even if they are quite different than I
> described.  Also, extension writers would have to worry about locking
> issues here, so it's not acceptable to assume somebody else will solve
> that problem.
>
> > Instead, focus on just the garbage collection.
>
> [

Re: writing pickle function

[Gerard Flanagan]

On Jan 23, 2:48 pm, perfr...@gmail.com wrote:
> hello,
>
> i am using nested defaultdict from collections and i would like to
> write it as a pickle object to a file. when i try:
>
> from collections import defaultdict
> x = defaultdict(lambda: defaultdict(list))
>
> and then try to write to a pickle file, it says:
>
> TypeError: can't pickle function objects
>
> is there a way around this? it's simply a dictionary that i want to
> write to file.. this works no problems with ordinary dicts.
>
> thank you.


One way via a subclass:

(from memory)

class MyCollection(defaultdict):

def __init__(self):
defaultdict.__init__(self, list)

def __reduce__(self):
return (MyCollection, (), None, None, self.iteritems())

and if you are so inclined (nothing to do with pickling):

__setattr__ = defaultdict.__setitem__
__getattr__ = defaultdict.__getitem__

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

Parsing XML: SAX, DOM, Expat, or Something Else?

[aha]

Hello All,
  I've been charged with developing an XML configuration file format,
for one of the applications that my company develops. (Yes, I know it
would have been easier to just use the configuration file format as
described in RFC 822)   While I am finally comfortable with the XML
description that we've agreed upon; I am still trying to determine the
best XML parser API to use.  I would love to use XPATH, however I face
the following restriction:

The Python scripts that perform the parsing of the XML configuration
file must be compatible with Python Versions 2.2-present.

This means that any functionality that I use needs to be compatible
with Python 2.2.

I started with the DOM API in xml.dom.minidom and I thought that it
might be the best way to go, but then I ran across the Recipes of Wai
Yip Tung

http://code.activestate.com/recipes/534109/


and John Bair, Christoph Dietze from the second edition of the Python
cookbook.

Wai's implementation uses thes SAX parser and John and Christoph's
implementation uses Expat API.

In the end what I really want is to transform the XML


   
 
   


into an object that looks like

config.component.setting or a map config[component][setting].

Another restriction is that I don't want to have to ship additional
modules.

Does anyone have any advice, comments, or HELP???

Aquil H. Abdullah
Developer
--
http://mail.python.org/mailman/listinfo/python-list

OCaml, Language syntax, and Proof Systems

[Xah Lee]

recently, as you might have noted by a previous post of mine, that
American Mathematical Society published a series of articles on formal
proofs in 2008 November. See: http://www.ams.org/notices/200811/ The
articles are:

 • Formal Proof by Thomas Hales
 • Formal Proof — The Four-Color Theorem by Georges Gonthier
 • Formal Proof — Theory and Practice by John Harrison
 • Formal Proof — Getting Started by Freek Wiedijk

I read 3 of them in December (only scanned the four-color theorem
one).

It was quite a fantastically enjoyable reading.

(
For some personal notes, see: Current State Of Theorem Proving Systems
at the bottom of
• The Codification of Mathematics
  http://xahlee.org/cmaci/notation/math_codify.html
)

As you may know, codification of math has been a long personal
interest. In fact, my logical analytic habit has made me unable to
read most math texts, which are full of logical errors and relies on a
“human” interpretation for its soundness and clarity.

having read those intro articles from the AMS publication on current
state of the art, i decided that i'm going to learn HOL Light. (tried
to learn Coq before and the tutorial is problematic)

One of the interesting finding was that almost all theorem proving
systems are written in ML family lang, e.g. Caml, Ocaml. Of course, i
heard of Ocaml since about 1998 when i was doing Scheme. Somehow it
never impressed me from reading the functional programing FAQ.  I have
always been attracted more to Haskell, perhaps only because it is
_pure_ in the sense of not allowing assignment. With that, ocaml has
been “just another functional lang” in my mind. But now, seeing that
most theorem proving systems used in the real world are in Caml, thus
i made start to learn Ocaml now. (in fact, its root is a theorem
prover)

i wanted to add proofs as enhancement to my A Visual Dictionary Of
Special Plane Curves. Also, had ambition to write more... about
algebraic geometry and differential geometry and geometry with complex
numbers. Proofs will be major part of these type of works. I can no
longer tolerate traditional mouthy written-english proofs. They must
be codified proofs.

In this:

HOL Light Tutorial (for version 2.20)
by John Harrison
September 9, 2006,

there's this paragraph:

“This fits naturally with the view, expressed for example by Dijkstra
(1976), that a programming language should be thought of first and
foremost as an algorithm-oriented system of mathematical notation, and
only secondarily as something to be run on a machine.”

Wee! That has been my view since about 1997. The only lang that adhere
to that view i know of is Mathematica.

(lisping morons don't understand a iota of it. See:

• Is Lisp's Objects Concept Necessary?
  http://xahlee.org/emacs/lisps_objects.html

• The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations
  http://xahlee.org/UnixResource_dir/writ/notations.html
)

btw, anyone know the source of that Dijkstra quote?

  Xah
∑ http://xahlee.org/

☄

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

Re: Why GIL?

[Hrvoje Niksic]

Carl Banks  writes:

> Unfortunately, references on the stack would need to be registered
> as well, so "PyObject* p;" might have to be replaced with something
> like "Py_DECLARE_REF(PyObject,p);" which magically registers it.
> Ugly.

Not only registered at the beginning of the function, but also (since
CPython uses C, not C++) explicitly unregistered at every point of
exit from the function.  Emacs implements these as macros called GCPRO
and UNGCPRO, and they're very easy to get wrong.  In a way, they are
even worse than the current Python INCREF/DECREF.

See description at, for example,
http://www.xemacs.org/Documentation/beta/html/internals_19.html#SEC78
--
http://mail.python.org/mailman/listinfo/python-list

Re: Parsing XML: SAX, DOM, Expat, or Something Else?

[Chris Rebert]

On Fri, Jan 23, 2009 at 11:19 AM, aha  wrote:
> Hello All,
>  I've been charged with developing an XML configuration file format,
> for one of the applications that my company develops. (Yes, I know it
> would have been easier to just use the configuration file format as
> described in RFC 822)   While I am finally comfortable with the XML
> description that we've agreed upon; I am still trying to determine the
> best XML parser API to use.  I would love to use XPATH, however I face
> the following restriction:
>
> The Python scripts that perform the parsing of the XML configuration
> file must be compatible with Python Versions 2.2-present.
>
> This means that any functionality that I use needs to be compatible
> with Python 2.2.
>
> I started with the DOM API in xml.dom.minidom and I thought that it
> might be the best way to go, but then I ran across the Recipes of Wai
> Yip Tung
>
> http://code.activestate.com/recipes/534109/
>
>
> and John Bair, Christoph Dietze from the second edition of the Python
> cookbook.
>
> Wai's implementation uses thes SAX parser and John and Christoph's
> implementation uses Expat API.
>
> In the end what I really want is to transform the XML
>
> 
>   
> 
>   
> 
>
> into an object that looks like
>
> config.component.setting or a map config[component][setting].
>
> Another restriction is that I don't want to have to ship additional
> modules.
>
> Does anyone have any advice, comments, or HELP???

ElementTree is in the std lib for Python 2.5+ and has a fairly
Pythonic API compared to SAX/DOM.
Docs for it: http://docs.python.org/library/xml.etree.elementtree.html

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Parsing XML: SAX, DOM, Expat, or Something Else?

[Stefan Behnel]

Chris Rebert wrote:
> On Fri, Jan 23, 2009 at 11:19 AM, aha  wrote:
>> I've been charged with developing an XML configuration file format,
>> for one of the applications that my company develops.
>> [...]
>> I am still trying to determine the
>> best XML parser API to use.  I would love to use XPATH, however I face
>> the following restriction:
>>
>> The Python scripts that perform the parsing of the XML configuration
>> file must be compatible with Python Versions 2.2-present.
> 
> ElementTree is in the std lib for Python 2.5+ and has a fairly
> Pythonic API compared to SAX/DOM.
> Docs for it: http://docs.python.org/library/xml.etree.elementtree.html

The downloadable package (version 1.2.x) still works with Python 2.2 (last
I heard, at least). ET also has simple support for XPath-like expressions
(without conditions, that is). Starting to use it now will however allow
you to switch to the mostly compatible lxml.etree package once you decide
to move on to Python 2.3 or later. lxml has full support for XPath (and
XSLT and tons of other goodies).

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

Re: what gives with

[Scott David Daniels]

Darren Dale wrote:

 What is the point of providing absolute_import in __future__ if the
api is completely different than the implementation in future python versions?


The point is to obtain user experience with a proposed feature _before_
you fix the interface and start having to be "backward compatible."

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Adding a field to a 'foreign' object from the outside

[Scott David Daniels]

Steve Holden wrote:

 Write a class that implements a __call__() method, and use an instance
> of that class as your callback. Then the data can be stored as the 
callback

> object's private instance data.

In fact, you needn't name the method __call__.  You can pass in
Holder().method if you have no other use for the instance of
your Holder instance.

--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list

Re: Why GIL? (was Re: what's the point of rpython?)

[Carl Banks]

On Jan 23, 7:33 am, s...@pobox.com wrote:
>     >> You mean every time you access a list or dictionary or class
>     >> instance, you have to acquire a mutex?  That sounds like a horrible
>     >> slowdown.
>
>     Steve> Indeed it would, but hey, let's not let that stop us repeating
>     Steve> the thinking that's gone into CPython over the last fifteen
>     Steve> years. "Those who cannot remember the past are condemned to
>     Steve> repeat it".
>
> Also, every object is mutable at some level.  Tuples, ints and floats are
> definitely mutable at creation time.  You need to hold a mutex then, so
> Carl's notion of three types of objects breaks down then.

immutable_type objects wouldn't exist at all until their
PyWhatever_New or their tp_new member is called.  After that, the
reference exists only on the local stack, which is accessible only to
one thread.  As long as you finish initializing the object while it's
still only on the stack, there is no possibility of a conflict.

What about tp_init, then, you ask?  Well it's simple: immutable_type
doesn't call it.  In fact, it requires that tp_init, tp_setattro,
tp_mapping->mp_setitem, etc., are all null.

immutable_obejcts have no instance dict, so if you want to create
attributes in Python you have to use slots.  immutable_object.__new__
accepts keyword arguments and initializes the slots with the value.

class Record(immutable_object,slots=['name','number']):
def __new__(cls,name):
number = db.lookup_number(name)
immutable_object.__new__(cls,name=name,number=number)


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

Re: writing pickle function

[Peter Otten]

perfr...@gmail.com wrote:

> i am using nested defaultdict from collections and i would like to
> write it as a pickle object to a file. when i try:
> 
> from collections import defaultdict
> x = defaultdict(lambda: defaultdict(list))
> 
> and then try to write to a pickle file, it says:
> 
> TypeError: can't pickle function objects
> 
> is there a way around this? it's simply a dictionary that i want to
> write to file.. this works no problems with ordinary dicts.

The error message is misleading. You can pickle your defaultdict if you use
a "normal" function instead of the lambda:

$ cat pickle_defaultdict.py
import sys
from collections import defaultdict
from cPickle import dumps, loads

if "--lambda" in sys.argv:
make_inner = lambda: defaultdict(list)
else:
def make_inner():
return defaultdict(list)

d = defaultdict(make_inner)
d[1][2].append(42)
e = loads(dumps(d))
print e == d

$ python pickle_defaultdict.py
True
$ python pickle_defaultdict.py --lambda
Traceback (most recent call last):
  File "pickle_defaultdict.py", line 13, in 
e = loads(dumps(d))
  File "/usr/lib/python2.5/copy_reg.py", line 69, in _reduce_ex
raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle function objects

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

is None vs. == None

[Gerald Britton]

Hi -- Some time ago I ran across a comment recommending using  is
None instead of  == None (also  is not None, etc.)  My own
testing indicates that the former beats the latter by about 30% on
average.  Not a log for a single instruction but it can add up in
large projects.

I'm looking for a (semi)-official statement on this, but couldn't find
one with normal googling.  Can someone please send a link?
--
http://mail.python.org/mailman/listinfo/python-list

Re: writing pickle function

[Steve Holden]

Peter Otten wrote:
> perfr...@gmail.com wrote:
> 
>> i am using nested defaultdict from collections and i would like to
>> write it as a pickle object to a file. when i try:
>>
>> from collections import defaultdict
>> x = defaultdict(lambda: defaultdict(list))
>>
>> and then try to write to a pickle file, it says:
>>
>> TypeError: can't pickle function objects
>>
>> is there a way around this? it's simply a dictionary that i want to
>> write to file.. this works no problems with ordinary dicts.
> 
> The error message is misleading. You can pickle your defaultdict if you use
> a "normal" function instead of the lambda:
> 
> $ cat pickle_defaultdict.py
> import sys
> from collections import defaultdict
> from cPickle import dumps, loads
> 
> if "--lambda" in sys.argv:
> make_inner = lambda: defaultdict(list)
> else:
> def make_inner():
> return defaultdict(list)
> 
> d = defaultdict(make_inner)
> d[1][2].append(42)
> e = loads(dumps(d))
> print e == d
> 
> $ python pickle_defaultdict.py
> True
> $ python pickle_defaultdict.py --lambda
> Traceback (most recent call last):
>   File "pickle_defaultdict.py", line 13, in 
> e = loads(dumps(d))
>   File "/usr/lib/python2.5/copy_reg.py", line 69, in _reduce_ex
> raise TypeError, "can't pickle %s objects" % base.__name__
> TypeError: can't pickle function objects
> 
But can you unpickle the objects you pickle? I believe that functions
are references relative to the modules they come from, and so won't be
found unless the same module can be imported at unpickle time. Could be
wrong, haven't read the source, but I understand that functions work the
same as classes.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: is None vs. == None

[Chris Rebert]

On Fri, Jan 23, 2009 at 11:58 AM, Gerald Britton
 wrote:
> Hi -- Some time ago I ran across a comment recommending using  is
> None instead of  == None (also  is not None, etc.)  My own
> testing indicates that the former beats the latter by about 30% on
> average.  Not a log for a single instruction but it can add up in
> large projects.
>
> I'm looking for a (semi)-official statement on this, but couldn't find
> one with normal googling.  Can someone please send a link?

>From http://www.python.org/dev/peps/pep-0008/ ,
2nd bullet under "Programming Recommendations":

- Comparisons to singletons like None should always be done with
  'is' or 'is not', never the equality operators.


Just FYI, `is` compares object identity (pointer equality) whereas ==
checks for value equivalence (which causes a method call). This is why
it's significantly faster.
But the main reason is because it's idiomatic.

Cheers,
Chris

-- 
Follow the path of the Iguana...
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list