[issue5082] Let frameworks to register attributes as builtins
New submission from Andrea Corbellini : Most of the Python frameworks have some functions and classes that are widely used. For example a 'log.debug' function will be used in almost all modules. It is inconvenient to write 'import log' every time. It would be useful to have a special place (a dict or a special module) where you can declare attributes that can be used everywhere without importing anything. Currently, the only way to do this is: >>> import __builtin__ >>> __builtin__.debug = log.debug However, I think that this shouldn't be the better solution. Using something like '__framework__' would be really better, in my opinion. -- components: Interpreter Core messages: 80656 nosy: andrea-bs severity: normal status: open title: Let frameworks to register attributes as builtins ___ Python tracker <http://bugs.python.org/issue5082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5082] Let frameworks to register attributes as builtins
Changes by Andrea Corbellini : -- type: -> feature request ___ Python tracker <http://bugs.python.org/issue5082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5082] Let frameworks to register attributes as builtins
Andrea Corbellini added the comment: Well, writing every time 'from X import Y' looks to me uncomfortable. But of course what I'm asking is not essential :-) ___ Python tracker <http://bugs.python.org/issue5082> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18807] Allow venv to create copies, even when symlinks are supported
New submission from Andrea Corbellini: I'd really appreciate if `venv` could create environments without symlinks. Working on many Python projects, each one with different requirements, I prefer to keep everything I need in a single virtualenv directory, rather than two (one for the virtualenv and one for the built Python). So I'd like to have a --copies option that lets me force venv not to create symlinks. I can work on a patch if this issue is accepted. -- components: Library (Lib) messages: 195883 nosy: candrea priority: normal severity: normal status: open title: Allow venv to create copies, even when symlinks are supported versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue18807> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined
Changes by Andrea Corbellini : -- versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue18454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
New submission from Andrea Corbellini : Creating a class (either using the 'class' statement or using type()) creates a circular reference. I've attached a script that simply demonstrates this. The problem is caused by the fact that MyClass.__dict__['__dict__'].__objclass__ is MyClass. Although most of the times classes are never deleted when the interpreted exits, some programs (like the popular Django framework) create temporary classes. And this is a pain because you can't disable the garbage collector. -- components: Interpreter Core files: test.py messages: 111935 nosy: candrea priority: normal severity: normal status: open title: Declaring a class creates circular references type: resource usage versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18251/test.py ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Corbellini added the comment: Disabling the GC can increase performances (although not significantly). But this bug is the cause of other problems too: what if the metaclass contains a __del__() method? An another issue that I've found is that debugging is harder. I always try to avoid to create ref cycles in my code, also if my objects are collectable. In this way, I'm sure that I'll always be able to add a __del__ method in the future without problems. However, I can't easily check ref cycles without manually inspecting `gc.garbage`. And also, specifying DEBUG_SAVEALL will put all the deleted classes and their attributes in the garbage, which makes debugging *very* hard in case of a leaking program. -- ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Corbellini added the comment: Having a __del__ inside a metaclass is strange, I know... but probably there are situations where you need to do so. Why shouldn't a developer be able to add a __del__ to a metaclass without creating uncollectable objects? I don't think this behavior is by design. Also, doing random contributions to various projects I've seen many odd things. However I don't think that the bug tracker is the right place to discuss development practices. A bug that causes problems in unusual situations is still a bug. :-) -- ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9417] Declaring a class creates circular references
Andrea Corbellini added the comment: This is an unwanted an unexpected behavior, so this is a bug by definition. If it's not easy to fix, it's a different matter. However here's a proposed solution: * for the __mro__: instead of using a tuple, use a new object that inherits from it. This new object should use weak reference for the first item and should return the real object (if available) only in __getitem__(). * __objclass__ can should become a property based on weak references. -- ___ Python tracker <http://bugs.python.org/issue9417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue812369] module shutdown procedure based on GC
Changes by Andrea Corbellini : -- nosy: +candrea ___ Python tracker <http://bugs.python.org/issue812369> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
