Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/2/2010 9:10 PM, D'Arcy J.M. Cain wrote: On 2 Jul 2010 15:00:17 -0700 a...@pythoncraft.com (Aahz) wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 So does http://www.Vex.Net/ so there's your two. Not according to Vex's published package list: http://www.vex.net/info/tech/pkglist/ They list packages only for Python 2.6. "vex.net" isn't exactly a major hosting service. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, with optional arguments
On 7/2/10 11:58 AM, Alf P. Steinbach /Usenet wrote:
>
> #Py3
I'm stuck on Python 2.x, as I mentioned (albeit only in a comment). That
said this code does not seem to be including any Py3isms that aren't
compatible.
> class Thing(object):
> @expose()
> def test1(self, arg1):
> return arg1
>
> @expose( "testing" )
> def test2(self, arg2):
> return arg2
Its the @expose() which bugs me. I have some decorators (made by me and
others) which have no args, that look like @hello. Then some which
always have args, that look like @hello("whatsup dude"). To then have a
decorator which has no args as @hello(), I can't abide. For internal
consistancy purposes, I want "no arguments" to always look like @hello,
and "arguments" to look like @hello(something). I don't want to have to
think, "Hey, does this no-arg version require parens or no?"
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
signature.asc
Description: OpenPGP digital signature
--
http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, with optional arguments
On 7/2/10 11:55 AM, Thomas Jollans wrote: > Looks good! You may still want to use functools.update_wrapper or > functools.wraps on "wrap". Are you sure? I've been doing a little bit of experimentation and I only did the 'wraps' on that inner function, because it seemed that it was all that was needed to get the propagation of function data I expected. I've since changed it to: def wrapper(fn, *args, **kwargs): print "Calling." result = fn(*args, **kwargs) print "Called." return result return decorator.decorator(wrapper, fn) Because the decorator library includes argspec propagation which was important for other parts of this code which does introspection. (This toy project is, I fully admit, going into very dark and evil places that I have at length advised people against, 'You don't want to do that!'). > PS: if you weren't stuck on 2.5, but were using 3.x, there's all kinds > of fun stuff you could do with function annotations ;-) Oh, believe me, I desperately wish I could go to 3.x. Between function annotations and the new metaclass power (Hi, __prepare__, I love you, please wait for me and I'll marry you when I migrate). I just can't yet. I can't quite figure out why people are all, '3.x brings you nothing'. Yes, the majority of the focus was cleaning, removing edges, but *lord* there's a LOT I am VERY looking forward to using. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ signature.asc Description: OpenPGP digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 2 Jul 2010 15:00:17 -0700 a...@pythoncraft.com (Aahz) wrote: > >5. Get at least two major hosting services to put up Python 3. > > webfaction.com has python3.1 So does http://www.Vex.Net/ so there's your two. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/2/2010 3:07 PM, John Nagle wrote: That's the real issue, not parentheses on the "print" statement. Where's the business case for moving to Python 3? It's not faster. It doesn't do anything you can't do in Python 2.6. False. One cannot run code in 2.6 that depends on bugfixes in 3.1. Nor can one run code with unicode identifiers. The exclusive new features in 3.1 and 3.2 are less than they might have been because the developers expended extra effort, now ended, to backport new things developed for 3.x. (One result was some neglect of the stdlib, which is now the focus of efforts.) One reason was to make porting to 3.x easier should one wish to do so. The other reason was to make some thing available should one wish not to do so. Using that extra effort as a reason to put down 3.x is not very gracious. There's no "killer app" for it. For some, unicode identifiers are 'killer reason' to use 3.1. Anyway, can you name me a "killer app" for each and every version of 2.x? > End of life for Python 2.x is many years away; Given that 1.x is still used, so what? most server Linux distros aren't even shipping with 2.6 yet. How can a business justify spending money on conversion to Python 3? How can a business justify spending money on conversion to 2.0, 2,1, 2.2, 2.3, 2.4, 2.5, 2.6, or soon, 2.7? Some cannot for some projects and have not. Enough with strawman arguments against claims no sensible person has made. Python3 was developed for new Python programmers and current programmers who wished to add or switch. It was developed for new code and old code that would benefit from the changes. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why Is Escaping Data Considered So Magical?
On Mon, Jun 28, 2010 at 6:44 PM, Gregory Ewing wrote: > Carl Banks wrote: > >> Indeed, strncpy does not copy that final NUL if it's at or beyond the >> nth element. Probably the most mind-bogglingly stupid thing about the >> standard C library, which has lots of mind-boggling stupidity. > > I don't think it was as stupid as that back when C was > designed Actually, strncpy had a very specific use case when it was introduced (dealing with limited-size entries in very old unix filesystem). It should never be used for C string handling, and I don't think it is fair to say it is stupid: it does exactly what it was designed for. It just happens that most people don't know what it was designed for. David -- http://mail.python.org/mailman/listinfo/python-list
Re: [farther OT] Re: Why Is Escaping Data Considered So Magical?
On Friday 02 July 2010 19:20:26 Lawrence D'Oliveiro wrote:
> In message , Rami
> Chowdhury wrote:
> > On Thursday 01 July 2010 16:50:59 Lawrence D'Oliveiro wrote:
> >> Nevertheless, it it at least self-consistent. To return to my original
> >>
> >> macro:
> >> #define Descr(v) &v, sizeof v
> >>
> >> As written, this works whatever the type of v: array, struct, whatever.
> >
> > Doesn't seem to, sorry. Using Michael Torrie's code example, slightly
> > modified...
> >
> > char *buf = malloc(512 * sizeof(char));
>
> Again, you misunderstand the difference between a C array and a pointer.
> Study the following example, which does work, and you might grasp the
> point:
>
> l...@theon:hack> cat test.c
> #include
>
> int main(int argc, char ** argv)
> {
> char buf[512];
> const int a = 2, b = 3;
> snprintf(&buf, sizeof buf, "%d + %d = %d\n", a, b, a + b);
> fprintf(stdout, buf);
> return
> 0;
> } /*main*/
> l...@theon:hack> ./test
> 2 + 3 = 5
I'm sorry, perhaps you've misunderstood what I was refuting. You posted:
> >> macro:
> >> #define Descr(v) &v, sizeof v
> >>
> >> As written, this works whatever the type of v: array, struct, whatever.
With my code example I found that, as others have pointed out, unfortunately it
doesn't work if v is a pointer to a heap-allocated area.
Rami Chowdhury
"A man with a watch knows what time it is. A man with two watches is never
sure". -- Segal's Law
+1-408-597-7068 / +44-7875-841-046 / +88-01819-245544
--
http://mail.python.org/mailman/listinfo/python-list
Re: why python don't support "extended slice direct assignment" for lists?
On Fri, Jul 2, 2010 at 7:19 PM, Robert William Hanks wrote: > to say is "wrong" i think is a bit too much, its just a different type of > usage, this type of sintax is extensively used in numpy arrays (extended > slice came from numerical python), just asking why not extend the sintax to > python list. (not sure if you can use None as in the code i posted in numpy > but numbers are ok). I was just rewriting some numpy code in pure python (no > numpy for python3 yet), personally i think the pure python way is just ugly > and more expensive. > > On Fri, Jul 2, 2010 at 10:55 PM, wrote: >> >> Send Python-list mailing list submissions to >> python-l...@python.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://mail.python.org/mailman/listinfo/python-list >> or, via email, send a message with subject or body 'help' to >> python-list-requ...@python.org >> >> You can reach the person managing the list at >> python-list-ow...@python.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Python-list digest..." >> >> Today's Topics: Please avoid replying to the list digest, especially without trimming, as it adds noise to the conversation (and can screw up threading). Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: [farther OT] Re: Why Is Escaping Data Considered So Magical?
In message , Rami
Chowdhury wrote:
> On Thursday 01 July 2010 16:50:59 Lawrence D'Oliveiro wrote:
>
>> Nevertheless, it it at least self-consistent. To return to my original
>> macro:
>>
>> #define Descr(v) &v, sizeof v
>>
>> As written, this works whatever the type of v: array, struct, whatever.
>
> Doesn't seem to, sorry. Using Michael Torrie's code example, slightly
> modified...
>
> char *buf = malloc(512 * sizeof(char));
Again, you misunderstand the difference between a C array and a pointer.
Study the following example, which does work, and you might grasp the point:
l...@theon:hack> cat test.c
#include
int main(int argc, char ** argv)
{
char buf[512];
const int a = 2, b = 3;
snprintf(&buf, sizeof buf, "%d + %d = %d\n", a, b, a + b);
fprintf(stdout, buf);
return
0;
} /*main*/
l...@theon:hack> ./test
2 + 3 = 5
--
http://mail.python.org/mailman/listinfo/python-list
Re: why python don't support "extended slice direct assignment" for lists?
to say is "wrong" i think is a bit too much, its just a different type of
usage, this type of sintax is extensively used in numpy arrays (extended
slice came from numerical python), just asking why not extend the sintax to
python list. (not sure if you can use None as in the code i posted in numpy
but numbers are ok). I was just rewriting some numpy code in pure python (no
numpy for python3 yet), personally i think the pure python way is just ugly
and more expensive.
On Fri, Jul 2, 2010 at 10:55 PM, wrote:
> Send Python-list mailing list submissions to
>python-list@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>http://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
>python-list-requ...@python.org
>
> You can reach the person managing the list at
>python-list-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
>
> Today's Topics:
>
> 1. Re: Why defaultdict? (Steven D'Aprano)
> 2. Re: why python don't support "extended slice direct
> assignment" for lists? (Shashwat Anand)
> 3. Sorting dicts inside dicts (abhijeet thatte)
> 4. Re: The real problem with Python 3 - no business case for
> conversion(was "I strongly dislike Python 3") (Shashwat Anand)
> 5. Crash in PyThread_acquire_lock (moerchendiser2k3)
> 6. Re: why python don't support "extended slice direct
> assignment" for lists? (MRAB)
> 7. Re: Sorting dicts inside dicts (MRAB)
> 8. Re: tp_richcompare vs tp_compare (Aahz)
> 9. Re: The real problem with Python 3 - no business case for
> conversion(was "I strongly dislike Python 3") (Aahz)
> 10. Re: Anyone using GPG or PGP encryption/signatures in your
> Python apps? (Martin Manns)
>
>
> -- Forwarded message --
> From: Steven D'Aprano
> To: python-list@python.org
> Date: 02 Jul 2010 23:59:52 GMT
> Subject: Re: Why defaultdict?
> On Fri, 02 Jul 2010 04:11:49 +, Steven D'Aprano wrote:
>
> > I would like to better understand some of the design choices made in
> > collections.defaultdict.
> [...]
>
>
> Thanks to all who replied.
>
>
> --
> Steven
>
>
>
>
>
> -- Forwarded message --
> From: Shashwat Anand
> To: Robert William Hanks
> Date: Sat, 3 Jul 2010 05:32:31 +0530
> Subject: Re: why python don't support "extended slice direct assignment"
> for lists?
>
>
> On Sat, Jul 3, 2010 at 4:54 AM, Robert William Hanks <
> astroultra...@gmail.com> wrote:
>
>> why pure python don't support "extended slice direct assignment" for
>> lists?
>>
>> today we have to write like this,
>>
>> >>> aList=[0,1,2,3,4,5,6,7,8,9]
>> >>> aList
>> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>> >>> aList[::2]= [None]*len(aList[::2]) #or do the math by hand, what's
>> not always possible
>>
>
> Can you show me a case where it really is cumbersome.
>
>
>> >>> aList
>> [None, 1, None, 3, None, 5, None, 7, None, 9]
>>
>> why not accept syntax like this for extended slice
>>
>> aList[::2] = None
>>
>> when let's say, the left side is a list and the right side is bool, int or
>> float.
>> the laborious [nunber]*len(aList[::2]) seens to me less readable when you
>> want to set lost of items of a list to the same number.
>> Also correct me if i am wrong, calling len() and building a list to this
>> kind of operation seems a waste.
>>
>
> >>> aList[::2]
> [0, 2, 4, 6, 8]
> Which means you are doing [0, 2, 4, 6, 8] = None, which is plain and simple
> - wrong. How will you define the legitimacy of this statement.
> What you are basically doing here is,,
>
> >>> [None]*len(aList[::2])
> [None, None, None, None, None]
> >>> aList[::2]
> [0, 2, 4, 6, 8]
>
> Setting [0, 2, 4, 6, 8] to [None, None, None, None, None], thereby
> operating on two similar data structure (here list)
>
>
>> Just want some feedback.
>>
>
> Just my thoughts.
>
> ~l0nwlf
>
>
>
> -- Forwarded message --
> From: abhijeet thatte
> To: python-list@python.org
> Date: Fri, 2 Jul 2010 17:17:36 -0700
> Subject: Sorting dicts inside dicts
> Hi,
> I have a huge dict structure like below:
> *
> {'module':{'reg_dict_0':{'name':'abc','reg_addr':'2004'},'reg_dict_1':{'name':'xyz','reg_addr':'2002'},'reg_dict_2':{'name':'pqr','reg_addr':'2008'}}
> *
>
> Module dict and reg_dicts contain many elements than shown.
>
> I want to sort this 'module' dictionary as per 'reg_addr' element in every
> 'reg_dict'.
>
> There is no relation between 'reg_dict' suffix and address. So, reg_dict_0
> can contain reg_address = 2000/72 (any number)
> I do not want output in a list format as the actual dict size is huge which
> I want to use based on key value pair.
>
> So, I want output as :
>
> *
> {'module':{'reg_dict_1':{'name':'xyz','reg_addr':'2002'},'reg_dict_0':{'name':'abc','reg_addr':'2004'},'reg_dict_2':{'name':'pqr','reg_addr':'2008'}}
> *
> *
> *
>
> Is it possible to sort the things? What I
Re: Anyone using GPG or PGP encryption/signatures in your Python apps?
On Thu, 01 Jul 2010 14:48:47 -0400 pyt...@bdurham.com wrote: > Curious if any of you are using GPG or PGP encryption and/or > signatures in your Python apps? ... > 4. generating signatures for files that you are exchanging/posting for > download? I use pyme to create and check save file signatures. > 5. what public keyring services are you using? None > Any comments on using the subprocess module to wrap the gpg or openssl > command line utilities? This seems to be a common technique for > encryption and signing solutions and appears to the technique used by > python-gnupg (for example). pyme works great with Linux. However, I have never installed it on a Windows system. Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
In article <4c2e79d3$0$1663$742ec...@news.sonic.net>, John Nagle wrote: >On 7/2/2010 3:00 PM, Aahz wrote: >> In article<4c2e38f5.10...@animats.com>, John Nagle wrote: >>> >>> 5. Get at least two major hosting services to put up Python 3. >> >> webfaction.com has python3.1 > >Any user can install Python 3.x, but it's not there by default. Yes, it is. I logged into my webfaction shell, typed python3.1, and got a standard Python prompt, without doing anything whatsoever to make Python 3.1 available. >"http://blog.webfaction.com/python-3-0-is-here"; Is there some reason you're using a broken URL format? >If that approach catches on, Python 3 deployment will be much easier. >But for now, only a few smaller players like WebFaction are using it. In the hosting space that makes Python available, WebFaction is hardly a smaller player. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: tp_richcompare vs tp_compare
In article , moerchendiser2k3 wrote: > >Do I need to implement both? Looks very redundant, isnt it? Or is it >just an extension and tp_richcompare is the better choice here? Can >anyone please make the light on here? :) Nobody else responded, so please take this non-expert advice: tp_compare is the older and now deprecated slot; you want to use tp_richcompare if you don't need to support older versions of Python. Don't implement both. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: Sorting dicts inside dicts
abhijeet thatte wrote:
Hi,
I have a huge dict structure like below:
/*{'module':{'reg_dict_0':{'name':'abc','reg_addr':'2004'},'reg_dict_1':{'name':'xyz','reg_addr':'2002'},'reg_dict_2':{'name':'pqr','reg_addr':'2008'}}*/
Module dict and reg_dicts contain many elements than shown.
I want to sort this 'module' dictionary as per 'reg_addr' element in
every 'reg_dict'.
There is no relation between 'reg_dict' suffix and address. So,
reg_dict_0 can contain reg_address = 2000/72 (any number)
I do not want output in a list format as the actual dict size is huge
which I want to use based on key value pair.
So, I want output as :
/*{'module':{'reg_dict_1':{'name':'xyz','reg_addr':'2002'},'reg_dict_0':{'name':'abc','reg_addr':'2004'},'reg_dict_2':{'name':'pqr','reg_addr':'2008'}}*/
/*
*/
Is it possible to sort the things? What I guess is Python stores dicts
in a tree like structure but I am forcing it to store the way I want. Is
it possible to do something like that.
Python dicts are implemented as hash tables, not trees, for speed, and
they are unordered.
If the order matters then you should use an ordered dict instead. You
should be able to find an implementation of one.
--
http://mail.python.org/mailman/listinfo/python-list
Re: why python don't support "extended slice direct assignment" for lists?
Robert William Hanks wrote: why pure python don't support "extended slice direct assignment" for lists? today we have to write like this, >>> aList=[0,1,2,3,4,5,6,7,8,9] >>> aList [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> aList[::2]= [None]*len(aList[::2]) #or do the math by hand, what's not always possible >>> aList [None, 1, None, 3, None, 5, None, 7, None, 9] why not accept syntax like this for extended slice aList[::2] = None when let's say, the left side is a list and the right side is bool, int or float. the laborious [nunber]*len(aList[::2]) seens to me less readable when you want to set lost of items of a list to the same number. Also correct me if i am wrong, calling len() and building a list to this kind of operation seems a waste. Just want some feedback. When you're assigning to a list slice, why should it duplicate an int but not a list? Or in general, duplicate something that's not iterable but not something that is iterable? A string is iterable, so what should: >>> a[ : : 2] = "abcde" do? It's just simpler and less surprising the way it is. -- http://mail.python.org/mailman/listinfo/python-list
Crash in PyThread_acquire_lock
Hi all,
I have a serious problem I want to solve. My app, where
Python is embedded crashs on OSX (10.6 SL). I can reproduce the crash
sometimes with a script that makes use of Python threads ( module:
threading).
'thelock->locked' is for sure still locked, but I can't identify the
problem.
Its just waiting, but it gets a 'EXC_BAD_ACCESS'. The line of the
crash
in PyThread_acquire_lock is the following one:
while ( thelock->locked ) {
status = pthread_cond_wait(&thelock->lock_released, &thelock-
>mut); <<
>From the view of my code, I can exclude that the GIL was ensured but
not properly released
by PyStateGIL_Ensure and PyStateGIL_Release.
Any ideas how to get rid of this crash somehow? Thanks in advance!!
Bye, moerchendiser2k3
#0 0x7fff86c95316 in __semwait_signal ()
#1 0x7fff86c99131 in _pthread_cond_wait ()
#2 0x00011c89f8f4 in PyThread_acquire_lock (lock=0x1013803c0,
waitflag=1) at thread_pthread.h:452
#3 0x00011c84a414 in PyEval_RestoreThread (tstate=0x101380200) at
Python/ceval.c:334
#4 0x00011c889725 in PyGILState_Ensure () at Python/pystate.c:592
--
http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On Sat, Jul 3, 2010 at 5:27 AM, Steven D'Aprano < st...@remove-this-cybersource.com.au> wrote: > On Fri, 02 Jul 2010 12:07:33 -0700, John Nagle wrote: > > > Where's the business case for moving to Python 3? It's not faster. It > > doesn't do anything you can't do in Python 2.6. There's no "killer app" > > for it. End of life for Python 2.x is many years away; most server Linux > > distros aren't even shipping with 2.6 yet. How can a business justify > > spending money on conversion to Python 3? > The point is python2.7 is the last 2.x version. It will be supported, bugs will be fixed but no new feature will be added. Core devs will concentrate on python 3.x. You can still use 2.x, no one is stopping you. But assume that it is stagnant now. After some time only security related bugs will be fixed. So if you want to wait by then, it's all your wish. ~l0nwlf -- http://mail.python.org/mailman/listinfo/python-list
Sorting dicts inside dicts
Hi,
I have a huge dict structure like below:
*
{'module':{'reg_dict_0':{'name':'abc','reg_addr':'2004'},'reg_dict_1':{'name':'xyz','reg_addr':'2002'},'reg_dict_2':{'name':'pqr','reg_addr':'2008'}}
*
Module dict and reg_dicts contain many elements than shown.
I want to sort this 'module' dictionary as per 'reg_addr' element in every
'reg_dict'.
There is no relation between 'reg_dict' suffix and address. So, reg_dict_0
can contain reg_address = 2000/72 (any number)
I do not want output in a list format as the actual dict size is huge which
I want to use based on key value pair.
So, I want output as :
*
{'module':{'reg_dict_1':{'name':'xyz','reg_addr':'2002'},'reg_dict_0':{'name':'abc','reg_addr':'2004'},'reg_dict_2':{'name':'pqr','reg_addr':'2008'}}
*
*
*
Is it possible to sort the things? What I guess is Python stores dicts in a
tree like structure but I am forcing it to store the way I want. Is it
possible to do something like that.
Thanks,
--
http://mail.python.org/mailman/listinfo/python-list
Re: why python don't support "extended slice direct assignment" for lists?
On Sat, Jul 3, 2010 at 4:54 AM, Robert William Hanks < astroultra...@gmail.com> wrote: > why pure python don't support "extended slice direct assignment" for lists? > > today we have to write like this, > > >>> aList=[0,1,2,3,4,5,6,7,8,9] > >>> aList > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > >>> aList[::2]= [None]*len(aList[::2]) #or do the math by hand, what's not > always possible > Can you show me a case where it really is cumbersome. > >>> aList > [None, 1, None, 3, None, 5, None, 7, None, 9] > > why not accept syntax like this for extended slice > > aList[::2] = None > > when let's say, the left side is a list and the right side is bool, int or > float. > the laborious [nunber]*len(aList[::2]) seens to me less readable when you > want to set lost of items of a list to the same number. > Also correct me if i am wrong, calling len() and building a list to this > kind of operation seems a waste. > >>> aList[::2] [0, 2, 4, 6, 8] Which means you are doing [0, 2, 4, 6, 8] = None, which is plain and simple - wrong. How will you define the legitimacy of this statement. What you are basically doing here is,, >>> [None]*len(aList[::2]) [None, None, None, None, None] >>> aList[::2] [0, 2, 4, 6, 8] Setting [0, 2, 4, 6, 8] to [None, None, None, None, None], thereby operating on two similar data structure (here list) > Just want some feedback. > Just my thoughts. ~l0nwlf -- http://mail.python.org/mailman/listinfo/python-list
Re: Why defaultdict?
On Fri, 02 Jul 2010 04:11:49 +, Steven D'Aprano wrote: > I would like to better understand some of the design choices made in > collections.defaultdict. [...] Thanks to all who replied. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On Fri, 02 Jul 2010 12:07:33 -0700, John Nagle wrote: > Where's the business case for moving to Python 3? It's not faster. It > doesn't do anything you can't do in Python 2.6. There's no "killer app" > for it. End of life for Python 2.x is many years away; most server Linux > distros aren't even shipping with 2.6 yet. How can a business justify > spending money on conversion to Python 3? If you (generic you, not John specifically) can't, then don't. It's as simple as that. Stick with 2.6, or 2.7, or even 1.5 if that's the version you're using. A client of mine is still using 2.3. That's okay. It's allowed. If your business case is best satisfied by staying with 2.x until the sun burns out, more power to you. Just don't expect security upgrades (let alone functional upgrades) for more than a few years. If they are important to you, then *that's* your business case for upgrading. But if you're starting a new project, there is no cost of conversion. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 7/2/2010 3:00 PM, Aahz wrote: In article<4c2e38f5.10...@animats.com>, John Nagle wrote: 5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 WebFaction's big thing is that they have a really good system for installing anything the user wants. They're doing semi-virtual machine hosting, where each user sees a somewhat different environment, but doesn't have their own copy of the Linux kernel. That's a nice advance in server management. Any user can install Python 3.x, but it's not there by default. See: "http://blog.webfaction.com/python-3-0-is-here"; If that approach catches on, Python 3 deployment will be much easier. But for now, only a few smaller players like WebFaction are using it. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion
John Nagle writes: > Where's the business case for moving to Python 3? It's not faster. It's faster to learn, because there's less to learn. How do you know that it's not faster? That's a matter of the speed of individual Python implementations. What data do you have? > It doesn't do anything you can't do in Python 2.6. In the trivial sense that Python doesn't do anything you can't do in pure assembly language, that's true. In the more interesting sense of what can the *programmer* do, there are a number of improvements (dealing with Unicde more sanely; keyword-only arguments; function annotations; etc.) that can't be done in Python 2. That set will only grow over time. > How can a business justify spending money on conversion to Python > 3? You'll have to ask the ones that *have* justified that expense. There are major libraries that work with Python 3 now because people have been funded to work on getting there, and others are happening now. >What I'm not seeing is a deployment plan along these lines: > >1. Identify key modules which must be converted before Python 3 > can be used in production environments. This needs to be done by those who want to use Python. You can't expect a single “key modules” for the whole of the Python ecosystem. >2. Get those modules converted to Python 3. Many of them have been converted, and many more are under active development. But this is entirely dependent on which libraries the specific use case demands. >3. Put together a distribution for the major platforms (at least > Linux and Windows) with builds of those modules. The better path for the GNU distributions is to get the package distributed by the operating system distributor, instead of expecting every developer to also get the packaging right. Fortunately, for a great many key libraries, that's already the case in Debian which is a huge share of the “major platforms”. >4. Get some major distros, like Debian and ActiveState, to > include Python 3, as "python3", not as the primary Python, > so there are no conflicts. (Debian already has a formal > policy to keep Python versions separate.) You know this is already the case; why are you saying you don't see it? >5. Get at least two major hosting services to put up Python 3. > >6. Get at least two popular end-user programs (not modules) to > support Python 3. And how is this part of a plan for the PYthon developers? What are you suggesting they do to “get [someone] to support Python 3”? That's up to the someone, surely? >7. Publicize some success stories. > > Unless the Python 3 enthusiasts get their act together and work much > harder on providing an easy transition experience, it's not going to > happen. Since you clearly don't count yourself in the set of “Python 3 enthusiasts”, why do you keep demanding that they do something you expressly don't care about? -- \ “If you do not trust the source do not use this program.” | `\—Microsoft Vista security dialogue | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
why python don't support "extended slice direct assignment" for lists?
why pure python don't support "extended slice direct assignment" for lists? today we have to write like this, >>> aList=[0,1,2,3,4,5,6,7,8,9] >>> aList [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> aList[::2]= [None]*len(aList[::2]) #or do the math by hand, what's not always possible >>> aList [None, 1, None, 3, None, 5, None, 7, None, 9] why not accept syntax like this for extended slice aList[::2] = None when let's say, the left side is a list and the right side is bool, int or float. the laborious [nunber]*len(aList[::2]) seens to me less readable when you want to set lost of items of a list to the same number. Also correct me if i am wrong, calling len() and building a list to this kind of operation seems a waste. Just want some feedback. -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
On 7/2/2010 2:38 PM Jay said... OK, so how does a program read the pixel? Well, you start with a screen capture utility. I'd check is pywinauto provides that access... Emile -- http://mail.python.org/mailman/listinfo/python-list
IMAP Problems
Hi,
I'm trying to write a simple script which displays the basic details
of a person's mailbox. My problem is that it causes all the messages
to be marked as read on the server, which is not what I'm after, and I
also can't get the imap.sort command to work properly (currently
commented out as I replaced it with a imap.search to get the thing
working.
These are probably very simple things, but I've not tried this library
before so am a bit stuck so any help wwould be very gratefully
received.
Thanks,
Paul
Code:
# -*- coding: cp1252 -*-
import imaplib,email
# you want to connect to a server; specify which server
server= imaplib.IMAP4_SSL('imap.googlemail.com')
# after connecting, tell the server who you are
server.login('x...@gmail.com', 'xxx')
# this will show you a list of available folders
# possibly your Inbox is called INBOX, but check the list of mailboxes
code, mailboxen= server.list()
print mailboxen
# if it's called INBOX, then…
server.select("INBOX")
typ, data = server.search(None, 'ALL')
#typ, data = server.sort("Date","UTF-8", 'ALL')
print len(data[0].split())
for num in data[0].split():
typ, data = server.fetch(num, '(RFC822)')
#print 'Message %s\n%s\n' % (num, data[0][1])
msg = email.message_from_string(data[0][1])
print msg["From"]
print msg["Subject"]
print msg["Date"]
print "___"
server.close()
server.logout()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Namespace problem?
On Jul 1, 3:30 pm, "Rhodri James" wrote: > > If this is a version of your code that actually fails when you run it > (rather than being another artistic interpretation of a photograph of your > code :-), then I'd go with Matt's analysis. This will give you a > NameError for fws_last_col if tracker.hasFWS() happens to return False for > all students. > Actually, tracker.hasFWS() was returning False for an entirely different reason that I didn't expect until I had the script dump all the information it was processing. Thanks for the clue. I added one parameter to one function elsewhere and the thing seems to be working again. Thanks for the help. Josh -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
In article <4c2e38f5.10...@animats.com>, John Nagle wrote: > >5. Get at least two major hosting services to put up Python 3. webfaction.com has python3.1 -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
On Jul 2, 2:13 pm, Terry Reedy wrote: > On 7/1/2010 10:18 PM, Emile van Sebille wrote: > > > > > > > On 7/1/2010 6:17 PM Terry Reedy said... > >> On 7/1/2010 6:42 PM, Emile van Sebille wrote: > >>> On 7/1/2010 2:52 PM Jay said... > pywinauto looks to be almost perfect. All I need now is to read the > numbers uncovered when a minesweeper square is clicked on, or that I > just hit a mine. > > >>> ... or, you could always win... > > >>>http://www.daniweb.com/forums/thread186209.html > > >> Did you actually try it? Though skeptical, I did, briefly, until I > >> decided that it probably should have been dated April 1. There is no way > >> to enter text into minesweeper, nor to make it full screen, nor, as far > >> as I know, for it to toggle pixels outside its window. > > > Yes. It works. > > Thanks all. I tried again with other windows minimized so that the upper > left pixel is medium brown from the wallpaper, and I can make out the > white pixel. A maximized unfocued background window has that pixel > normally black surrounded by light blue pixels that make one white pixel > harder to see for imperfect eyes. Live, post errors, and learn ;-). > > -- > Terry Jan Reedy- Hide quoted text - > > - Show quoted text - OK, so how does a program read the pixel? -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
On Jul 2, 6:17 am, superpollo wrote: > Ethan Furman ha scritto: > > > > > Terry Reedy wrote: > >> On 7/1/2010 6:42 PM, Emile van Sebille wrote: > > >>> On 7/1/2010 2:52 PM Jay said... > > pywinauto looks to be almost perfect. All I need now is to read the > numbers uncovered when a minesweeper square is clicked on, or that I > just hit a mine. > > >>> ... or, you could always win... > > >>>http://www.daniweb.com/forums/thread186209.html > > >> Did you actually try it? Though skeptical, I did, briefly, until I > >> decided that it probably should have been dated April 1. There is no > >> way to enter text into minesweeper, nor to make it full screen, nor, > >> as far as I know, for it to toggle pixels outside its window. > > > The pixel can be hard to see depending on your background colors and > > whether your screen is adjusted correctly (I could see the white, but > > not the black). But on XP Pro is still works. > > works for me too I'm confirming that it even works with Wine emulator in Linux. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
On 7/1/2010 10:18 PM, Emile van Sebille wrote: On 7/1/2010 6:17 PM Terry Reedy said... On 7/1/2010 6:42 PM, Emile van Sebille wrote: On 7/1/2010 2:52 PM Jay said... pywinauto looks to be almost perfect. All I need now is to read the numbers uncovered when a minesweeper square is clicked on, or that I just hit a mine. ... or, you could always win... http://www.daniweb.com/forums/thread186209.html Did you actually try it? Though skeptical, I did, briefly, until I decided that it probably should have been dated April 1. There is no way to enter text into minesweeper, nor to make it full screen, nor, as far as I know, for it to toggle pixels outside its window. Yes. It works. Thanks all. I tried again with other windows minimized so that the upper left pixel is medium brown from the wallpaper, and I can make out the white pixel. A maximized unfocued background window has that pixel normally black surrounded by light blue pixels that make one white pixel harder to see for imperfect eyes. Live, post errors, and learn ;-). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On Jul 2, 12:07 pm, John Nagle wrote: > This has all been said before. Yes, we know. And when no one did anything about it the first dozen times it's been said, it wasn't because we didn't hear it, it was because we didn't care. We still don't care now, and won't care no matter how many times you repeat it, because it's simply wrong. So, please do everyone a favor, and stop wasting your own time, and stop repeating this. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: GAE + recursion limit
> Does anyone have any clue what that might be? > Why the problem is on GAE (even when run locally), when command line > run works just fine (even with recursion limit decreased)? Can't explain why you see different behavior on GAE vs. local, but it is unusual for a "small" translator to flirt with recursion limit. I don't usually see parsers come close to this with fewer than 40 or 50 sub-expressions. You may have some left-recursion going on. Can you post your translator somewhere, perhaps on pastebin, or on the pyparsing wiki Discussion page (pyparsing.wikispaces.com)? -- Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Lockless algorithms in python (Nothing to do with GIL)
On Mon, 28 Jun 2010 16:46:41 -0700
Zac Burns wrote:
> In my experience it is far more expensive to allocate a lock in python then
> it is the types that use them. Here are some examples:
>
> >>> timeit.timeit('Lock()', 'from threading import Lock')
> 1.4449114807669048
>
> >>> timeit.timeit('dict()')
> 0.2821554294221187
>
> >>> timeit.timeit('list()')
> 0.17358153222312467
I'm not sure what Python version on what machine you are using, but
here (Python 2.7):
>>> timeit.timeit('Lock()', 'from threading import Lock')
0.09944796562194824
>>> timeit.timeit('dict()')
0.17817902565002441
>>> timeit.timeit('list()')
0.19633007049560547
>>> timeit.timeit('{}')
0.03823709487915039
>>> timeit.timeit('[]')
0.05156302452087402
--
http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, with optional arguments
On Jul 2, 10:41 am, Stephen Hansen wrote:
> Okay, so!
>
> I actually never quite got around to learning to do deep and useful
> magic with decorators. I've only ever done the most basic things with
> them. Its all been a little fuzzy in my head: things like what order
> decorators end up being called in if there's more then one, etc.
>
> But in my current situation, what I'm wanting to do is have a decorator
> that wraps a function but which takes an *optional* argument, and sets
> that argument as an attribute on said function if its there.
>
> Here's what some tweaking and playing around has gotten me, as a recipe:
>
> import functools
>
> def my_decorator(arg):
> if callable(arg): # Stuck on 2.5. Leavemealone. :)
> protocol = None
> else:
> protocol = arg
>
> def wrap(fn):
> print "Wrapping."
> fn.protocol = protocol
>
> �...@functools.wraps(fn)
> def wrapper(*args, **kwargs):
> print "Calling."
> result = fn(*args, **kwargs)
> print "Called."
> return result
>
> return wrapper
>
> if not protocol: # argument-less decorator
> print "Calling wrap."
> return wrap(arg)
> else:
> print "Returning wrap."
> return wrap
>
> To be used as:
>
> class Thing(object):
> �...@expose
> def test1(self, arg1):
> return arg1
>
> �...@expose("testing")
> def test2(self, arg2):
> return arg2
>
> So, my question: am I doing this right? :) Some play-through testing
> appears to work. But, the dizzying array of nested def's up there leaves
> me a bit dazed, so I'm wondering if there's a simpler way to accomplish
> what I'm trying to do.
I usually recommend to factoring out magic parts into their own little
function, which then invoke the non-magical part in different ways:
def expose_as(protocol):
def wrap(fn):
print "Wrapping."
fn.protocol = protocol
@functools.wraps(fn)
def wrapper(*args, **kwargs):
print "Calling."
result = fn(*args, **kwargs)
print "Called."
return result
return wrapper
return wrap
def expose(arg):
"""Magic function to allow omitting argument."""
if type(arg) is types.FunctionType:
print "Calling with arg as function"
return expose_as(None)(arg)
print "Calling with arg as protocol"
return expose_as(arg)
I believe it's a good practice to isolate magic so that it's easy to
see, and also to ensure there's a non-magical way to do it if that is
needed. However, the world won't come to an end if you do it your
way.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
On 07/02/2010 09:07 PM, John Nagle wrote: > >What I'm not seeing is a deployment plan along these lines: > >1.Identify key modules which must be converted before Python 3 > can be used in production environments. That depends VERY strongly on the environment in question. > >2.Get those modules converted to Python 3. The stdlib is there. The rocky bits are being fixed all the time. The other important modules all have strong development communities. Upstream numpy works with Python 3 already. (no release yet) That enables SciPy to update, which they will do. PyGObject is also working on Py3 support. > >3.Put together a distribution for the major platforms (at least > Linux and Windows) with builds of those modules. This > could be done on PyPi, which is at present is mostly a link > farm, not a repository. The use cases for Python being as diverse as they are, this is utter nonsense. Also, I myself see no benefit in making PyPI a mirror of everything, as opposed to a useful index of packages that you may or may not want to use. > >4.Get some major distros, like Debian and ActiveState, to > include Python 3, as "python3", not as the primary Python, > so there are no conflicts. (Debian already has a formal > policy to keep Python versions separate.) Current Ubuntu releases include Python 3.1 as /usr/bin/python3. So does Debian (not sure about stable at this point). I'm sure the other major Linux distributions are doing the same thing. It's happening! > >5.Get at least two major hosting services to put up Python 3. Apparently, some hosters already support Python 3. Web development is a bit of a weak spot at the moment though, and this is problematic, due to WSGI not being quite unicode ready. > >6.Get at least two popular end-user programs (not modules) to > support Python 3. > >7.Publicize some success stories. > > Unless the Python 3 enthusiasts get their act together and work much > harder on providing an easy transition experience, it's not going to > happen. It's not happening fast, it probably can't, but it *is* happening. Software distributions are including Python 3, and popular modules/packages are starting to support it. Other software is going to move on in its own time. -- http://mail.python.org/mailman/listinfo/python-list
The real problem with Python 3 - no business case for conversion (was "I strongly dislike Python 3")
David Cournapeau wrote: I think one point which needs to be emphasized more is what does python 3 bring to people. The" what's new in python 3 page" gives the impression that python 3 is about removing cruft. That's a very poor argument to push people to switch. That's the real issue, not parentheses on the "print" statement. Where's the business case for moving to Python 3? It's not faster. It doesn't do anything you can't do in Python 2.6. There's no "killer app" for it. End of life for Python 2.x is many years away; most server Linux distros aren't even shipping with 2.6 yet. How can a business justify spending money on conversion to Python 3? If Python 3 came with Unladen Swallow, and ran several times faster than Python 2.x, there'd be a strong business case for conversion. Especially for large sites with racks of servers grinding through slow CPython code. But it looks like Unladen Swallow will be available for 2.6 before it's available for 3.x. So that's not a selling point for 3.x. Python 3 is a nice cleanup of some legacy syntax issues. But that's just not enough. Perl 6 is a nice cleanup of Perl 5, and look how that went. Ten years on, it's not even mainstream, let alone dominant. This has all been said before. See "Python 3.0: What’s The Point?" from December 2008: http://jens.mooseyard.com/2008/12/python-30-whats-the-point/ Not much has changed since then. What I'm not seeing is a deployment plan along these lines: 1. Identify key modules which must be converted before Python 3 can be used in production environments. 2. Get those modules converted to Python 3. 3. Put together a distribution for the major platforms (at least Linux and Windows) with builds of those modules. This could be done on PyPi, which is at present is mostly a link farm, not a repository. 4. Get some major distros, like Debian and ActiveState, to include Python 3, as "python3", not as the primary Python, so there are no conflicts. (Debian already has a formal policy to keep Python versions separate.) 5. Get at least two major hosting services to put up Python 3. 6. Get at least two popular end-user programs (not modules) to support Python 3. 7. Publicize some success stories. Unless the Python 3 enthusiasts get their act together and work much harder on providing an easy transition experience, it's not going to happen. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, with optional arguments
* Stephen Hansen, on 02.07.2010 19:41:
Okay, so!
I actually never quite got around to learning to do deep and useful
magic with decorators. I've only ever done the most basic things with
them. Its all been a little fuzzy in my head: things like what order
decorators end up being called in if there's more then one, etc.
But in my current situation, what I'm wanting to do is have a decorator
that wraps a function but which takes an *optional* argument, and sets
that argument as an attribute on said function if its there.
Here's what some tweaking and playing around has gotten me, as a recipe:
import functools
def my_decorator(arg):
if callable(arg): # Stuck on 2.5. Leavemealone. :)
protocol = None
else:
protocol = arg
def wrap(fn):
print "Wrapping."
fn.protocol = protocol
@functools.wraps(fn)
def wrapper(*args, **kwargs):
print "Calling."
result = fn(*args, **kwargs)
print "Called."
return result
return wrapper
if not protocol: # argument-less decorator
print "Calling wrap."
return wrap(arg)
else:
print "Returning wrap."
return wrap
To be used as:
class Thing(object):
@expose
def test1(self, arg1):
return arg1
@expose("testing")
def test2(self, arg2):
return arg2
So, my question: am I doing this right? :) Some play-through testing
appears to work. But, the dizzying array of nested def's up there leaves
me a bit dazed, so I'm wondering if there's a simpler way to accomplish
what I'm trying to do.
If you're willing to have slightly more explicit usage code, consider e.g.
#Py3
import functools
class expose:
def __init__( self, protocol = None ):
self._protocol = protocol
def __call__( self, f ):
print( "Wrapping." )
f.protocol = self._protocol
@functools.wraps( f )
def wrapper( *args, **kwargs ):
print( "Calling." )
result = f( *args, **kwargs )
print( "Called." )
return result
return wrapper
class Thing(object):
@expose()
def test1(self, arg1):
return arg1
@expose( "testing" )
def test2(self, arg2):
return arg2
o = Thing()
print( o.test1( 1.11 ) )
print( o.test2( 2.22 ) )
Cheers & hth.,
- Alf
--
blog at http://alfps.wordpress.com>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, with optional arguments
I like to think of decorators with arguments as decorator factory functions.
I try and unroll them as much as possible... I have some decorators that
work like so (and please note that the wraps and returns_as_output are
separate so that I can mutate the behavior as needed, if you just wanted a
single decorator this could be condensed):
def wrap(f, wrapping_function, *args):
argspec = inspect.getargspec(f)
without_defaults = len(argspec.args) - len(argspec.defaults or [])
f._args = {}
f._varkw = []
f._arg_defaults = (None,) * without_defaults + (argspec.defaults or
tuple())
for arg in args:
if arg in argspec.args:
f._args[arg] = argspec.args.index(arg)
else:
if argspec.keywords:
f._varkw.append(arg)
return decorator.decorator(wrapping_function, f)
def return_as_output(output_f):
def func(f, *args, **kwargs):
new_args = list(args)
for (dict_name, index) in f._args.items():
if len(args) > index:
new_args[index] = output_f(args[index])
else:
d = f._arg_defaults[index]
kwargs[dict_name] = output_f(kwargs.pop(dict_name, d))
for dict_name in f._varkw:
kwargs[dict_name] = output_f(kwargs.pop(dict_name, None))
return f(*new_args, **kwargs)
return func
def iterables(*args):
'''
Decorator that guarantees that the named arguments will be iterable.
'''
as_iterables = return_as_output(iter_)
return lambda f: wrap(f, as_iterables, *args)
Just as an example... I have a family of decorators that check compliance
with abstract base classes, then try to mutate variables to provide it if
duck typing would fail. I don't know if this helps, it is kind of
convoluted, but hopefully it gives you another example to work from.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Decorators, with optional arguments
On 07/02/2010 07:41 PM, Stephen Hansen wrote:
> Okay, so!
>
> I actually never quite got around to learning to do deep and useful
> magic with decorators. I've only ever done the most basic things with
> them. Its all been a little fuzzy in my head: things like what order
> decorators end up being called in if there's more then one, etc.
>
> But in my current situation, what I'm wanting to do is have a decorator
> that wraps a function but which takes an *optional* argument, and sets
> that argument as an attribute on said function if its there.
>
> Here's what some tweaking and playing around has gotten me, as a recipe:
>
> import functools
>
> def my_decorator(arg):
> if callable(arg): # Stuck on 2.5. Leavemealone. :)
> protocol = None
> else:
> protocol = arg
>
> def wrap(fn):
> print "Wrapping."
> fn.protocol = protocol
>
> @functools.wraps(fn)
> def wrapper(*args, **kwargs):
> print "Calling."
> result = fn(*args, **kwargs)
> print "Called."
> return result
>
> return wrapper
>
> if not protocol: # argument-less decorator
> print "Calling wrap."
> return wrap(arg)
> else:
> print "Returning wrap."
> return wrap
Looks good! You may still want to use functools.update_wrapper or
functools.wraps on "wrap".
PS: if you weren't stuck on 2.5, but were using 3.x, there's all kinds
of fun stuff you could do with function annotations ;-)
>
> To be used as:
>
> class Thing(object):
> @expose
> def test1(self, arg1):
> return arg1
>
> @expose("testing")
> def test2(self, arg2):
> return arg2
>
> So, my question: am I doing this right? :) Some play-through testing
> appears to work. But, the dizzying array of nested def's up there leaves
> me a bit dazed, so I'm wondering if there's a simpler way to accomplish
> what I'm trying to do.
>
> Thanks.
>
--
http://mail.python.org/mailman/listinfo/python-list
[ANN] Emacs For Python 0.1, collection of emacs extensions for python development
Emacs For Python 0.1 Emacs for python (epy) is a collection of emacs extensions for python development, yet ready and configured for you. It includes also tweaks to commonly used extension to provide extra functionality and fast bug correction. There are also sane configuration that helps you getting started pretty fast. Some of the most important extensions configured and included in the distribution are: - ido prompts - autocompletion + rope (if you have pymacs) - snippets, simplified and standard-compliant - automatic error/warning/info highlighting with flymake (powered by pyflakes) - custom keybindings - much more (really) I remaind you for further information to the home page: http://gabrielelanaro.github.com/emacs-for-python/ You'll find additional information on the github page (readme and wiki): http://github.com/gabrielelanaro/emacs-for-python Thank you for the attention! - Gabriele -- http://mail.python.org/mailman/listinfo/python-list
CFP for Surge Scalability Conference 2010
A quick reminder that there's one week left to submit your abstract for this year's Surge Scalability Conference. The event is taking place on Sept 30 and Oct 1, 2010 in Baltimore, MD. Surge focuses on case studies that address production failures and the re-engineering efforts that led to victory in Web Applications or Internet Architectures. Our Keynote speakers include John Allspaw and Theo Schlossnagle. We are currently accepting submissions for the Call For Papers through July 9th. You can find more information, including suggested topics and our current list of speakers, online: http://omniti.com/surge/2010 I'd also like to urge folks who are planning to attend, to get your session passes sooner rather than later. We have limited seating and we are on track to sell out early. For more information, including the CFP, sponsorship of the event, or participating as an exhibitor, please visit the Surge website or contact us at su...@omniti.com. Thanks, -- Jason Dixon OmniTI Computer Consulting, Inc. jdi...@omniti.com 443.325.1357 x.241 -- http://mail.python.org/mailman/listinfo/python-list
Re: Numerics question
Please disregard my ineptly posed question. ~K In kj writes: >I define >ninv = 1.0/n >...where n is some integer, and I want to write some function f such >that f(m * ninv) returns the smallest integer that is >= m * ninv, >where m is some other integer. And, in particular, if m is p*n >for some integer p, then f((p*n) * ninv) should return the integer >p. >The first solution that comes to mind is something like >def f(x): >return int(math.ceil(x)) >At first this seems to work: f((7*2) * (1.0/2)) >7 f((7*3) * (1.0/3)) >7 >...but there are values of n for which it fails: f((7*75) * (1.0/75)) >8 >The problem here is that, due to numerical error, the expression >((7*75) * (1.0/75)) evaluates to a number *just* above 7. The >surrounding math.ceil then turns this into 8.0, etc. >Is there a way to define f so that it behaves as expected? >TIA! >~K -- http://mail.python.org/mailman/listinfo/python-list
Importing package with zip-archives
I'd like to have the following structure of my Python code: I have a directory called 'mysystem'. In this directory, I have files 'comp1.zip' and 'comp2.zip' etc which are zipped archives with python packages and modules. I'd like to be able to use them like this in my code: import mysystem.comp1.module import mysystem.comp2.package.module etc. Can I do that? I guess it requires that the __init__.py in mysystem is written in a clever way, but it's not clear how to do this, and I don't find a lot on this in any Python books or on the net. I tried: mysystem/__init__.py: import sys import os dir = os.path.abspath(os.path.dirname(__file__)) sys.path.insert(0, os.path.join(dir, 'comp1.zip')) import comp1 That doesn't do what I want. To access comp1 with this __init__.py I'll have to do import mysystem import comp1.module instead of import mysystem.comp1.module :-( Optionally, I'd like to be able to patch the system by putting a module.py in mysystem/comp2/package/ and get that to override the 'package/module.py' in comp2.zip. It's OK if I need to patch __init__.py in mysystem to do that. -- http://mail.python.org/mailman/listinfo/python-list
Numerics question
I define ninv = 1.0/n ...where n is some integer, and I want to write some function f such that f(m * ninv) returns the smallest integer that is >= m * ninv, where m is some other integer. And, in particular, if m is p*n for some integer p, then f((p*n) * ninv) should return the integer p. The first solution that comes to mind is something like def f(x): return int(math.ceil(x)) At first this seems to work: >>> f((7*2) * (1.0/2)) 7 >>> f((7*3) * (1.0/3)) 7 ...but there are values of n for which it fails: >>> f((7*75) * (1.0/75)) 8 The problem here is that, due to numerical error, the expression ((7*75) * (1.0/75)) evaluates to a number *just* above 7. The surrounding math.ceil then turns this into 8.0, etc. Is there a way to define f so that it behaves as expected? TIA! ~K -- http://mail.python.org/mailman/listinfo/python-list
Decorators, with optional arguments
Okay, so!
I actually never quite got around to learning to do deep and useful
magic with decorators. I've only ever done the most basic things with
them. Its all been a little fuzzy in my head: things like what order
decorators end up being called in if there's more then one, etc.
But in my current situation, what I'm wanting to do is have a decorator
that wraps a function but which takes an *optional* argument, and sets
that argument as an attribute on said function if its there.
Here's what some tweaking and playing around has gotten me, as a recipe:
import functools
def my_decorator(arg):
if callable(arg): # Stuck on 2.5. Leavemealone. :)
protocol = None
else:
protocol = arg
def wrap(fn):
print "Wrapping."
fn.protocol = protocol
@functools.wraps(fn)
def wrapper(*args, **kwargs):
print "Calling."
result = fn(*args, **kwargs)
print "Called."
return result
return wrapper
if not protocol: # argument-less decorator
print "Calling wrap."
return wrap(arg)
else:
print "Returning wrap."
return wrap
To be used as:
class Thing(object):
@expose
def test1(self, arg1):
return arg1
@expose("testing")
def test2(self, arg2):
return arg2
So, my question: am I doing this right? :) Some play-through testing
appears to work. But, the dizzying array of nested def's up there leaves
me a bit dazed, so I'm wondering if there's a simpler way to accomplish
what I'm trying to do.
Thanks.
--
... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
--
http://mail.python.org/mailman/listinfo/python-list
Anyone using GPG or PGP encryption/signatures in your Python apps?
On Fri, Jul 2, 2010 at 6:15 AM, Stef Mientki wrote: > On 02-07-2010 09:39, geremy condra wrote: >> On Thu, Jul 1, 2010 at 11:48 AM, wrote: >>> Curious if any of you are using GPG or PGP encryption and/or signatures >>> in your Python apps? >> Yes; disclaimer: I'm the author of evpy and am currently working on a >> openssl wrapper proposed for inclusion in the stdlib. > Great Geremy !, > but it's difficult to find, > and I couldn't find any documentation. > Did I not look at the right places ? I assume you're talking about the proposed (and unnamed) crypto library, in which case I would be very surprised if you found it unless you looked on my hard drive ;). I don't usually release security-critical code for general use until I've done extensive testing and I simply haven't had time for that over the last week or so. If you're talking about evpy, the documentation for the three user-facing modules is in the docstrings, and I'm almost always here or available by email if you have any questions. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4.2 Installation error
On 07/02/2010 05:38 PM, Dhilip S wrote: > > > Hello Everyone.. > > I'm using Ubuntu 10.04, i try to install Python 2.4.2 & Python 2.4.3 got > error message while doing make command. anybody can tell tell, How to > overcome this error Finally i got message like this ... > > 4036e000-403ad000 r--p 08:08 156978 > /usr/lib/locale/en_IN/LC_CTYPE > bff9a000-bffaf000 rw-p 00:00 0 [stack] > Aborted > make: ***[sharedmodes] Error 13 > That looks like the last line of a glibc backtrace, and doesn't tell us much. Please post the exact commands you entered to produce the problem. Best to try again, even if you're sure it will fail. Then post the complete error message, which can span several screenfuls with this kind of problem. Include at least a few lines of output that you can be sure are correct, to give us some context. It's better to post a bit too much than too little. -- Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: delegation pattern via descriptor
On Fri, 02 Jul 2010 06:28:59 -0700, kedra marbun wrote: > hello, friendliest prog lang community on earth ;) > > i'm feeling that > (0) delegation pattern thru descriptor encourages dedicated delegate for > each task, if feeling: print(benefits) (1) the delegate is designed to > be blind about the class on which the delegate is attached to > > isn't that the two strengthen the coupling between delegator & delegate > obviously __getattribute__ & his 2 friends of 'object' & 'type' have > what it takes to make it not like that, it's just that they're not > designed to pass it. thus i think it is by design > > yes i know there's a way around it, the most obvious to me is defining > your own hooks (which is not trival, at least to me) , but like i said, > it's encouraged I'm sorry, I don't understand a thing you're saying there. Can you explain what you mean? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Python 2.4.2 Installation error
Hello Everyone.. I'm using Ubuntu 10.04, i try to install Python 2.4.2 & Python 2.4.3 got error message while doing make command. anybody can tell tell, How to overcome this error Finally i got message like this ... 4036e000-403ad000 r--p 08:08 156978 /usr/lib/locale/en_IN/LC_CTYPE bff9a000-bffaf000 rw-p 00:00 0 [stack] Aborted make: ***[sharedmodes] Error 13 -- with regards, Dhilip.S -- http://mail.python.org/mailman/listinfo/python-list
Re: drag & drop in a python GUI application
On 07/01/2010 08:57 AM, Alan wrote: > I know drag & drop is not possible with TK. Is this a Python Tk limitation or a Tk limitation in general? Google suggests that Tk itself supports some form of dnd. > Which widget could I use for my > python application to be able to work with drag & drop? PyQt will do drag and drop on all platforms. GTK does drag and drop on Unix/X11, and to a lesser degree Win32--not sure about OS X support. I believe wxWidgets also does some level of dnd on all platforms. -- http://mail.python.org/mailman/listinfo/python-list
delegation pattern via descriptor
hello, friendliest prog lang community on earth ;) i'm feeling that (0) delegation pattern thru descriptor encourages dedicated delegate for each task, if feeling: print(benefits) (1) the delegate is designed to be blind about the class on which the delegate is attached to isn't that the two strengthen the coupling between delegator & delegate obviously __getattribute__ & his 2 friends of 'object' & 'type' have what it takes to make it not like that, it's just that they're not designed to pass it. thus i think it is by design yes i know there's a way around it, the most obvious to me is defining your own hooks (which is not trival, at least to me) , but like i said, it's encouraged wow, it's almost time for brazil to beat the dutch, sorry Guido ;) if fifa['wc']['2010'].winner is not brazil: raise SystemError -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
Ethan Furman ha scritto: Terry Reedy wrote: On 7/1/2010 6:42 PM, Emile van Sebille wrote: On 7/1/2010 2:52 PM Jay said... pywinauto looks to be almost perfect. All I need now is to read the numbers uncovered when a minesweeper square is clicked on, or that I just hit a mine. ... or, you could always win... http://www.daniweb.com/forums/thread186209.html Did you actually try it? Though skeptical, I did, briefly, until I decided that it probably should have been dated April 1. There is no way to enter text into minesweeper, nor to make it full screen, nor, as far as I know, for it to toggle pixels outside its window. The pixel can be hard to see depending on your background colors and whether your screen is adjusted correctly (I could see the white, but not the black). But on XP Pro is still works. works for me too bye -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
Terry Reedy wrote: On 7/1/2010 6:42 PM, Emile van Sebille wrote: On 7/1/2010 2:52 PM Jay said... pywinauto looks to be almost perfect. All I need now is to read the numbers uncovered when a minesweeper square is clicked on, or that I just hit a mine. ... or, you could always win... http://www.daniweb.com/forums/thread186209.html Did you actually try it? Though skeptical, I did, briefly, until I decided that it probably should have been dated April 1. There is no way to enter text into minesweeper, nor to make it full screen, nor, as far as I know, for it to toggle pixels outside its window. The pixel can be hard to see depending on your background colors and whether your screen is adjusted correctly (I could see the white, but not the black). But on XP Pro is still works. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python v3.1.2 documentation question
Terry Reedy wrote: On 7/1/2010 6:42 PM, Ethan Furman wrote: Hmmm Well, as this is my first ever bug post (yay! ;) Great! > I *think* this is what you want: http://bugs.python.org/issue9121 I believe Benjamin meant that it was already fixed in http://docs.python.org/dev/py3k/ which is currently the 3.2a0 docs. Good to check there before reporting a doc bug. Terry Jan Reedy Thanks for the pointer, I didn't know about that. Checking it out, though, it seems the entry for nested scopes has been removed in its entirety -- not sure about fixed, but I guess it's definitely not broken anymore! ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Ignorance and Google Groups (again)
On 2 July 2010 05:10, D'Arcy J.M. Cain wrote: > On Thu, 1 Jul 2010 21:34:15 +0300 > Dotan Cohen wrote: >> I'm one of them. Gmail is great for mailing lists, though I would >> never use it as a personal email client. But I'm more of a lurker than >> a poster on this list, so D'Arcy won't miss me anyway. > > As the song says. "How can I miss you if you won't go away." :-) > I've never heard that, but it sounds line a great line. Googling now! > As I explained, I don't block just because you are on gmail.com. I > only block if you use Google Groups to post via news. > Yes, I got to that part after I posted. I should have read to whole thread first. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: escape character / csv module
On Jul 2, 6:04 am, MRAB wrote: > The csv module imports from _csv, which suggests to me that there's code > written in C which thinks that the "\x00" is a NUL terminator, so it's a > bug, although it's very unusual to want to write characters like "\x00" > to a CSV file, and I wouldn't be surprised if this is the first time > it's been noticed! :-) Don't be surprised, read the documentation (http://docs.python.org/ library/csv.html#module-csv): """Note This version of the csv module doesn’t support Unicode input. Also, there are currently some issues regarding ASCII NUL characters. Accordingly, all input should be UTF-8 or printable ASCII to be safe; see the examples in section Examples. These restrictions will be removed in the future.""" The NUL/printable part of the note has been there since the module was introduced in Python 2.3.0. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pool Module: iterator does not yield consistently with different chunksizes
syockit wrote: I've been playing around with custom iterators to map into Pool. When I run the code below: def arif(arr): return arr def permutate(n): k = 0 a = list(range(6)) while k While I didn't actually try to follow all your code, I suspect your problem is that when you yield the same object multiple times, they're being all saved, and then when evaluated, they all have the final value. If the values are really independent, somebody has to copy the list, and the [:] does that. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Pool Module: iterator does not yield consistently with different chunksizes
syockit wrote: > I've been playing around with custom iterators to map into Pool. When > I run the code below: > > def arif(arr): > return arr > > def permutate(n): > k = 0 > a = list(range(6)) > while k for i in range(6): > a.insert(0, a.pop(5)+6) > #yield a[:] <-- produces correct results > yield a > k += 1 > return > > def main(): > from multiprocessing import Pool > pool = Pool() > chksize = 15 > for x in pool.imap_unordered(arif, permutate(100), chksize): > print(x) > > if __name__=="__main__": > main() > > will output something like this: > > > [36, 37, 38, 39, 40, 41] > [36, 37, 38, 39, 40, 41] > [36, 37, 38, 39, 40, 41] > [36, 37, 38, 39, 40, 41] > [36, 37, 38, 39, 40, 41] > [36, 37, 38, 39, 40, 41] > [72, 73, 74, 75, 76, 77] > [72, 73, 74, 75, 76, 77] > [72, 73, 74, 75, 76, 77] > [72, 73, 74, 75, 76, 77] > [72, 73, 74, 75, 76, 77] > [72, 73, 74, 75, 76, 77] > [108, 109, 110, 111, 112, 113] > [108, 109, 110, 111, 112, 113] > [108, 109, 110, 111, 112, 113] > [108, 109, 110, 111, 112, 113] > [108, 109, 110, 111, 112, 113] > [108, 109, 110, 111, 112, 113] > [144, 145, 146, 147, 148, 149] > > ... where results are duplicated number of times equal to chunk size, > and the results between the gap are lost. Using a[:] instead, i get: > > [6, 7, 8, 9, 10, 11] > [12, 13, 14, 15, 16, 17] > [18, 19, 20, 21, 22, 23] > [24, 25, 26, 27, 28, 29] > [30, 31, 32, 33, 34, 35] > [36, 37, 38, 39, 40, 41] > [42, 43, 44, 45, 46, 47] > [48, 49, 50, 51, 52, 53] > > it comes out okay. Any explanation for such behavior? > > Ahmad Syukri Python passes references araound, not copies. Consider it = permutate(100) chunksize = 15 from itertools import islice while True: chunk = tuple(islice(it, chunksize)) if not chunk: break # dispatch items in chunk print chunk chunksize items are calculated before they are dispatched. When you yield the same list every time in permutate() previous items in the chunk will see any changes you make on the list with the intention to update it to the next value. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Python as a scripting language. Alternative to bash script?
* Dave Pawson [2010-07-02 08:22]: > I'm the OP btw. > > On 1 July 2010 18:10, Dennis Lee Bieber wrote: > > >> I think that Python "could" be a alternative to bash and have some > >> advantages, but it's a long way off from being fully implemented. > > Take a look at Python for Unix and Linux System Administration: http://www.amazon.com/Python-Unix-Linux-System-Administration/dp/0596515820 I quite like the book, I learned about Ipython from this book and I'm quite glad I did! Jerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone using GPG or PGP encryption/signatures in your Python apps?
On 02-07-2010 09:39, geremy condra wrote: > On Thu, Jul 1, 2010 at 11:48 AM, wrote: >> Curious if any of you are using GPG or PGP encryption and/or signatures >> in your Python apps? > Yes; disclaimer: I'm the author of evpy and am currently working on a > openssl wrapper proposed for inclusion in the stdlib. Great Geremy !, but it's difficult to find, and I couldn't find any documentation. Did I not look at the right places ? thanks Stef Mientki -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 06/30/10 01:25, Ethan Furman wrote: But if so why setattr() still exists? What is it for if we can do the same thing via assignments? Also, in order to be perfect, Python should accept to add dynamic attributes dynamically, something like PEP 363. That doesn't happen. Setattr and friends exist to work with dynamic attributes. Yeah, my point is why setattr() for dynamic attributes while assignments for static attributes? Why not unify them? What is a "dynamic" and what is a "static" attribute Agreed, but at least, the reason why I am being against so many people here is also trying to make Python be more perfect with my understanding. Please start with learning Python's execution model (what exactly happens at runtime, what most statement are syntactic sugar for etc) and Python's object model (how are Python objects, classes, methods etc implemented, attributes lookup rules, metaclasses, descriptors etc). Then PERHAPS you MIGHT have a chance to help making Python "more perfect". -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 07/01/10 23:19, Stephen Hansen wrote: As long as setattr() exists in Python, that will be not so ordinary. :) setattr is perfectly ordinary. If you think setattr() is as ordinary as a trivial assignment, setattr IS a trivial assignment. However, I think setattr() is a builtin function, using it exposes the *magic* of metaprogramming (or class-programming, if more correct) at a first glance. No "magic" and no "meta"whatever involved. setattr is as simple as: def setattr(obj, name, value): obj.__setattribute__(name, value) which is *exactly* what gets called when you use the binding statement form ie "obj.someattr = value" which FWIW is just syntactic sugar for the former (just like the 'class' statement is just syntactic sugar for a call to type, etc). I fail to understand why you insist on seeing something as trivial as "magic", "metaprogramming" or whatever. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: However, I think setattr() is a builtin function, using it exposes the *magic* of metaprogramming (or class-programming, if more correct) at a first glance. But, in Python, creating instance variables is *not* class-programming. It doesn't touch the class at all. In many OO languages, such as Simula, C++ and Java, one of the responsibilities of a class is to define what attributes its instances have. However, that really comes about because those languages are statically typed -- it's not an essential principle of OO at all. In Python, restricting what attributes an object can have is *not* considered to be a responsibility of the class. The class is just a convenient place to put stuff (mostly methods) that some bunch of objects all need to have. Anything beyond that is up to the objects themselves. It so happens that, in most Python programs, all the instances of a given class will usually have a well- defined set of attributes. But Python doesn't go out of its way to enforce that. This is just a part of Python's general philosophy of not requiring declarations. There are very few declarative constructs in Python -- even class and function definitions are executable statements that construct data structures at run time. The only true declarations are the 'global' and 'nonlocal' statements, and they only exist because without them there would be no way to achieve certain things. They are not there to enforce any kind of static check. Why does Python not require declarations? Because it makes code easier and faster to develop. Instead of having to spend time and effort writing declarations, you just get straight on and write the code that does the actual work. And if you change your mind and need to move things around, you don't have to perform extra work to keep the declarations up to date. This can be a big help in the early stages of development, when you're feeling your way and the design is fluid. It also makes the program easier to extend and modify later. The downside is that certain kinds of error, that would be caught at compile time in a more static language, don't show up until you run the program. But if you're testing properly -- which you need to do anyway, whatever language you're using -- they usually show up pretty soon, and aren't much harder to fix when they do. Experience has shown that the overall process -- design, programming, testing and debugging -- tends to be faster using a dynamic, fluid language such as Python, than a static one such as C++ or Java. And, many people would say, more fun as well -- which is a good enough reason on its own for using Python! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Why defaultdict?
On 07/02/2010 11:26 AM, Chris Rebert wrote: > On Fri, Jul 2, 2010 at 2:20 AM, Thomas Jollans wrote: >> On 07/02/2010 06:11 AM, Steven D'Aprano wrote: >>> I would like to better understand some of the design choices made in >>> collections.defaultdict. > >>> Second, why is the factory function not called with key? There are three >>> obvious kinds of "default values" a dict might want, in order of more-to- >>> less general: >>> >>> (1) The default value depends on the key in some way: return factory(key) >> >> I agree, this is a strange choice. However, nothing's stopping you from >> being a bit verbose about what you want and just doing it: >> >> class mydict(defaultdict): >>def __missing__(self, key): >># ... >> >> the __missing__ method is really the more useful bit the defaultdict >> class adds, by the looks of it. > > Nitpick: You only need to subclass dict, not defaultdict, to use > __missing__(). See the part of the docs Raymond Hettinger quoted. > Sorry Raymond, I didn't see you. This is where I cancel my "filter out google groups users" experiment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why defaultdict?
On Fri, Jul 2, 2010 at 2:20 AM, Thomas Jollans wrote: > On 07/02/2010 06:11 AM, Steven D'Aprano wrote: >> I would like to better understand some of the design choices made in >> collections.defaultdict. >> Second, why is the factory function not called with key? There are three >> obvious kinds of "default values" a dict might want, in order of more-to- >> less general: >> >> (1) The default value depends on the key in some way: return factory(key) > > I agree, this is a strange choice. However, nothing's stopping you from > being a bit verbose about what you want and just doing it: > > class mydict(defaultdict): > def __missing__(self, key): > # ... > > the __missing__ method is really the more useful bit the defaultdict > class adds, by the looks of it. Nitpick: You only need to subclass dict, not defaultdict, to use __missing__(). See the part of the docs Raymond Hettinger quoted. Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Why defaultdict?
On 07/02/2010 06:11 AM, Steven D'Aprano wrote: > I would like to better understand some of the design choices made in > collections.defaultdict. > > Firstly, to initialise a defaultdict, you do this: > > from collections import defaultdict > d = defaultdict(callable, *args) > > which sets an attribute of d "default_factory" which is called on key > lookups when the key is missing. If callable is None, defaultdicts are > *exactly* equivalent to built-in dicts, so I wonder why the API wasn't > added on to dict rather than a separate class that needed to be imported. > That is: > > d = dict(*args) > d.default_factory = callable That's just not what dicts, a very simple and elementary data type, do. I know this isn't really a good reason. In addition to what Chris said, I expect this would complicate the dict code a great deal. > > If you failed to explicitly set the dict's default_factory, it would > behave precisely as dicts do now. So why create a new class that needs to > be imported, rather than just add the functionality to dict? > > Is it just an aesthetic choice to support passing the factory function as > the first argument? I would think that the advantage of having it built- > in would far outweigh the cost of an explicit attribute assignment. > The cost of this feature would be over-complication of the built-in dict type when a subclass would do just as well > > > Second, why is the factory function not called with key? There are three > obvious kinds of "default values" a dict might want, in order of more-to- > less general: > > (1) The default value depends on the key in some way: return factory(key) I agree, this is a strange choice. However, nothing's stopping you from being a bit verbose about what you want and just doing it: class mydict(defaultdict): def __missing__(self, key): # ... the __missing__ method is really the more useful bit the defaultdict class adds, by the looks of it. -- Thomas > (2) The default value doesn't depend on the key: return factory() > (3) The default value is a constant: return C > > defaultdict supports (2) and (3): > > defaultdict(factory, *args) > defaultdict(lambda: C, *args) > > but it doesn't support (1). If key were passed to the factory function, > it would be easy to support all three use-cases, at the cost of a > slightly more complex factory function. E.g. the current idiom: > > defaultdict(factory, *args) > > would become: > > defaultdict(lambda key: factory(), *args) > > > (There is a zeroth case as well, where the default value depends on the > key and what else is in the dict: factory(d, key). But I suspect that's > well and truly YAGNI territory.) -- http://mail.python.org/mailman/listinfo/python-list
Re: GAE + recursion limit
On Fri, Jul 2, 2010 at 5:06 PM, Maciej wrote: > Does anyone have any clue what that might be? > Why the problem is on GAE (even when run locally), when command line > run works just fine (even with recursion limit decreased)? > Thanks in advance for any help. Most likely google runs a customized python, with different settings to avoid requests to take too long. I doubt there is much you can do for this problem, but you should ask on GAE group. David -- http://mail.python.org/mailman/listinfo/python-list
Re: Bento 0.0.3 (ex-toydist), a pythonic packaging solution
On Fri, Jul 2, 2010 at 4:46 PM, Tim Golden wrote: > > Looks very interesting. Just one thing (which might just be me): > the front page looks very stylish and is quite a nice summary. > But I actually *missed* the (grey on grey) [Take me to Bento documentation] > button, which is way below the fold on my screen. Rather, I hit the > more evident Github flag at the top and started looking for docs there! Good point, I will think about a better way to display this, thanks, David -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: When I talked about OOP, it is general OOP, not related with > any concrete programming languages. There isn't really any such thing, though. There is no universally agreed set of features that a language must have in order to be considered OOP. Arguments of the form "Language L isn't really OOP because it doesn't have feature F" don't wash with anyone who has studied a sufficiently wide variety of languages. Every OOP language has its own take on what it means to be OOP, and none of them is any more correct about it than another. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote:
Yeah, my point is why setattr() for dynamic attributes while assignments
for static attributes?
I think there may be a misunderstanding here. You seem to
be thinking of "dynamic attribute" vs. "static attribute"
as the distinction between creating a new attribute and
modifying an existing one.
But that's not what it means in this context -- "dynamic"
just means that the attribute name is being computed rather
than written into the program. In either case, the attribute
may or may not be pre-existing.
Why not unify them?
If you mean using exactly the same syntax for both, that would
require making the static case more verbose, e.g. instead of
foo.blarg
you would have to write something like
foo.("blarg")
just to allow for the possibility of writing
foo.(some_arbitrary_expression)
If you keep the existing static-attribute syntax, then you
haven't really unified anything, you've just added a new
syntax for dynamic attributes. And because dynamic attribute
access is extremely rare, it's not considered worth having
a special syntax for it. It's been suggested before, and
rejected on those grounds.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Pool Module: iterator does not yield consistently with different chunksizes
I've been playing around with custom iterators to map into Pool. When I run the code below: def arif(arr): return arr def permutate(n): k = 0 a = list(range(6)) while khttp://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: If you think setattr() is as ordinary as a trivial assignment, I will argue with you, this is personal taste. To my way of thinking, getattr() and setattr() are the fundamental way of accessing attributes in Python. The dot notation is just syntactic sugar for the overwhelmingly common case of a static attribute name. So the dot-notation is more "ordinary" in the sense of being more commonly used, but not in the sense of being a simpler operation. Both are doing exactly the same thing underneath. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Packaging question
snorble wrote: > My question is, why do the modules bar and foo show up in mypack's > dir()? I intend for Foo (the class foo.Foo) and Bar (the class > bar.Bar) to be there, but was not sure about the modules foo and bar. > $ ls mypack/*.py > bar.py > foo.py > __init__.py > > $ cat mypack/__init__.py > from foo import Foo > from bar import Bar > > $ python > Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. import mypack dir(mypack) > ['Bar', 'Foo', '__builtins__', '__doc__', '__file__', '__name__', > '__package__', '__path__', 'bar', 'foo'] How is Python to know that you won't perform an import mypack.foo afterwards? After this statement foo must be an attribute of mypack. But when mypack.foo has been imported before this just performs mypack = sys.modules["mypack"] If the foo attribute weren't added by from foo import Foo the caching mechanism would not work. While import mypack.foo might also have been implemented as mypack = sys.modules["mypack"] if not hasattr(mypack", "foo"): mypack.foo = sys.modules["mypack.foo"] I think that would have been a solution to a non-problem. If you're sure you don't need to access mypack.foo directly you can add del foo to mypack/__init__.py, but don't complain when you get bitten by >>> import mypack.foo >>> mypack.foo Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'foo' > My big picture intention is to create smaller modules, but more of > them (like I am used to doing with C++), and then use a package to > organize the namespace so I'm not typing out excessively long names > and making the code less readable. Is that a reasonable approach to > developing Python programs? I like to put related classes and functions into a single file. As a rule of thumb, when a class needs a file of its own the class is too big... Peter -- http://mail.python.org/mailman/listinfo/python-list
GAE + recursion limit
Hi, I'm writing a small translator using pyparsing library v1.5.2 (http://pyparsing.wikispaces.com/) and I'm using it both from command line and on Google App Engine. Recently I checked one of my samples which runs perfect from CLI against GAE and it throws me "RuntimeError 'maximum recursion depth exceeded'". I did some investigation and found out that recursion limit is the same locally and inside GA (1000). I've also tested it locally decreasing this limit to 900 but the error didn't happen. The problem itself rises inside pyparsing lib, line 995. Does anyone have any clue what that might be? Why the problem is on GAE (even when run locally), when command line run works just fine (even with recursion limit decreased)? Thanks in advance for any help. Soltys -- http://mail.python.org/mailman/listinfo/python-list
Re: Bento 0.0.3 (ex-toydist), a pythonic packaging solution
On 02/07/2010 03:38, David wrote: I am pleased to announce the release 0.0.3 for Bento, the pythonic packaging solution. Bento aims at being an alternative to distutils/setuptools/distribute, based on a static metadata file format. Existing packages can be converted from setup.py to bento format automatically. http://cournape.github.com/Bento/ Looks very interesting. Just one thing (which might just be me): the front page looks very stylish and is quite a nice summary. But I actually *missed* the (grey on grey) [Take me to Bento documentation] button, which is way below the fold on my screen. Rather, I hit the more evident Github flag at the top and started looking for docs there! Just in case it helps anyone else... TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone using GPG or PGP encryption/signatures in your Python apps?
On Thu, Jul 1, 2010 at 11:48 AM, wrote: > Curious if any of you are using GPG or PGP encryption and/or signatures > in your Python apps? Yes; disclaimer: I'm the author of evpy and am currently working on a openssl wrapper proposed for inclusion in the stdlib. > In particular are you: > > 1. clearsigning specific emails? Yes; I use python-gnupg. > 2. validating clearsigned emails from others? Yes, see above. > 3. encrypting/decrypting files? Yes, I use evpy. > 4. generating signatures for files that you are exchanging/posting for > download? Yes, evpy again. > 5. what public keyring services are you using? Can't comment on this as I don't use them. > I'm also looking for recommendations on which 3rd party modules you're > using for these tasks? In particular is there a particular module you > prefer or have concerns about? Obviously I'm biased towards evpy, but I'm a really, really big fan of people not rolling their own crypto. It sounds like for most of what you want to do gpg or python-gnupg are pretty good options. > Here's my short list of modules that *might* support encryption and > signing in general: > > - m2crypto Supports encryption and signing; a high quality library with much to recommend it, assuming you need the full power of openssl and are able to use SWIG'd software. I think you probably have easier to use alternatives here, though. > - pycrypto (standalone or with expycrypto or yawpycrypto wrappers) pycrypto is a good library as far as it goes, but I see a lot of nonexperts do things very badly with it, and AFAICS it hasn't seen the same level of scrutiny that something like openssl has, especially WRT side channel cryptanalysis. That's very worrying. > - tlslite > - pyme no experience here, can't comment. > - evpy I like it ;). It supports encryption (public and private key) as well as signing and verification routines, and as long as you know your threat model it's reasonably hard to screw up. Having said that, it doesn't do anything with the web of trust or key revocation etc OOTB, so if what you're really looking for is gpg in python, use the right tool for the job. > - python-gnupg (by developer of Python's logging module) I use it and like it for the reasons above. > Any comments on using the subprocess module to wrap the gpg or openssl > command line utilities? This seems to be a common technique for > encryption and signing solutions and appears to the technique used by > python-gnupg (for example). Seems fine, just make sure you know and trust where your keys are going. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: automate minesweeper with python
Just tested it in XP, it works. -- http://mail.python.org/mailman/listinfo/python-list
drag & drop in a python GUI application
Hello there, I know drag & drop is not possible with TK. Which widget could I use for my python application to be able to work with drag & drop? Thanks, Alan -- Alan Wilter S. da Silva, D.Sc. - CCPN Research Associate Department of Biochemistry, University of Cambridge. 80 Tennis Court Road, Cambridge CB2 1GA, UK. >>http://www.bio.cam.ac.uk/~awd28<< -- http://mail.python.org/mailman/listinfo/python-list
