songroger

docx cracked experience

Mon, 07 Sep 2020 20:20:39 +0000

1.Hash file

Use john¹ to get the hash file.

python john.py 2020.docx >hash.txt

2.Hashcat² to crack the password

Example commands for hashcat:

hashcat -a 3 -m 9400 --username -o cracked_pass.txt 111.txt song?d?d?d --force --self-test-disable

hashcat -a 0 -m 9400 rockyou.txt 111.txt --username -o cracked_pass.txt --force --self-test-disable

hashcat -a 3 -m 9600 hash.txt test.hcmask --username -o cracked_pass.txt --force --self-test-disable

john ↩
hashcat ↩

自动编曲软件可以做到什么程度了

Mon, 06 Apr 2020 09:20:39 +0000

最近把我的老伙计(ipad)修好了，亲切而又陌生之余，发现里面有款宝藏APP-「music-memos」.

表面看这是一个录音软件，其实它应该是轻量级的自动配伴奏APP，每个录音文件下面有个吉他和架子鼓的logo，点一下，神奇的事情就发生了。

所以，看我ipad里面的录音文件记录，我应该是16年开始就在玩自动编曲软件了，可是我像失忆了似的，完全不记得录了那么多…囧.

于是像发现了新大陆似的，找了一圈相关的软件，全部装上研究了一遍，最后完成了《少年》这首成品。没错，这首抖音爆款 BGM 就是我的第一首用了整个标配乐队阵容（鼓、贝斯、吉他、键盘）的作品了。（—笑—）

里面的和弦编排全部是由软件根据录入的钢琴旋律自动排出来的，确定调号和节拍速度即可。

附一张工作界面图：

去年在二叉树上看到彩虹合唱团万源说的那句“音乐是理性的艺术”，我深以为然。

自动编曲软件的原理其实很简单，识别音乐文件的频率对应上固定音名，然后根据和弦编排乐理，根据一些算法生成一系列和弦编排。如果做得更智能的话，可以结合AI训练一些常用和弦走向，应该可以拿下市面上大部分流行歌曲的「完美」编配了。或者再结合训练一些古典经典作品，那就更高级了吧。

最后再秉承本人一贯「科学严谨」求索的态度回答一下标题疑问吧。

对于乐理知识有一定修为的，自动编曲软件可以帮你构思整首曲子和弦架构的大部分工作，至少能给你一个相对完整的参考。对于不太了解乐理的人来说，自动编曲软件可以帮你把自己的录音自动合成一个带有伴奏版本的成品曲子。

来，我们一起唱爆款神曲~ 
愿你出走半生，归来仍是少年

我还是从前那个少年
没有一丝丝改变
时间只不过是考验
种在心中信念丝毫未减
...

别「惹」学霸

Sat, 04 Apr 2020 13:50:39 +0000

前段时间因帮忙了一位朋友，一直说要请我吃饭。今日刚好得闲，下午临时发了信息给她。她爽快地答应跑过来，生怕耽误还我一顿饭似的。

可是在等她过来的时间中，我查了半天附近饭馆，突然什么胃口都没有。我心想这下可不好，于是灵机一动，跟她说我想喝「鲫鱼汤」¹，这附近可能暂时不好找，要不我们去瑞幸找点喝的算了，算是蹭个最近的热点吧²。

她迟疑了一下，可能觉得对不起她跑过来这趟，竟然说“就请你喝鲫鱼汤，我自己做”。这倒出乎我意料，可是更让我没想到的是，她补充说以前从没做过，我可能是第一个吃她煮的鱼的人…

我开始有点担心，可是又没法不识好歹地自己再作回去…

我们径直去了菜市场买食材，一路上她都在拿着手机各种百度。看她迷糊的样子，我才完全相信，眼前这位大小姐真的从来没有煮过鱼，可能其他菜也没做过！在追问中得知，她从小到大下厨的经验可能仅限于「泡面」。我已经完全没了期待，告诉自己好好享受别人做饭的乐趣吧，饭后不是可以给没胃口的自己一个很好的「理由」了不是？

直到这位同学，从我锅里倒出题图这一碗「茼蒿豆腐鲫鱼汤」，我有点惊了³。

奶白色的汤，真是神奇的存在，相机拍不出半分它的鲜、甜来。

我只想说，别惹学霸，那种学什么都可以称霸的孩子！

随便想的一个饭馆不好找的菜罢了。 ↩
瑞幸自查报告公布销售额造假22亿，股价暴跌门店爆单。 ↩
你能想象，没胃口的我最后喝了半锅汤，下了三大碗米饭？！ ↩

奇技淫巧系列

Tue, 24 Mar 2020 14:09:39 +0000

前言：

这篇主要记录本人碰到的一些奇怪的软硬件问题以及解决方式。可能不是所有人通用的，但是肯定是我自己验证过并且获得解决的才会记录在此。

1. 电脑自动输入反斜杠。

现象：电脑一开机就任何输入框都自动输入反斜杠。非键盘坏。
最终确认： .NET Framework的问题
解决：禁用.NET Framework服务

Understand Flask (一)

Sat, 10 Aug 2019 09:15:39 +0000

Previous answers already give a nice overview of what goes on in the background of Flask during a request. If you haven't read it yet I recommend @MarkHildreth's answer prior to reading this. In short, a new context (thread) is created for each http request, which is why it's necessary to have a thread Local facility that allows objects such as request and g to be accessible globally across threads, while maintaining their request specific context. Furthermore, while processing an http request Flask can emulate additional requests from within, hence the necessity to store their respective context on a stack. Also, Flask allows multiple wsgi applications to run along each other within a single process, and more than one can be called to action during a request (each request creates a new application context), hence the need for a context stack for applications. That's a summary of what was covered in previous answers.

My goal now is to complement our current understanding by explaining how Flask and Werkzeug do what they do with these context locals. I simplified the code to enhance the understanding of its logic, but if you get this, you should be able to easily grasp most of what's in the actual source (werkzeug.local and flask.globals).

Let's first understand how Werkzeug implements thread Locals.

Local

When an http request comes in, it is processed within the context of a single thread. As an alternative mean to spawn a new context during an http request, Werkzeug also allows the use of greenlets (a sort of lighter "micro-threads") instead of normal threads. If you don't have greenlets installed it will revert to using threads instead. Each of these threads (or greenlets) are identifiable by a unique id, which you can retrieve with the module's get_ident() function. That function is the starting point to the magic behind having request, current_app,url_for, g, and other such context-bound global objects.

try:
    from greenlet import get_ident
except ImportError:
    from thread import get_ident

Now that we have our identity function we can know which thread we're on at any given time and we can create what's called a thread Local, a contextual object that can be accessed globally, but when you access its attributes they resolve to their value for that specific thread. e.g.

# globally
local = Local()

# ...

# on thread 1
local.first_name = 'John'

# ...

# on thread 2
local.first_name = 'Debbie'

Both values are present on the globally accessible Local object at the same time, but accessing local.first_name within the context of thread 1 will give you 'John', whereas it will return 'Debbie' on thread 2.

How is that possible? Let's look at some (simplified) code:

class Local(object)
    def __init__(self):
        self.storage = {}

    def __getattr__(self, name):
        context_id = get_ident() # we get the current thread's or greenlet's id
        contextual_storage = self.storage.setdefault(context_id, {})
        try:
            return contextual_storage[name]
        except KeyError:
            raise AttributeError(name)

    def __setattr__(self, name, value):
        context_id = get_ident()
        contextual_storage = self.storage.setdefault(context_id, {})
        contextual_storage[name] = value

    def __release_local__(self):
        context_id = get_ident()
        self.storage.pop(context_id, None)

local = Local()

From the code above we can see that the magic boils down to get_ident() which identifies the current greenlet or thread. The Local storage then just uses that as a key to store any data contextual to the current thread.

You can have multiple Local objects per process and request, g, current_app and others could simply have been created like that. But that's not how it's done in Flask in which these are not technically Local objects, but more accurately LocalProxy objects. What's a LocalProxy?

LocalProxy

A LocalProxy is an object that queries a Local to find another object of interest (i.e. the object it proxies to). Let's take a look to understand:

class LocalProxy(object):
    def __init__(self, local, name):
        # `local` here is either an actual `Local` object, that can be used
        # to find the object of interest, here identified by `name`, or it's
        # a callable that can resolve to that proxied object
        self.local = local
        # `name` is an identifier that will be passed to the local to find the
        # object of interest.
        self.name = name

    def _get_current_object(self):
        # if `self.local` is truly a `Local` it means that it implements
        # the `__release_local__()` method which, as its name implies, is
        # normally used to release the local. We simply look for it here
        # to identify which is actually a Local and which is rather just
        # a callable:
        if hasattr(self.local, '__release_local__'):
            try:
                return getattr(self.local, self.name)
            except AttributeError:
                raise RuntimeError('no object bound to %s' % self.name)

        # if self.local is not actually a Local it must be a callable that 
        # would resolve to the object of interest.
        return self.local(self.name)

    # Now for the LocalProxy to perform its intended duties i.e. proxying 
    # to an underlying object located somewhere in a Local, we turn all magic
    # methods into proxies for the same methods in the object of interest.
    @property
    def __dict__(self):
        try:
            return self._get_current_object().__dict__
        except RuntimeError:
            raise AttributeError('__dict__')

    def __repr__(self):
        try:
            return repr(self._get_current_object())
        except RuntimeError:
            return '<%s unbound>' % self.__class__.__name__

    def __bool__(self):
        try:
            return bool(self._get_current_object())
        except RuntimeError:
            return False

    # ... etc etc ... 

    def __getattr__(self, name):
        if name == '__members__':
            return dir(self._get_current_object())
        return getattr(self._get_current_object(), name)

    def __setitem__(self, key, value):
        self._get_current_object()[key] = value

    def __delitem__(self, key):
        del self._get_current_object()[key]

    # ... and so on ...

    __setattr__ = lambda x, n, v: setattr(x._get_current_object(), n, v)
    __delattr__ = lambda x, n: delattr(x._get_current_object(), n)
    __str__ = lambda x: str(x._get_current_object())
    __lt__ = lambda x, o: x._get_current_object() < o
    __le__ = lambda x, o: x._get_current_object() <= o
    __eq__ = lambda x, o: x._get_current_object() == o

    # ... and so forth ...

Now to create globally accessible proxies you would do

# this would happen some time near application start-up
local = Local()
request = LocalProxy(local, 'request')
g = LocalProxy(local, 'g')

and now some time early over the course of a request you would store some objects inside the local that the previously created proxies can access, no matter which thread we're on

# this would happen early during processing of an http request
local.request = RequestContext(http_environment)
local.g = SomeGeneralPurposeContainer()

The advantage of using LocalProxy as globally accessible objects rather than making them Locals themselves is that it simplifies their management. You only just need a single Local object to create many globally accessible proxies. At the end of the request, during cleanup, you simply release the one Local (i.e. you pop the context_id from its storage) and don't bother with the proxies, they're still globally accessible and still defer to the one Local to find their object of interest for subsequent http requests.

# this would happen some time near the end of request processing
release(local) # aka local.__release_local__()

To simplify the creation of a LocalProxy when we already have a Local, Werkzeug implements the Local.__call__() magic method as follows:

class Local(object):
    # ... 
    # ... all same stuff as before go here ...
    # ... 

    def __call__(self, name):
        return LocalProxy(self, name)

# now you can do
local = Local()
request = local('request')
g = local('g')

However, if you look in the Flask source (flask.globals) that's still not how request, g, current_app and session are created. As we've established, Flask can spawn multiple "fake" requests (from a single true http request) and in the process also push multiple application contexts. This isn't a common use-case, but it's a capability of the framework. Since these "concurrent" requests and apps are still limited to run with only one having the "focus" at any time, it makes sense to use a stack for their respective context. Whenever a new request is spawned or one of the applications is called, they push their context at the top of their respective stack. Flask uses LocalStack objects for this purpose. When they conclude their business they pop the context out of the stack.

LocalStack

This is what a LocalStack looks like (again the code is simplified to facilitate understanding of its logic).

class LocalStack(object):

    def __init__(self):
        self.local = Local()

    def push(self, obj):
        """Pushes a new item to the stack"""
        rv = getattr(self.local, 'stack', None)
        if rv is None:
            self.local.stack = rv = []
        rv.append(obj)
        return rv

    def pop(self):
        """Removes the topmost item from the stack, will return the
        old value or `None` if the stack was already empty.
        """
        stack = getattr(self.local, 'stack', None)
        if stack is None:
            return None
        elif len(stack) == 1:
            release_local(self.local) # this simply releases the local
            return stack[-1]
        else:
            return stack.pop()

    @property
    def top(self):
        """The topmost item on the stack.  If the stack is empty,
        `None` is returned.
        """
        try:
            return self.local.stack[-1]
        except (AttributeError, IndexError):
            return None

Note from the above that a LocalStack is a stack stored in a local, not a bunch of locals stored on a stack. This implies that although the stack is globally accessible it's a different stack in each thread.

Flask doesn't have its request, current_app, g, and session objects resolving directly to a LocalStack, it rather uses LocalProxy objects that wrap a lookup function (instead of a Local object) that will find the underlying object from the LocalStack:

_request_ctx_stack = LocalStack()
def _find_request():
    top = _request_ctx_stack.top
    if top is None:
        raise RuntimeError('working outside of request context')
    return top.request
request = LocalProxy(_find_request)

def _find_session():
    top = _request_ctx_stack.top
    if top is None:
        raise RuntimeError('working outside of request context')
    return top.session
session = LocalProxy(_find_session)

_app_ctx_stack = LocalStack()
def _find_g():
    top = _app_ctx_stack.top
    if top is None:
        raise RuntimeError('working outside of application context')
    return top.g
g = LocalProxy(_find_g)

def _find_app():
    top = _app_ctx_stack.top
    if top is None:
        raise RuntimeError('working outside of application context')
    return top.app
current_app = LocalProxy(_find_app)

All these are declared at application start-up, but do not actually resolve to anything until a request context or application context is pushed to their respective stack.

If you're curious to see how a context is actually inserted in the stack (and subsequently popped out), look in flask.app.Flask.wsgi_app() which is the point of entry of the wsgi app (i.e. what the web server calls and pass the http environment to when a request comes in), and follow the creation of the RequestContext object all through its subsequent push() into _request_ctx_stack. Once pushed at the top of the stack, it's accessible via _request_ctx_stack.top. Here's some abbreviated code to demonstrate the flow:

So you start an app and make it available to the WSGI server...

app = Flask(*config, **kwconfig)

# ...

Later an http request comes in and the WSGI server calls the app with the usual params...

app(environ, start_response) # aka app.__call__(environ, start_response)

This is roughly what happens in the app...

def Flask(object):

    # ...

    def __call__(self, environ, start_response):
        return self.wsgi_app(environ, start_response)

    def wsgi_app(self, environ, start_response):
        ctx = RequestContext(self, environ)
        ctx.push()
        try:
            # process the request here
            # raise error if any
            # return Response
        finally:
            ctx.pop()

    # ...

and this is roughly what happens with RequestContext...

class RequestContext(object):

    def __init__(self, app, environ, request=None):
        self.app = app
        if request is None:
            request = app.request_class(environ)
        self.request = request
        self.url_adapter = app.create_url_adapter(self.request)
        self.session = self.app.open_session(self.request)
        if self.session is None:
            self.session = self.app.make_null_session()
        self.flashes = None

    def push(self):
        _request_ctx_stack.push(self)

    def pop(self):
        _request_ctx_stack.pop()

Say a request has finished initializing, the lookup for request.path from one of your view functions would therefore go as follow:

start from the globally accessible LocalProxy object request.
to find its underlying object of interest (the object it's proxying to) it calls its lookup function _find_request() (the function it registered as its self.local).
that function queries the LocalStack object _request_ctx_stack for the top context on the stack.
to find the top context, the LocalStack object first queries its inner Local attribute (self.local) for the stack property that was previously stored there.
from the stack it gets the top context
and top.request is thus resolved as the underlying object of interest.
from that object we get the path attribute

So we've seen how Local, LocalProxy, and LocalStack work, now think for a moment of the implications and nuances in retrieving the path from:

a request object that would be a simple globally accessible object.
a request object that would be a local.
a request object stored as an attribute of a local.
a request object that is a proxy to an object stored in a local.
a request object stored on a stack, that is in turn stored in a local.
a request object that is a proxy to an object on a stack stored in a local. <- this is what Flask does.

一点笔记

Tue, 26 Mar 2019 21:10:14 +0000

又一年了。
一直想写2018，但是每有提笔的冲动都又放下了。
没有太多的波澜，但也并不宁静。
在这个本该奋斗的年纪，总觉得缺一番惊天动地。
特别是前段时间看到云舒与妻子离婚，放下家庭全力投入创业的举措，再次激起本就迷茫的自己去思考人生的意义。

亲情、友情、爱情。

相对不变的一直是亲情，只希望家人健康，生活平凡而喜乐。
而友情和爱情，在我心中同样重要的两部分，从没让我省心过。
甚至都在强行怪自己打字的时候，为什么不在中文和英文之间加空格呢？！¹

年前，在相识十多年的好基友家玩了几天。两个男人，每每聊到凌晨，提及这些年来发生的事情，不亚于《人在囧途》的各种百态。
总的来说，
失去了一些人，也得到了新伙伴。
以为会没那么快失散的，却也提前消失在了人海。

更早的三年，和计划结婚的女友分手，最后一次旅行定格在澳门威尼斯人，我们还在一起牵手憧憬未来，可笑的是几个月后因为家里的原因分手了。我很长的一段时间内一直非常非常努力的工作，再也不想触及爱情。
好在时间真是个好东西，心受伤了也只是恢复得慢一点。
直到我渐渐想通一些事情，开始走出来这份悲观了。「现在倒在想，又想要贴心的基友，又想要甜甜的女票，是不是太贪心了点？！」

深交过的人，都说我很文艺。但我倒不觉得，我只是享受我没经历过的一切，喜欢折腾艺文的东西，也刚好可能略有天赋。人生总归要回归柴米油盐的生活的，这些精神食粮只是会冲淡我的一些物质欲，这样挺好。

在和好哥们的夜聊中说到，最不能接受他们（某些大学同学）的就是甘于平庸。他们的生活似乎接受了被父母操控着，被安排进国局、去接替、只选公职，总之即使拿着再多的灰色收入，也只每天搪瓷缸子人民日报的日子。
而我们，靠自己去奋斗，反而是真正的在“享受”生活了。用他的话说，我们这是回到平凡，而不是始终平庸。当然，个中心酸，也只容我们这么愤青了。

也奢望2018这一年的遗憾都可以成为2019惊喜的铺垫。

“在路上”的感觉也许应该就是这样的吧～

最后推一下最近在看的毛姆的小说《月亮与六便士》。
选择月亮还是六便士？
哪一种值得敬畏，哪一种该被怜悯？
这是一个问题。它没有正确答案。

毛姆在书中说：
“做自己最想做的事，过自己想过的生活，求得内心安宁，怎么能叫作贱自己？做一个有名的外科医生，一年赚一万英镑，娶一位漂亮的妻子，就是成功？我想，这取决于你如何看待生活的意义。”

有研究显示，打字的时候不喜欢在中文和英文之间加空格的人，感情路都走得很辛苦. ↩

python 单例模式

Tue, 12 Feb 2019 12:25:10 +0000

单例模式（Singleton Pattern）是一种常用的软件设计模式，该模式的主要目的是确保某一个类只有一个实例存在。当你希望在整个系统中，某个类只能出现一个实例时，单例对象就能派上用场。

比如，某个服务器程序的配置信息存放在一个文件中，客户端通过一个 AppConfig 的类来读取配置文件的信息。如果在程序运行期间，有很多地方都需要使用配置文件的内容，也就是说，很多地方都需要创建 AppConfig 对象的实例，这就导致系统中存在多个 AppConfig 的实例对象，而这样会严重浪费内存资源，尤其是在配置文件内容很多的情况下。事实上，类似 AppConfig 这样的类，我们希望在程序运行期间只存在一个实例对象。

在 Python 中，我们可以用多种方法来实现单例模式：

使用模块
使用 new
使用装饰器（decorator）
使用元类（metaclass）

使用 new :

class Singleton(object):
    _instance = None

    def __init__(self, a, *args, **kw):
        self.a = a
        print(self.a)

    def __new__(cls, a, *args, **kw):
        # NOTICE: __init__方法中除了self之外定义的参数，都将与__new__方法中除cls参数之外的参数是必须保持一致或者等效
        if not cls._instance:
            cls._instance = super(Singleton, cls).__new__(cls, *args, **kw)
        return cls._instance


class NonSingleton(object):
    def __init__(self, a, *args, **kw):
        self.a = a
        print(self.a)


class MySingleClass(Singleton):
    a = 1


class MyNonSingleClass(NonSingleton):
    a = 1


a1 = MySingleClass(1)
print(a1.a)
a2 = MySingleClass(2)
print(a1.a)
print(a2.a)

print(a1 is a2)  # --> True

a3 = MyNonSingleClass(3)
print(a3.a)
a4 = MyNonSingleClass(4)
print(a3.a)
print(a4.a)

print(a3 is a4)  # --> False

python super()

Sun, 10 Feb 2019 08:05:10 +0000

super() 函数是用于调用父类(超类)的一个方法。 super 是用来解决多重继承问题的，直接用类名调用父类方法在使用单继承的时候没问题，但是如果使用多继承，会涉及到查找顺序（MRO）、重复调用（钻石继承）等种种问题。 super 的一大好处在于，当父类的名字修改时，其继承类不用修改调用方法。每次调用super()则是，调用MRO中下一个函数。 MRO(Method Resolution Order) 就是类的方法解析顺序表, 其实也就是继承父类方法时的顺序表。

super(type[, object-or-type])

type – 类。 object-or-type – 类，一般是 self

注意： super(type, obj).func()函数调用的是，obj实例在MRO中下一个父类的可调用func()，而不是type的父类中的func()

Python 线程池 fragment

Wed, 16 Jan 2019 11:05:39 +0000

import sys
from queue import Queue
from threading import Thread


class Worker(Thread):
    """ Thread executing tasks from a given tasks queue """
    def __init__(self, tasks):
        Thread.__init__(self)
        self.tasks = tasks
        self.daemon = True
        self.start()

    def run(self):
        while True:
            func, args, kargs = self.tasks.get()
            try:
                func(*args, **kargs)
            except Exception as e:
                # An exception happened in this thread
                print(e)
            finally:
                # Mark this task as done, whether an exception happened or not
                self.tasks.task_done()


class ThreadPool:
    """ Pool of threads consuming tasks from a queue """
    def __init__(self, num_threads):
        self.tasks = Queue(num_threads)
        for _ in range(num_threads):
            Worker(self.tasks)

    def add_task(self, func, *args, **kargs):
        """ Add a task to the queue """
        self.tasks.put((func, args, kargs))

    def map(self, func, args_list):
        """ Add a list of tasks to the queue """
        for args in args_list:
            self.add_task(func, args)

    def wait_completion(self):
        """ Wait for completion of all the tasks in the queue """
        self.tasks.join()


if __name__ == "__main__":
    from random import randrange
    from time import sleep

    # Function to be executed in a thread
    def wait_delay(d):
        print("sleeping for (%d)sec" % d)
        sleep(d)

    # Generate random delays
    delays = [randrange(3, 7) for i in range(50)]

    # Instantiate a thread pool with 5 worker threads
    pool = ThreadPool(5)

    # Add the jobs in bulk to the thread pool. Alternatively you could use
    # `pool.add_task` to add single jobs. The code will block here, which
    # makes it possible to cancel the thread pool with an exception when
    # the currently running batch of workers is finished.
    pool.map(wait_delay, delays)
    pool.wait_completion()

小鸭子的故事

Mon, 12 Nov 2018 08:02:10 +0000

1. Python: Strongly-typed? Dynamic?

Dynamic？
- 静态类型：编译时就知道每个变量的类型，因为类型错误而不能做的事情是语法错误。
- 动态类型：编译时不知道每个变量的类型，因为类型错误而不能做的事情是运行时错误。
```
 优点：
  更适合开发小的项目，无需声明类型;
  Duck typing 解除了很多束缚;
 缺点：
  慢：编译器对于没有typing的变量，需要一个个check具体type
```
Strongly-typed？
- 强类型语言：偏向于不容忍隐式类型转换。
- 弱类型语言：偏向于容忍隐式类型转换。
Python 是动态强类型语言。

Python uses dynamic typing, which allows you to change the type of a variable, by replacing an integer with a string, for example.

2. Duck typing

【“当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。”】

鸭子类型是动态类型的一种风格。在这种风格中，一个对象有效的语义，不是由继承自特定的类或实现特定的接口，而是由”当前方法和属性的集合”决定。没有了接口类型的继承约束。鸭子类型可以在不使用继承的情况下使用多态。(其实就是因为变量没有显式的类型)

利用鸭子类型的思想，我们不必借助超类型的帮助，就能轻松地在动态类型语言中实现一个原则：“面向接口编程，而不是面向实现编程”。例如，一个对象若有push和pop方法，并且这些方法提供了正确的实现，它就可以被当作栈来使用。一个对象如果有length属性，也可以依照下标来存取属性（最好还要拥有slice和splice等方法），这个对象就可以被当作数组来使用。

在静态类型语言中，要实现“面向接口编程”并不是一件容易的事情，往往要通过抽象类或者接口等将对象进行向上转型。当对象的真正类型被隐藏在它的超类型身后，这些对象才能在类型检查系统的“监视”之下互相被替换使用。只有当对象能够被互相替换使用，才能体现出对象多态性的价值。

class Duck:
    def fly(self):
        print("Duck flying")


class Airplane:
    def fly(self):
        print("Airplane flying")


class Whale:
    def swim(self):
        print("Whale swimming")


for animal in Duck(), Airplane(), Whale():
    animal.fly()

output:
Duck flying
Airplane flying
AttributeError: 'Whale' object has no attribute 'fly'

C++、Java 虽然不是动态语言, 但是它们也能支持 Duck Typing，它们是通过模板来支持的。 go 同样可以实现，并且相对比较灵活，又不失类型检查。