Re: [Python-Dev] More compact dictionaries with faster iteration

2013-01-07 Thread Andrea Griffini
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 actually do the hashing... a small table could be kept with just
key/value pairs (saving also the hash space) with a linear scan first
for identity and then a second scan for equality.

Given the level of optimization of dicts however I'm 99% sure this was
already tried before tho.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Why no venv in existing directory?

2013-01-07 Thread Vinay Sajip
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

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] More compact dictionaries with faster iteration

2013-01-07 Thread Maciej Fijalkowski
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 cant recall, perhaps 50%.  Since the small table is small by 
> definition, I think it ought to be worth investigating if we cannot allow it 
> to fill to 100% before growing, even if it costs some collisions.  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.
> K

If you're very interested in the memory footprint you should do what
PyPy does. It gives you no speed benefits without the JIT, but it
makes all the instances behave like they are having slots. The trick
is to keep a dictionary name -> index into a list on a class (you go
through hierarchy of such dicts as you add or remove attributes) and a
list of attributes on the instance.

We call it maps, V8 calls it hidden classes, it's well documented on
the pypy blog.

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] More compact dictionaries with faster iteration

2013-01-07 Thread Mark Shannon



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 populated up to a certain 
percentage, I cant recall, perhaps 50%.  Since the small table is small by 
definition, I think it ought to be worth investigating if we cannot allow it to 
fill to 100% before growing, even if it costs some collisions.  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.
K


In 3.3 dicts no longer have a small table.


If you're very interested in the memory footprint you should do what
PyPy does. It gives you no speed benefits without the JIT, but it
makes all the instances behave like they are having slots. The trick
is to keep a dictionary name -> index into a list on a class (you go
through hierarchy of such dicts as you add or remove attributes) and a
list of attributes on the instance.

We call it maps, V8 calls it hidden classes, it's well documented on
the pypy blog.


They are called shared keys in CPython 3.3 :)



Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] More compact dictionaries with faster iteration

2013-01-07 Thread Maciej Fijalkowski
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 the fact that with the
>>> default implementation, the smll table is only ever populated up to a
>>> certain percentage, I cant recall, perhaps 50%.  Since the small table is
>>> small by definition, I think it ought to be worth investigating if we cannot
>>> allow it to fill to 100% before growing, even if it costs some collisions.
>>> 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.
>>> K
>
>
> In 3.3 dicts no longer have a small table.
>
>>
>> If you're very interested in the memory footprint you should do what
>> PyPy does. It gives you no speed benefits without the JIT, but it
>> makes all the instances behave like they are having slots. The trick
>> is to keep a dictionary name -> index into a list on a class (you go
>> through hierarchy of such dicts as you add or remove attributes) and a
>> list of attributes on the instance.
>>
>> We call it maps, V8 calls it hidden classes, it's well documented on
>> the pypy blog.
>
>
> They are called shared keys in CPython 3.3 :)

shared keys don't go to the same lengths, do they?

>
>>
>> Cheers,
>> fijal
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/mark%40hotpy.org
>>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Accessing value stack

2013-01-07 Thread Dima Tisnek
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() returns, that value is added to bar and is lost.

I would very much like to be able to read (and maybe even change) that
ephemeral value.

If it is absolutely not possible to achieve from Pythonland, I welcome
pointers on how to write a C/cython/types extension to achieve this.

Thanks,
d.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Accessing value stack

2013-01-07 Thread Oleg Broytman
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/news
group is the best place; there are Python developers who participate in it;
you may get a faster, and probably more complete, answer there. See
http://www.python.org/community/ for other lists/news groups/fora. Thank
you for understanding.

On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek  wrote:
> Hi, is it possible to access the values stored on the stack in Python stack
> machine from Python?

   In short: it's possible but very much discouraged. Don't hack into
python internals.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Accessing value stack

2013-01-07 Thread Maciej Fijalkowski
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 another forum. Probably python-list/comp.lang.python mailing list/news
> group is the best place; there are Python developers who participate in it;
> you may get a faster, and probably more complete, answer there. See
> http://www.python.org/community/ for other lists/news groups/fora. Thank
> you for understanding.
>
> On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek  
> wrote:
>> Hi, is it possible to access the values stored on the stack in Python stack
>> machine from Python?
>
>In short: it's possible but very much discouraged. Don't hack into
> python internals.

Is it possible? I claim it's not (from *Python* because obviously data
is in memory).

Cheers,
fijal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Accessing value stack

2013-01-07 Thread Brett Cannon
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 having problems learning, understanding or using Python, please
>> find another forum. Probably python-list/comp.lang.python mailing list/news
>> group is the best place; there are Python developers who participate in it;
>> you may get a faster, and probably more complete, answer there. See
>> http://www.python.org/community/ for other lists/news groups/fora. Thank
>> you for understanding.
>>
>> On Mon, Jan 07, 2013 at 03:06:51PM +0100, Dima Tisnek  
>> wrote:
>>> Hi, is it possible to access the values stored on the stack in Python stack
>>> machine from Python?
>>
>>In short: it's possible but very much discouraged. Don't hack into
>> python internals.
>
> Is it possible? I claim it's not (from *Python* because obviously data
> is in memory).

Nope, it's not.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] FYI: don't CC the peps mailing list

2013-01-07 Thread Lennart Regebro
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 update vs. people replying to some discussion which in no way
> affects the PEP editors. Emails to the peps list should deal only with
> adding/updating peps and only between the PEP editors and PEP authors.
>
> Lennart, I tossed all emails that got held up in moderation, so please
> check that the latest version of your PEP is in as you want, else send a
> patch to the peps list directly (inlined text is not as easy to work with).
>

A simple fix for this is to send separate mails to the two mailing lists.
Is that OK?

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 431 Time zone support improvements - Update

2013-01-07 Thread Lennart Regebro
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
> > > have their own database
> >
> > Well, it's the same thing really. If the platform does have a database,
> the
> > fallback will not be used.
>
> I suggest that configure script support
> --enable-internal-timezone-database / --disable-internal-timezone-database
> options.
> --disable-internal-timezone-database should cause that installational
> targets in Makefile would not install files of timezone
> database.


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.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 431 Time zone support improvements - Update

2013-01-07 Thread Lennart Regebro
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 of the pytz modules in there, but letting the public API go only
through datetime, ie no timezone submodule?

If the list decides so, I'll update the PEP.

//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 431 Time zone support improvements - Update

2013-01-07 Thread Dirkjan Ochtman
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] FYI: don't CC the peps mailing list

2013-01-07 Thread Brett Cannon
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 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 update vs. people replying to some discussion which in no way
>> affects the PEP editors. Emails to the peps list should deal only with
>> adding/updating peps and only between the PEP editors and PEP authors.
>>
>> Lennart, I tossed all emails that got held up in moderation, so please
>> check that the latest version of your PEP is in as you want, else send a
>> patch to the peps list directly (inlined text is not as easy to work with).
>
>
> A simple fix for this is to send separate mails to the two mailing lists. Is
> that OK?
>
> //Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 431 Time zone support improvements - Update

2013-01-07 Thread Brett Cannon
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 popular support for doing so, ie make datetime into a package, have
> all of the pytz modules in there, but letting the public API go only through
> datetime, ie no timezone submodule?
>
> If the list decides so, I'll update the PEP.

+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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Accessing value stack

2013-01-07 Thread PJ Eby
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 the stack in Python stack
 machine from Python?
>>>
>>>In short: it's possible but very much discouraged. Don't hack into
>>> python internals.
>>
>> Is it possible? I claim it's not (from *Python* because obviously data
>> is in memory).
>
> Nope, it's not.

I took that as a challenge, and just tried to do it using
gc.get_referents().  ;-)

Didn't work though...  which actually makes me wonder if that's a bug
in gc.get_referents(), or whether I'm making a bad assumption about
when you'd have to run gc.get_referents() on a frame in order to see
items from the value stack included.  Could this actually be a bug in
frames' GC implementation, or are value stack items not supposed to
count for GC purposes?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Accessing value stack

2013-01-07 Thread Maciej Fijalkowski
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:
> Hi, is it possible to access the values stored on the stack in Python 
> stack
> machine from Python?

In short: it's possible but very much discouraged. Don't hack into
 python internals.
>>>
>>> Is it possible? I claim it's not (from *Python* because obviously data
>>> is in memory).
>>
>> Nope, it's not.
>
> I took that as a challenge, and just tried to do it using
> gc.get_referents().  ;-)
>
> Didn't work though...  which actually makes me wonder if that's a bug
> in gc.get_referents(), or whether I'm making a bad assumption about
> when you'd have to run gc.get_referents() on a frame in order to see
> items from the value stack included.  Could this actually be a bug in
> frames' GC implementation, or are value stack items not supposed to
> count for GC purposes?

valustack is a static list in C (it's not a Python list at all) that's
stored on the frame. You can't do it that way. gc.get_referrers
returns you only python objects (and in fact should return you only
python objects that are accessible otherwise, but those details are
really implementation-dependent)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Add "e" (close and exec) mode to open()

2013-01-07 Thread 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?

On Linux (glibc), the feature is available as the "e" flag for fopen()
(O_CLOEXEC or FD_CLOEXEC depending on the kernel version). With Visual
Studio, it's the "N" flag (O_NOINHERIT).

I would like to modify open() to be able to benefit of O_CLOEXEC
atomicity. The FD_CLOEXEC method has a race condition if another
thread does fork() between open() and fcntl() (two calls to fcntl()
are required).

I created a patch available on the following issue:
http://bugs.python.org/issue16850

Drawbacks of my idea/patch:

- my patch raises NotImplementedError if the platform doesn't support
close-and-exec flag. I tested Linux, OpenBSD, FreeBSD, OpenIndiana
(Solaris) and Mac OS X: my patch works on all these platforms (except
OpenBSD 4.9 because of an OS bug fixed in OpenBSD 5.2). I don't know
platform without this flag.

- my patch raises an error if opener argument of open() is used:
opener and the "e" mode are exclusive (see the issue for details)

---

I first proposed to only expose the atomic close-and-exec option, but
only a few platforms (Linux 2.6.23+, FreeBSD 8.3+, Windows, QNX)
support it. It's more convinient to have the best-effort method (only
atomic if available).

This article of Ulrich Drepper explain which kind of problem are
solved by O_CLOEXEC:
http://udrepper.livejournal.com/20407.html

Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Add "e" (close and exec) mode to open()

2013-01-07 Thread Benjamin Peterson
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 it's worth cluttering the open() interface with such a
non-portable option. People requiring such control should use the
low-level os.open interface.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Add "e" (close and exec) mode to open()

2013-01-07 Thread Benjamin Peterson
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 version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider
>> > that such flag would be interesting?
>>
>> I'm not sure it's worth cluttering the open() interface with such a
>> non-portable option. People requiring such control should use the
>> low-level os.open interface.
>
>
> The ability to supply such flags really belongs on _all_ high or low level
> file descriptor creating APIs so that things like subprocess_cloexec_pipe()
> would not be necessary:
> http://hg.python.org/cpython/file/0afa7b323abb/Modules/_posixsubprocess.c#l729

I think the open() interface should have consistent and
non-conditional support features to the maximum extent possible. The
recent addition of "x" is a good example I think. The myriad cloexec
APIs between different platforms suggests to me that using this
features requires understanding its various quirks on different
platforms.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Add "e" (close and exec) mode to open()

2013-01-07 Thread Zbigniew Jędrzejewski-Szmek
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_NOINHERIT. Do you consider
> > that such flag would be interesting?
Having close-on-exec makes the code much cleaner, often. Definitely
interesting.

> I'm not sure it's worth cluttering the open() interface with such a
> non-portable option. People requiring such control should use the
> low-level os.open interface.
If the best-effort fallback is included, it is quite portable. Definitely
all modern and semi-modern systems support either the atomic or the
nonatomic methods.

Zbyszek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Add "e" (close and exec) mode to open()

2013-01-07 Thread 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 version: O_CLOEXEC, FD_CLOEXEC and O_NOINHERIT. Do you consider
> > that such flag would be interesting?
>
> I'm not sure it's worth cluttering the open() interface with such a
> non-portable option. People requiring such control should use the
> low-level os.open interface.
>

The ability to supply such flags really belongs on _all_ high or low level
file descriptor creating APIs so that things like subprocess_cloexec_pipe()
would not be necessary:
http://hg.python.org/cpython/file/0afa7b323abb/Modules/_posixsubprocess.c#l729

I'm not excited about raising an exception when it isn't supported; it
should attempt to get the same behavior via multiple API calls instead
(thus introducing a race condition for threads+fork+exec, but there is no
choice at that point and it is what most people would want in that
situation regardless). Not being supported will be such an extremely rare
situation for any OS someone runs a Python 3.4 program on that that detail
is pretty much a non-issue either way as far as I'm concerned.

-gps
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] FYI - wiki.python.org compromised

2013-01-07 Thread Brian Curtin
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 instance data for both the Python and Jython
wikis. The attack also had full access to all MoinMoin user data on
all wikis. In light of this, the Python Software Foundation encourages
all wiki users to change their password on other sites if the same one
is in use elsewhere. We apologize for the inconvenience and will post
further news as we bring the new and improved wiki.python.org online.

If you have any questions about this incident please contact
jnol...@python.org. Thank you for your patience.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] PEP 431 Time zone support improvements - Update

2013-01-07 Thread Alexander Belopolsky
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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] FYI - wiki.python.org compromised

2013-01-07 Thread Aluísio Augusto Silva Gonçalves
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 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 instance data for both the Python and Jython
> wikis. The attack also had full access to all MoinMoin user data on
> all wikis. In light of this, the Python Software Foundation encourages
> all wiki users to change their password on other sites if the same one
> is in use elsewhere. We apologize for the inconvenience and will post
> further news as we bring the new and improved wiki.python.org online.
>
> If you have any questions about this incident please contact
> jnol...@python.org. Thank you for your patience.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com