In my day job, we have a large code base of mostly identical projects, each
with their own customizations. The customizations can be a real pain
sometimes. Especially when debugging binary data. The interesting part of
the binary dumps are most often the stuff that are tweaked from project to
proj
Try unpacking the nested struct as a fixed width string and then unpacking the
string.
Then unpack the string
On Monday, March 4, 2013 10:22:07 AM UTC-8, Ari King wrote:
> Hi,
>
>
>
> I'm trying to nest the "info_header", "info_body", and &quo
Hi,
I'm trying to nest the "info_header", "info_body", and "info_trailer" structs
(see below) into a "data_packet" struct. Does anyone know how I can/should
accomplish this? Thanks.
batch_header_format = struct.Struct('!c2h')
info_
Aaron Brady wrote:
On Apr 18, 2:25 pm, KoolD wrote:
Hey all,
I need to convert a C code to python please help me figure out how to
do
it.
Suppose the C program's like:
typedef struct _str
{
int a;
char *b;
int c;}str;
int main()
{
str mbr;
fd=en("/dev/s
On Apr 18, 2:25 pm, KoolD wrote:
> Hey all,
> I need to convert a C code to python please help me figure out how to
> do
> it.
> Suppose the C program's like:
>
>
> typedef struct _str
> {
> int a;
> char *b;
> int c;}str;
>
> int main()
> {
> str mbr;
> fd=ope
On Sat, 18 Apr 2009 12:25:29 -0700 (PDT), KoolD wrote:
Hi,
> I need to convert a C code to python please help me figure out how to
> do
> it.
> Suppose the C program's like:
...
> Is there a way to code it in python.
You need struct module:
http://docs.python.org/library/struct.html
http://www.d
Hey all,
I need to convert a C code to python please help me figure out how to
do
it.
Suppose the C program's like:
typedef struct _str
{
int a;
char *b;
int c;
}str;
int main()
{
str mbr;
fd=open("/dev/sda",O_RDONLY);
read(fd,&mbr,sizeof(str));
}
-
Keith Thompson writes:
> "Gary Herron" writes:
>> Python *is* object-oriented
>
> I disagree. Care to provide proof of that statement?
AWOOGA!
The article I'm following up to (together with at least one other) is a
forgery, and the Followup-To header is set to comp.lang.c as part of an
effort
Keith Thompson wrote:
> "Gary Herron" writes:
>> Python *is* object-oriented
>
> I disagree. Care to provide proof of that statement?
Disagree all you like. Just do it silently, please.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://w
"Gary Herron" writes:
> Python *is* object-oriented
I disagree. Care to provide proof of that statement?
--
http://mail.python.org/mailman/listinfo/python-list
"Scott David Daniels" writes:
> To avoid using epsilon, do something like:
> if 1 + abs(x) != 1:
An OK effort, but you're wrong. That's not how to do it at all.
--
http://mail.python.org/mailman/listinfo/python-list
Hello Gabriel,
I just recently discovered that struct.pack does return a string. Everything
works fine now. Thanks for the heads up!
static PyObject *
sendMessage(PyObject *self, PyObject *args)
{
char *msg = "";
int len;
if (!PyArg_ParseTuple(args, "s#", &msg, &len))
return NULL;
ret
Hello Gabriel,
I just recently discovered that struct.pack does return a string. Everything
works fine now. Thanks for the heads up!
static PyObject *
sendMessage(PyObject *self, PyObject *args)
{
char *msg = "";
int len;
if (!PyArg_ParseTuple(args, "s#", &msg, &len))
return NULL;
ret
En Wed, 09 Apr 2008 05:05:45 -0300, Alvin Delagon <[EMAIL PROTECTED]>
escribió:
> I'm currently writing a simple python SCTP module in C. So far it works
> sending and receiving strings from it. The C sctp function sctp_sendmsg()
> has been wrapped and my function looks like this:
>
> sendMessag
Hello fellow pythonistas,
I'm currently writing a simple python SCTP module in C. So far it works
sending and receiving strings from it. The C sctp function sctp_sendmsg()
has been wrapped and my function looks like this:
sendMessage(PyObject *self, PyObject *args)
{
const char *msg = "";
if
"Marc 'BlackJack' Rintsch" schrieb
>
> > I don't think this qualifies as a bug, but I am astonished
> > that the struct module does not tell you whether you are
> > big endian, you have to find out yourself with
> >struct.unpack('@I', s)[0]==struct.unpack(">I", s)[0]
>
> Maybe a little more
On Sun, 16 Mar 2008 18:45:19 +0100, Martin Blume wrote:
> I don't think this qualifies as a bug, but I am astonished
> that the struct module does not tell you whether you are
> big endian, you have to find out yourself with
>struct.unpack('@I', s)[0]==struct.unpack(">I", s)[0]
Maybe a little
Completely helped! Working as expected now.
Thanks. You really got me out of a bind!
J.
On Mar 16, 10:23 am, "Martin Blume" <[EMAIL PROTECTED]> wrote:
> "jasonwiener" schrieb
>
> > I am having a VERY odd problem with unpacking right now.
> > I'm reading data from a binary file and then using a
"sturlamolden" schrieb
>
> > This seems to imply that the Mac, although running now
> > on Intel processors, is still big-endian.
>
> Or maybe the struct module thinks big-endian is native
> to all Macs? It could be a bug.
>
Dunno, I'm on thin ice here. Never used a Mac.
Maybe the underlying
you can specifify which encoding when you unpack the struct, so just try
them till it works, or read the specs on the mac.. i find it quicker to try,
there's only 4-5
2008/3/16, sturlamolden <[EMAIL PROTECTED]>:
>
> On 16 Mar, 18:23, "Martin Blume" <[EMAIL PROTECTED]> wrote:
>
> > This seems to im
On 16 Mar, 18:23, "Martin Blume" <[EMAIL PROTECTED]> wrote:
> This seems to imply that the Mac, although running now on Intel
> processors, is still big-endian.
Or maybe the struct module thinks big-endian is native to all Macs? It
could be a bug.
--
http://mail.python.org/mailman/listinfo/p
"jasonwiener" schrieb
>
> I am having a VERY odd problem with unpacking right now.
> I'm reading data from a binary file and then using a very
> simple struct.unpack to get a long. Works fine on my MacBook,
> but when I push it to a Linux box,it acts differently and
> ends up pewking.
> [...]
try twiddling the unpack prefix, they're probably stored in different binary
formats on the disk...
on the struct helppage, is a list of prefixes, can be like
unpack('=HI',data)
unpack('@HI',data)
etc...
find out which one works on each machine
2008/3/16, jasonwiener <[EMAIL PROTECTED]>:
>
> H
Hi-
I am having a VERY odd problem with unpacking right now. I'm reading
data from a binary file and then using a very simple struct.unpack to
get a long. Works fine on my MacBook, but when I push it to a Linux
box,it acts differently and ends up pewking.
here's the code snippet:
[EMAIL PROTECTED] schrieb:
> (Is this the right place to ask ctypes questions? There's a mailing list
> but the last post to it seems to have been in November 2006.)
You could use the ctypes-users mailing list:
https://lists.sourceforge.net/lists/listinfo/ctypes-users
It is also available via gm
> > (Is this the right place to ask ctypes questions? There's a mailing list
> > but the last post to it seems to have been in November 2006.)
>
> No, it's active.
Thanks. I guess the official ASPN-based archive must be dead.
I managed to sort of get access to the array just using indexing
as
[EMAIL PROTECTED] schrieb:
> (Is this the right place to ask ctypes questions? There's a mailing list
> but the last post to it seems to have been in November 2006.)
No, it's active.
> Using ctypes I reference a structure which contains a pointer to an array of
> another structure:
>
> clas
(Is this the right place to ask ctypes questions? There's a mailing list
but the last post to it seems to have been in November 2006.)
Using ctypes I reference a structure which contains a pointer to an array of
another structure:
class SYMBOL(Structure):
_fields_ = [("symbol", c_ch
I'm having some trouble building a proper argument for an ioctl call.
The operation I'm working with is TUNSETIFF _IOW('T', 202, int) which
takes a struct ifreq as the arg. Could someone familiar with the
struct (usually defined in net/if.h) tell me how the heck to encode it
using the struct/array
ile format". Quite a
difference.
3. One could ask: How you would do it in your C app, if C didn't have
bitfields in structs?
Never mind, I'll give a bit more detail:
In your Python script:
!APOS = 0; BPOS = 1; CPOS = 2
!for each record: # pseudocode
! outint = 0
! if is_a:
Anyone have any idea?
[EMAIL PROTECTED] wrote:
> Roy Smith wrote:
> > In article <[EMAIL PROTECTED]>,
> > Cappy2112 <[EMAIL PROTECTED]> wrote:
> > >there is a bitfiled mainpulator class inthe Cookbook, but I don't
> > >understand his explanation, and the example given doesn't really
> show
> > >of
Roy Smith wrote:
> In article <[EMAIL PROTECTED]>,
> Cappy2112 <[EMAIL PROTECTED]> wrote:
> >there is a bitfiled mainpulator class inthe Cookbook, but I don't
> >understand his explanation, and the example given doesn't really
show
> >off the features of the class.
>
> I assume you're talking abou
In article <[EMAIL PROTECTED]>,
Cappy2112 <[EMAIL PROTECTED]> wrote:
>there is a bitfiled mainpulator class inthe Cookbook, but I don't
>understand his explanation, and the example given doesn't really show
>off the features of the class.
I assume you're talking about the struct module? If you gi
there is a bitfiled mainpulator class inthe Cookbook, but I don't
understand his explanation, and the example given doesn't really show
off the features of the class.
I too need bit-level manipulation, and will probably have to write my
own class to do it.
--
http://mail.python.org/mailman/listi
[EMAIL PROTECTED] wrote:
> How would I go about writing a bitfield that can be read by my C app? I
> want to pack a few bools into one int.
>
> I know an extended module exists (npstruct) which helps you do this but
> I want to do it manually or using one of the standard modules.
>
struct.pack is
How would I go about writing a bitfield that can be read by my C app? I
want to pack a few bools into one int.
I know an extended module exists (npstruct) which helps you do this but
I want to do it manually or using one of the standard modules.
--
http://mail.python.org/mailman/listinfo/python-
Alex Martelli wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
I like the idea of chain, though, so I'll probably add the class with
just __init__ and __getattribute__ to the current implementation. I'm
willing to be persuaded, of course, but for the moment, since I can see
a few different options
Alex Martelli wrote:
Nick Coghlan <[EMAIL PROTECTED]> wrote:
For bindings, you could just go with standard Python semantics - normal
name binding always happens in the innermost scope, so binding a name in a
namespace should happen in the directly referenced namespace. Then you can
shadow names fro
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I'm not sure how much _I_ like them... =) It makes me uneasy that
>
> del b.x
> print b.x
>
> doesn't throw an AttributeError. OTOH, if you're using namespaces as
> the equivalent of nested scopes, deleting all 'x' attributes is probably
> n
Alex Martelli wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
I didn't know what to do for __setattr__... Was that what you meant by
"The best semantics for _bindings_ as opposed to lookups isn't clear
though"?
Yep. __delattr__ ain't too obvious to me either, though I guess your
semantics for t
Steven Bethard <[EMAIL PROTECTED]> wrote:
> I didn't know what to do for __setattr__... Was that what you meant by
> "The best semantics for _bindings_ as opposed to lookups isn't clear
> though"?
Yep. __delattr__ ain't too obvious to me either, though I guess your
semantics for that are OK.
Alex Martelli wrote:
Nick Coghlan <[EMAIL PROTECTED]> wrote:
We could use __add__, instead for combining namespaces
Update already let's us combine namespaces. To create a new object that
merges
two namespaces do:
namespace.update(namespace(ns_1), ns_2)
One thing I'd like to see in namespaces
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > One thing I'd like to see in namespaces is _chaining_ -- keeping each
> > namespace separate but having lookups proceed along the chain. (The
> > best semantics for _bindings_ as opposed to lookups isn't clear though).
>
> Hmm, s
On Wed, 09 Feb 2005 21:56:54 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > One thing I'd like to see in namespaces is _chaining_ -- keeping each
> > namespace separate but having lookups proceed along the chain. (The
> > best semantics for _bindings_ as opposed to looku
Alex Martelli wrote:
One thing I'd like to see in namespaces is _chaining_ -- keeping each
namespace separate but having lookups proceed along the chain. (The
best semantics for _bindings_ as opposed to lookups isn't clear though).
Hmm, so if it doesn't find it in the current namespace, it looks i
On Tue, 8 Feb 2005 12:01:23 +0100, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> > > We could use __add__, instead for combining namespaces
> >
> > Update already let's us combine namespaces. To create a new object that
> > merges
> > two namespaces do:
>
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > We could use __add__, instead for combining namespaces
>
> Update already let's us combine namespaces. To create a new object that merges
> two namespaces do:
>namespace.update(namespace(ns_1), ns_2)
One thing I'd like to see in namespaces is _chai
Michael Spencer wrote:
Nick Coghlan wrote:
The other issue is that a namespace *is* a mutable object, so the
default behaviour should be to make a copy
I don't follow this argument. Why does mutability demand copy? Given
that somedict here is either a throwaway (in the classic bunch
applicati
Steven Bethard wrote:
I wonder if it would be worth adding a descriptor that gives a warning
for usage from instances, e.g.:
Thinking about it some more, I realised that a class method approach means that
'type(self).method(self,...)' still works as a way to spell the call in a
polymorphism frie
Michael Spencer wrote:
I see no problem in repeating the methods, or inheriting the
implementation. However, if namespace and bunch are actually different
concepts (one with reference semantics, the other with copy), then
__repr__ at least would need to be specialized, to highlight the
differen
Steven Bethard wrote:
Do you mean there should be a separate Namespace and Bunch class? Or do
you mean that an implementation with only a single method is less useful?
The former.
If the former, then you either have to repeat the methods __repr__,
__eq__ and update for both Namespace and Bunch,
On Mon, 07 Feb 2005 13:31:20 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> Carlos Ribeiro wrote:
> > On Mon, 07 Feb 2005 11:50:53 -0700, Steven Bethard
> > <[EMAIL PROTECTED]> wrote:
> >
> >>Michael Spencer wrote:
> >>
> >>>We could use __add__, instead for combining namespaces
> >>
> >>I don'
Carlos Ribeiro wrote:
On Mon, 07 Feb 2005 11:50:53 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
Michael Spencer wrote:
We could use __add__, instead for combining namespaces
I don't think this is a good idea. For the same reasons that dicts
don't have an __add__ (how should attributes with dif
On Mon, 07 Feb 2005 11:50:53 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> Michael Spencer wrote:
> > We could use __add__, instead for combining namespaces
>
> I don't think this is a good idea. For the same reasons that dicts
> don't have an __add__ (how should attributes with different va
Michael Spencer wrote:
Nick Coghlan wrote:
Steven Bethard wrote:
It was because these seem like two separate cases that I wanted two
different functions for them (__init__ and, say, dictview)...
I see this, but I think it weakens the case for a single implementation,
given that each implementatio
Nick Coghlan wrote:
Steven Bethard wrote:
It was because these seem like two separate cases that I wanted two
different functions for them (__init__ and, say, dictview)...
I see this, but I think it weakens the case for a single implementation, given
that each implementation is essentially one me
Nick Coghlan wrote:
Finally, I've just used normal names for the functions. I think the
issue of function shadowing is best handled by recommending that all of
the functions be called using the class explicitly - this works just as
well for instance methods as it does for class or static methods
Alex Martelli said unto the world upon 2005-02-06 18:06:
Brian van den Broek <[EMAIL PROTECTED]> wrote:
...
(I'm just a hobbyist, so if this suggestion clashes with some well
established use of 'Bag' in CS terminology, well, never mind.)
Yep: a Bag is a more common and neater name for a "multi
Steven Bethard wrote:
It was because these seem like two separate cases that I wanted two
different functions for them (__init__ and, say, dictview)...
The other issue is that a namespace *is* a mutable object, so the default
behaviour should be to make a copy (yeah, I know, I'm contradicting mys
Michael Spencer wrote:
ISTM that 'bunch' or 'namespace' is in effect the complement of vars
i.e., while vars(object) => object.__dict__, namespace(somedict) gives
an object whose __dict__ is somedict.
Yeah, I kinda liked this application too, and I think the symmetry would
be nice.
Looked at th
Alex Martelli wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
Hmm... interesting. This isn't the main intended use of
Bunch/Struct/whatever, but it does seem like a useful thing to have...
I wonder if it would be worth having, say, a staticmethod of Bunch that
produced such a view, e.g.:
class
Steven Bethard wrote:
> The complications with attribute hiding is one of main reasons I've
> tried to minimize the number of methods associated with Bunch...
in order for bunches to be fully useful in general, open contexts, I think that
number of methods should be exactly zero (at least without
Brian van den Broek <[EMAIL PROTECTED]> wrote:
...
> (I'm just a hobbyist, so if this suggestion clashes with some well
> established use of 'Bag' in CS terminology, well, never mind.)
Yep: a Bag is a more common and neater name for a "multiset" -- a
set-like container which holds each item ``
Alex Martelli wrote:
Steven Bethard <[EMAIL PROTECTED]> wrote:
I don't know what the right solution is here... I wonder if I should
write a classmethod-style descriptor that disallows the calling of a
function from an instance? Or maybe I should just document that the
classmethods should only b
Steven Bethard <[EMAIL PROTECTED]> wrote:
> Seems pretty reasonable -- the only thing I worry about is that
> classmethods and other attributes (e.g. properties) that are accessible
> from instances can lead to subtle bugs when a user accidentally
> initializes a Bunch object with the attributes
Alex Martelli wrote:
I think this ``view'' or however you call it should be a classmethod
too, for the same reason -- let someone handily subclass Bunch and still
get this creational pattern w/o extra work. Maybe a good factoring
could be something like:
class Bunch(object):
def __init__(self,
Steven Bethard <[EMAIL PROTECTED]> wrote:
> Hmm... interesting. This isn't the main intended use of
> Bunch/Struct/whatever, but it does seem like a useful thing to have...
> I wonder if it would be worth having, say, a staticmethod of Bunch that
> produced such a view, e.g.:
>
> class Bunch(ob
Nick Coghlan wrote:
By assigning to __dict__ directly, you can use the attribute view either
as it's own dictionary (by not supplying one, or supplying a new one),
or as a convenient way to programmatically modify an existing one. For
example, you could use it to easily bind globals without need
Steven Bethard wrote:
Nick Coghlan wrote:
I think the idea definitely deserves mention as a possible
implementation strategy in the generic objects PEP, with the data
argument made optional:
That's basically what the current implementation does (although I use
'update' instead of '='). The cod
Carlos Ribeiro said unto the world upon 2005-02-05 16:35:
On Sat, 05 Feb 2005 15:59:00 -0500, Brian van den Broek
<[EMAIL PROTECTED]> wrote:
(I'm just a hobbyist, so if this suggestion clashes with some well
established use of 'Bag' in CS terminology, well, never mind.)
There's already a well know
On Sat, 05 Feb 2005 15:59:00 -0500, Brian van den Broek
<[EMAIL PROTECTED]> wrote:
> (I'm just a hobbyist, so if this suggestion clashes with some well
> established use of 'Bag' in CS terminology, well, never mind.)
There's already a well know know use for the 'bag' name, including a
recipe in Py
On Sat, 05 Feb 2005 12:05:13 -0700, Steven Bethard
<[EMAIL PROTECTED]> wrote:
> The type suggested in this PEP also allows a simple means of
> representing hierarchical data that allows attribute-style access::
>
> >>> x = Bunch(spam=Bunch(rabbit=1, badger=[2, 3, 4]), ham='neewom')
> >>>
Steven Bethard said unto the world upon 2005-02-05 14:05:
Nick Coghlan wrote:
Steven Bethard wrote:
Yes -- help me rally behind my generic object PEP which proposes a
Bunch type (probably to be renamed) for the Python standard lib. =)
Did you see the suggestion of 'namespace' as a name?
Yup, it'
Steven Bethard wrote:
Nick Coghlan wrote:
class attr_view(object):
def __init__(self, data):
self.__dict__ = data
I think the idea definitely deserves mention as a possible
implementation strategy in the generic objects PEP, with the data
argument made optional:
That's basically wh
Alex Martelli wrote:
Nick Coghlan <[EMAIL PROTECTED]> wrote:
...
Michael Spencer also posted ...
Wasted indirection, IMHO. A better implementation:
class attr_view(object):
def __init__(self, data):
self.__dict__ = data
Alex
Indeed! A complete brain-blip
Michael
--
http://mail.pyth
Nick Coghlan wrote:
Alex Martelli wrote:
Nick Coghlan <[EMAIL PROTECTED]> wrote:
...
Michael Spencer also posted an interesting idea recently about
setting up
a view of an existing dictionary, rather than as a separate object:
class attr_view(object):
def __init__(self, data):
object.__s
Nick Coghlan wrote:
Steven Bethard wrote:
Yes -- help me rally behind my generic object PEP which proposes a
Bunch type (probably to be renamed) for the Python standard lib. =)
Did you see the suggestion of 'namespace' as a name?
Yup, it's in the current PEP draft. See the "Open Issues" section:
Alex Martelli wrote:
Nick Coghlan <[EMAIL PROTECTED]> wrote:
...
Michael Spencer also posted an interesting idea recently about setting up
a view of an existing dictionary, rather than as a separate object:
class attr_view(object):
def __init__(self, data):
object.__setattr__(self, "_data"
On Sat, 05 Feb 2005 02:38:13 -0500, Leif K-Brooks <[EMAIL PROTECTED]> wrote:
> Actually, in Python, class definitions are runtime executable statements
> just like any other. You can do this:
>
> >>> def make_class(with_spam=True):
> ... if with_spam:
> ... class TheClass(object):
> ...def
Nick Coghlan <[EMAIL PROTECTED]> wrote:
...
> Michael Spencer also posted an interesting idea recently about setting up
> a view of an existing dictionary, rather than as a separate object:
>
> class attr_view(object):
>def __init__(self, data):
> object.__setattr__(self, "_data", data
Steven Bethard wrote:
Yes -- help me rally behind my generic object PEP which proposes a Bunch
type (probably to be renamed) for the Python standard lib. =)
Did you see the suggestion of 'namespace' as a name? Given that the idea is to
get access to the contents using the standard Python syntax f
Alan McIntyre wrote:
You could do something like this:
blah = type('Struct', (), {})()
blah.some_field = x
I think I'd only do this if I needed to construct objects at runtime
based on information that I don't have at compile time, since the two
lines of code for your empty class would probably b
Christopher J. Bottaro wrote:
I find myself doing the following very often:
class Struct:
pass
...
blah = Struct()
blah.some_field = x
blah.other_field = y
...
Is there a better way to do this? Is this considered bad programming
practice? I don't like using tuples (or lists) because I'd r
Christopher,
I've found myself doing the same thing. You could do something like this:
blah = type('Struct', (), {})()
blah.some_field = x
I think I'd only do this if I needed to construct objects at runtime
based on information that I don't have at compile time, since the two
lines of code for
Christopher J. Bottaro wrote:
I find myself doing the following very often:
class Struct:
pass
...
blah = Struct()
blah.some_field = x
blah.other_field = y
...
Is there a better way to do this?
Yes -- help me rally behind my generic object PEP which proposes a Bunch
type (probably to be re
I find myself doing the following very often:
class Struct:
pass
...
blah = Struct()
blah.some_field = x
blah.other_field = y
...
Is there a better way to do this? Is this considered bad programming
practice? I don't like using tuples (or lists) because I'd rather use
symbolic names, ra
86 matches
Mail list logo
