Такой вопрос. Здравствуйте, кстати!
В С, как известно, fread пишет в выделенную область памяти, которая передается по указателю, а возвращает число реально прочитанных байт. В Python read прямо возвращает считанные данные в виде строки (через стек!). Отсюда вопросы:

1. Не произойдет ли беда со стеком, если мне нужно считать слишком много данных?
   
2. Можно ли сделать свой маленький велосипедик который будет работать так, как fread в C, или это решается только на уровне builtin-ов

Кратко опишу, почему возник вопрос: надо разбить большой файл на куски и записать в несколько файлов поменьше. В существующем read надо либо считывать по маленькому кусочку (теряем в производительности) либо рискнуть считать большой кусок (он полезет в стек, и что будет дальше — зависит от текущей ситуации: может все рухнуть из-за переполнения стека, а может и нет).

Здравствуйте, Аноним, Вы писали:

А>Кратко опишу, почему возник вопрос: надо разбить большой файл на куски и записать в несколько файлов поменьше. В существующем read надо либо считывать по маленькому кусочку (теряем в производительности) либо рискнуть считать большой кусок (он полезет в стек, и что будет дальше — зависит от текущей ситуации: может все рухнуть из-за переполнения стека, а может и нет).

Что это у вас за питон такой экзотический, который строки в стек пихает? Или вы это сами придумали?

Здравствуйте, quodum, Вы писали:

Q>Что это у вас за питон такой экзотический, который строки в стек пихает? Или вы это сами придумали?

Я пишу:

data=file.read(100000)

The bytes are returned as a string object

Как ко мне возвращается этот самый объект — через стек? Вроде так, другого пути у него нет.

Здравствуйте, Аноним, Вы писали:

А>Как ко мне возвращается этот самый объект — через стек? Вроде так, другого пути у него нет.

В питоне все объекты хранятся в куче, а переменные -- это ссылки на них.

Здравствуйте, SergH, Вы писали:

SH>В питоне все объекты хранятся в куче, а переменные -- это ссылки на них.

Thank you.

Здравствуйте, Аноним, Вы писали:

А>Кратко опишу, почему возник вопрос: надо разбить большой файл на куски и записать в несколько файлов поменьше. В существующем read надо либо считывать по маленькому кусочку (теряем в производительности) либо рискнуть считать большой кусок (он полезет в стек, и что будет дальше — зависит от текущей ситуации: может все рухнуть из-за переполнения стека, а может и нет).

Не могу не поделиться ссылкой, как бы это сделал сам создатель Python
http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html
Здесь задача, конечно, совершенно другая, однако сам принцип — использовать yield-ы и буферы, примерно тот же самый.