This is an interesting project. Is your goal to simplify the use of CoreGraphics from Python? What's the advantage of using your python module over just importing Quartz and using it directly? That's not intended as a criticism, but a serious question. The answer will inform how you design the interface for your library.
Naming
#Naming OneOne thing I'd like to point out is that your naming is confusing. For example, you have:
def inch(x):
From just looking at the function prototype, it's not clear at all what the function returns or what the argument is supposed to be. The comment makes this even less clear. (If I'm using inches, why does the function return points?) A better way to name these would be something like:
def inchesToPoints(inches):
...
def cmToPoints(cm):
Also, why are you changing the constant name pi to PI?
Your naming is also inconsistent. You have makeRectangle() (which draws a rectangle rather than making one) and then just line() and circle(). These should all be something like fillRectangle(), strokeLine() and fillAndStrokeCircle(). Also, it would make sense to have the same forms for all shapes - fillRectangle(), strokeRectangle(), fillCircle(), strokeCircle(), etc.
API
#API
LookingLooking at the Quartz.framework headers, there is an object model immediately suggested to me. The main object in CoreGraphics is the CGContext. The header treats it as an opaque pointer, but we can assume for our purposes that it points to some sort of object behind-the-scenes. You could mimic that, offering a Context or DrawingContext class.
CoreGraphics also has several data types that it passes around, such as CGPoint, CGRect, and CGColor. These would make good classes, as well. And it turns out that python supports some operator overloading so you can make some useful methods like overloading + and - for easy use of points as vectors.
Now all of this might not be the right abstraction for your library. (Though it might be useful internally for it.) The right abstraction will depend on your goals. But most modern graphics APIs have a concept of some sort of context to draw into and a set of methods to do the drawing of various types of primitives (shapes, images, text, etc.). So it's a decent model to follow.
This is an interesting project. Is your goal to simplify the use of CoreGraphics from Python? What's the advantage of using your python module over just importing Quartz and using it directly? That's not intended as a criticism, but a serious question. The answer will inform how you design the interface for your library.
#Naming One thing I'd like to point out is that your naming is confusing. For example, you have:
def inch(x):
From just looking at the function prototype, it's not clear at all what the function returns or what the argument is supposed to be. The comment makes this even less clear. (If I'm using inches, why does the function return points?) A better way to name these would be something like:
def inchesToPoints(inches):
...
def cmToPoints(cm):
Also, why are you changing the constant name pi to PI?
Your naming is also inconsistent. You have makeRectangle() (which draws a rectangle rather than making one) and then just line() and circle(). These should all be something like fillRectangle(), strokeLine() and fillAndStrokeCircle(). Also, it would make sense to have the same forms for all shapes - fillRectangle(), strokeRectangle(), fillCircle(), strokeCircle(), etc.
#API
Looking at the Quartz.framework headers, there is an object model immediately suggested to me. The main object in CoreGraphics is the CGContext. The header treats it as an opaque pointer, but we can assume for our purposes that it points to some sort of object behind-the-scenes. You could mimic that, offering a Context or DrawingContext class.
CoreGraphics also has several data types that it passes around, such as CGPoint, CGRect, and CGColor. These would make good classes, as well. And it turns out that python supports some operator overloading so you can make some useful methods like overloading + and - for easy use of points as vectors.
Now all of this might not be the right abstraction for your library. (Though it might be useful internally for it.) The right abstraction will depend on your goals. But most modern graphics APIs have a concept of some sort of context to draw into and a set of methods to do the drawing of various types of primitives (shapes, images, text, etc.). So it's a decent model to follow.
This is an interesting project. Is your goal to simplify the use of CoreGraphics from Python? What's the advantage of using your python module over just importing Quartz and using it directly? That's not intended as a criticism, but a serious question. The answer will inform how you design the interface for your library.
Naming
One thing I'd like to point out is that your naming is confusing. For example, you have:
def inch(x):
From just looking at the function prototype, it's not clear at all what the function returns or what the argument is supposed to be. The comment makes this even less clear. (If I'm using inches, why does the function return points?) A better way to name these would be something like:
def inchesToPoints(inches):
...
def cmToPoints(cm):
Also, why are you changing the constant name pi to PI?
Your naming is also inconsistent. You have makeRectangle() (which draws a rectangle rather than making one) and then just line() and circle(). These should all be something like fillRectangle(), strokeLine() and fillAndStrokeCircle(). Also, it would make sense to have the same forms for all shapes - fillRectangle(), strokeRectangle(), fillCircle(), strokeCircle(), etc.
API
Looking at the Quartz.framework headers, there is an object model immediately suggested to me. The main object in CoreGraphics is the CGContext. The header treats it as an opaque pointer, but we can assume for our purposes that it points to some sort of object behind-the-scenes. You could mimic that, offering a Context or DrawingContext class.
CoreGraphics also has several data types that it passes around, such as CGPoint, CGRect, and CGColor. These would make good classes, as well. And it turns out that python supports some operator overloading so you can make some useful methods like overloading + and - for easy use of points as vectors.
Now all of this might not be the right abstraction for your library. (Though it might be useful internally for it.) The right abstraction will depend on your goals. But most modern graphics APIs have a concept of some sort of context to draw into and a set of methods to do the drawing of various types of primitives (shapes, images, text, etc.). So it's a decent model to follow.
This is an interesting project. Is your goal to simplify the use of CoreGraphics from Python? What's the advantage of using your python module over just importing Quartz and using it directly? That's not intended as a criticism, but a serious question. The answer will inform how you design the interface for your library.
#Naming One thing I'd like to point out is that your naming is confusing. For example, you have:
def inch(x):
From just looking at the function prototype, it's not clear at all what the function returns or what the argument is supposed to be. The comment makes this even less clear. (If I'm using inches, why does the function return points?) A better way to name these would be something like:
def inchesToPoints(inches):
...
def cmToPoints(cm):
Also, why are you changing the constant name pi to PI?
Your naming is also inconsistent. You have makeRectangle() (which draws a rectangle rather than making one) and then just line() and circle(). These should all be something like fillRectangle(), strokeLine() and fillAndStrokeCircle(). Also, it would make sense to have the same forms for all shapes - fillRectangle(), strokeRectangle(), fillCircle(), strokeCircle(), etc.
#API
Looking at the Quartz.framework headers, there is an object model immediately suggested to me. The main object in CoreGraphics is the CGContext. The header treats it as an opaque pointer, but we can assume for our purposes that it points to some sort of object behind-the-scenes. You could mimic that, offering a Context or DrawingContext class.
CoreGraphics also has several data types that it passes around, such as CGPoint, CGRect, and CGColor. These would make good classes, as well. And it turns out that python supports some operator overloading so you can make some useful methods like overloading + and - for easy use of points as vectors.
Now all of this might not be the right abstraction for your library. (Though it might be useful internally for it.) The right abstraction will depend on your goals. But most modern graphics APIs have a concept of some sort of context to draw into and a set of methods to do the drawing of various types of primitives (shapes, images, text, etc.). So it's a decent model to follow.