Python-сообщество

Тогда о чём речь, вы делаете как вам нравится, я делаю как мне нравится. Я может ширину комментариев окном регулирую и не люблю когда за меня ширину делают жёсткой, а при сужении окна такие комментарии превратятся по пол слова на второй строке в рваный вид. Ладно, тема то у нас архив примеров, вы создайте тему про красоту кода и я в полне могу обсудить детально рассудительно а не эмоционально…

Отредактировано AZJIO (Сен. 14, 2014 00:53:03)

Говнокод связан не с красотой или с оформлением. Покажу на примерах

Говнокод:

if not var:
	print('Ошибка')
if var:
	print('Успех')

for i in list1: # Цикл вставки в Listbox
	lbox1.insert(END,i)

f = open(sa, 'a')

if not (text==''):

n = n + 1

Отредактировано 4kpt_II (Сен. 14, 2014 01:05:52)

AZJIO
Я может ширину комментариев окном регулирую и не люблю когда за меня ширину делают жёсткой

AZJIO
dev сообщал о программе контроля версий, но я ещё не дошёл до момента, когда мне требуется этот контроль. До этого надо дожить, прочувствовать необходимость. А так ради красивых слов, ради того, чтобы меня считали умным и модным, врядли я пойду на добавление себе проблем

ihor_ua
55@d

ihor_ua
что значит пишет в регистр?

"aY "ap

AZJIO
Не увидел этого, чел тыкал мышкой и что-то наживал.

AZJIO
Ну для тех 6 столбиков пойдёт и так, а для остального, но в Notepad++ тоже есть генерация столбика чисел, но одно дело в конце строки вставить, другое дело вставить в позицию и ещё угадать чем заменить.

AZJIO
Кто их измерял? Они на Си написаны

AZJIO
Я тут в конфе на джаббере просил помощи, как бы сделать несколько версий например Geany

AZJIO
Ну и с ассоциациями такое бы не плохо бы провернуть.

AZJIO
Как бы c Notepad++ я как раз таки в винде сапускаю сколько угодно копий и сколькко угодно версий и прописать могу через реестр каждый тип файла с любой из версий.

AZJIO
Ну тогда наверно легче извлечь из CHM, в винде он его как архив 7-zip'ом открывает

AZJIO
а то прям про print в своём посте 2 раза упомянул

AZJIO
На предыдущем языке один из dev сообщал о программе контроля версий, но я ещё не дошёл до момента, когда мне требуется этот контроль. До этого надо дожить, прочувствовать необходимость. А так ради красивых слов, ради того чтобы меня считали умным и модным, врядли я пойду на добавление себе проблем.

AZJIO
Каждый этап вмотрирования новых фич сопровождается созданием копии проекта.

AZJIO
Вряд ли я логом пользовался бы. Ещё раз головой думаю.

AZJIO
Если человек не думает о своих действиях и по логу оченивает состояние кода

[guest@localhost git]$ git log -3 --author=Linus
commit 74faaa16f016af9fc429770ba701f2aa598d9f21
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Oct 17 10:00:37 2012 -0700

    Fix "git diff --stat" for interesting - but empty - file changes
    
    The behavior of "git diff --stat" is rather odd for files that have
    zero lines of changes: it will discount them entirely unless they were
    renames.
    
    Which means that the stat output will simply not show files that only
    had "other" changes: they were created or deleted, or their mode was
    changed.
    
    Now, those changes do show up in the summary, but so do renames, so
    the diffstat logic is inconsistent. Why does it show renames with zero
    lines changed, but not mode changes or added files with zero lines
    changed?
    
    So change the logic to not check for "is_renamed", but for
    "is_interesting" instead, where "interesting" is judged to be any
    action but a pure data change (because a pure data change with zero
    data changed really isn't worth showing, if we ever get one in our
    diffpairs).
    
    So if you did
    
       chmod +x Makefile
       git diff --stat
    
    before, it would show empty (" 0 files changed"), with this it shows
    
     Makefile | 0
     1 file changed, 0 insertions(+), 0 deletions(-)
    
    which I think is a more correct diffstat (and then with "--summary" it
    shows *what* the metadata change to Makefile was - this is completely
    consistent with our handling of renamed files).
    
    Side note: the old behavior was *really* odd. With no changes at all,
    "git diff --stat" output was empty. With just a chmod, it said "0
    files changed". No way is our legacy behavior sane.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit 9d55b2e12f82b344709b0f2981eaf142b0b1f7a8
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Sep 30 15:10:48 2012 -0700

    mailinfo: don't require "text" mime type for attachments
    
    Currently "git am" does insane things if the mbox it is given contains
    attachments with a MIME type that aren't "text/*".
    
    In particular, it will still decode them, and pass them "one line at a
    time" to the mail body filter, but because it has determined that they
    aren't text (without actually looking at the contents, just at the mime
    type) the "line" will be the encoding line (eg 'base64') rather than a
    line of *content*.
    
    Which then will cause the text filtering to fail, because we won't
    correctly notice when the attachment text switches from the commit message
    to the actual patch. Resulting in a patch failure, even if patch may be a
    perfectly well-formed attachment, it's just that the message type may be
    (for example) "application/octet-stream" instead of "text/plain".
    
    Just remove all the bogus games with the message_type. The only difference
    that code creates is how the data is passed to the filter function
    (chunked per-pred-code line or per post-decode line), and that difference
    is *wrong*, since chunking things per pre-decode line can never be a
    sensible operation, and cannot possibly matter for binary data anyway.
    
    This code goes all the way back to March of 2007, in commit 87ab79923463
    ("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to
    pass random mbox contents to git. However, the pre-decode vs post-decode
    logic really shouldn't matter even for that case, and more importantly, "I
    fed git am crap" is not a valid reason to break *real* patch attachments.
    
    If somebody really cares, and determines that some attachment is binary
    data (by looking at the data, not the MIME-type), the whole attachment
    should be dismissed, rather than fed in random-sized chunks to
    "handle_filter()".
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Don Zickus <dzickus@redhat.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit 08a94a145c3231c0fa36469682591a3c45222271
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 28 11:24:14 2012 -0700

    commit/commit-tree: correct latin1 to utf-8
    
    When a line in the message is not a valid utf-8, "git mailinfo"
    attempts to convert it to utf-8 assuming the input is latin1 (and
    punt if it does not convert cleanly).  Using the same heuristics in
    "git commit" and "git commit-tree" lets the editor output be in
    latin1 to make the overall system more consistent.
    
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
[guest@localhost git]$

AZJIO
Тесты делал так.

Отредактировано py.user.next (Сен. 14, 2014 01:43:52)

AZJIO
Пытались двигаться дальше? Или всё так и зависло?

ZZZ
То что вы выложили в архиве примеряя к моему архиву это полный отстой. Там нет ни последовательности не структурированности, какие то случайные мысли связанные с чем то увиденным в гугле. Я черновик-заметки пишу более упорядоченнее. Походу эта записка даже не читалась после написанного. Первое что мне не хватало на предыдущем языке это отсутствие готовых примеров. Нормальный человек посмотрит на код, особенно если он работающей и поймёт как он работает. Может не сразу, может расставит комментарии в каждой строке и начнёт понимать как это работает. Я говорю про алгоритмы. Про функции я вообще молчу, пользователь увидев функцию в справке может целый день её пытаться понять, а если функция сделана как пример, то он поймёт её сразу от увиденного и произведённого действия.

На любом форуме люди задают одни и те же вопросы, со временем начинает надоедать это, что вы делаете? Сначала даёте пример, после 2-3 раз одного и того же примера пишете на словах как это сделать, раз 20 потом и это начинает надоедать и вы пишите что пользователь тупой, что он говнокодер, что он не знает как пользоваться гуглом, что он… ну и так далее. Какой ответ был полезный для пользователя? Первые 3 раза, остальное бесполезные трата времени пользователя и своего, кроме конечно случая, если вы получаете удовольствие от тролинга. Итак ваше решение? Моё я уже сказал, архив и отсылка на пример в архиве, а умный пользователь без вас сообразит посмотреть остальные примеры и сказать огромное спасибо. Я уже выкладывал архив на предыдущем языке и мне ставили за него плюсы, так что любые попытки обесценить мой тезис выглядят подозрительно, как будто я у вас отбираю хлеб, как будто вы заботитесь чтобы пользователи не могли чему то научится и постоянно спрашивали у вас крошки от программирования.

И кстати я не брезгую для новичка написать простейший пример, который для меня уже кажется слишком бесполезным… так что критерий простоты тут на кого вы нацеливаете контент. Я выше уже сказал - можно сделать примеры простые средние и сложные, для разного уровня, добавляя индекс к примеру.

py.user.next

Во-во, а в лине вообще всё равно, есть ли у файла расширение. То есть ограничения такого нет, и, следовательно, проблем с этим нет.

Ну, это же психологический приём. Когда повторяешь, важность сказанного увеличивается, а важное запоминается.

А ещё html удобен тем, что его можно отредактировать. Можно и закладки расставлять, но я тебе уже говорил, как удобнее закладки делать. Я вот так делал с документацией к Gimp'у. Там был тёмный фон, а я его заменил на белый, отредактировав css.

AZJIO
Кстати не плакал, спокойно относился.

Отредактировано AZJIO (Сен. 14, 2014 14:50:05)

AZJIO
ZZZТо что вы выложили в архиве примеряя к моему архиву это полный отстой. Там нет ни последовательности не структурированности, какие то случайные мысли связанные с чем то увиденным в гугле. Я черновик-заметки пишу более упорядоченнее. Походу эта записка даже не читалась после написанного. Первое что мне не хватало на предыдущем языке это отсутствие готовых примеров. Нормальный человек посмотрит на код, особенно если он работающей и поймёт как он работает. Может не сразу, может расставит комментарии в каждой строке и начнёт понимать как это работает. Я говорю про алгоритмы. Про функции я вообще молчу, пользователь увидев функцию в справке может целый день её пытаться понять, а если функция сделана как пример, то он поймёт её сразу от увиденного и произведённого действия.

import sys
print(sys.argv)

Отредактировано Nata (Сен. 14, 2014 17:15:44)

Nata
Я такой же новичок как и вы, подключайтесь, будет пример. Можете написать несколько примеров. Если каждый десяток напишет, будет стартовый капитал, если так и будут тролить, ждите примерно в течении года улучшение качества.
Сейчас я пока не знаю как сделать этот пример, кроме как написать в него коменты, ведь его запуск должен быть с параметрами, чтобы получить их вывод в консоль.

Отредактировано AZJIO (Сен. 14, 2014 17:46:14)

AZJIO
Я такой же новичок как и вы, подключайтесь, будет пример. Можете написать несколько примеров. Если каждый десяток напишет, будет стартовый капитал, если так и будут тролить, ждите примерно в течении года улучшение качества.

AZJIO
NataЯ такой же новичок как и вы, подключайтесь, будет пример. Можете написать несколько примеров.

for line in f.readlines():

AZJIO
Если каждый десяток напишет, будет стартовый капитал, если так и будут тролить, ждите примерно в течении года улучшение качества.

Отредактировано Nata (Сен. 14, 2014 19:29:41)