[MySQL]查看用户权限与GRANT用法

本网站用的阿里云ECS,推荐大家用。自己搞个学习研究也不错

先提示,本文需要一定的python源码基础。许多内容请参考《python源码剖析》。下面切入正题。

 

今天在群里有人问了一个问题。形如如下的一段程序。

 

Python代码

  1.      
  2. class person:  
  3.     sum = 0  
  4.     def __init__(self,name):  
  5.         self.name=name  
  6.         person.sum += 1  
  7.   
  8.     def __del__(self):  
  9.         person.sum -= 1  
  10.         print “%s is leaving” % self.name  
  11.   
  12. a = person(‘a’)  
  13. a2 = person(‘a2’)  

class person: sum = 0 def __init__(self,name): self.name=name person.sum += 1 def __del__(self): person.sum -= 1 print “%s is leaving” % self.name a = person(‘a’) a2 = person(‘a2’)

 

这段程序的预期的执行结果应该是”a is leaving”和”a2 is leaving”。但是实际上却出乎意料之外,实际的执行结果如下:

 

Python代码

  1. a is leaving  
  2. Exception exceptions.AttributeError: “‘NoneType’ object has no attribute ‘sum'” in   
  3. > ignored  

a is leaving Exception exceptions.AttributeError: “‘NoneType’ object has no attribute ‘sum'” in > ignored

为什么引用的名字不同造成的结果会有这么大的差别呢?

 

分析表面的原因,是person这个引用被指向了None。那他是不是真的是None呢?

 

Python代码

  1. def __del__(self):  
  2.     print globals()[‘person’] #1  
  3.     person.sum -= 1  
  4.     #print “%s is leaving” % self.name  

def __del__(self): print globals()[‘person’] #1 person.sum -= 1 #print “%s is leaving” % self.name

 

加入红色这行代码,看看是不是真的变成了None。运行结果如下:

 

Java代码

  1. __main__.person  
  2. None  
  3. Exception exceptions.AttributeError: “‘NoneType’ object has no attribute ‘sum'”  
  4.  in > ignored  

__main__.person None Exception exceptions.AttributeError: “‘NoneType’ object has no attribute ‘sum'” in > ignored

看来是真的变成了None了。

 

初步分析原因,应该是程序在执行结束以后,python虚拟机清理环境的时候将”person”这个符号先于”a2″清理了,所以导致在a2的析构函数中无法找到”person”这个符号了。

 

但是转念一想还是不对,如果是”person”符号找不到了,应该是提示“name ‘person’ is not defined”才对。说明”person”这个符号还在,那”person”指向的class_object对象还在吗?改变程序为以下格式:

 

Python代码

  1. class person:  
  2.     sum = 0  
  3.     def __init__(self,name):  
  4.         self.name=name  
  5.         person.sum += 1  
  6.   
  7.     def __del__(self):  
  8.         #person.sum -= 1  
  9.         self.__class__.sum -= 1 #1  
  10.         #print “%s is leaving” % self.name  
  11.   
  12. a = person(‘a’)  
  13. a2 = person(‘a2’)  

class person: sum = 0 def __init__(self,name): self.name=name person.sum += 1 def __del__(self): #person.sum -= 1 self.__class__.sum -= 1 #1 #print “%s is leaving” % self.name a = person(‘a’) a2 = person(‘a2’)

红色代码就是修改部分,利用自身的__class__来操作。运行结果一切正常。

 

说明python虚拟机在回收的过程中,只是将”person”这个符号设置成None了。这个结论同时带来2个问题:第一,为什么会设置成None?第二:为什么”person”会先于”a2″而晚于”a”被回收?

 

先来分析第二个问题。第一反应是不是按照字母的顺序来回收?但是马上这个结论被推翻。”a”和”a2″都在”person”的前面。那么难道是根据globals()这个字典的key顺序来回收?执行一下globals().keys()方法,得到以下结果:

 

Python代码

  1. [‘a’, ‘__builtins__’, ‘__file__’, ‘person’, ‘a2’, ‘__name__’, ‘__doc__’]   

[‘a’, ‘__builtins__’, ‘__file__’, ‘person’, ‘a2’, ‘__name__’, ‘__doc__’] 

 

看来的确是这样。

 

但是为什么是这样?要得出这个结论,看来只有去python源码中找答案了。

 

大家都知道,python代码在运行的时候,会存在一个frameobject对象来表示运行时的环境。类似于c语言的栈帧,也有点像lisp的函数的生存空间,看起来答案要从frameobject.c这个文件中去找了。

 

在frameobject.c中发现了一个函数:static void frame_dealloc(PyFrameObject *f)。看来解决问题的关键就在眼前。

 

在frame_dealloc里面截取了以下一段代码:

 

Python代码

  1. Py_XDECREF(f->f_back);  
  2. Py_DECREF(f->f_builtins);  
  3. Py_DECREF(f->f_globals);  
  4. Py_CLEAR(f->f_locals);  
  5. Py_CLEAR(f->f_trace);  
  6. Py_CLEAR(f->f_exc_type);  
  7. Py_CLEAR(f->f_exc_value);  
  8. Py_CLEAR(f->f_exc_traceback);  

Py_XDECREF(f->f_back); Py_DECREF(f->f_builtins); Py_DECREF(f->f_globals); Py_CLEAR(f->f_locals); Py_CLEAR(f->f_trace); Py_CLEAR(f->f_exc_type); Py_CLEAR(f->f_exc_value); Py_CLEAR(f->f_exc_traceback);

原来减少了引用啊。。关于Py_DECREF这个宏,python源码里面的解释是这样的:

 

The macros Py_INCREF(op) and Py_DECREF(op) are used to increment or decrement
reference counts. Py_DECREF calls the object’s deallocator function when
the refcount falls to 0;

 

这么说来,我们就要去找f_globals的析构函数了。f_globals是个什么呢?当然是PyDictObject了。证据么遍地都是啊,比 如随手找了一个,在PyFrameObject * PyFrame_New(PyThreadState *tstate, PyCodeObject *code, PyObject *globals,PyObject *locals)这个函数里面有一段代码:

 

Python代码

  1. #ifdef Py_DEBUG  
  2.     if (code == NULL || globals == NULL || !PyDict_Check(globals) ||  
  3.         (locals != NULL && !PyMapping_Check(locals))) {  
  4.         PyErr_BadInternalCall();  
  5.         return NULL;  
  6.     }  
  7. #endif  

#ifdef Py_DEBUG if (code == NULL || globals == NULL || !PyDict_Check(globals) || (locals != NULL && !PyMapping_Check(locals))) { PyErr_BadInternalCall(); return NULL; } #endif

PyDict_Check。。。检查是否是Dict对象。好吧,此处略过,直接奔向dictobject.c看看里面的代码。

 

C代码

  1. static void  
  2. dict_dealloc(register dictobject *mp)  
  3. {  
  4.     register dictentry *ep;  
  5.     Py_ssize_t fill = mp->ma_fill;  
  6.     PyObject_GC_UnTrack(mp);  
  7.     Py_TRASHCAN_SAFE_BEGIN(mp)  
  8.     for (ep = mp->ma_table; fill > 0; ep++) {  
  9.         if (ep->me_key) {  
  10.             –fill;  
  11.             Py_DECREF(ep->me_key);  #  
  12.             Py_XDECREF(ep->me_value); #仅仅只是引用计数减一  
  13.         }  
  14.     }  
  15. 以下略  

static void dict_dealloc(register dictobject *mp) { register dictentry *ep; Py_ssize_t fill = mp->ma_fill; PyObject_GC_UnTrack(mp); Py_TRASHCAN_SAFE_BEGIN(mp) for (ep = mp->ma_table; fill > 0; ep++) { if (ep->me_key) { –fill; Py_DECREF(ep->me_key); # Py_XDECREF(ep->me_value); #仅仅只是引用计数减一 } } 以下略

哈哈哈。还真是按照key的顺序来一个一个清除的。

 

不过,怎么又回到了Py_DECREF啊?

 

看来最终解释这个问题要回到GC上面了。

 

其实从这个地方也可以看出第一个问题的答案了,为什么是None?

 

从上面代码可以看出,dictobject对象在析构的时候,仅仅只是将value的引用计数减一,至于这个对象什么时候被真正回收,其实是由GC决定而不确定的。也就是说为什么是None,是因为减一了以后,凑巧GC到了而已。

 

根据Python本身的文档。

 

Python 写道Warning: Due to the precarious circumstances under which __del__() methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to sys.stderr instead. Also, when __del__() is invoked in response to a module being deleted (e.g., when execution of the program is done), other globals referenced by the __del__() method may already have been deleted. For this reason, __del__() methods should do the absolute minimum needed to maintain external invariants. Starting with version 1.5, Python guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other references to such globals exist, this may help in assuring that imported modules are still available at the time when the __del__() method is called.

Python不能保证__del__被调用的时候所有的引用都有,所以,尽量不要overried类的__del__方法。

 

到此结束。

未经允许不得转载:演道网 » [MySQL]查看用户权限与GRANT用法

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册