complex data handler with type defs, need help disabling I/O

A forum for general discussion of the Python programming language.

complex data handler with type defs, need help disabling I/O

Postby Tcll » Wed Jan 01, 2014 7:03 pm

I tried to keep the title as simple as possible... heh
before-hand: if I'm posting this in the wrong area, I'm sorry :)

so...
what I'm trying to achieve is 2 seperate functions which return the same class definition (not an instance),
one function of which disables data I/O on an external array.

here's the idea:
Code: Select all
#read 1 byte of data from external memory source and return the value as a bu8 instance
data1 = bu8()
print type(data1) #>>> <class '__main__.BU_1'>

data2 = BU8(240) #return '240' as a bu8 instance (disable external I/O)
print type(data2) #>>> <class '__main__.BU_1'>

print type(data1) == bu8 #>>> True
print type(data2) == bu8 #>>> True
print type(data2) == bu(1) #>>> True (bu8's class definition)


note that a bu8 instance caps an int between 0 and 255

can I get your ideas on this?? :/
(credit will be given in the src for your help)
Last edited by stranac on Wed Jan 01, 2014 7:10 pm, edited 1 time in total.
Reason: First post lock.
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Wed Jan 01, 2014 7:18 pm

I don't really understand the question...

Can you post the code for your class definition?
Also, explain what parts of it you want to disable/change.
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Wed Jan 01, 2014 8:01 pm

well... this is my last working code, which gets the functions working as they should,
but the types aren't comparable:

Code: Select all
def _BUinitIO(this, value=''):
    this.value = 0
    if value=='': #read
        DATA = [0xff]*this.size #dummy data generator till I finish memory objects
        for v in DATA: this.value = (this.value<<8)|v #convert the 'B' array into a single value
    elif type(value) == int:
        if -1<value<(1<<(this.size<<3))-1:
            DATA = [(value>>(i*8))&255 for i in range(this.size)]
            this.value = value
        else: #pass with lossy values:
            if 0>value: DATA = [0]*this.size; this.value = 0
            else: DATA = [255]*this.size; this.value = (1<<(this.size<<3))-1
            #write DATA to the file
    else:
        raise TypeError('an int or blank string is required')

def _BUinitNIO(this, value):
    this.value = 0
    if type(value) == int:
        if -1<value<(1<<(this.size<<3))-1: this.value = value
        else: this.value = 0 if 0>value else (1<<(this.size<<3))-1 #pass with lossy values:
    else:
        raise TypeError('an int is required')

_buTypes = {}
def bu(byte_size):
    global _buTypes
    try: del _buTypes[byte_size]
    except KeyError:
    _buTypes[byte_size] = type(
        'BU_%i'%byte_size,
        (int,),
        dict( size=byte_size,
              __init__=_BUinitIO,
              __call__=lambda this: this.value,
              #__repr__=lambda this: '%i'%this.value
              )
        )
    return _buTypes[byte_size] #return the class object
   
def BU(byte_size):
    global _buTypes
    try: del _buTypes[byte_size]
    except KeyError:
    _buTypes[byte_size] = type(
        'BU_%i'%byte_size,
        (int,),
        dict( size=byte_size,
              __init__=_BUinitNIO,
              __call__=lambda this: this.value,
              #__repr__=lambda this: '%i'%this.value
              )
        )
    return _buTypes[byte_size] #return the class object

#fixed-type functions/types:
byte = bu8 = bu(1)
short = bu16 = bu(2)
bu24 = bu(3)
word = bu32 = bu(4)
dword = bu64 = bu(8)

BYTE = BU8 = BU(1)
SHORT = BU16 = BU(2)
BU24 = BU(3)
WORD = BU32 = BU(4)
DWORD = BU64 = BU(8)


the reason I asked for ideas is because I'm not sure if this whole thing should be scrapped and redone...
so yea... change everything if needed... :/
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Wed Jan 01, 2014 9:03 pm

Wow, that's an incredible abuse of... everything.
I'll take a better look later, and let you know if I have any ideas.
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Wed Jan 01, 2014 9:43 pm

stranac wrote:Wow, that's an incredible abuse of... everything.
I'll take a better look later, and let you know if I have any ideas.

kk thanks :)

the reason for everything being like that (shoulda explained earlier)...
the initial code I started with was simply for R/W purposes...
(I wanted to add my own handlers for C-type data and how it would behave represented as such)

but then I changed my mind and wanted it to return an int object when modified:
bu8() >>> bu(1) object
bu8()+1 >>> int object
BU8(bu8()+1) >>> bu(1) object
basically a somewhat similar method to defining C variables.

so anyways...
originally, the bu() function would try to return the created class for a specific byte-size:
bu8 = bu(1)
bu(1)() #read a big-unsigned 1-byte int
bu8(240) #write a big-unsigned 1-byte int (return a bu(1) object for possible further inspection)

type(bu(1)()) == (bu(1) or bu8)

bu16 = bu(2)

internally, you'll notice the private _buTypes dict-var.
that should now look like:
{
1: <class '__main__.BU_1'>,
2: <class '__main__.BU_2'>
}

calling bu(size) is like calling _buTypes[size],
except bu(size) also creates a new class if it doesn't exist.
(idea from C#'s .NET profiler)

EDIT:
also... please excuse me if my speech doesn't make any sense what-so-ever... heh
I have to blame my autism on that one, and it's also the reason I didn't explain earlier. :P
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Wed Jan 01, 2014 10:31 pm

Why not normally create two classes, instead of using type()?
That would probably be simpler and more readable.

Also, making subclasses of int callable seems...silly.
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Wed Jan 01, 2014 11:26 pm

stranac wrote:Why not normally create two classes, instead of using type()?
That would probably be simpler and more readable.


/is confused by your question

1: I'm trying to make it easy for python noobs dealing with files to write a script for my program
I want it to return the value as it's type so the noobs won't have stupid questions... heh

2: I need the types to match...
what I mean is the function doesn't instantiate the class... you do, in the script...

so we need bu() to return the same object as BU(), but it's up to the object to identify and maintain that data.
(such as memory overflows and such, though it caps it when that happens)

I don't want the importer to stop unless it absolutely has to
(meaning for u8() vertices, if it's capped before it's parsed as a float, it'll just display improperly.)
^ the import is still successful even though the data turned out to be invalid


stranac wrote:Also, making subclasses of int callable seems...silly.

I know... I want to leave a loose end in case I need support for that type of analysis

the data I'm dealing with is model data from MANY various platforms...
so there may be a case where I'll need to test the data before I can send it to the program.
(I doubt it, but I've seen some pretty weird formatting back in my days... heh)


another reason for these data types is pointer validation in memory objects
(thus partly the reason for the modified value becoming an int)

or am I just sounding stupid and highly over-thinking things??


should I explain even further back??
or perhaps just show you my program:
public repo: https://www.dropbox.com/sh/9c6s8kg3jd3gqje/5_mWYuuuT1
recent progress images: http://picasaweb.google.com/Tcll5850/UMC#

note, the linked stuff is for dev4... the code here is for dev5 which is a complete rehaul over everything.


also... I now finally understood your question XD
(curse my autism)

the reason for type() is to create a new class based off the byte-size and profile it for reference as explained in my last message
creating 2 classes would basically allow: bu(1) == bu(2) >>> True
as bu(1) >>> <class '__main__.BU_'>
and bu(2) >>> <class '__main__.BU_'>

and it would also not match the type reference:
bu(1) == BU(1) >>> False

from the current standpoint:
>>> BU_1
NameError
>>> bu(1) #or BU(1) (create the class)
<class '__main__.BU_1'>
>>> bu(1) #or BU(1) (reference the class)
<class '__main__.BU_1'>
>>> BU_1
<class '__main__.BU_1'>

take note:
>>> bu(1)
<class '__main__.BU_1'>

EDIT:
there is a simple way I could pull this off, but that means the user has to set and option such as:
bu(1)(enableIO=False)
I don't want the user to know about that.
"user" as in the noob building the script.
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Thu Jan 02, 2014 12:47 am

Tbh, I don't understand what you mean by most of those points...

Can you show some concrete examples of what you want to happen, and what you think will happen instead if you use two classes?
I mean, you have shown some examples, but I don't understand if that's what you want, or what you don't want...

This part in particular makes absolutely no sense to me, but there are others:
Tcll wrote:so we need bu() to return the same object as BU(), but it's up to the object to identify and maintain that data.
(such as memory overflows and such, though it caps it when that happens)

I don't want the importer to stop unless it absolutely has to
(meaning for u8() vertices, if it's capped before it's parsed as a float, it'll just display improperly.)
^ the import is still successful even though the data turned out to be invalid


Tcll wrote:or am I just sounding stupid and highly over-thinking things??

That's one possibility.

Tcll wrote:creating 2 classes would basically allow: bu(1) == bu(2) >>> True
as bu(1) >>> <class '__main__.BU_'>
and bu(2) >>> <class '__main__.BU_'>

Err, no. == will compare values, not types.

Tcll wrote:there is a simple way I could pull this off, but that means the user has to set and option such as:
bu(1)(enableIO=False)
I don't want the user to know about that.

What's the point in hiding stuff?
It's more obvious what the difference is if you let them set the option explicitly.
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Thu Jan 02, 2014 12:58 am

ah
sorry for being so confusing...

so... ok... what do you have in mind when you say "2 classes"??

all I want is for 2 seperate functions to tag the data as a type.
one function performs a R/W
the other just handles the data given to it.

the problem though is when the returned class is instantated...
how can I tell if I'm reading/writing an int and tagging it, or just tagging a supplied value??

EDIT:
stranac wrote:
Tcll wrote:creating 2 classes would basically allow: bu(1) == bu(2) >>> True
as bu(1) >>> <class '__main__.BU_'>
and bu(2) >>> <class '__main__.BU_'>

Err, no. == will compare values, not types.


uhh...
http://www.daniweb.com/software-develop ... -type-defs
that's the old idea, fully working

EDIT2:
also there's: type(9) == int
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Thu Jan 02, 2014 1:59 am

Tcll wrote:so... ok... what do you have in mind when you say "2 classes"??

Something like:
Code: Select all
def create_bu(byte_size):
    class bu(int):
        size = byte_size

        def __init__(self, value):
            # do I/O in here
            super(bu, self).__init__(self, value)

    return bu


def create_BU(byte_size):
    class BU(int):
        size = byte_size

        def __init__(self, value):
            # don't do I/O in here
            super(BU, self).__init__(self, value)

    return BU


I mean, the instances are not going to be the exact same type, but that should pretty much never be important in python.
If you wanna know if their sizes are equal, just check that...

Tcll wrote:the problem though is when the returned class is instantated...
how can I tell if I'm reading/writing an int and tagging it, or just tagging a supplied value??

Sorry, don't know what "reading/writing an int and tagging it, or just tagging a supplied value" means.

Tcll wrote:also there's: type(9) == int

Don't see how that's relevant...
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Thu Jan 02, 2014 2:46 am

ah...
yea, I just want 1 class for both functions.

the only differences between bu() and BU() are:
- bu() handles data on an external variable (a var containing array('B',[]) to store the bytes of a file for extremely fast access)
- BU() only tags the data, and doesn't accept the read input like bu()('')

for example:
Code: Select all
color = bu(1)(['','','','']) #read 4 values from the file and tag as bu(1)

#or

d = bu(2)() #16bit RGB565 format
R = int(((d>>11)&31)*(255.0/31))
G = int(((d>>5)&63)*(255.0/63))
B = int((d&31)*(255.0/31))

color = BU(1)([R,G,B,255]) #tag each value as bu(1)
#BU(1) won't try to write the data where bu(1) will

ugeSetColor(color) #store the vertex color internally
#(since the type is bu(1), it won't auto-assume an invalid type when converting to the export format)
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Thu Jan 02, 2014 3:21 am

Tcll wrote:the only differences between bu() and BU() are:
- bu() handles data on an external variable (a var containing array('B',[]) to store the bytes of a file for extremely fast access)
- BU() only tags the data, and doesn't accept the read input like bu()('')

Yeah, they're doing different stuff, so it doesn't make sense that they're the same class.
There really is very little benefit to them being the same class(and they're not the same class in the original code either, each call to the functions creates a new class).

Tcll wrote:
Code: Select all
ugeSetColor(color) #store the vertex color internally
#(since the type is bu(1), it won't auto-assume an invalid type when converting to the export format)

Why does your code care if the type is bu(1) or BU(1) ?

Honestly, I would just pass an argument to signify if you want I/O or not.
Hiding stuff from your users is stupid: they know if they want I/O or not(how would they choose the right function otherwise), so telling them to pass an argument shouldn't be a problem...
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Thu Jan 02, 2014 3:43 am

stranac wrote:(and they're not the same class in the original code either, each call to the functions creates a new class).

that was a dummy test... it's slow and inefficient (re-creating the class every time is a bad idea)
the older code is a better example to go by for that.

stranac wrote:Why does your code care if the type is bu(1) or BU(1) ?

because the logic is much simpler to build.
(the converter won't need to stress over lossy conversion methods from HQ to LQ values)

also... I think I've finally understood your hint about using 2 classes:

BU can call a much simpler class which can simply be used to store the value.
where the class on bu will call a wrapper class to accept the "" input,
read/write the value, and then inject the value into the class used by BU and return the instance.
where-by negating the class used by bu and replacing it with the the returned instance. :geek:

is that around what you meant??

EDIT:
I had that backwards...
that would make BU() the object... not bu() like I want... heh
Last edited by Tcll on Thu Jan 02, 2014 3:54 am, edited 1 time in total.
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Thu Jan 02, 2014 3:51 am

Tcll wrote:
stranac wrote:Why does your code care if the type is bu(1) or BU(1) ?

because the logic is much simpler to build.
(the converter won't need to stress over lossy conversion methods from HQ to LQ values)

That doesn't really make sense. The instances of the two classes are holding the same values, so how would the class make a difference?

Tcll wrote:also... I think I've finally understood your hint about using 2 classes:

BU can call a much simpler class which can simply be used to store the value.
where the class on bu will call a wrapper class to accept the "" input,
read/write the value, and then inject the value into the class used by BU and return the instance.
where-by negating the class used by bu and replacing it with the the returned instance. :geek:

is that around what you meant??

I guess. But this is exactly what the code you posted is doing, it's just doing it a weird way.
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Thu Jan 02, 2014 4:03 am

stranac wrote:That doesn't really make sense. The instances of the two classes are holding the same values, so how would the class make a difference?

2 or 3 steps (class validation) vs 1 step

multiply that by the number of verts, normals, UVs, and possibly even vertex colors for the model.
that's quite alot of extra steps that can really slow down the conversion process.

while I did say python was fast, I didn't say it was THAT fast... :P
there has to be a sacrifice somewhere :3
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Thu Jan 02, 2014 4:24 am

Tcll wrote:
stranac wrote:That doesn't really make sense. The instances of the two classes are holding the same values, so how would the class make a difference?

2 or 3 steps (class validation) vs 1 step

Sounds like you are doing something wrong...
If you care which class it is, you have to do the type-checking.(complicated)
If you don't, no need for type-checking.(simple)

If you can post an example, I'll be happy to take a look...tomorrow. It's really late here.(or should I say it's kinda early?)
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Thu Jan 02, 2014 4:38 pm

stranac wrote:
Tcll wrote:also... I think I've finally understood your hint about using 2 classes:

BU can call a much simpler class which can simply be used to store the value.
where the class on bu will call a wrapper class to accept the "" input,
read/write the value, and then inject the value into the class used by BU and return the instance.
where-by negating the class used by bu and replacing it with the the returned instance. :geek:

is that around what you meant??

I guess. But this is exactly what the code you posted is doing, it's just doing it a weird way.


what I meant was this...
and now I finally have an example to show off, but there's a small error I'm not pin-pointing atm:
Code: Select all
>>>
>>> BU8 = BU(1)
>>> BU8(0)

Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    BU8(0)
  File "C:\Dropbox\Universal_Model_Converter\API\data_handlers.py", line 40, in _BUinit
    def _BUinit(this, value): this.instance = this.subclass(value, __EnIO__=False)
TypeError: '__EnIO__' is an invalid keyword argument for this function
>>> bu(1) == bu(1)
True
>>> type(bu(1)()) == bu(1)
True
>>> bu(1) == bu(2)
False
>>>

NOTE: what's expected:
BU8 == bu(1) >>> False
type(BU8(23)) == bu(1) >>> True

anyways... here's my current code:
(everything else but what's noted works properly, and what's noted SHOULD work properly once passed this error)
Code: Select all
def _buinit(this, value='', __EnIO__=True):
    this.value = 0
    if __EnIO__ and value=='': #read
        DATA = [0xff]*this.size #dummy data generator till I finish memory objects
        for v in DATA: this.value = (this.value<<8)|v #convert the 'B' array into a single value
    elif type(value) == int:
        if -1<value<(1<<(this.size<<3))-1:
            if __EnIO__: DATA = [(value>>(i*8))&255 for i in range(this.size)]
            this.value = value
        else: #pass with lossy values:
            if 0>value: DATA = [0]*this.size; this.value = 0
            else: DATA = [255]*this.size; this.value = (1<<(this.size<<3))-1
            if __EnIO__: #write DATA to the file
                pass
    else:
        if __EnIO__:
            raise TypeError('an int or blank string is required')
        else:
            raise TypeError('an int is required')

_buTypes = {}
def bu(byte_size):
    global _buTypes
    try: return _buTypes[byte_size]
    except KeyError:
        _buTypes[byte_size] = type(
            'BU_%i'%byte_size, (int,),
            dict( size=byte_size,
                  __init__=_buinit,
                  )
            )
   
    return _buTypes[byte_size] #return the class object

_BUTypes = {}
def _BUinit(this, value): this.instance = this.subclass(value, __EnIO__=False)
def BU(byte_size):
    global _BUTypes, _buTypes
    try: return _BUTypes[byte_size]
    except KeyError:
        _BUTypes[byte_size] = type(
            'BU_%i'%byte_size, (object,),
            dict( subclass=_buTypes[byte_size],
                  __init__=_BUinit,
                  __call__=lambda this: this.instance,
                  )
            )
   
    return _BUTypes[byte_size] #return the class object

#fixed-type functions/types:
byte = bu8 = bu(1)
short = bu16 = bu(2)
bu24 = bu(3)
word = bu32 = bu(4)
dword = bu64 = bu(8)

BYTE = BU8 = BU(1)
SHORT = BU16 = BU(2)
BU24 = BU(3)
WORD = BU32 = BU(4)
DWORD = BU64 = BU(8)



also... after these are finished, I'm gonna need a little help on memory objects with sub-memory objects (for archives and sub-data of a file),
AND THEN pointer validation (HAL's DAT format found in SSB Melee and Kirby Air-Ride, and the MDL0 format found in quite a few Wii games could REALLY use this)...
that one could be a pain because I understand very little about pointers...
(tried designing my own language and failed) best image
^ I'm not giving up on it though... I just need knowledge and experience. XD
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby stranac » Thu Jan 02, 2014 10:02 pm

I would probably do something like this. Maybe. Or maybe I'd use separate init functions. Also maybe.
Actually, I probably wouldn't be doing stuff like this at all...
Code: Select all
_bu_dict = {}
_BU_dict = {}

def bu(size, enable_io=True, name_template='bu_%s', type_dict=_bu_dict):
    try:
        return type_dict[size]
    except KeyError:
        bu_class = create_class(size, enable_io)
        # change the name, add class to the dict and return it
        bu_class.__name__ = name_template % size
        type_dict[size] = bu_class
        return bu_class

def BU(size):
    return bu(size, enable_io=False, name_template='BU_%s', type_dict=_BU_dict)

def create_class(size, enable_io):
    class bu_class(int):
        def __init__(self, value=None):
            if value is None:
                if enable_io:
                    value = 0
                    data = [0xff] * size
                    for v in data:
                        value = (value << 8) | v
                else:
                    raise ValueError('The value argument can not be None '
                                     'for types with disabled I/O')
            # no need to do type checking
            try:
                something = (1 << (size << 3))-1
            except TypeError:
                # not *exactly* true
                # anything that behaves like an int for << is ok
                raise TypeError('The value must be an int')
            else:
                if -1 < value < something:
                    if enable_io:
                        data = [(value >> (i * 8)) & 255 for i in range(size)]
                elif 0 > value:
                    if enable_io:
                        data = [0] * size
                    value = 0
                else:
                    if enable_io:
                        data = [255] * size
                    value = something
            # do the writing if needed
            if enable_io:
                # write data
                print 'data:', data

    return bu_class

You can see a few style changes I have made, I would recommend you follow my example in your code:
  • naming:
    • ALL_CAPS names should only be used for constants
    • You should not be creating your own __dunder__ names
  • spacing: spaces around operators make code more readable
  • multiple statements on a single line should never be used
  • I also believe the way I placed comments is more readable
Friendship is magic!

R.I.P. Tracy M. You will be missed.
User avatar
stranac
 
Posts: 1132
Joined: Thu Feb 07, 2013 3:42 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Thu Jan 02, 2014 11:10 pm

well thanks for your input... but I can't accept the naming part... heh :)
I've got a few people on my repo who find my methods easier...
especially when it comes to building a script for my program (not precisely a Python script)

I'm trying to make that option hidden, but available if they REALLY need it.
(we're talking about noob programmers who know very little about data formatting)
^ as in they don't really need what's hidden

I want people to learn about advanced methods while building their scripts,
but not have to be stressed by writing highly complex schemes.

so all of this naming and typing is for simplification of high complexity when it comes to data handling.

as for the parts that don't use spaces and such...
that code has been optimized as I don't think it needs to be changed any further.

I'm a fan of 1-liners, and taking the smallest approach to achieving the same result.
(it's kindof by habbit now... heh)

EDIT: tried your code:
>>> var = bu(1)()
data: [255]
>>> var2 = BU(1)(25)
>>> type(var) == bu(1)
True

>>> type(var2) == bu(1)
False


EDIT2:
also... I've made changes to the last code...
BU is now a class:
Code: Select all
def _buinit(this, value='', IO=True):
    this.value = 0
    print type(value)
    if IO and value=='': #read
        DATA = [0xff]*this.size #dummy data generator till I finish memory objects
        for v in DATA: this.value = (this.value<<8)|v #convert the 'B' array into a single value
    elif type(value) == int:
        if -1<value<(1<<(this.size<<3))-1:
            if IO: DATA = [(value>>(i*8))&255 for i in range(this.size)]
            this.value = value
        else: #pass with lossy values:
            if 0>value: DATA = [0]*this.size; this.value = 0
            else: DATA = [255]*this.size; this.value = (1<<(this.size<<3))-1
            if IO: #write DATA to the file
                pass
    else:
        if IO:
            raise TypeError('an int or blank string is required')
        else:
            raise TypeError('an int is required')

_buTypes = {}
def bu(byte_size):
    global _buTypes
    try: return _buTypes[byte_size]
    except KeyError:
        _buTypes[byte_size] = type(
            'bu_%i'%byte_size, (int,),
            dict( size=byte_size,
                  __init__=_buinit,
                  )
            )
   
    return _buTypes[byte_size] #return the class object

class BU:
    def __init__(this, byte_size): this.size = byte_size
    def __call__(this, value): return bu(this.size)(value, False)
   
#fixed-type functions/types:
byte = bu8 = bu(1)
short = bu16 = bu(2)
bu24 = bu(3)
word = bu32 = bu(4)
dword = bu64 = bu(8)

BYTE = BU8 = BU(1)
SHORT = BU16 = BU(2)
BU24 = BU(3)
WORD = BU32 = BU(4)
DWORD = BU64 = BU(8)

there's still a few errors, and invalid returns... heh
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm

Re: complex data handler with type defs, need help disabling

Postby Tcll » Fri Jan 03, 2014 5:56 am

well, this is the best I can get it to currently:
Code: Select all
_buTypes = {}
def bu(byte_size):
    global _buTypes
    try: return _buTypes[byte_size]
    except KeyError:
        class bu_(object):
            size = byte_size; value = 0
            def __init__(this, value='', IO=True):
                if type(value) == float: value = int(value)
                if IO:
                    if value=='': #read
                        DATA = [0xff]*this.size #dummy data generator till I finish memory objects
                        for v in DATA: this.value = (this.value<<8)|v #convert the 'B' array into a single value
                    elif type(value) == int:
                        if -1<value<(1<<(this.size<<3))-1:
                            DATA = [(value>>(i*8))&255 for i in range(this.size)]
                            this.value = value
                        else: #pass with lossy values:
                            if 0>value: DATA = [0]*this.size; this.value = 0
                            else: DATA = [255]*this.size; this.value = (1<<(this.size<<3))-1
                            #write DATA to the file
                    else:
                        raise TypeError('an int or blank string is required')
                else:
                    if type(value) == int:
                        if -1<value<(1<<(this.size<<3))-1: this.value = value
                        else: this.value = 0 if 0>value else (1<<(this.size<<3))-1
                    else:
                        raise TypeError('an int is required')
                   
            def __repr__(this): return '%i'%this.value
           
            #TODO: operator handlers for managing these data types and returning ints, longs, or floats.
                   
        bu_class = bu_; bu_class.__name__ = 'bu_%s'%byte_size
        _buTypes[byte_size] = bu_class
    return _buTypes[byte_size] #return the class object

class BU(object):
    def __init__(this, byte_size): this.size = byte_size
    def __call__(this, value): return bu(this.size)(value, False)
   
#fixed-type functions/types:
byte = bu8 = bu(1)
short = bu16 = bu(2)
bu24 = bu(3)
word = bu32 = bu(4)
dword = bu64 = bu(8)

BYTE = BU8 = BU(1)
SHORT = BU16 = BU(2)
BU24 = BU(3)
WORD = BU32 = BU(4)
DWORD = BU64 = BU(8)


the only thing that slightly bothers me:
BU(1) == bu(1) >>> False
"slightly" because:
type(BU(1)(10)) == bu(1) >>> True

so everything seems to work as expected.
btw, thanks for reminding me about class definition within a class/function. ;)

I'm gonna make one last edit to reduce the type() calls.

also, the reason for the '' test is for back-end support when I was a real noob with python and didn't know how to:
def func(value='', ... ):

so I made '' a requirement as it was easier to type and just as understandable.
*sigh* memories...


also... D-post... bite meh :3
User avatar
Tcll
 
Posts: 100
Joined: Wed Jan 01, 2014 6:36 pm


Return to General Discussions

Who is online

Users browsing this forum: No registered users and 2 guests