German Jet

1. Собака не имеет никакого отношения к include. Это не один оператор, а два совершенно разных оператора.
   
2. Увидев @ в коде ты можешь почти со стопроцентной уверенностью сказать, что его писал неграмотный пользователь, и пользоваться этим кодом не стоит.
   
3. Увидев в коде @include ты можешь смело считать его автора абсолютным лохом и нубом, а сам код надо выкидывать немедленно. Потому что @include глушит не только саму ошибку включения файла, но и все ошибки в этом файле - то есть, поступает стократ хуже. Это значит, что если автор допускает такие косяки в коде, то и все остальное у него тоже ад кромешный.
   
4. Самое главное. Ошибки надо не подавлять. Ошибки надо исправлять. Но опять же, делать это с умом. Начинающие программисты считают сообщения об ошибках своими личными врагами, и борются с ними всеми доступными средствами - с помощью @, error_reporting(0) и др. Получив линейкой по рукам и запомнив на всю жизнь, что так делать не надо, ониначинают с не меньшим рвением писать всякие проверки - лишь бы не допустить, не дай бог, ненавистного сообщения об ошибке. Например:
   
   

if (file_exists($inc))
{
    include $inc;
} else {
    echo "Файл не найден";
}

Так вот, это - еще хуже. Для начала, часть ошибок этот код все равно не отловит. Но это даже не самое главное. Главное - что вот это вот "Файл не найден" не имеет ни малейшего смысла. Пользователю оно ничего не скажет. А программист о нем не узнает. А если и узнает, то ничего не поймет! Какой файл? Где не найден? По какой причине? Системное сообщение об ошибке содержит массу бесценной информации помогающей идентифицировать ошибку, сообщая нам где она произошла, какой файл не найден, по какой причине не найден. Выдавать вместо этого огрызок "файл не найден" - это мазохизм.

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

Ошибки не надо подавлять. Ошибки не надо прятать. Ошибки надо исправлять.

Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

UPD:
Важно отличать паттерн Dependency Injection от Dependency Injection Container.
Простейший пример внедрения зависимости:

interface IEngine {}
 
class V8Engine implements IEngine {}
 
class Car {
  public function __constructor(IEngine $engine) {
    $this->engine = $engine;
  }
}
 
$car = new Car(new V8Engine());

Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):

class V8Engine {}

class Car {
  public function __constructor() {
    $this->engine = new V8Engine();
  }
}

$car = new Car();

Отличный (и легковесный) пример DIC - это pimple:

// define some services
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

И да, контейнер сам по себе можно использовать как service locator, если к нему, например, есть глобальный доступ. Но это очень плохая практика, потому что если что-то обращается к сервис локатору, то формально оно начинает зависеть сразу от всех компонентов системы.

Гугл: https://www.google.ru/webhp?sourceid=chrome-instan...
2 верхних ссылки оттуда:
stackoverflow.com/questions/21882298/django-upload...
stackoverflow.com/questions/13704320/django-upload...

Про request.FILES: https://docs.djangoproject.com/en/1.7/ref/request-...

Подозреваю, что вам необходимо использовать requests.Session()

url = 'https://...'
login = 'login'
password = 'password'
s = requests.Session()
r = s.get(url, auth=(login, password))

Раз вы взялись использовать какую-то библиотеку, начните с чтения документации к этой библиотеке, обычно там есть ответы на большинство ваших вопросов.
Тут например

Еще, зачастую, чтение чужого кода помогает понять как правильно (или неочень) пользоваться тем или иным инструментом. Скрипт авторизующийся в вконтакте и качающий музыку пишет, пожалуй, каждый начинающий питонщик. Найти несложно.
Немало также статей по парсингу сайтов с помощью python. В них непременно будет urllib или requests. Например тут.
Вообщем, ищите и обрящете =)
Вот и в результате послал в гугл, мда. =)

upd. Раз вы самообучаетесь для себя, попробуйте порешать задачи тут: checkio.org. Полезнее всего будет не просто решать задачи, а смотреть как ту же задачу решили другие, много нового для себя откроете и цели в виде решения очередной задачи всегда будут иметься (ачивки, если вы искушенный задрот, тоже самоцель). В примерах оставленными другими есть как хорошо документированные, так и безумные решения завернутые в одну строку.

ИМХО, тут есть несколько аспектов:
1. Как написал brainick , математический бэкграунд и английский в data science практически обязателен.
Причин этому несколько: отсутствие хорошей литературы на русском языке (как по теории, так и по программированию), обилие английских терминов (lift/top/cross-validation и прочие), значение которых в переводной литературе порой объяснятся весьма туманно.
2. Если говорить о конкретной литературе, которую стоит почитать, я бы выделил несколько уровней:
Уровень 0
1. Бизнес-аналитика - Паклин, Орешков (самое базовое и обзорное введение)
2. Статистика/Тервер ( по мне, хороши книги Айвазяна/Мхитаряна)
3. SQL - в обязательном порядке. Мне в свое время помогла книга "SQL для простых смертных"
4. Изучаем Python - М. Лутц (наиболее полная книга по языку, все что нужно для data science здесь точно есть)
5. Программируем коллективный разум (к слову сказать, вот в этой книге отличный перевод)
Уровень 1
1. Математические основы машинного обучения и прогнозирования - Вьюгин (книга сложная, без подготовки по учебникам НМУ на тему анализа и линейной алгебры лучше не подходить)
2. Python for Data Analysis (pandas во всей красе, тут нечего добавить)
3. Примеры и статьи по построению моделей в sklearn - на хабре в последнее время часто мелькают статьи на эту тему, там все достаточно хорошо расписано.
Уровень 2
1. Hadoop и иже с ним ("Hadoop в действии", "Programming Pig")
2. Apache Spark - достаточно почитать описание Python API.
Тут есть еще один момент - не стоит слишком привязываться к одному языку и фреймворку.
Одна из неприятных проблем python+pandas+sklearn заключается в том, что эта связка слабо масштабируется - при 2-3-4 гб данных становится сложно разместить их в оперативной памяти. Я знаю про chunk-reading+partial_fit, но точность таких моделей оставляет желать лучшего.
С другой стороны, если обрабатывать эти данные в pyspark, то теряется все удобство pandas.DataFrame и так далее. Отрасль data science быстро развивается и обрастает новыми технологиями, так что нужно все время держать руку на пульсе.
UPD: в spark 1.3 появились DataFrame.