Any programming language in existence today has primitive types that values can be defined as. An example of this would be an integer or a string. This holds true for both statically typed languages and dynamically typed languages. The differences between the two programming language varieties is that in statically typed languages, variables require at least a primitive type before they may be assigned a value. That is, you can't say that variable int_obj has a value of 10 before declaring that int_obj is going to store integer values. Additionally, once a variable has been declared to store certain types, it cannot store a different type. So our int_obj cannot decide to store "10".
The reason for doing this is so that the program can be compiled into machine code that is directly executable by the hardware. Otherwise, the it only serves as a limitation. So are statically typed languages dead? This obviously depends on context because the raw machine code performance is always going to be a requirement. But does this been that entire applications need to be built using a statically typed languages such as C? Probably not. Developing in these languages is no easy task and there are several other development factors to consider during development such as maintainability. Dynamically typed languages offer much more flexibility in both design and maintainability. But this comes at the cost of performance because dynamically typed languages need a virtual machine to execute programs.
Java is an interesting language because it was designed to help implement C++ style applications without the added complexity. Java, however, is still considered a statically typed language. Developers still need to declare the type of the construct before it is used. Java still does perform well, but it is still an interpreted language that is statically typed. This actually helps with the performance even though it is an interpreted language.
So is it possible to have a dynamically typed language that can still support the raw performance offered by statically typed languages? The best approach here is to have a dynamically typed languages which are extended by the low level constructs of statically typed languages.
Showing posts with label type. Show all posts
Showing posts with label type. Show all posts
Monday, October 5, 2009
Wednesday, May 20, 2009
SQLAlchemy Bind and Result Processors
With any given object-relational mapper technology, the basic use case is the ability to map abstract data types to tables and instances of these types to rows in these tables. There is also a need to may primitive programming language types to primitive database column types. This is be no means easily achieved. Especially if the object-relational mapper in question supports multiple databases. Any popular object-relational mapper will support more than a single database. If it were the case that only a single database were supported by an ORM, there really wouldn't be a need for the ORM to begin with. In fact, if only a single database would need to be supported, it might be beneficial to not use an ORM because of the overhead that would be removed. This is rarely the case. Having said that, developers can generally assume that support for multiple database technologies is a given. Going back to the problem of dealing with primitive type mapping, how would an ORM accomplish this? One approach might be to implement the specific column types for each supported database. This would mean much duplicated functionality and would not be good object oriented practice. SQLAlchemy takes a different approach to handling the vary disparate column types between different database technologies.
SQLAlchemy defines two abstract type classes; AbstractType and TypeEngine. These two classes not only provide the base type interfaces used in SQLAlchemy, but also provide the default implementations for these methods. When mapping a primitive programming language type to a primitive database column type, there are two directions these types can be mapped. When supplying binding parameters to SQL queries that are initially primitive programming language types, and when retrieving query results from an executed query. In the latter case, the type mapping goes from the primitive database column type to the primitive programming language type.
The AbstractType class defines two methods to accomplish this; bind_processor() and result_processor(). Both methods accept a database dialect parameter so they know which database technology they are dealing with and the idea is to return a callable that performs the necessary transformations before using the data in a query or result set. In other words, bind_processor() returns a function to make the bind parameters used in a query actually usable. The result_processor() method uses the inverse concept. The SQLAlchemy String type is a good example of why these methods are useful. With strings, there are many questions of encoding before they can be used in a database.
One implementation note on the SQLAlchemy implementation of the AbstractType and TypeEngine classes. As illustrated below, the TypeEngine class directly inherits from AbstractType. TypeEngine unnecessarily overrides the bind_processor() and result_processor() methods. Both the signature and implementation of the two methods are the same in both classes. All that changes is the API documentation.
SQLAlchemy defines two abstract type classes; AbstractType and TypeEngine. These two classes not only provide the base type interfaces used in SQLAlchemy, but also provide the default implementations for these methods. When mapping a primitive programming language type to a primitive database column type, there are two directions these types can be mapped. When supplying binding parameters to SQL queries that are initially primitive programming language types, and when retrieving query results from an executed query. In the latter case, the type mapping goes from the primitive database column type to the primitive programming language type.
The AbstractType class defines two methods to accomplish this; bind_processor() and result_processor(). Both methods accept a database dialect parameter so they know which database technology they are dealing with and the idea is to return a callable that performs the necessary transformations before using the data in a query or result set. In other words, bind_processor() returns a function to make the bind parameters used in a query actually usable. The result_processor() method uses the inverse concept. The SQLAlchemy String type is a good example of why these methods are useful. With strings, there are many questions of encoding before they can be used in a database.
One implementation note on the SQLAlchemy implementation of the AbstractType and TypeEngine classes. As illustrated below, the TypeEngine class directly inherits from AbstractType. TypeEngine unnecessarily overrides the bind_processor() and result_processor() methods. Both the signature and implementation of the two methods are the same in both classes. All that changes is the API documentation.
Monday, February 9, 2009
Testing types with boduch
The boduch Python library provides a simple type testing utility function that allows truth tests for both primitive and user-defined data types. Python does offer built-in type testing utilities, but there is currently no unification between user-defined classes and primitive types. Here is an example of how to use the is_type() function.
As you can see, we can significantly cut down the number of lines required for type testing with a single function. Also note, is_type() can also test if the specified instance belongs in an inheritance lattice, as demonstrated in this example.
#boduch type testing example.
from boduch.type import is_type
class MyBaseType:
pass
class MyType(MyBaseType):
pass
if __name__=="__main__":
print "Testing string type."
print is_type("my string", "str")
print "Testing boolean type."
print is_type(False, "boolean")
print "Testing a class type."
print is_type(MyType(), "MyType")
print "Testing for a base class."
print is_type(MyType(), "MyBaseType")
Monday, January 5, 2009
New in boduch 0.0.4
I thought I'd mention what is going on development-wise in the boduch Python library. The upcoming 0.0.4 release has a new handler for EventSetPush events. This handler is what actually pushes data onto the set instance that produces the event. Typically, there is no point. The push() method may as well be responsible for actually pushing the data onto the set instance.
There are cases where we may want to send the data being pushed somewhere remote in addition to the set. Also, when creating reactive interfaces that "sit on top of" the library, this could potentially increase the responsiveness.
There will also be a new Hash data type. This data type is essentially a Python dictionary that will emit events. It will follow a similar interface as that provided by the Set data type.
There are cases where we may want to send the data being pushed somewhere remote in addition to the set. Also, when creating reactive interfaces that "sit on top of" the library, this could potentially increase the responsiveness.
There will also be a new Hash data type. This data type is essentially a Python dictionary that will emit events. It will follow a similar interface as that provided by the Set data type.
Subscribe to:
Posts
(
Atom
)