I'd like to escalate http://bugs.python.org/issue12226 : 'use secured
channel for uploading packages to pypi' to be shipped with next Python
This will prevent pydotorg password sniffing when submitting packages
through public networks (such as hotels).
before opening an issue to track the request, I'd like to ask advice
here about this: extend os.chown() to accept even user/group names
instead of just uid and gid.
On a Unix system, you can call chown command passing either id or
names, so it seems (to me at least) natural to expect os.chown() to
behave similarly; but that's not the case.
I can see os module wants to be a thin wrapper around OS syscalls and
chown(2) accepts only uid/gid as input, so what would be best: extend
os.chown() or provide a chown() function in shutil module for this
Thanks in advance,
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
The docs were not added alongside the code when packaging was merged
back into CPython because they were not in a shape conforming with the
rest of the docs. I’d like your input on layout so that I can fix this
ASAP and merge the docs. (They would still require a lot of additions,
fixes and improvements after that, but at least they’d be in the repo.)
The easiest part is the library documentation, i.e. the docs for
developers of packaging-related tools that want to use for example
packaging.version or packaging.metadata to do their own stuff. These
documents should go into Doc/library/packaging.*, I think this is a
no-brainer. (Distutils has only a stub here, its API docs is mixed
its usage docs.)
There is a guide for end-users, which contains an outdated copy of the
old “Installing Python Modules” and a few documents about the new
pysetup script (superseder of setup.py scripts), which are not
integrated with the first document. I think those should supersede the
existing distutils-based Doc/install tree. We want to advertise
and packaging as the way of gettting modules in 3.3. A question
remains: is it worthwhile to keep the old document somewhere?
Last but not least, the doc for authors wanting to package and
distribute their project (“Distributing Python Modules”,
I think we should not overwrite this directory, because the directory
name is tied to distutils and because there will be users needing that
documentation (distutils is not removed). So, is it okay to create a
new Doc/packaging directory and change the link on the docs front page
from distutils to packaging?
(Technical question: I think I’ll get a complaint from Sphinx that
distutils is not included in any toctree; I’ll try adding a toctree
library/distutils to distutils/index and see if that works.)
Thanks for reading
On Tue, May 31, 2011 at 7:04 AM, victor.stinner
> +.. function:: get_ident()
> + Return the 'thread identifier' of the current thread. This is a nonzero
> + integer. Its value has no direct meaning; it is intended as a magic cookie
> + to be used e.g. to index a dictionary of thread-specific data. Thread
> + identifiers may be recycled when a thread exits and another thread is
> + created.
That's not quite true - the Thread id isn't relinquished until the
Thread object itself is destroyed, rather than when the underlying
thread finishes execution (i.e. the lifecycle of a_thread.ident is the
same as that of id(a_thread)).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On 30.05.2011 17:54, Terry Reedy wrote:
> On 5/30/2011 6:25 AM, tarek.ziade wrote:
> Should not old_out be sys.stderr, since that is what you over-write and
>> + old_out = sys.stdout
>> + sys.stderr = StringIO()
>> + try:
>> + dist = self.run_setup('install_dist', '--prefix=' + self.root_dir)
>> + finally:
>> + sys.sterr = old_out
And even more importantly, shouldn't this be "sys.stderr" instead of "sys.sterr"?
Really, what happened to testing before you push?
On behalf of the Python development team, I'm happy to announce the immediate
availability of Python 2.7.2 release candidate 1.
2.7.2 is the second in bugfix release for the Python 2.7 series. 2.7 is the last
major verison of the 2.x line and will be receiving bug fixes while new feature
development focuses on 3.x.
2.7 includes many features that were first released in Python 3.1. The faster io
module, the new nested with statement syntax, improved float repr, set literals,
dictionary views, and the memoryview object have been backported from 3.1. Other
features include an ordered dictionary implementation, unittests improvements, a
new sysconfig module, auto-numbering of fields in the str/unicode format method,
and support for ttk Tile in Tkinter. For a more extensive list of changes in
2.7, see http://doc.python.org/dev/whatsnew/2.7.html or Misc/NEWS in the Python
To download Python 2.7.2rc1 visit:
The 2.7.2 changelog is at:
2.7 documentation can be found at:
This is a preview release. Assuming no major problems, 2.7.2 will be released in
two weeks. Please report any bugs you find to
benjamin at python.org
(on behalf of the entire python-dev team and 2.7.2's contributors)
On behalf of the Python development team, I'm happy as a swallow to announce a
release candidate for the fourth bugfix release for the Python 3.1
3.1.4 will the last bug fix release in the 3.1 series before 3.1. After 3.1.4,
3.1 will be in security-only fix mode.
The Python 3.1 version series focuses on the stabilization and optimization of
the features and changes that Python 3.0 introduced. For example, the new I/O
system has been rewritten in C for speed. File system APIs that use unicode
strings now handle paths with undecodable bytes in them. Other features include
an ordered dictionary implementation, a condensed syntax for nested with
statements, and support for ttk Tile in Tkinter. For a more extensive list of
changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in
the Python distribution.
This is a testing release. To download Python 3.1.4rc1 visit:
A list of changes in 3.1.4 can be found here:
The 3.1 documentation can be found at:
Bugs can always be reported to:
benjamin at python.org
(on behalf of the entire python-dev team and 3.1.4's contributors)
I'm now currently finishing my MsC and am thinking about enrolling
into the PhD program. I was wondering if any of you would like to
suggest me some research topic that could benefit the scientific
community, that might also result as a potential improvement for
I love everything that's web related (Django here) and software
engineering but I don't yet have any idea for a research topic that
would be relevant for a PhD so I'm completely open to suggestions.
Please contact me directly.
Tiago Boldt Sousa