New submission from Lars :
I noticed some (perhaps intentional) oddities with the __name__ attribute:
- typing classes like Any (subclass of _SpecialForm) do not have a __name__
attribute,
- abstract base classes in typing, like MutableSet do not have a __name__
attribute,
- 'Cha
Lars added the comment:
I have been doing some research, but note that I don't have much experience
with the typing module. That said, there seem to be 2 main cases:
- '_SpecialForm': with instances Any, Union, etc.
- '_BaseGenericAlias'/'_SpecialGenericAl
Lars added the comment:
Happy to see progress on this issue and I can see that adding these attributes
to the ABC's in typing makes the most sense. However for my direct use-case
(simplified: using Any in a type checking descriptor) it would be really
practical to have the __name__
New submission from Lars :
Hi everybody
I just noticed that the uuid.uuid4().hex command does not create fully random
hex values. The character on the 13th position is always 4 and the 17th
position is equally distributed 8,9,a,b.
One million uuids follow following distribution.
{&#
Lars added the comment:
Ok that makes sense. Thanks for letting me know. Should have read the doku more
precisely.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Lars added the comment:
in my project i need to be able to let the user dynamically make and
remove inheritance relationships between classes and in my testing i
think i have run into this issue assigning to __bases__. the
class object(object):
pass
trick seems to work, but i can't r
Lars added the comment:
ok, i see what you mean, for me at this time the most important question
is whta does
class object(object)
pass
do, why can i change baseclasses after i redeclare object this way, and
will it get me into trouble when i use this to let users dynamically
define
Lars Gustäbel added the comment:
Closing this due to lack of interest. This is no tarfile issue. If
direct device addressing should be supported by Python, os.stat() would
be the place to implement it.
--
resolution: -> wont fix
status: open ->
New submission from Lars Gustäbel:
tarfile does not check pathnames or linknames on extraction. This can
lead to data loss or attack scenarios when members with absolute
pathnames or pathnames outside of the archive's scope overwrite or
overlay existing files or directories.
Example
Lars Gustäbel added the comment:
In principle I do not object, but this is a preliminary patch. I am
still not happy with the naming of the "check_paths" argument. Also, the
patch was made against the trunk which means that it contains hunks with
the new reStructuredText documentation.
New submission from Lars Gustäbel:
For example in tarfile.rst and logging.rst there are function
definitions using *args and/or **kwargs like:
.. function:: debug(msg[, *args[, **kwargs]])
The * and ** should be escaped IMO, so that they are not mistaken as
reStructuredText markup, which
Lars Gustäbel added the comment:
After careful consideration and a private discussion with Martin I do no
longer think that we have a security issue here. tarfile.py does nothing
wrong, its behaviour conforms to the pax definition and pathname
resolution guidelines in POSIX. There is no known or
Lars Gustäbel added the comment:
I updated the documentation, r57764 (trunk) and r57765 (2.5).
--
resolution: -> works for me
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Lars Gustäbel:
When rebuilding parts of the documentation the search index is emptied.
The problem is that the extensions are not stripped from the filenames
that are given to IndexBuilder.prune() method.
Therefore, the Search widget on http://docs.python.org/dev/3.0
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue12800>
___
___
Python-bugs-list mailing list
Un
Lars Gustäbel added the comment:
Attached is a patch with the current state of my work on lzma integration into
tarfile (17 test errors).
--
assignee: -> lars.gustaebel
keywords: +patch
Added file: http://bugs.python.org/file23162/2011-09-15-tarfile-lzma.d
Lars Gustäbel added the comment:
Today I played around with lzma support for tarfile based on your last patch
(see issue5689). There are a few minor issues that I just wanted to mention, as
they break the tarfile testsuite:
- LZMAFile does not expose a name attribute. BZ2File doesn't e
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
priority: normal -> low
versions: +Python 3.3 -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/i
New submission from Lars Buitinck :
I've found some counterintuitive behavior in collections.Counter while hacking
on the scikit-learn project [1]. I wanted to use a bunch of Counters to do some
simple term counting in a set of documents, roughly as follows:
count_total = Counter()
Lars Buitinck added the comment:
If this is not implemented because it is backwards incompat, then it might be
useful to add a note to update's docstring explaining that it is much more
efficient than +=. I was very surprised that it took *minutes* to add a few
thousand moderate-
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Lars Gustäbel added the comment:
Thanks for the report. There was a problem decoding a special and rare kind of
header field in the archive. The format of the archive is of very bad quality
BTW ;-)
--
resolution: -> fixed
stage: -> committed/rejected
status: open -&g
Lars Gustäbel added the comment:
Some testing reveals that the bz2 module < 3.3 cannot fully decompress the file
in question. Only the first 900k are decompressed. Thus, this issue is not
related to issue13158 or the tarfile module.
--
nosy: +lars.gustae
Lars Gustäbel added the comment:
This is no bad idea. I recommend keeping it as simple as possible. I would
definitely not be supportive of a full tar clone. List, extract, create - that
should be enough. There are two possible command line choices: do what the
zipfile module does or emulate
Lars Gustäbel added the comment:
I will be happy to, but my spare time is limited right now, so this could take
about a week. If this is a problem, please go ahead.
--
___
Python tracker
<http://bugs.python.org/issue5
Lars Gustäbel added the comment:
For those who want to test it first, I post the current state of the patch
here. It is ready for commit, there are no failing tests. If nobody objects, I
will apply it this weekend.
--
Added file: http://bugs.python.org/file23880/2011-12-08-tarfile
Lars Gustäbel added the comment:
Thanks for the review, guys! I can't close this issue yet because it depends on
#6715.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
___
Python tracker
<http://bugs.python
Lars Gustäbel added the comment:
Please, go ahead!
--
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lars Gustäbel added the comment:
Is there a good reason why the tarfile mode that is used is "w|gz"? It seems to
me that this is not necessary, "w:gz" should be enough. "w|gz" is for special
operations only (see the tarfile docs).
--
nosy: +l
Lars Gustäbel added the comment:
tarfile under Python 2.x is not particularly designed to support unicode
filenames (the gzip module does not support them either), but that should not
be too hard to fix.
--
keywords: +patch
Added file:
http://bugs.python.org/file24066/tarfile-stream
Lars Gustäbel added the comment:
Just for the record:
The gzip format (defined in RFC 1952) allows storing the original filename
(without the .gz suffix) in an additional field in the header (the FNAME
field). Latin-1 (iso-8859-1) is required. It is ironic that this causes so much
trouble
Lars Gustäbel added the comment:
See http://bugs.python.org/issue11638#msg150029
--
___
Python tracker
<http://bugs.python.org/issue13639>
___
___
Python-bug
Lars Gustäbel added the comment:
Wouldn't it be better then to use a default compresslevel of 6 in tarfile? I
used level 9 in my patch without a particular reason, just because I thought 9
must be better than 6 ;-)
--
Added file: http://bugs.python.org/file24084/lzma-preset
Changes by Lars Gustäbel :
Removed file: http://bugs.python.org/file24084/lzma-preset.diff
___
Python tracker
<http://bugs.python.org/issue5689>
___
___
Python-bugs-list m
Lars Gustäbel added the comment:
Yes, that's much better. Thanks for the tip.
--
Added file: http://bugs.python.org/file24086/lzma-preset.diff
___
Python tracker
<http://bugs.python.org/i
Lars Gustäbel added the comment:
I thought about that myself, too. It is clearly no new feature, it is really
more some kind of a fix.
Unicode pathnames given to tarfile.open() are just passed through to the open()
function, which is why this always has been working, except for this
Lars Gustäbel added the comment:
I think we should wrap this up as soon as possible, because it has already
absorbed too much of our time. The issue we discuss here is a tiny glitch
triggered by a corner-case. My original idea was to fix it in a minimal sort of
way that is backwards
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Lars Gustäbel added the comment:
You actually hit two bugs at the same time here: The target of the created
symlink was not translated from unix to windows path delimiters and is
therefore broken. The second bug is issue12926 which leads to the error in
TarFile.makefile().
Brian, AFAIK all
Lars Gustäbel added the comment:
The dereference option is only used for archive creation, so the contents of
the file a symbolic link is pointing to is added instead of the symbolic link
itself.
--
___
Python tracker
<http://bugs.python.
Lars Gustäbel added the comment:
This should be fixed now, thanks.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.3
___
Python tracker
<http://bugs.python.or
New submission from Lars Wirzenius :
Attached patch adds a few words to the os.stat documentation for the st_blocks
and st_blksize fields to clarify them.
--
assignee: docs@python
components: Documentation
files: stat_result.patch
keywords: patch
messages: 138467
nosy: docs@python, liw
Lars Wirzenius added the comment:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html says "A
file system-specific preferred I/O block size for this object. In some file
system types, this may vary from file to file.", which says essentially the
same as the Li
Lars Wirzenius added the comment:
Right. So I guess at least the following should be changed (I'll make an actual
patch once there's consensus):
* st_blocks should say that the size of block is often 512 bytes, but that's
not guaranteed, and there's no way to know fo
Lars Gustäbel added the comment:
The patch is fine. Thank you very much for it, Sebastien. I think we have to go
without a unit test.
--
___
Python tracker
<http://bugs.python.org/issue12
Lars Gustäbel added the comment:
Yes, it should be fixed in all affected branches.
--
___
Python tracker
<http://bugs.python.org/issue12841>
___
___
Python-bug
Lars Gustäbel added the comment:
Yes, I can do that as soon as I've managed to wrap my head around using
Mercurial and the new way of developing Python. I have been away from Python
programming for quite some time and haven't adapted my wo
Lars Gustäbel added the comment:
Issue #12841 is a duplicate of this one, but I give it precedence because it
comes with a working patch.
--
resolution: -> duplicate
status: open -> closed
versions: +Python 2.7, Python 3.3
___
Python t
Changes by Lars Gustäbel :
--
versions: +Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue12841>
___
___
Python-bugs-list mailing list
Unsub
Lars Gustäbel added the comment:
Close as fixed. Thanks all!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Lars Gustäbel added the comment:
It's the low-level operating system aspects of tarfile that are very difficult
to test, e.g. filesystem and operating system dependent features such as
symbolic links, hard links, file permissions, ownership. It is not even
possible to reliably determin
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue12926>
___
___
Python-bugs-list mailing list
Un
Lars Gustäbel added the comment:
Fixed in r85211 (py3k), r85212 (release31-maint), r85213 (release27-maint).
Thank you for the report.
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
type: -> behavior
__
Lars Gustäbel added the comment:
The patch goes a bit too far. Though it solves this particular problem with the
way TarFile.extractall() works, it breaks TarFile.extract(). Running the
testsuite does not expose this, simply because there's no testcase :-(
Please see the attached testc
Lars Gustäbel added the comment:
I'm not entirely happy with the name of the "touch" argument. Apart from it
being nice and short, I think it's a little too unix-y and might be misleading
because it is not only about setting the modification time as the name implies,
but
Lars Gustäbel added the comment:
I assume you're using Python 2.x. because tarfile's memory footprint was
significantly reduced in Python 3.0, see the patch in issue2058 and r62337.
This patch was not backported to the 2.x branch back then. As the 2.x branch
has been closed for ne
Lars Gustäbel added the comment:
Apparently you were in quite a hurry when you filed this bug report.
- What is the exact problem and how does it manifest itself?
- Any helpful details (tracebacks, output)?
- Is there a testcase or example code you can provide?
- Which other tools are you
Lars Gustäbel added the comment:
Hm, why don't you just do this:
with stat_tarfile.open(fileobj = sys.stdout, mode = "w|") as tar:
for number in xrange(100):
fileobj = generate_file_content(number)
tarinfo = tar.gettarinfo(fileobj=open("/etc/passwd"
Lars Gustäbel added the comment:
This behaviour is intentional. A tar archive does not contain a central
directory structure, it is just a chain of files. As a side-effect it is
possible to have multiple files with the same name in one archive, e.g. when
append mode was used. That's wh
Lars Gustäbel added the comment:
Thanks for your great report. This is fixed now in r88528 (py3k) and r88529
(release32-maint).
--
keywords: +3.2regression
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
versions: +P
Lars Gustäbel added the comment:
If I understand correctly, the solution to your problem would be to use the
stream mode "w|" instead of "w". Could you please try that?
--
assignee: -> lars.gustaebel
___
Python tracker
Changes by Lars Gustäbel :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Lars Gustäbel added the comment:
I kept this issue open, because I have not yet come to a decision. I don't
think the current behaviour is a bug, but these kinds of errors could be
handled more intelligently.
For example, errors during extraction can be hidden depending o
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue11787>
___
___
Python-bugs-list mailing list
Un
Lars Gustäbel added the comment:
Good point. Do you happen to have a working implementation already?
--
assignee: -> lars.gustaebel
priority: normal -> low
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/i
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
priority: normal -> low
___
Python tracker
<http://bugs.python.org/issue11879>
___
___
Pyth
New submission from Lars Michelsen :
Hello Devs,
digging around in the python manpage and playing with the parameters I found a
wrong parameter specification in the python manpage. The -OO parameter for
discarding docstrings is written as -O0 (the 2nd is a zero).
A patch is attached
Lars Gustäbel added the comment:
Okay, this bug has been fixed in the 2.7 series. Python 2.6 is now in
security-fix-only mode which means that there will not be a fix for it.
Therefore, I close this issue.
--
resolution: -> fixed
status: open -> closed
versions: +Python 2.6 -
Lars Gustäbel added the comment:
There is no trivial or backwards-compatible solution to this problem. The way
it is now, there is no alternative to storing all TarInfo objects: there is no
central table of contents in an archive we could use, so we must create our
own. In other words
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
components: +Library (Lib) -None
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issu
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue10761>
___
___
Python-bugs-lis
Lars Gustäbel added the comment:
_FileInFile.read() does lots of unnecessary seeking and reads the same block
again and again. The attached patch fixes that. Please try if it works for you.
--
assignee: -> lars.gustaebel
keywords: +patch
Added file: http://bugs.python.org/file20
Lars Gustäbel <[EMAIL PROTECTED]> added the comment:
With some effort I could reproduce the problem (on a FAT32 filesystem),
but what we have here is clearly a usage problem. In unpack_tarfile() in
setuptools/archive_util.py TarFile's internal _extract_member() method
is used to
Changes by Lars Gustäbel <[EMAIL PROTECTED]>:
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Lars Gustäbel <[EMAIL PROTECTED]> added the comment:
Thank you very much for your patch, I applied it to the trunk as r65402.
However, I decided to remove the TarFileCompat class from the Python 3.0
branch, see
http://mail.python.org/pipermail/python-3000/2008-July/014448.html for
d
Lars Gustäbel <[EMAIL PROTECTED]> added the comment:
This problem existed only in the first 2.5 release.
--
resolution: -> works for me
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Lars Gustäbel <[EMAIL PROTECTED]> added the comment:
The patch is okay. Go ahead.
BTW, I've never used Cygwin before, is it always that slow? 10 minutes
for a configure script on a recent machine is a real pain.
--
nosy: +lars.gustaebel
___
Lars Gustäbel added the comment:
So, use the pax format. It stores the filenames as utf-8 and this way you will
be on the safe side.
I hope we both agree that the solution to your particular problem is nothing
tarfile.py can provide. So, I am going to close this issue now
Lars Gustäbel added the comment:
Another version of the patch (issue7232.6.diff) that checks if the TarFile
object is still open in the __enter__() method (plus a test for that). I
removed the docstrings as Eric suggested. This is common practice in the
standard library.
--
Added
Lars Gustäbel added the comment:
IMO it is okay for __enter__() and __exit__() not to have docstrings.
I cannot see what's so special about the behaviour of __enter__() and
__exit__().
__enter__() raises IOError only if the TarFile object has been already closed.
This is exactl
Lars Gustäbel added the comment:
I found an issue that needs to be addressed: if there is an error while the
TarFile object is opened for writing, we cannot simply call TarFile.close() in
the __exit__() method. close() would try to finalize the archive, i.e. write
two zero end-of-archive
Lars Gustäbel added the comment:
Okay, it is done, see r78623 (trunk) and r78626 (py3k).
Thanks to all for your work and support!
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Lars Gustäbel :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue7232>
___
___
Python-bugs-list mai
Lars Gustäbel added the comment:
0666 is the right mode and the patch is correct.
@Tarek: Why does shutil.make_archive() use mode "w|..." instead of "w:..."?
IMHO that is not necessary, because it works on regular files only.
--
__
Lars Gustäbel added the comment:
I applied the patch and added a test case (see r80616-r80619). Thanks for the
report.
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Lars Gustäbel added the comment:
Yes, I will soon have ;-) Please give me a few days...
--
___
Python tracker
<http://bugs.python.org/issue8390>
___
___
Pytho
Lars Gustäbel added the comment:
I think it is a good suggestion to use "surrogateescape" as the default,
because (I hope) it produces the fewest errors and is the best choice if
tarfile is used in connection with Python's filesystem calls.
- When reading tar headers, undec
Lars Gustäbel added the comment:
Victor, you misunderstood the pax definition, but it wouldn't harm tarfile if
it knew how to handle these corrupt GNU tar archives. In the meantime I filed a
bug report on bug-...@gnu.org for this.
I said in msg105085 that POSIX gives no advice on h
Lars Gustäbel added the comment:
I am currently working on a patch to let tarfile use the hdrcharset field.
--
___
Python tracker
<http://bugs.python.org/issue8
Changes by Lars Gustäbel :
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue8701>
___
___
Python-bugs-lis
Lars Gustäbel added the comment:
Unfortunately, I cannot reproduce your problem and ask you to please provide
more information. Would it be possible to attach the output or a screenshot
depicting the problem? Which operating system/distribution do you use? Have you
double-checked your
Changes by Lars Gustäbel:
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1531>
__
___
Python-bu
Lars Gustäbel added the comment:
I fixed this in the trunk (r59260) and release25-maint branch (r59261).
Thanks for the report. If you cannot wait for the next release, I
recommend you use mode "r|" as a workaround.
BTW, 756 is absolutely no realistic example value for the posit
Changes by Lars Gustäbel:
--
assignee: -> lars.gustaebel
nosy: +lars.gustaebel
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1735>
__
___
Python-bu
Lars Gustäbel added the comment:
Committed to release25-maint branch as r59713.
--
resolution: -> accepted
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Lars Gustäbel added the comment:
Thanks for the patch. I added a testcase and applied it to the trunk,
see r59712. Python 2.5 follows later on.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Lars Gustäbel added the comment:
I close this issue because it is out of date. The new
TarFile.extractall() method in Python 2.5 provides a way to solve the
original problem IMO.
--
resolution: -> out of date
status: open -> closed
_
Tracker &
Lars Gustäbel added the comment:
I close this issue as there has been no progress over the last 1.5 year.
--
resolution: -> rejected
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
Lars Gustäbel added the comment:
I just did some tests and could not find any major difference. Which are
the differences you found?
BTW, in your patch the "dist" directory is not automatically created.
__
Tracker <[EMAIL PROTECTED]>
<htt
Lars Gustäbel added the comment:
Hm, on my Linux box both files are more or less identical. Sorry, I
cannot reproduce your problem.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
1 - 100 of 283 matches
Mail list logo
