Can this possibly be related to the exploit on the Debian wiki (
http://lwn.net/Articles/531726/ )?
On Tue, Jan 8, 2013 at 1:38 AM, Brian Curtin wrote:
>
> On December 28th, an unknown attacker used a previously unknown remote
> code exploit on http://wiki.python.org/. The attacker was able to
On Mon, Jan 7, 2013 at 1:06 PM, Brett Cannon wrote:
..
> +1 for putting this under datetime; "Namespaces are one honking great
> idea". People looking for date stuff is going to look in datetime or
> time first so might as well put it there to begin with.
+1 for the same reason.
_
On December 28th, an unknown attacker used a previously unknown remote
code exploit on http://wiki.python.org/. The attacker was able to get
shell access as the "moin" user, but no other services were affected.
Some time later, the attacker deleted all files owned by the "moin"
user, including all
On Mon, Jan 7, 2013 at 4:03 PM, Benjamin Peterson wrote:
> 2013/1/7 Victor Stinner :
> > Hi,
> >
> > I would like add a new flag to open() mode to close the file on exec:
> > "e". This feature exists using different APIs depending on the OS and
> > OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT
On Mon, Jan 07, 2013 at 06:03:54PM -0600, Benjamin Peterson wrote:
> 2013/1/7 Victor Stinner :
> > Hi,
> >
> > I would like add a new flag to open() mode to close the file on exec:
> > "e". This feature exists using different APIs depending on the OS and
> > OS version: O_CLOEXEC, FD_CLOEXEC and O_
2013/1/7 Gregory P. Smith :
>
>
>
> On Mon, Jan 7, 2013 at 4:03 PM, Benjamin Peterson
> wrote:
>>
>> 2013/1/7 Victor Stinner :
>> > Hi,
>> >
>> > I would like add a new flag to open() mode to close the file on exec:
>> > "e". This feature exists using different APIs depending on the OS and
>> > OS
2013/1/7 Victor Stinner :
> Hi,
>
> I would like add a new flag to open() mode to close the file on exec:
> "e". This feature exists using different APIs depending on the OS and
> OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider
> that such flag would be interesting?
I'm not sure
Hi,
I would like add a new flag to open() mode to close the file on exec:
"e". This feature exists using different APIs depending on the OS and
OS version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider
that such flag would be interesting?
On Linux (glibc), the feature is available as the
On Mon, Jan 7, 2013 at 10:40 PM, PJ Eby wrote:
> On Mon, Jan 7, 2013 at 11:32 AM, Brett Cannon wrote:
>> On Mon, Jan 7, 2013 at 10:46 AM, Maciej Fijalkowski wrote:
>>> On Mon, Jan 7, 2013 at 4:22 PM, Oleg Broytman wrote:
On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek
wrote:
>
On Mon, Jan 7, 2013 at 11:32 AM, Brett Cannon wrote:
> On Mon, Jan 7, 2013 at 10:46 AM, Maciej Fijalkowski wrote:
>> On Mon, Jan 7, 2013 at 4:22 PM, Oleg Broytman wrote:
>>> On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek
>>> wrote:
Hi, is it possible to access the values stored on
On Mon, Jan 7, 2013 at 12:01 PM, Lennart Regebro wrote:
> On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren
> wrote:
>>
>> The module could be split into several modules in a package without
>> affecting the public API if that would help with maintenance, simular to
>> unittest.
>
>
> Is there po
Yep, or a BCC. Just as long as people blindly replying to anything
PEP-related don't send mail to the PEP mailing list.
On Mon, Jan 7, 2013 at 11:47 AM, Lennart Regebro wrote:
> On Mon, Dec 31, 2012 at 2:40 PM, Brett Cannon wrote:
>>
>> Since this has happened for the second time in the past mon
On Mon, Jan 7, 2013 at 5:57 PM, Lennart Regebro wrote:
> Will this help the makers of distributions, like Ubuntu etc? If that is the
> case, then it might be worth doing, otherwise I don't think it's very
> useful.
As a Gentoo packager, I think it's useful.
Cheers,
Dirkjan
_
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren wrote:
> The module could be split into several modules in a package without
> affecting the public API if that would help with maintenance, simular to
> unittest.
>
Is there popular support for doing so, ie make datetime into a package,
have all
On Sat, Dec 29, 2012 at 8:05 PM, Arfrever Frehtes Taifersar Arahesis <
arfrever@gmail.com> wrote:
> 2012-12-29 19:54:42 Lennart Regebro napisał(a):
> > On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
> wrote:
> >
> > > - -Lots for enabling fallback by default except on platforms known not
> to
>
On Mon, Dec 31, 2012 at 2:40 PM, Brett Cannon wrote:
> Since this has happened for the second time in the past month, I want to
> prevent a trend from starting here. Please do not CC the peps mailing list
> on any discussions as it makes it impossible to know what emails are about
> an actual upd
On Mon, Jan 7, 2013 at 10:46 AM, Maciej Fijalkowski wrote:
> On Mon, Jan 7, 2013 at 4:22 PM, Oleg Broytman wrote:
>> Hello.
>>
>>We are sorry but we cannot help you. This mailing list is to work on
>> developing Python (adding new features to Python itself and fixing bugs);
>> if you're havin
On Mon, Jan 7, 2013 at 4:22 PM, Oleg Broytman wrote:
> Hello.
>
>We are sorry but we cannot help you. This mailing list is to work on
> developing Python (adding new features to Python itself and fixing bugs);
> if you're having problems learning, understanding or using Python, please
> find a
Hello.
We are sorry but we cannot help you. This mailing list is to work on
developing Python (adding new features to Python itself and fixing bugs);
if you're having problems learning, understanding or using Python, please
find another forum. Probably python-list/comp.lang.python mailing list/
Hi, is it possible to access the values stored on the stack in Python stack
machine from Python?
As in, consider expression:
tmp = foo() + bar()
At the point in time when bar() is called, foo() already returned
something, and that value is on top of the stack in that frame, a few steps
after bar
On Mon, Jan 7, 2013 at 1:08 PM, Mark Shannon wrote:
>
>
> On 07/01/13 10:55, Maciej Fijalkowski wrote:
>>
>> On Sun, Jan 6, 2013 at 11:40 PM, Kristján Valur Jónsson
>> wrote:
>>>
>>> The memory part is also why I am interested in this approach.
>>> Another thing has been bothering me. This is th
On 07/01/13 10:55, Maciej Fijalkowski wrote:
On Sun, Jan 6, 2013 at 11:40 PM, Kristján Valur Jónsson
wrote:
The memory part is also why I am interested in this approach.
Another thing has been bothering me. This is the fact that with the default
implementation, the smll table is only ever p
On Sun, Jan 6, 2013 at 11:40 PM, Kristján Valur Jónsson
wrote:
> The memory part is also why I am interested in this approach.
> Another thing has been bothering me. This is the fact that with the default
> implementation, the smll table is only ever populated up to a certain
> percentage, I ca
Christian Tismer stackless.com> writes:
> Anything I'm missing here?
The use case was missed during PEP and patch review, so the feature didn't make
it into 3.3. Issue #15776 raised the problem; it has been resolved and the
feature should appear in Python 3.4.
Regards,
Vinay Sajip
___
On Sun, Jan 6, 2013 at 10:40 PM, Kristján Valur Jónsson
wrote:
> A linear lookup in a handful of slots can't be that much of a bother, it is
> only with larger number of entries that the O(1) property starts to matter.
Something that I was thinking is if for small tables does make sense
to actu
25 matches
Mail list logo
