vila-sf
added the comment:
Bill == Bill Janssen [EMAIL PROTECTED] writes:
Bill Bill Janssen added the comment:
Bill Fixed in 2.6.
Bill --
Bill resolution: - fixed
Bill status: open - closed
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
Georg Brandl added the comment:
Lars Gustäbel schrieb:
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
Georg Brandl added the comment:
Lars Gustäbel schrieb:
Lars Gustäbel added the comment:
Oh, I thought Emacs was an operating system, I didn't know you could
edit text files with it. You live and learn ;-)
I suspected that this was intentional. If you make backslash escaping
optional,
Georg Brandl added the comment:
The docs say (at least the development docs) that Unicode filenames must
be encoded to str before passing them to ZipFile.write().
(This issue will have to be solved differently for Py3k, I'll look into it.)
--
nosy: +georg.brandl
resolution: - wont fix
Georg Brandl added the comment:
Dupe of #1528802.
--
nosy: +georg.brandl
resolution: - duplicate
status: open - closed
superseder: - Turkish Character
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1193061
Georg Brandl added the comment:
If I'm not mistaken, i.upper() will never be LATIN CAPITAL LETTER I
WITH DOT ABOVE, regardless of the locale?
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
_
Georg Brandl added the comment:
This is the same issue you can see with
cStringIO.StringIO(uabc).getvalue(). This behavior will not be
changed, as per #1730114.
Marc-Andre: would it be okay to add an explicit str() call in the
StringIO calls in quopri_codec and uu_codec, so that non-ASCII
Georg Brandl added the comment:
Affects 2.5 only.
--
nosy: +georg.brandl
versions: +Python 2.5 -Python 2.6
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1709599
_
Georg Brandl added the comment:
Committed as rev. 57716.
--
assignee: facundobatista - georg.brandl
nosy: +georg.brandl
resolution: - accepted
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1680959
Ismail Donmez added the comment:
@George,
i.upper() WILL be I-with-a-dot-above in Turkish.i
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
_
___
Python-bugs-list
Marc-Andre Lemburg added the comment:
Georg: Yes, sure.
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue883466
___
Python-bugs-list mailing list
Unsubscribe:
Marc-Andre Lemburg added the comment:
Unassigning this.
Unless someone provides a patch to add context sensitivity to the
Unicode upper/lower conversions, I don't think anything will change.
The mapping you see in Python (for Unicode) is taken straight from the
Unicode database and there's
Ismail Donmez added the comment:
There is no need to unassign this, the bug is invalid.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
_
___
Python-bugs-list
New submission from Guido van Rossum:
The various caches in abc.py should be turned into weak sets so that the
caches don't keep the subclass objects alive forever.
--
messages: 55480
nosy: gvanrossum
severity: normal
status: open
title: ABC caches should use weak refs
versions: Python
Martin v. Löwis added the comment:
This is now fixed in r57720.
Using wide APIs would be possible through GetTimeZoneInformation,
however, then TZ won't be supported anymore (unless the CRT code to
parse TZ is duplicated).
--
nosy: +loewis
resolution: - fixed
status: open - closed
Kevin Ar18 added the comment:
Here's another bug report that talks about a 2GB file limit:
http://bugs.python.org/issue1189216
The diff offered there does not solve the problem; actually it's
possible that the diff may not have anything to do with fixing the
problem (though I'm not certain), but
toxik added the comment:
Minor note: The patch mixes tabs and spaces. AFAIK, PEP 7 says to use
four spaces when making new code, and follow suite in legacy, or convert it.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1686386
Martin v. Löwis added the comment:
I now see the problem. What you want to do cannot possibly work.
You are trying to create a string object that is larger than 2GB; this
is not possible on a 32-bit system (which I assume you are using). No
matter how you modify the read() function, it would
Changes by Martin v. Löwis:
--
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1039
__
___
Python-bugs-list mailing list
Unsubscribe:
Kevin Ar18 added the comment:
Just some thoughts
In posting about this problem elsewhere, it has been argued that you
shouldn't be copying that much stuff into memory anyways (though there
are possible cases for a need for that).
However, the question is what should the zipfile module do.
Kevin Ar18 added the comment:
So, just add an error to the module (so it won't crash)?
BTW, is Python 2.6 ready for use? I could use that feature now. :)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1060
__
Kevin Ar18 added the comment:
Maybe a message that says that strings on 32-bit CPUs cannot handle more
than 2GB of data; use the stream instead?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1060
__
jan matejek added the comment:
if that can be considered official stance, it's fine by me. feel free
to close the bug.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1044
__
___
Changes by Martin v. Löwis:
--
versions: +Python 3.0 -Python 2.6
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1675334
_
___
Python-bugs-list mailing list
Changes by Martin v. Löwis:
--
versions: +Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1001
__
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
On 8/30/07, Thomas Wouters [EMAIL PROTECTED] wrote:
Thomas Wouters added the comment:
Here's a working version of that idea, with a WeakSet implementation I
had lying around (but never really used.) It seems to work, and fixes
the refcount issues, but
Changes by Martin v. Löwis:
--
versions: +Python 3.0
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1463370
_
___
Python-bugs-list mailing list
Unsubscribe:
Martin v. Löwis added the comment:
The patch looks fine to me, please apply.
--
assignee: loewis - georg.brandl
resolution: - accepted
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1753395
_
Changes by Guido van Rossum:
--
priority: immediate - normal
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1467929
_
___
Python-bugs-list mailing list
Thomas Heller added the comment:
Applied in rev. 57731.
--
resolution: accepted - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1039
__
___
Bill Janssen added the comment:
The new SSL code does work with self-signed certs, either by skipping
validation with CERT_NONE, or by adding the cert to the ca_certs file. I
don't believe there are any other options that make sense, but if you can
suggest one, let's hear it.
New submission from Bill Janssen:
It would be useful to have a way to determine whether a socket is or is
not already bound to a local port (i.e., has had bind or connect
called on it). It's tempting to call socket.socket.getsockname(), but
the behavior of this method is essentially
Collin Winter added the comment:
orsenthil: that this will break external modules is completely
acceptable. Those modules won't work out-of-the-box with Python 3
anyway, and hopefully Paul's patch to 2to3 will alleviate some of the
burden.
--
nosy: +collinwinter
Bill Janssen added the comment:
What happened to my issue metadata?
--
assignee: - janssen
priority: - low
title: None - nice to have a way to tell if a socket is bound
type: - rfe
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
Thomas Heller added the comment:
Set to accepted. As pointed out in private email, please apply it to
the trunk.
Your thoughts about the 'length' of pointers make sense, and are very
similar to what I had in mind when I implemented pointer indexing.
For indexing pointers, negative indices (in
Changes by Thomas Heller:
--
assignee: theller - twouters
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617699
_
___
Python-bugs-list mailing list
Georg Brandl added the comment:
Martin v. Löwis schrieb:
Martin v. Löwis added the comment:
The patch looks fine to me, please apply.
Done in rev. 57752.
--
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1753395
Martin v. Löwis added the comment:
I have now fixed it in 57750, 57751, 57754. I leave the bug open until I
can actually test it.
--
resolution: - fixed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1746880
Martin v. Löwis added the comment:
Given that the underlying platform has no support for that, it will be
difficult to implement correctly across all systems.
--
nosy: +loewis
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1062
Martin v. Löwis added the comment:
I agree with cartman: Python behaves as designed in all cases discussed
here. Closing this report as invalid.
--
nosy: +loewis
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
Georg Brandl added the comment:
Guido van Rossum schrieb:
Guido van Rossum added the comment:
On 8/30/07, Thomas Wouters [EMAIL PROTECTED] wrote:
Thomas Wouters added the comment:
Here's a working version of that idea, with a WeakSet implementation I
had lying around (but never really
Changes by Georg Brandl:
--
resolution: - invalid
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1528802
_
___
Python-bugs-list mailing
Martin v. Löwis added the comment:
Thanks for the patch. Committed as r57759 and r57760. I added it to the
trunk as well, as it might be possible that the test is run on FAT even
if the operating system is Windows XP.
--
nosy: +loewis
resolution: - accepted
status: open - closed
Martin v. Löwis added the comment:
The fatal error is raised if the stack overflows in the process of
handling RuntimeError. In certain cases, the C algorithms won't bail out
if a RuntimeError is raised, and just catch it. If that then causes
another stack overflow, Python gives up. One such
New submission from Carsten Grohmann:
The example for property() contains a typo / small bug:
class C(object):
def __init__(self): self.__x = None
[...]
should be:
class C(object):
def __init__(self): self._x = None
[...]
Source: http://docs.python.org/lib/built-in-funcs.html
Thomas Wouters added the comment:
Well, that's not quite how I implemented the slicing, and it's also not
how the existing simple-slicing was implemented: A negative start index
is taken to mean 0, and a stop index below the start index is taken to
mean 'the start index' (leading to an empty
Thomas Heller added the comment:
Yes.
But looking at your examples I think it would be better to forbid
missing indices completely instead of allowing them only where they
clearly mean 0.
Writing (and reading!) a 0 is faster than thinking about if a missing
index is allowed or what it means.
New submission from Martin v. Löwis:
Let's see who gets this
--
assignee: georg.brandl
messages: 55508
nosy: georg.brandl, loewis
severity: normal
status: open
title: Test issue
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1064
Changes by Martin v. Löwis:
--
resolution: - invalid
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1064
__
___
Python-bugs-list mailing list
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.python.org/issue1044
__
Thomas Wouters added the comment:
Hmmm Well, that's fine by me, but it changes current behaviour, and
in a way that ctypes own testsuite was testing, even ;) (it does, e.g.,
'p[:4]' in a couple of places.) Requiring the start always would
possibly break a lot of code. We could make only the
Guido van Rossum added the comment:
Georg, would you have time to submit an improved patch?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1061
__
___
Python-bugs-list mailing
Georg Brandl added the comment:
Martin v. Löwis schrieb:
New submission from Martin v. Löwis:
Let's see who gets this
I did. :)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1064
__
Georg Brandl added the comment:
Thanks, this is already fixed in the development docs
(http://docs.python.org/dev).
--
nosy: +georg.brandl
resolution: - out of date
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1063
Bill Janssen added the comment:
Indeed. Calls for some design chops. Again, it's a question of what
the socket.socket class really is.
Bill
On 8/30/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Martin v. Löwis added the comment:
Given that the underlying platform has no support for that,
New submission from Bill Janssen:
It seems like a bad idea to have ssl.sslsocket(socket) suddenly become
ssl.SSLSocket(fileno) in 2.3. Since no user code is currently using the
ssl module, it would be a good idea to change it upfront (if possible)
so that code written against 2.6's version
Changes by Skip Montanaro:
--
nosy: +skip.montanaro
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1462525
_
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro:
--
nosy: +skip.montanaro
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1675455
_
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Collin Winter:
This does not implement __context__; it turned out to be much more
difficult than expected and will require some more thought. The new
raise syntax and the __traceback__ and __cause__ attributes are
implemented, however. This does not yet include a docs patch,
Changes by Collin Winter:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1066
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Collin Winter:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1066
__
___
Python-bugs-list mailing list
Unsubscribe:
Thomas Wouters added the comment:
Checked in a slightly newer version.
--
resolution: accepted - fixed
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1617699
_
Guido van Rossum added the comment:
Please check it in yourself.
--
assignee: gvanrossum - collinwinter
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1066
__
New submission from Thomas Wouters:
test_smtplib fails because asyncore uses bytes(data) where data may be
bytes or str or some undefined type. The attached patch fixes it to the
extend that test_smtplib works again (plus a small fix in test_smtplib
itself.) I'm not sure if this is the right
Changes by Guido van Rossum:
--
versions: +Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1067
__
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Great, please check it in. This is close to what I had sitting
somewhere, but I hadn't finished it.
--
assignee: gvanrossum - twouters
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
Thomas Wouters added the comment:
Checked in.
--
resolution: accepted - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1067
__
___
Changes by Collin Winter:
--
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1066
__
___
Python-bugs-list mailing list
Unsubscribe:
Collin Winter added the comment:
Committed as r57783.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1066
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Skip Montanaro:
--
nosy: +skip.montanaro
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue980098
___
Python-bugs-list mailing list
Unsubscribe:
Guido van Rossum added the comment:
Barry, what do you think of this patch? How does the email package
handle this case?
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue504152
72 matches
Mail list logo