Hello,
I am a newbie to this mailing list, i have seen in some mail discussions
about a tar archive creation by forcibly setting the UID/GID to a specific
user (say root).
Te code mentioned goes like this:
tar = tarfile.open("foo.tar.gz", "w:gz")
for filename in filenames:
tarinfo = tar.gettarinfo(filename)
if tarinfo.isreg():
fobj = open(filename)
else:
fobj = None
tarinfo.uid = 0
tarinfo.gid = 0
tar.addfile(tarinfo, fobj)
tar.close()
But this is not really working for me as when i am trying to un-tar or
un-compress contents to a new directory and contents still have diff GID &
UID in the long listing of directory.
Can somebody suggest an alternative or a working case if already changes are
done here.
Thanks in advance.
Best regards,
Bheemesh
I thought it might be useful for those who don't have time to read a
million posts to have a summary of what's happened in the formatting
discussion.
The basic problem is that many APIs in the standard library and
elsewhere support only %-formatting and not {}-formatting, e.g.
logging.Formatter accepts::
logging.Formatter(fmt="%(asctime)s - %(name)s")
but not::
logging.Formatter(fmt="{asctime} - {name}")
There seems to be mostly agreement that these APIs should at least
support both formatting styles, and a sizable group (including Guido)
believe that %-formatting should eventually be phased out (e.g. by
Python 4). There are a number of competing proposals on how to allow
such APIs to start accepting {}-format strings:
* Add a parameter which declares the type of format string::
logging.Formatter(fmt="{asctime} - {name}", format=BRACES)
The API code would then switch between %-format and {}-format
based on the value of that parameter. If %-formatting is to be
deprecated, this could be done by first deprecating
format=PERCENTS and requiring format=BRACES, and then changing the
default to format=BRACES.
* Create string subclasses which convert % use to .format calls::
__ = brace_fmt
logging.Formatter(fmt=__("{asctime} - {name}"))
The API code wouldn't have to change at all at first, as applying
% to brace_fmt objects would call .format() instead. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring brace_fmt strings, and
then allowing plain strings again but assuming they are {}-format
strings.
* Teach the API to accept callables as well as strings::
logging.Formatter(fmt="{asctime} - {name}".format)
The API code would just call the object with .format() style
arguments if a callable was given instead of a string. If
%-formatting is to be deprecated, this could be done by first
deprecating plain strings and requiring callables, and then
allowing plain strings again but assuming they are {}-format
strings
* Create translators between %-format and {}-format::
assert to_braces("%(asctime)s") == "{asctime}"
assert to_percents("{asctime}") == "%(asctime)s"
these could then either be used outside of the API::
logging.Formatter(fmt=to_percents("{asctime} - {name}"))
or they could be used within the API combined with some sort of
heuristic for guessing whether a {}-format string or a %-format
string was passed in::
logging.Formatter(fmt="{asctime} - {name}")
If %-formatting is to be deprecated, the transition strategy here
is trivial. However, no one has yet written translators, and it is
not clear what heuristics should be used, e.g. should the method
just try %-formatting first and then {}-formatting if it fails?
I don't think there is consensus yet on which of these proposals
should be the "blessed" one.
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
At 11:21 AM 10/5/2009 -0700, Brett Cannon wrote:
>I have to admit I find it really disheartening that we are letting
>an unmaintained project dictate how we fix a bug.
Setuptools was not the only project broken by this change. See:
http://bugs.python.org/issue7020#msg93355
Apparently, I'm not the only person who read the get_ext_filename()
docstring that way, and subclassed build_ext in a way that broke
it. (In this case, it was pywin32.)
IMO, the fact that it broke Pywin32 in 2.6.3rc1 should have been
considered evidence that the change was not suitable for a bugfix release.
At 04:17 PM 10/5/2009 +0200, Tarek Ziadé wrote:
>Now I am astonished that we are talking about reverting changes in
>Distutils that were done for bugfixes, for a third party package that
>does monkey patches on Distutils.
Subclassing is not monkeypatching, so if you consider the above to be
a general policy, then the developers of at least Numpy and Twisted
should consider themselves warned that bugfix releases may break
their build processes.
The first (and hopefully last) release candidate for Python 2.6.3 is
now available via
http://www.python.org/download/releases/2.6.3/
Source releases and Windows binaries are currently available, and Mac
OS X binaries should be forthcoming.
Nearly 100 bugs have been fixed since 2.6.2. Barring any unforeseen
problems, we will make the final 2.6.3 release this Friday, October
2nd. Please give this release candidate a spin and let us know if you
encounter any show stopping problems.
Enjoy,
-Barry
Interested in the recent threads about % and str.format(), I wrote a
little Python 3 script that converts % format strings to format
strings compatible with str.format(). I invite you to try it out. The
code is at https://code.launchpad.net/~gutworth/+junk/mod2format (That
means you can do "bzr branch lp:~gutworth/+junk/mod2format".) It
should basically work except for some obscure cases like "%#.0f".
--
Regards,
Benjamin
What real status of this document?
As I figured out py3k trunk uses this ones.
Most part of 'battery included' modules don't use this feature,
leaving m_traverse, m_clear and m_free NULL pointers.
There are only exception: _io.
But looks like all underground python machinery is already ported to
support PEP.
Maybe it's good point to update PEP?
"accepted; may not be implemented yet" sounds a bit confusing.
Just insert somethere close to top of content: "Implemented by Python
itself, but builtin modules should be converted".
Next question: are where all 'python standard library' modules looks
like "not converted yet" really need to be refactored?
Or we can split this huge set to 'looks already good' and 'requires some work'?
And just add comment for every PyModuleDef definition like:
"Completely satisfy PEP 3121, signed and stamped by Martin von Loewis
and GvR".?
Last question: PEP refers to "multiple interpreters" feature of python.
This feature presented at least in 2.xx branch (don't remember about
1.xx - up to 2003 I used python as scripting language only and not
care about C interface).
I never saw usage of this one in real use cases.
Is there projects (preferable with code sources, of course) what runs
multiple interpreter in same process?
On behalf of the Python community, I'm happy to announce the
availability of Python 2.6.3. This is the latest production-ready
version in the Python 2.6 series. Somewhere near 100 bugs have been
fixed since Python 2.6.2 was released in April 2009. Please see the
NEWS file for all the gory details.
http://www.python.org/download/releases/2.6.3/NEWS.txt
Source tarballs, Windows installers and the Mac OS X disk image can be
downloaded from the Python 2.6.3 page.
http://www.python.org/download/releases/2.6.3/
For more information on Python 2.6 in general, please see
http://docs.python.org/whatsnew/2.6.html
Please report bugs for any Python version in the Python tracker.
http://bugs.python.org
Enjoy,
-Barry
Barry Warsaw
barry(a)python.org
Python 2.6 Release Manager
(on behalf of the entire python-dev team)
At 05:15 PM 9/30/2009, Yuvgoog Greenle wrote:
>I like how python has a minimalistic and powerful syntax (-1 for the
>break ___ PEP).
>
>Also, I really dislike the for/else ambiguity "butterflies".
>
>When is the else after a loop executed?
>1. When the loop isn't entered at all.
>2. When the loop terminates through exhaustion of the list (does
>this include when the list was empty?)
>3. When the loop didn't exit because of a break statement.
>
>HINTS: The way django does it is opposite the way python does it and
>there may be more than one correct answer.
Django's template language does not have for/else, it has for/empty:
<http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty>http://docs.djangoproject.com/en/dev/ref/templates/builtins/#for-empty
This construct did come from an external snippet that used 'else'
instead of 'empty'. However when it was integrated into Django the
'else' name was specifically rejected because it did the opposite of
what for/else does in Python.
Karen
