Is there a Python programmer living near Bend Oregon that I could call via phone & ask some questions on how they accomplish certain tasks? I’ve been programming using several languages for over fifty years, but am unable to get Python to due what I would like to do! Papa Jackson
From: [EMAIL PROTECTED]: Python-list Digest, Vol 57, Issue 206To: [EMAIL PROTECTED]: Fri, 13 Jun 2008 19:00:04 +0200Send 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-listor, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specificthan "Re: Contents of Python-list digest..." --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 21:59:06 +0530Subject: Python Socket programmingHi,I am going to do some socket related programming in Python. Before that, I wish to know the Gotchas of Python Scoket Programming.Can anyone send me any link that satisfies my needs??Thanks,Srini Explore your hobbies and interests. Go to http://in.promos.yahoo.com/groups/ --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 10:28:45 -0600Subject: RE: namedtuple suggestionsI also agree with your point on concatting. I used that syntax because itseemed more clear, given the already awkward syntax. And while the original motivation of namedtuple might be to avoid having tomake a class or subclass, subclasses have already emerged even within thestandard library (see lib/urlparse for a prime example of extending thenamedtuple class). Regards,Jason -----Original Message-----From: Calvin Spealman [mailto:[EMAIL PROTECTED] Sent: Friday, 13 June, 2008 12:17To: Jason R. CoombsCc: [EMAIL PROTECTED]: Re: namedtuple suggestions On Jun 13, 2008, at 11:17 AM, Jason R. Coombs wrote: > I see a new function in (python 2.6) lib/collections called> namedtuple. This is a great function. I can see many places in my> code where this will be immensely useful.>> I have a couple of suggestions.>> My first suggestion is to use self.__class__.__name__ instead of the> hard-coded typename in __repr__, so that subclasses don't have to> override these methods just to use the correct name.>> def __repr__(self):> return self.__class__.__name__ + '(%(reprtxt)s)' %% self> \n I feel like a large point of NamedTuple is for those cases where you need a small object with some attributes _without_ creating a subclass. Useful for mocks, for example, or when you need to trick a function into dealing with a quick proxy or stub. If a large point is not needing to create a class but instead creating a cheap object, should it be a good idea to then subclass the very thing that was intended to help you avoid creating a class in the first place? What do you gain subclassing it? However, I always think a repr reflecting a type name should reflect the correct type, so I'm not disagreeing on that point. But, just don't use concating :-) --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 16:41:46 +0000Subject: Automatically restarting system calls? I wrote a script(1) replacement in python (http://stromberg.dnsalias.org/~dstromberg/pypty/), but I'm encountering a problem in it. I think I know the solution to the problem, but I'd've thought python was high level enough that this solution isn't required, so I wanted to inquire about it here. Specifically, the program has a signal handler for window size changes. And if the window is resized during an os.write() (for example), I get a python exception about needing to restart the system call. In C, I know you're supposed to wrap your system calls with while loops until you don't get an ERESTART, but does one really need to wrap all of one's os.write()'s (for example) with such while loops in python? Thanks! --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 18:46:46 +0200Subject: Re: Python Socket programmingHi, Le Friday 13 June 2008 18:29:06 srinivasan srinivas, vous avez écrit :> Hi,> I am going to do some socket related programming in Python. Before that, I> wish to know the Gotchas of Python Scoket Programming. Can anyone send me> any link that satisfies my needs?? Yes, the friendly manual :) http://docs.python.org/lib/module-socket.html and if you want to know more about socket themselves, the gnu libc info page is a good starting point as the python module is basically an interface to it: http://www.gnu.org/software/libc/manual/html_node/Sockets.html#Sockets -- Cédric Lucantis --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 18:55:24 +0200Subject: Re: Summing a 2D listHello, Le Friday 13 June 2008 17:55:44 Karsten Heymann, vous avez écrit :> Maric Michaud <[EMAIL PROTECTED]> writes:> > So, writing C in python, which has dictionnary as builtin type,> > should be considered "more elegant" ?>> IMO that's a bit harsh.> harsh ? Sorry, I'm not sure to understand. > > You are comparing apples with lemons, there is no such a difference> > between list index access and dictionnary key access in Python.>> [...]>> > If you know in advance the number and names of users, what prevent> > you to initialize completelly the target dictionnary ?> >> > The following code compare the same algorithm, once with list and> > the second time with dict :>> [...]>> > The result is pretty close now :> >> > [EMAIL PROTECTED] 17:04:36:~$ ./test.py> > with list 1.40726399422> > with dict 1.63094091415> >> > So why use list where the obvious and natural data structure is a> > dictionnary ?>> I'd never argue that using a dictionary is the obvious and natural> data structure for this case. But is it the best? Honestly, as your> very nice example shows, we have two solutions that are equally fast,> equally complex to code and equally robust, but one needs Yes, but my example take ordered integer for keys (users' names) which they should not be in a real case, so retrieving the result is by way easier (and faster) with a dictionnary. > approximately the double amount of memory compared to the other. I don't see how you came to this conclusion. Are you sure the extra list take twice more memory than the extra dictionary ? > So, as much as i like dictionaries, what's the gain you get from using it> in this corner case? It's the very purpose of it's usage, store and retrieve data by key. Cheers, -- _____________ Maric Michaud --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 18:59:02 +0200Subject: Re: Summing a 2D listLe Friday 13 June 2008 18:55:24 Maric Michaud, vous avez écrit :> > approximately the double amount of memory compared to the other.>> I don't see how you came to this conclusion. Are you sure the extra list> take twice more memory than the extra dictionary ? twice less, I meant, of course... -- _____________ Maric Michaud --Forwarded Message Attachment--From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 13 Jun 2008 09:55:04 -0700Subject: Re: weird iteration/assignment problemOn Jun 13, 8:07 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:> cirfu schrieb:>> > for i in xrange(0, len(texts)):> > texts[i] = "yes">> > for i in texts:> > i = "no">> > why is the first one working but not the second. i mean i see why the> > firts one works but i dont udnerstand why the second doesnt.>> Because in the second you only bind the contents of texts to a name i.>> But that doesn't mean that i magically became an "alias" for> texts[index] - it just happens to point at the same object.>> To accomplish what you want, the pythonic idiom is to use enumerate:>> for i, text in enumerate(texts):> text[i] = "yes">> Diez That should be: for i, text in enumerate(texts): texts[i] = "yes"
-- http://mail.python.org/mailman/listinfo/python-list
