Re: [Python-Dev] More compact dictionaries with faster iteration
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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/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/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()
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()
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
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
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
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