Можно создать освободивший буфер файл и присвоить этот файл sys.stdout.
import sys
myFile= open( "a.log", "w", 0 )
sys.stdout= myFile
Вы не можете волшебно изменить предоставленный систему stdout; так как это предоставляется Вашей программе Python ОС.
ASP.Net уже предоставляет статический экземпляр текущего поставщика членства через статический класс членство и его статическое свойство Provider . Привязка, скорее всего, будет в вашем методе Application_Start и будет выглядеть примерно так:
Bind<MembershipProvider>()
.ToMethod(ctx => Membership.Provider);
Опять же, поскольку Memberhip.Provider является статическим, он уже как синглтон, поэтому поведение, которое вы пытаетесь применить не имеет особого значения.
Если не указывать какое-либо поведение в приведенном выше фрагменте, Ninject по умолчанию будет переходить на временное поведение. Я полагаю, что в такого рода привязке это будет равносильно вызову лямбда-выражения, возвращающего Membership.Provider каждый раз, когда ему нужно ввести тип MembershipProvider .
Я полагаю, что может быть аргумент для явного указания одноэлементного поведения, поскольку Ninject, скорее всего, "кэширует" значение, возвращаемое лямбда-выражением, при первом введении MembershipProvider , что фактически экономит накладные расходы. выполнения лямбды. Я не уверен на 100%, как Ninject будет работать в этой ситуации, но кажется разумным, что так оно и будет.
С учетом всего сказанного, я лично предпочитаю использовать OnePerRequestBehavior , таким образом я знаю Ninject будет вызывать мою лямбду один раз для каждого запроса. Не уверен, что это необходимо, но мне нравится идея получать поставщика из Membership.Provider один раз при каждом запросе, поскольку я полагаю, вы не можете делать предположений о том, как и когда Membership.Provider получит установлен, хотя вы, вероятно, могли бы узнать, достаточно ли покопаетесь с Reflector.
Bind<MembershipProvider>()
.ToMethod(ctx => Membership.Provider)
.Using<OnePerRequestBehavior>();
Удачи. Извините, ваш вопрос здесь так долго не задавался!