Are you sending binary data if so you can use the struct module to pack, unpack and interpret binary data http://docs.python.org/library/struct.html ,
You will have to design the header scheme yourself you can either embed length in the packets or try to use a carefully selected delimiter character . Thanks Aman On Sun, Jul 10, 2011 at 5:31 PM, <python-list-requ...@python.org> 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: parsing packets (Michael Hrivnak) > 2. Re: Wgy isn't there a good RAD Gui tool fo python (CM) > 3. Re: Function docstring as a local variable (Ben Finney) > 4. Re: Function docstring as a local variable (Tim Johnson) > 5. Re: Function docstring as a local variable (Chris Rebert) > 6. Re: Function docstring as a local variable (Chris Rebert) > 7. Re: Function docstring as a local variable (Tim Johnson) > 8. Re: Function docstring as a local variable (Corey Richardson) > 9. Re: Virtual functions are virtually invisible! (Michael Hrivnak) > > > ---------- Forwarded message ---------- > From: Michael Hrivnak <mhriv...@hrivnak.org> > To: ty...@tysdomain.com > Date: Sun, 10 Jul 2011 19:33:38 -0400 > Subject: Re: parsing packets > In order to find the end of the packet, include a field that is the > packet length. This is what IP packets do to find the end of their > header. > > http://en.wikipedia.org/wiki/IPv4#Header > > And the TCP header (see "data offset") does the same: > > > http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure > > Of course in both cases they are specifying the header length, not > including a data payload. However, it sounds like you might not have > a payload, so your entire packet might consist of header-like data. > > Michael > > > On Sun, Jul 10, 2011 at 4:59 PM, Littlefield, Tyler <ty...@tysdomain.com> > wrote: > > Hello all: > > I'm working on a server that will need to parse packets sent from a > client, > > and construct it's own packets. > > The setup is something like this: the first two bytes is the type of the > > packet. > > So, lets say we have a packet set to connect. There are two types of > connect > > packet: a auth packet and a connect packet. > > The connect packet then has two bytes with the type, another byte that > notes > > that it is a connect packet, and 4 bytes that contains the version of the > > client. > > The auth packet has the two bytes that tells what packet it is, one byte > > denoting that it is an auth packet, then the username, a NULL character, > and > > a password and a NULL character. > > > > With all of this said, I'm kind of curious how I would 1) parse out > > something like this (I am using twisted, so it'll just be passed to my > > Receive function), and how I get the length of the packet with multiple > NULL > > values. I'm also looking to build a packet and send it back out, is there > > something that will allow me to designate two bytes, set individual bits, > > then put it altogether in a packet to be sent out? > > > > -- > > > > Take care, > > Ty > > my website: > > http://tds-solutions.net > > my blog: > > http://tds-solutions.net/blog > > skype: st8amnd127 > > My programs don't have bugs; they're randomly added features! > > > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > > > > ---------- Forwarded message ---------- > From: CM <cmpyt...@gmail.com> > To: python-list@python.org > Date: Sun, 10 Jul 2011 16:49:51 -0700 (PDT) > Subject: Re: Wgy isn't there a good RAD Gui tool fo python > On Jul 10, 6:50 pm, Ivan Kljaic <iklj...@gmail.com> wrote: > > Ok Guys. I know that most of us have been expiriencing the need for a > > nice Gui builder tool for RAD and most of us have been googling for it > > a lot of times. But seriously. Why is the not even one single RAD tool > > for Python. I mean what happened to boa constructor that it stopped > > developing. I simply do not see any reasons why there isn't anything. > > Please help me understand it. Any insights? > > Just because Boa Constructor stopped (or lengthily paused?) > development > doesn't mean it doesn't exist. It does, and (at least on Windows), it > is, IMO, really good. So why don't you use it? > > Che > > > > > ---------- Forwarded message ---------- > From: Ben Finney <ben+pyt...@benfinney.id.au> > To: python-list@python.org > Date: Mon, 11 Jul 2011 09:48:46 +1000 > Subject: Re: Function docstring as a local variable > "Colin J. Williams" <c...@ncf.ca> writes: > > > On 10-Jul-11 13:44 PM, rantingrick wrote: > > > On Jul 10, 12:41 pm, Tim Johnson<t...@johnsons-web.com> wrote: > > >> It possible for a function to print it's own docstring? > > > > > > def f(): > > > """docstring""" > > > print "docstring" > > > > Try: > > > > def f(): > > ds= """docstring""" > > print ds > > The OP wants the function to print its own docstring, which your example > does not do. You've defined a function with an empty docstring. > > >>> def foo(): > ... ds = "The Larch" > ... print ds > ... > >>> foo.__doc__ > >>> > > -- > \ “Firmness in decision is often merely a form of stupidity. It | > `\ indicates an inability to think the same thing out twice.” | > _o__) —Henry L. Mencken | > Ben Finney > > > > ---------- Forwarded message ---------- > From: Tim Johnson <t...@johnsons-web.com> > To: python-list@python.org > Date: Sun, 10 Jul 2011 16:00:54 -0800 > Subject: Re: Function docstring as a local variable > * Carl Banks <pavlovevide...@gmail.com> [110710 15:18]: > > On Sunday, July 10, 2011 3:50:18 PM UTC-7, Tim Johnson wrote: > > > Here's a related question: > > > I can get the docstring for an imported module: > > > >>> import tmpl as foo > > > >>> print(foo.__doc__) > > > Python templating features > > > > > > Author - tim at akwebsoft dot com > > > > > > ## Is it possible to get the module docstring > > > ## from the module itself? > > > > > > print __doc__ > Thanks Carl. > > Where is general documentation on the subject of variables > beginning with 2 underscores? > > I'm presuming the key phrase is 'builtin variables'. I'm searching > too ... > > -- > Tim > tim at johnsons-web dot com or akwebsoft dot com > http://www.akwebsoft.com > > > > ---------- Forwarded message ---------- > From: Chris Rebert <c...@rebertia.com> > To: Tim Johnson <t...@johnsons-web.com> > Date: Sun, 10 Jul 2011 17:09:27 -0700 > Subject: Re: Function docstring as a local variable > On Sun, Jul 10, 2011 at 5:00 PM, Tim Johnson <t...@johnsons-web.com> wrote: > > * Carl Banks <pavlovevide...@gmail.com> [110710 15:18]: > >> On Sunday, July 10, 2011 3:50:18 PM UTC-7, Tim Johnson wrote: > <snip> > >> > ## Is it possible to get the module docstring > >> > ## from the module itself? > >> > >> print __doc__ > > Thanks Carl. > > > > Where is general documentation on the subject of variables > > beginning with 2 underscores? > > > > I'm presuming the key phrase is 'builtin variables'. I'm searching > > too ... > > I've never heard that phrase used to describe __doc__ or its friends. > > Look in the "underscore" section of the documentation index: > http://docs.python.org/genindex-_.html > > Cheers, > Chris > > > > ---------- Forwarded message ---------- > From: Chris Rebert <c...@rebertia.com> > To: Corey Richardson <kb1...@aim.com> > Date: Sun, 10 Jul 2011 17:16:23 -0700 > Subject: Re: Function docstring as a local variable > On Sun, Jul 10, 2011 at 4:06 PM, Corey Richardson <kb1...@aim.com> wrote: > > Excerpts from Carl Banks's message of Sun Jul 10 18:59:02 -0400 2011: > >> print __doc__ > >> > > > > Python 2.7.1 (r271:86832, Jul 8 2011, 22:48:46) > > [GCC 4.4.5] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > >>>> def foo(): > > ... "Docstring" > > ... print __doc__ > > ... > >>>> foo() > > None > >>>> > > > > > > What does yours do? > > The question Carl's code was in answer to was, slightly paraphrased: > "Is it possible to get a *module*'s docstring from within the module > itself?" > The question had nothing to do with *function* docstrings. > > The interactive interpreter environment also isn't quite a true > module, so you can't give it a docstring or really test the relevant > feature there. Try this instead: > $ cat test.py > """I am the docstring of the `test` module!""" > > print("This module's docstring is:", __doc__) > $ python test.py > This module's docstring is: I am the docstring of the `test` module! > $ > > Cheers, > Chris > -- > http://rebertia.com > > > > ---------- Forwarded message ---------- > From: Tim Johnson <t...@johnsons-web.com> > To: Python ML <python-list@python.org> > Date: Sun, 10 Jul 2011 16:21:59 -0800 > Subject: Re: Function docstring as a local variable > * Chris Rebert <c...@rebertia.com> [110710 16:14]: > > > > > > Where is general documentation on the subject of variables > > > beginning with 2 underscores? > > > > I've never heard that phrase used to describe __doc__ or its friends. > :) That why I wasn't satified with my search results. > > Look in the "underscore" section of the documentation index: > > http://docs.python.org/genindex-_.html > And that is what I was looking for. > thanks > -- > Tim > tim at johnsons-web dot com or akwebsoft dot com > http://www.akwebsoft.com > > > > ---------- Forwarded message ---------- > From: Corey Richardson <kb1...@aim.com> > To: python-list <python-list@python.org> > Date: Sun, 10 Jul 2011 20:26:02 -0400 > Subject: Re: Function docstring as a local variable > Excerpts from Chris Rebert's message of Sun Jul 10 20:16:23 -0400 2011: > > The question Carl's code was in answer to was, slightly paraphrased: > > "Is it possible to get a *module*'s docstring from within the module > > itself?" > > The question had nothing to do with *function* docstrings. > > > > Ah. My bad, thank you for clarifying. > -- > Corey Richardson > "Those who deny freedom to others, deserve it not for themselves" > -- Abraham Lincoln > > > ---------- Forwarded message ---------- > From: Michael Hrivnak <mhriv...@hrivnak.org> > To: rantingrick <rantingr...@gmail.com> > Date: Sun, 10 Jul 2011 20:31:49 -0400 > Subject: Re: Virtual functions are virtually invisible! > It sounds to me like you need a better IDE, better documentation, > and/or better code to work on and use. I don't understand why it's > difficult to look at a derived class as see what methods are > overridden. If you are working on the code, it is quite obvious what > methods exist in the base class. If you're not willing to get an > intimate understanding of how the base class works, you probably > shouldn't be working on the subclass. If the base class is difficult > to understand, it's probably poorly written and/or poorly documented. > Neither of these problems should be solved by adding complexity to the > language. Referencing the Zen of Python: "If the implementation is > hard to explain, it's a bad idea." > > If you are just using a library but not developing it, why does it > matter what methods are overridden? As long as class "Derived" > behaves the way it is documented, who cares how it got that way or > what is going on behind the scenes? If you need to read the code to > figure out how it works, then it's just poorly documented. > > Django is a great example, because it is very well documented. Most > users have little idea of what base classes are involved and what > features are overridden, because it doesn't matter when you are just > using the library. When you need to write your own subclass of a > django class, then it might matter, and you should see my first > paragraph. > > And in terms of "non-starters", any "Pythonista" who isn't willing to > adhere to the style guide and document their code wouldn't work on my > team for very long, if at all. There is just no excuse for that. > > Michael > > On Sun, Jul 10, 2011 at 1:15 PM, rantingrick <rantingr...@gmail.com> > wrote: > > On Jul 4, 3:43 am, Gregory Ewing <greg.ew...@canterbury.ac.nz> wrote: > >> rantingrick wrote: > >> > what concerns me is the fact that virtual methods in derived > >> > classes just blend in to the crowd. > >> > I think we really need some > >> > sort of visual cue in the form of forced syntactical notation (just > >> > like the special method underscores). > >> > >> If you're suggesting that it should be impossible to override > >> a method unless it is specially marked somehow in the base > >> class, I think that would be a bad idea. > > > > Sorry i did explain properly... No NOT marked in the BASE class but > > marked in the DERIVED class! My concerns are from a readability > > standpoint. Here's a naive example... > > > > class Top(object): > > def __init__(self): > > pass > > def m1(self): > > """overide""" > > return True > > def m2(self): > > print 'm2' > > > > > > def Derived(Top): > > def __init__(self): > > Top.__init__(self) > > def <overide>m1(self): > > return False > > > > My argument is this... > > > > """If class "Derived" exists in another module the reader has no > > idea which methods where clobbered and which were not WITHOUT being > > intimate with the entire code base.""" > > > > I suggest we solve this dilemma by forcing a syntax "tag" when > > declaring clobbering virtual functions. And if someone forgets to > > include the tag python would throw an exception. This has the effect > > of making the code MUCH easier to follow by the human readers. And it > > put NO constraints on the API. Also it has the added effect of warning > > unsuspecting programmers of name clashes that would otherwise not > > produce an error. > > > >> One of the principles behind the design of Eiffel is that > >> classes should *always* be open to modification in any way > >> by a subclass. The reason is that the author of a class > >> library can't anticipate all the ways people might want to > >> use it. Consequently Eiffel has no equivalent of C++'s > >> "private" declaration -- everything is at most "protected". > >> It also has no equivalent of Java's "final". > > > > Exactly! We should never put limits on what methods CAN be virtual. > > However, we CAN enforce a syntax that removes ambiguity from the > > equation. > > -- > > http://mail.python.org/mailman/listinfo/python-list > > > > > -- > http://mail.python.org/mailman/listinfo/python-list > -- Aman Nijhawan
-- http://mail.python.org/mailman/listinfo/python-list