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
jnoller(a)python.org. Thank you for your patience.
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
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.
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).
While trying 3.3 beta I found that I cannot use my favorite virtualenv pattern with pyvenv:
$ virtualenv .
$ pyvenv .
Error: Directory exists: /Users/stefan/sandbox/foo
I appreciate that this behavior is documented and was in the PEP from the start:
"If the target directory already exists an error will be raised, unless the --clear or --upgrade option was provided."
Still, I am curious what the rationale behind this restriction is. For me, being able to "bless" an existing directory with a virtualenv has always been one of its attractions.
Stefan H. Holek
On Sun, 6 Jan 2013 08:25:44 +0100 (CET)
nick.coghlan <python-checkins(a)python.org> wrote:
> changeset: 4654:3eb7e4b587da
> user: Nick Coghlan <ncoghlan(a)gmail.com>
> date: Sun Jan 06 17:22:45 2013 +1000
> Updates in response to Barry Warsaw's feedback
> pep-0432.txt | 217 ++++++++++++++++++++++++++------------
> 1 files changed, 146 insertions(+), 71 deletions(-)
> diff --git a/pep-0432.txt b/pep-0432.txt
> --- a/pep-0432.txt
> +++ b/pep-0432.txt
> @@ -40,19 +40,21 @@
> well-defined phases during the startup sequence:
> * Pre-Initialization - no interpreter available
> -* Initialization - interpreter partially available
> -* Initialized - full interpreter available, __main__ related metadata
> +* Initializing - interpreter partially available
> +* Initialized - interpreter available, __main__ related metadata
> -* Main Execution - optional state, __main__ related metadata populated,
> - bytecode executing in the __main__ module namespace
> +* Main Execution - __main__ related metadata populated, bytecode
> + executing in the __main__ module namespace (embedding applications
> + may choose not to use this phase)
Since we are here, I would bikeshed a little and point out that
"initializing" and "initialiazed" are states, not phases. Either way,
the nomenclature should be consistent.
Dear python-dev *and* python-ideas,
I am posting PEP 3156 here for early review and discussion. As you can
see from the liberally sprinkled TBD entries it is not done, but I am
about to disappear on vacation for a few weeks and I am reasonably
happy with the state of things so far. (Of course feedback may change
this. :-) Also, there has already been some discussion on python-ideas
(and even on Twitter) so I don't want python-dev to feel out of the
loop -- this *is* a proposal for a new standard library module. (But
no, I haven't picked the module name yet. :-)
There's an -- also incomplete -- reference implementation at
http://code.google.com/p/tulip/ -- unlike the first version of tulip,
this version actually has (some) unittests.
Let the bikeshedding begin!
(Oh, happy holidays too. :-)
--Guido van Rossum (python.org/~guido)
I submitted a simple patch for updates to IDLE's documentation http://bugs.python.org/issue5066 and it has not been reviewed by an official Python developer. Since it is now been over 1month since last update can somebody please review and or commit? I did get some comments from another contributor and updated the patch based on those comments. The original bug was opened in 2009 and the IDLE documentation is out of date with undocumented menu options and inconsistencies between the help file and the HTML documentation. I hate to be pushy but I would like to see some progress made on IDLE. Thanks for the support.
Sent from my iPad
I'm writing a static language analyzer for an IDE which reuses the
CPython parser (for parsing) . Two years ago, I asked about a few
changes to be made to the AST provided by CPython, but the discussion
thread dried up before a definite decision was made. I decided to just
copy the parser code to my project and make the necessary changes
there back then. I'm bringing this up again now since after my project
has seen its first release recently, packagers are (understandably) a
bit unhappy about the python fork residing in its repository. I would
really like to get rid of that fork and link against the vanilla
There's two things which are at the very least required to make this work:
1. The col_offset and lineno of an Attribute must give the beginning
of the word that names the attribute, not the beginning of the
expression. Example: In "foo.bar.baz", the col_offset of the Attribute
belonging to "bar" says "0" currently, it would need to be "4".
2. Column offsets and line numbers would need to be available for
function arguments (those with and without stars), and for alias
In total, this requires very little change to the existing code, "a
few tens of lines changed at most" order of magnitude; those are
mostly trivial changes.
For what I can tell, the impact on existing code using the AST stuff
will be about zero. Even if there was some really obscure case where
the change would matter, porting would only require about three lines
of python code.
Additionally, there's a few more things which would be useful to have
available from the AST (namely the ranges of class and function names
when they are defined -- currently only the start of the first
decorator is available), but since those are reasonably easy to work
around it's not that important. It would still be nice tough.
If you think this is a reasonable suggestion then I'll be happy to
provide a patch for more detailed discussion.
 See https://projects.kde.org/kdev-python