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) objectbu8()+1 >>> int objectBU8(bu8()+1) >>> bu(1) objectbasically 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 intbu8(240) #write a big-unsigned 1-byte int (return a bu(1) object for possible further inspection)

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 programI 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)

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 messagecreating 2 classes would basically allow: bu(1) == bu(2) >>> Trueas 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

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.

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

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()('')

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).

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...

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.

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.

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.

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.

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.

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:

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

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)