EaE Jul 25 2012 at 14:13

Кросс-вмный (CLR/JVM) код на Python

4 min

.NET*Java*Python*

+42

Comments 10

JustAMan Jul 25 2012 at 14:46

Несколько замечаний:

Параметр по-умолчанию, равный globals() — адское попадалово на сложно отслеживаемые ошибки, поскольку оператор def в python исполняется один раз, создавая переменную-функцию, у которой сразу будут прописаны эти значения. Именно с globals(), скорее всего, ничего криминального не произойдёт, оно и так возвращает ~указатель на словарь, но на будущее — это лучше учесть, что иметь mutable-значения по-умолчанию для функций — напрашиваться на очень сложные в отладке проблемы. В Вашем случае лучше вообще опустить это значение, всё равно Вы передаёте его явно.
К той же функции… не хотите передавать globals() явно — не передавайте, есть же sys._getframe() и у фрейма есть .f_back и .f_globals… Ну то есть код может выглядеть как-то так:
```
import sys
def myImport(module, cls, globs = None):
    if not globs:
        try:
            fr = sys._getframe()
            globs = fr.f_back.f_globals
        finally:
            del fr # to remove possible ref-loops
    """do main import stuff"""
```

Вместо вот этого странного куска

        if name[0:1] in string.uppercase:
            continue
        newname = name[0:1].upper() + name[1:]

можно просто написать

        newname = name.capitalize()

Правда, всё это я пишу для CPython, но не думаю, что IronPython/Jython различаются в этих вопросах.

jellyfish Jul 26 2012 at 01:28

использование capitalize() — не даёт идентичный результат, если, например, в name есть другие заглавные буквы

EaE Jul 26 2012 at 06:52

Да, я думал это то, что мне нужно, но оно же сломает мне остальные заглавные буквы в названиях.

JustAMan Jul 26 2012 at 10:58

Хм, действительно, не проверил до конца… В любом случае, можно было написать

newname = name[:1].upper() + name[1:]

и не заморачиваться с проверкой — всё равно потом проверяется, нет ли такого атрибута, перед его созданием…

akzhan Jul 26 2012 at 05:34

Случай, когда стоило использовать IronRuby и JRuby ;)

cblp Jul 26 2012 at 05:59

Есть принципиальные отличия? Думаю, если бы разработчики лучше знали Ruby, то взяли бы её.

akzhan Jul 26 2012 at 16:42

Проще писать тесты. Например, уже есть очень приятные RSpec и RR.

EaE Jul 26 2012 at 16:47

Обычные юниттестовые фреймворки. Каких миллион под любой язык. А учитывая то, что у нас даже не о юнит-тестах речь идет… В любом случае, выбор языка был сделан из практических соображений — питон народ в среднем знает лучше.

EaE Jul 26 2012 at 06:47

Да, как правильно написали выше, Руби команде дольше пришлось бы осваивать.

KvanTTT Jul 26 2012 at 21:20

Что за библиотека то?