how old is page created by on student server

I seems that I'm with python since my graduation. 

Last-Modified:·Tue,·07·Apr·2009·16:51:38·GMT

Rex Swain's HTTP Viewer

http://www.rexswain.com/httpview.html

Parameters:

URL = http://debian.fmi.uni-sofia.bg/~hardcode/python/
UAG = Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0
REF = http://www.rexswain.com/httpview.html
AEN =
REQ = GET ; VER = 1.1 ; FMT = AUTO
Link: http://www.rexswain.com/cgi-bin/httpview.cgi?url=http:/ ... &req=GET&ver=1.1&fmt=AUTO

Sending request:

GET /~hardcode/python/ HTTP/1.1
Host: debian.fmi.uni-sofia.bg
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 62.44.108.18
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·200·OK(CR)(LF)
Date:·Mon,·19·Oct·2015·20:56:57·GMT(CR)(LF)
Server:·Apache/2.2.9·(Debian)·mod_ssl/2.2.9·OpenSSL/0.9.8g(CR)(LF)
Last-Modified:·Tue,·07·Apr·2009·16:51:38·GMT(CR)(LF)
ETag:·"10b46b6-4029-466f9d416da80"(CR)(LF)
Accept-Ranges:·bytes(CR)(LF)
Content-Length:·16425(CR)(LF)
Vary:·Accept-Encoding(CR)(LF)
Connection:·close(CR)(LF)
Content-Type:·text/html(CR)(LF)
(CR)(LF)

End of Header (Length = 310)

Да се научи нещо полезно от интернет

Но ето, че може и да се научи нещо полезно от интернет. Примерно оня ден се научих на една електронна схема, която ми беше много полезна в управлението на 12 волтови вентилатори, разбира се първо изгорих няколко транс-ре-зистора опитвайки се да разделя на 2 * 6 волта безболезнено, докато не намерих една  малка черна кутийка с номер 7039 или 7093 ..цифри питай ги, така наречена интегрална схема, но незнам каква е интегралната-верига, как са свързани елементите, колкото ток харчат, кои са, но важното е че просто работи,но не простовато а гениално просто, как не се сетих че може да е толкова елементарно до съвършенство и дели напрежението над две, за какво ми е да знам повече аз го ползвам то а ми служи. Да по дяволите и ангелите та това е интегрирана електрическа верига, магия подбрана в малка кутийка и вътре човечета просто делят напрежението на две.

Nice asynchronous multitasking with python Workersz.

Multi-Thread programming should be easy and automated to the core, leaving free developers' focus on application problem, ensuring maximum comfort with confidence to parallelism and asynchronous event handling. Other  goals followed by Workersz project are minimizing the bureaucracy and providing compatibility with existing code (currently tested with python 2.7).

In resume Workersz is python framework to deal with thread pools. Every thread pool contains a task-scheduler event loop that exhaust task in queue to free workers. It  distributes any python function as target data in Task class object. Target could be synchronized or none, depending on developer choice of architecture or style. Workers in pool will lock or not on shared resources within target. On done task event handler are  implemented in asynchronous application with error event handlers. All callbacks ( event handlers) on their side could be targeted to same or another pool or in __main__ process.

Currently status of project is working beta. Python package and docs will be released soon. Any participation  is welcome! Work is licensed under terms of Apache 2.0.

WorkerPool may used conveniently with automation provided from own decorator.  Here is the example of non-blocking socket server using it:

https://github.com/workersz/workersz/blob/master/examples/srvd_deco.py

Python function make-up for the make-up artists.

Some ideas how and for what to use function decorator part one:

the problem:

def one( *args, **kwargs ):
    if kwargs['goodone'] == 1:
        return 1
    else:
        return 0

a lot of code rely on exception handling and you must surround it with try catch...

one(123)

will raise KeyError

Do you know the tale: " Ask the lazy man to do work in and he will teach you! " или на български: Накарай мързеливия да работи за да те научи на акъл!

And here decoration or wrap will save us a lot of try-except-try-excpet spaghetti code:

# our reusable error handling function:

def error_handle( args,kwargs,e ):
    print "handling error: ",repr(e)

# the make-up artist: try except python decorator

def try_wrap( func, exception_class, exception_handle ):
    def wrap(*args, **kwargs):
        try:
            return func( *args, **kwargs )
        except exception_class, e:
            return exception_handle(args, kwargs, e )
    return wrap

# apply the make up:
one = try_wrap(one, KeyError, error_handle)

one(123)

Universal function interface in Python language for reusable and compatible code.

When I started to hack in Python after Java thinking there were a need for defining  data and /or function interface to pass over other functions, defining API, etc. I was missing that design time frame-working in source coded interfaces and/or inheritances was needing re-factoring each time when interface changed. And big thinking was... wtf is the best interface for my API. But it has always being there ... just in front me but it was kept hidden for a while until this obvious axiom came into my mind:

Every Python function object has None arguments, arguments tuple(), keyword arguments dict() or both args and kwargs.  

The obvious answer to which is the universal function interface: ( *args,  **kwargs ) is python native protocol to handle any kind of arguments, if you do type - kind understanding of what comes around. ( it should be OK to do that in your specific implementation). Also one great feature from Python as platform are that things there are dictionary items, and this make it's use extremely flexible and productive.

Other obvious  standard interface: the dict: __setitem__(self, key, value),  __getitem__(self, key) , __delitem__(self, key) ,  or d[ 'key' ] = 'value', d['key'], del d['key'] , here language itself define a slight setter and getter interface for key value storage ( associative array, map ) There are also list() interface defining behavior for stack, queue, linked-list, and many-many of modules defining any different kind of different interfaces and flavors to dictionaries and lists, that are unable to bound to standard predefined interfaces.

For that reason my conclusion is that if I want python code to be implementation independent as reusable plugin module, I should use ( <self>, *args, **kwargs ) as universal and native pythonic interface even in well defined standard interface as dict. Also ( <self>,*args ) if  I want to translate easily generic Python prototype code into C implementation for achieving high performance component.