Мне кажется, это из серии определения реального уровня/опыта. По таким вопросам можно понять глубину изучения языка. Эксперт в этой области будет знать 100500 всяких нюансов. Вплоть до с++ кода питона.

>> Вплоть до с++ кода питона Которого в cpython нет

>> Вплоть до с++ кода питона Которого в cpython нет

Значит си))?

Да на любой. :) Многие не знают, что del a[:] очищает список.

Зачем это может быть надо?

Т.е. чем это лучше a = list() ?

@iroln @lig11 ?

Зачем это может быть надо?

В случае, если ты хочешь поменять список, который пришёл тебе как параметр функции например

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

В случае, если ты хочешь поменять список, который пришёл тебе как параметр функции например

ну это относительно редкий случай, кмк.

ну это относительно редкий случай, кмк.

Ну да. А еще, когда оно не list.

del a[:] ничего не знает о типе коллекции

И даже a = a.__class__() ещё хуже, потому что мы не знаем какие аргументы были у конструктора, когда коллекцию создавали

А как такое может быть, что a[:] вызванный два раза выдает один и тот же айдишник? При этом тип у этого объекта list, такой же, как и у a. При этом del a удалит a, а del a[:] удалит не отображение, а лишь только элементы. Это взрыв мозга какой-то

del a[:] ничего не знает о типе коллекции

ну да, я уже подумал о происходящем под капотом

но мне всё равно не нравится идея с модификацией переданного. получается какой-то Си

А как такое может быть, что a[:] вызванный два раза выдает один и тот же айдишник? При этом тип у этого объекта list, такой же, как и у a. При этом del a удалит a, а del a[:] удалит не отображение, а лишь только элементы. Это взрыв мозга какой-то

там есть slice_cache, а нет. это не то. по идее id не гарантированно будет одинаковый. это же копия.

Вместо del можно и так сделать a[:] = list() То же самое в результате. Правда, не знаю, что эффективнее. Сейчас поискал у себя во всём коде, только в одном месте модифицируется переданный список.

там есть slice_cache, а нет. это не то. по идее id не гарантированно будет одинаковый. это же копия.

type(a[:]) показывает list? Видимо, вычисляется выражение, а оно лист

ага это list

Более того, id сделает то же и вернет id листа, а не слайса

Корпускулярно-волновой дуализм слайса в Питоне

>>> id(a) 140624854404128 >>> id(a[:]) 140624854688400

id разный

id разный

И вот второй - это про новый лист уже, а не про слайс

Вместо del можно и так сделать a[:] = list() То же самое в результате. Правда, не знаю, что эффективнее. Сейчас поискал у себя во всём коде, только в одном месте модифицируется переданный список.

на pypy быстрее del x[:]

https://github.com/vvanders/wasm_lua

я кажется понял, почему так. a = [1,2,3] print id(a[:]) print id(a[:]) здесь на первом принте не создается ссылок для слайса, поэтому он тут же убивается. А второй вызов слайса прикрепляется к тому же уже освобожденному идентификатору a = [1,2,3] print id(a[:]) c = a[:] print id(a[:]) выведет уже два разных айдишника, потому что в выражении c=a[:] айдишник из первого пнинта будет занят , пока существует ссылка с.

я кажется понял, почему так. a = [1,2,3] print id(a[:]) print id(a[:]) здесь на первом принте не создается ссылок для слайса, поэтому он тут же убивается. А второй вызов слайса прикрепляется к тому же уже освобожденному идентификатору a = [1,2,3] print id(a[:]) c = a[:] print id(a[:]) выведет уже два разных айдишника, потому что в выражении c=a[:] айдишник из первого пнинта будет занят , пока существует ссылка с.

Или просто интерпретатор ast правильно разобрал, поняв, что надо переиспользовать объект. Надо код смотреть. И меньше пустых строк в постах ставить.

Или просто интерпретатор ast правильно разобрал, поняв, что надо переиспользовать объект. Надо код смотреть. И меньше пустых строк в постах ставить.

Пустые строки убрал)

Хотел было сделать так: text[:-2] += some_text Получил: TypeError: 'str' object does not support item assignment А если так: »a = [1, 2, 3, 4] »a[:-2] += [5, 6] »a [1, 2, 5, 6, 3, 4] Прикольно

не сразу понял почему так получилось :( >>> a = [1, 2, 3, 4] >>> a[:-2] += [5, 6] >>> a [1, 2, 5, 6, 3, 4] хотя если записать как a[:-2] = a[:-2] + [5, 6] становится понятнее.

https://www.youtube.com/watch?v=wjFgOckkVYM

кто там спрашивал ранее

https://pp.userapi.com/c836730/v836730585/34670/rh3W-PYBWiw.jpg

Я тоже подписан на этот паблик

https://pp.userapi.com/c836730/v836730585/34670/rh3W-PYBWiw.jpg

А? Чего?

А? Чего?

смотри выше мессадж

на последней посиделке кто-от спрашивал про то как называется

на последней посиделке кто-от спрашивал про то как называется

А. Ясно. Надо свою питоновскую отыскать.

А. Ясно. Надо свою питоновскую отыскать.

А что у вас не питоновское?

https://twitter.com/dabeaz/status/843256520678739972

https://twitter.com/dabeaz/status/843256520678739972

Интересно, почему это сразу не сделали

Интересно, почему это сразу не сделали

Сначала инструмент, потом интеграция. Но сотни тысяч строк кода уже никогда не избавятся от open(str(mypath))

О_о джанга в качестве Model, flask в качестве view, template. В репе одна задача-вопрос WHYYYYY ))

flango - стартовый набор, Django-бэкэнд, Flask-фронтенд http://github.com/kennethreitz/flango

flango - стартовый набор, Django-бэкэнд, Flask-фронтенд http://github.com/kennethreitz/flango

Это Котопёс.

Он писал как-то, что ему нравится орм джанги и простота описания вьюшек и роутинг фласка, поэтому запилил это :)

https://twitter.com/hynek/status/843430109503787008

>In L2 and L3 throughput tests of 32 100GbE ports, Mellanox Spectrum delivered 100% line rate throughput with zero frame loss in at all frame sizes from 64-byte to 9216-byte jumbo frames in port-pair and full mesh scenarios.

читая такое ощущаешь себя в прошлом.

читая такое ощущаешь себя в прошлом.

С точностью до единиц измерения на порту

С точностью до единиц измерения на порту

да хрен с ним )) у людей 32 порта по 100(сто) гигабит.

А, в смысле у тебя такого нет и тебе завидно?:)

да хрен с ним )) у людей 32 порта по 100(сто) гигабит.

можешь пожалуйста кратко пояснить, о чем это :)

А, в смысле у тебя такого нет и тебе завидно?:)

Да )

это цитата из сравнительного теста чипов для ethernet-свитчей. только свитчей с портами на 100(сто) гигабит. и в этом тесте нагружали 32 порта под завязку и смотрели наличие потерь.

а rust выглядит няшно

@arturkornakov все, бросаешь джаваскрипт свой?

@andreyzakharevich ахахах :) да, в нем жизни нет) На самом деле хочу вакансию чуть позже запостить

ERROR: S client not available

У нас уже весна, поздно к вам улетать

@andreyzakharevich посмотрел сейчас ваш прогноз погоды, чет не айс все равно)

@andreyzakharevich посмотрел сейчас ваш прогноз погоды, чет не айс все равно)

Ну пока там собеседования, сборы, все дела, уже май будет. А у вас дожди пойдут

парни есть вопрос на 100$ почему 1-й вариант быстрее import cProfile cProfile.run("sum([int(line) for line in open('1.txt')])") cProfile.run("sum(int(line) for line in open('1.txt'))") где 1.txt -- файл с цифрами 4мб

деньги вперед

парни есть вопрос на 100$ почему 1-й вариант быстрее import cProfile cProfile.run("sum([int(line) for line in open('1.txt')])") cProfile.run("sum(int(line) for line in open('1.txt'))") где 1.txt -- файл с цифрами 4мб

может потому что list comprehension загружается в оперативку, а генератор - нет?

парни есть вопрос на 100$ почему 1-й вариант быстрее import cProfile cProfile.run("sum([int(line) for line in open('1.txt')])") cProfile.run("sum(int(line) for line in open('1.txt'))") где 1.txt -- файл с цифрами 4мб

python 2?

может потому что list comprehension загружается в оперативку, а генератор - нет?

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

ну и память надо мерять

парни есть вопрос на 100$ почему 1-й вариант быстрее import cProfile cProfile.run("sum([int(line) for line in open('1.txt')])") cProfile.run("sum(int(line) for line in open('1.txt'))") где 1.txt -- файл с цифрами 4мб

Намного быстрее?

в 2 раза

5 function calls in 1.225 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.877 0.877 0.877 0.877 <string>:1(<listcomp>) 1 0.190 0.190 1.225 1.225 <string>:1(<module>) 1 0.000 0.000 1.225 1.225 {built-in method builtins.exec} 1 0.158 0.158 0.158 0.158 {built-in method builtins.sum} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 10000005 function calls in 2.361 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 10000001 1.233 0.000 1.233 0.000 <string>:1(<genexpr>) 1 0.000 0.000 2.361 2.361 <string>:1(<module>) 1 0.000 0.000 2.361 2.361 {built-in method builtins.exec} 1 1.128 1.128 2.361 2.361 {built-in method builtins.sum} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects}

это причем почему-то cprofile дает такие дикие результаты. обычный тайм говорит что не сильно, но lc быстрее

time python3.6 generators.py python3.6 generators.py 0.82s user 0.01s system 98% cpu 0.849 total time python3.6 lc.py python3.6 lc.py 0.72s user 0.23s system 95% cpu 1.002 total

sum([x for x in range(10000000)]) vs sum((x for x in range(10000000)))

time python3.6 generators.py python3.6 generators.py 0.82s user 0.01s system 98% cpu 0.849 total time python3.6 lc.py python3.6 lc.py 0.72s user 0.23s system 95% cpu 1.002 total

потому что io - много времени кушает. зацени разницу system

@pragus тебе расскажет;)

профайлер не считает iowait. а вот cputime включает и iowait тоже

С profile на py3.5 у меня такие результаты: lc: 6 function calls in 1.203 seconds gen: 10000006 function calls in 16.156 seconds

генератор закэшировался?

положи генератор в переменную, потом sum, потом del переменной

генератор закэшировался?

не знаю, я просто для файла запускаю: python -m profile a.py где a.py - это одна строчка: s = sum(x for x in range(10000000))

c timeit всё ок %timeit sum((x for x in range(10000000))) 1 loop, best of 3: 1.03 s per loop %timeit sum([x for x in range(10000000)]) 1 loop, best of 3: 1.19 s per loop

да почему-то timeit показывает, что +- работают одинаково. Но time в pypy,py3.5,py3.6 lc > gen, а python 2.7 gen > lc

С vmprof, кстати, работает иначе

самый быстрый вариант в pypy такой: def fn(): x = 0 for line in open('1.txt'): x += int(line) return x

In [32]: %timeit fn1() 100 loops, best of 7: 13.7 ms per loop In [33]: %timeit fn2() 100 loops, best of 7: 12.7 ms per loop In [34]: %timeit fn() 100 loops, best of 7: 10.4 ms per loop

10.4 - это что я написал

12.7 - генератор

13.7 - list