Bill Janssen <[EMAIL PROTECTED]> added the comment:
Any progress here? I haven't yet found a formulation which suppresses
the warning on all platforms. I'm guessing there will have to be some
kind of cpp test
#if SOMEFEATURE
#define D2I_PARAMETER_2_TYPE unsigned char
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I've committed the patch which I have for 2.6.
Still need renamings for 3.0, and implementations
of recvfrom_into and recv_into.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Added this in 2.6, still needs it for 3.x.
--
versions: +Python 3.0 -Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
The 2.6/3.0 changes are now up-to-date. We could reconsider this
problem. My guess is that we still don't quite know what to do.
I think the issue is that we need a way to "unwrap" the SSL-secured
TCP stream, after i
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I believe this is now fixed in the SVN.
There's a new parameter on SSLSocket, suppress_ragged_eofs, which allows
it to be enabled selectively, but default to True.
--
resolution:
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
assignee: -> janssen
nosy: +janssen
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
But httplib is far from fixed. It's a nasty tarball of interdependencies...
Bill
On Mon, Jun 30, 2008 at 4:12 AM, Giampaolo Rodola' <[EMAIL PROTECTED]>
wrote:
>
> Giampaolo Rodola' <[EMAIL PROTECTED]&
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Thanks. I'll read it.
Bill
On Thu, Jul 31, 2008 at 6:16 AM, Daniel Arbuckle <[EMAIL PROTECTED]>wrote:
>
> Daniel Arbuckle <[EMAIL PROTECTED]> added the comment:
>
> I&#x
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Here's my version of how quote and unquote should be implemented in
Python 3.0. I haven't looked at the uses of it in the library, but I'd
expect improper uses (and there are lots of them) will break, and thus
can be fixed
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11062/myunquote.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Here's a patch to parse.py (and test/test_urllib.py) that makes the
various tests (cgi, urllib, httplib) pass. It basically adds
"unquote_as_string", "unquote_as_bytes", "quote_as_string",
"quote_
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Just to reply to Antoine's comments on my patch:
- it would be nice to have more unit tests, especially for the various
bytes/unicode possibilities, and perhaps also roundtripping (Matt's
patch has a lot of tests)
Yes, I
Bill Janssen <[EMAIL PROTECTED]> added the comment:
My main fear with this patch is that "unquote" will become seen as
unreliable, because naive software trying to parse URLs will encounter
uses of percent-encoding where the encoded octets are not in fact UTF-8
bytes. They
Bill Janssen <[EMAIL PROTECTED]> added the comment:
> Your original proposal was to make unquote() behave like
> unquote_to_bytes(), which would require changes to virtually every app
> using unqote(), since almost all apps assume the result is a (text)
> string.
Actually, ca
Bill Janssen <[EMAIL PROTECTED]> added the comment:
On Thu, Aug 7, 2008 at 4:23 PM, Guido van Rossum <[EMAIL PROTECTED]>wrote:
>
> >> However I fear that this middle ground will in practice cause:
> >>
> >> (a) more in-the-field failures, since devs
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Now I'm looking at the failing test_http_cookiejar test, which fails
because it encodes a non-UTF-8 byte, 0xE5, in a path segment of a URI.
The question is, does the "http" URI scheme allow non-ASCII (say,
Latin-1) oc
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11078/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11076/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Looks like the failing test in test_http_cookiejar is just a bad test;
it attempts to build an HTTP request object from an invalid URL, yet
still seem to expect to be able to extract a cookie from the response
headers for that request
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Just to be clear: any octet would seem to be allowed in the "path" of
an "http" URL, but any non-ASCII octet must be percent-encoded. So the
URL itself is still an ASCII s
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Here's the updated version of my patch. It returns a string, but
doesn't clobber bytes that are contained in the string. Naive code
(basically code that expects ASCII strings from unquote) should continue
to work as well as
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11064/patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Bill Janssen <[EMAIL PROTECTED]>:
Hi, I'm having more problems with ctypes.util.find_library. On my
Intel box, this works fine:
% python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", &quo
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Caused by setting DYLD_FALLBACK_LIBRARY_PATH badly on the PPC machine.
--
resolution: -> invalid
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Bill Janssen <[EMAIL PROTECTED]> added the comment:
On Sat, Aug 9, 2008 at 11:34 AM, Matt Giuca <[EMAIL PROTECTED]> wrote:
>
> Matt Giuca <[EMAIL PROTECTED]> added the comment:
>
> Bill, I had a look at your patch. I see you've decided to make
> quote_
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11101/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Some interesting notes here (from Erik van der Poel at Google; Guido,
you might want to stroll over to his location and talk with him):
http://lists.w3.org/Archives/Public/www-international/2007JanMar/0004.html
and more particularly
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I think I'm just going to bring the unwrap already in the _ssl.c code
out to the ssl.py module, that seems to be the simplest fix. Still not
sure you can do a proper fix to ftplib here, but that seems to be a good
thing to do any
Bill Janssen <[EMAIL PROTECTED]> added the comment:
OK, I think I've done the minimal fix necessary to the SSL module to
allow this work to proceed.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Larry Masinter is off on vacation, but I did get a brief message saying
that he will dig up similar discussions that he was involved in when he
gets back.
Out of curiosity, I sent a note off to the www-international mailing
list, and re
Bill Janssen <[EMAIL PROTECTED]> added the comment:
For Antoine:
I think the problem that Barry is facing with the email package is that
Unicode strings are an ambiguous representation of a sequence of bytes;
that is, there are a number of different byte sequences a Unicode string
may hav
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Here's another thought:
Let's put string_to_bytes and string_from_bytes into the binascii
module, as a2b_percent and b2a_percent, respectively.
Then parse.py would import them as
from binascii import a2b_percent as percent
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Feel free to take the function implementation from my patch, if it speeds
things up (and it should).
Bill
On Wed, Aug 13, 2008 at 9:41 AM, Guido van Rossum <[EMAIL PROTECTED]>wrote:
>
> Guido van Rossum <[EMAIL PROTECTE
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Erik van der Poel at Google has now chimed in with stats on current URL
usage:
``...the bottom line is that escaped non-utf-8 is still quite prevalent,
enough (in my opinion) to require an implementation in Python, possibly
even allowi
Bill Janssen <[EMAIL PROTECTED]> added the comment:
On Wed, Aug 13, 2008 at 10:51 AM, Antoine Pitrou <[EMAIL PROTECTED]>wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le mercredi 13 août 2008 à 17:05 +, Bill Janssen a écrit :
> > I
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Nope. Hostname verification was never a good idea -- the "hostname" is
just a vague notion, at best -- lots of hostnames can map to one or more
IP addresses of the server. It's exposed to the application code, so if
a cli
New submission from Bill Janssen <[EMAIL PROTECTED]>:
Not sure how to class this, but shouldn't the "parse_header" function in
cgi really be in email.header? And what about parse_multipart?
--
components: Library (Lib)
messages: 71500
nosy: janssen
priority: no
Bill Janssen <[EMAIL PROTECTED]> added the comment:
> I imagine if they were moved (at least for a few versions) the old ones
> would still work, with a deprecation warning?
Yes, that's what I was thinking.
___
Python tracker <[EMA
Bill Janssen <[EMAIL PROTECTED]> added the comment:
checking hostnames is false security, not real security.
On 8/20/08, Heikki Toivonen <[EMAIL PROTECTED]> wrote:
>
> Heikki Toivonen <[EMAIL PROTECTED]> added the comment:
>
>
> I would think most people/applic
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I believe this is now implemented in all the branches. And when I run the
tests, they run fine. There's still an issue with unwrap; it does a
blocking tear-down of the SSL session, and can block when you don't want
it t
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10337/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Thanks. If you can identify a specific bug, I'll take a look at it.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I'm afraid you're ahead of me in knowledge here. I've experimented with
the ciphers a bit, but there seem to be various compatibility issues. I
finally decided to let the OpenSSL folks and various standard groups
Bill Janssen <[EMAIL PROTECTED]> added the comment:
We might consider this for 3.x. We didn't want to do this for 2.6, to
maintain compatibility with the older socket.ssl module in Python.
--
nosy: +janssen
___
Python tracker <[E
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Simon, Python 3.x now has recvfrom and recv_into, but not recvfrom_into.
If you'd like to work up a patch for that, I'll add it to the next
release cycle.
___
Python tracker <[EMAI
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
resolution: accepted -> fixed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1223>
___
_
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I think I'm going to close this. file.read(N) is not guaranteed to
return N bytes, it's guaranteed to return at most N bytes.
--
resolution: -> rejected
___
Python tracke
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1291446>
___
__
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
resolution: later -> fixed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue508944>
___
__
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Take a look at the thread here:
http://mailman2.u.washington.edu/mailman/htdig/imap-protocol/2008-February/000811.html
I think the summary is, arbitrary bytes may occur in some places, but
they're likely to be UTF-8. Otherwise,
Bill Janssen <[EMAIL PROTECTED]> added the comment:
The way I read the documentation, file.read() (and that's what we're
talking about) is still not guaranteed to read all the bytes of the
file. But, you're right, that is the accepted semantics. So the
documentati
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Simon, thanks, this patch looks good to me (2.6 only, right?). I'll try
it out and report back. If it looks good, I'll commit it.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Ah, sorry. I was looking at the 2.6 documentation, not the 2.5
documentation. In 2.6 (which is what the new SSL code is for),
documentation of socket.ssl has been removed entirely, along with the
text that you cite, although the functio
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Re: nomenclature
I think this is partly a design bug on my part, supporting the old
pre-2.6 "read" and "write" methods on the SSL context. Users should
really call "makefile" to get something they can &quo
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I've applied Simon's patch to the 2.6 trunk.
___
Python tracker <[EMAIL PROTECTED]>
<http://
Bill Janssen <[EMAIL PROTECTED]> added the comment:
And for the 3K branch. Thanks!
--
resolution: accepted -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Bill Janssen <[EMAIL PROTECTED]> added the comment:
There was a reason to do it that way. Now if I can only remember what
it was...
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
priority: high -> low
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3805>
___
___
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Please, guys, let's not deep-end on this. It's an admittedly eccentric but
working and purely internal interface. There are actual release-blockers
that need to be addressed.
On Tue, Sep 9, 2008 at 4:14 AM, Amaury Forge
Changes by Bill Janssen <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11446/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Bill Janssen <[EMAIL PROTECTED]> added the comment:
But I should say... Greg, I do appreciate the review and the comments.
I was waiting for the bytes work in 3K to settle down before looking at
that code again. When I do, I'll take your commen
Changes by Bill Janssen <[EMAIL PROTECTED]>:
--
resolution: -> accepted
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3823>
___
__
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Sorry to be so brief there -- I was off on vacation.
Verifying hostnames is a prescription that someone (well, OK, Eric
Rescorla, who knows what he's talking about) put in the https IETF RFC
(which, by the way, is only an inform
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Thanks, Simon.
I remember digging through all this last year, and finally deciding
to keep things simple and use the strategy the current codebase uses.
It almost sounds like we'd need to create Key and Certificate objects
in the
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Sure -- but the point of the SSL module was to do something
small and compatible with the existing socket.ssl module; I really don't
want to get into a full-fledged Python interface to OpenSSL. Perhaps
incremental progress
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I think that, where it's appropriate, you can do that. Just don't put it in
the SSL module.
Bill
On Wed, Sep 10, 2008 at 11:24 PM, Heikki Toivonen <[EMAIL PROTECTED]>wrote:
>
> Heikki Toivonen <[EMAIL PROTEC
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I tried applying this patch to a clean SVN checkout of the 2.6 trunk on
an OS X Leopard machine and it works (except for the part which patches
configure.in). I then built the source tree and ran the test_socket
test, which also worke
Bill Janssen <[EMAIL PROTECTED]> added the comment:
On Wed, Sep 17, 2008 at 10:45 AM, bms <[EMAIL PROTECTED]> wrote:
>
> Exercising the API fully requires an SSM capable multicast LAN.
>
Let's hope the PARC network is still up-to-date. It was when we were
developing
Bill Janssen <[EMAIL PROTECTED]> added the comment:
The server wasn't meant to be non-blocking. The non-blocking test is
performed when the client (which is non-blocking) connects to it.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Looks OK to me. I think this is a back-port problem from 3.0.
I'll put it in if no one objects.
--
assignee: -> janssen
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Sure, no argument. I was just making clear what was going on.
Bill
On Thu, Sep 18, 2008 at 7:33 PM, Josiah Carlson <[EMAIL PROTECTED]>wrote:
>
> Josiah Carlson <[EMAIL PROTECTED]> added the comment:
>
> Being a
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Will do.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3910>
___
___
Python-bugs
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Maybe not. test_ssl hangs when I run it "-u all -v". It's hanging on
testSimpleSSLWrap. This is on OS X 10.5.5.
___
Python tracker <[EMAIL PROTECTED]>
<ht
Bill Janssen <[EMAIL PROTECTED]> added the comment:
OK, I found the fix.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Bill Janssen <[EMAIL PROTECTED]> added the comment:
As I read RFC 2396,
1.5: "A URI is a sequence of characters from a very
limited set, i.e. the letters of the basic Latin alphabet, digits,
and a few special characters."
2.4: "Data must be escaped if it does not
Bill Janssen <[EMAIL PROTECTED]> added the comment:
It's not immediately clear to me how an auto-quote function can be
written; as you say (and as the URI spec points out), you have to take
a URL apart before quoting it, and you can't parse an invalid URL,
which is what the in
Bill Janssen <[EMAIL PROTECTED]> added the comment:
I'm not concerned about any example inputs. I was just trying to
explain why this isn't a bug.
On the other hand, the IRI spec (RFC 3897) is another thing we might
try to implement for Python.
--
type: -&
Bill Janssen <[EMAIL PROTECTED]> added the comment:
Yes, we were looking at using this for linking PyLucene's JCC extension.
I believe we came up with a different way of doing it. It would still
be useful to have distutils.unixccompiler.runtime_library_dir_option()
updated to und
Bill Janssen added the comment:
Victor, I'll take a look.
--
___
Python tracker
<http://bugs.python.org/issue8108>
___
___
Python-bugs-list mailing list
Bill Janssen added the comment:
What's happening is that the new state returns from SSL_shutdown() are saying,
"the shutdown you asked for didn't happen this time, but call me again when you
get a chance. And here is a hint about why it didn't happen, so that if you
are
Bill Janssen added the comment:
Looking at this further, what we're seeing is the trace of an ineffective
attempt to handle an exception presumably raised from the FTP code. Can we see
that exception? What's the actual state of the TCP connection at
Bill Janssen added the comment:
I think Giampaolo is right about this not being an ssl.py issue. Could the
exception handling in ftp.py perhaps also be made more sophisticated? I'd
really love to understand what the state of the TCP connection is here. I'm
presuming that it&#x
Bill Janssen added the comment:
And it would be interesting to know why all the SSL module tests don't fail in
the same way.
--
___
Python tracker
<http://bugs.python.org/i
Bill Janssen added the comment:
> AFAICT, his proposed "quick fix" snippet should be good enough for us.
Depends on what we want. It just suppresses information that's now available.
What we'd really like is for the caller to recognize that close() can fail, and
s
Bill Janssen added the comment:
> Maybe because only the FTP test uses an SSL socket in non blocking mode.
No, the SSL unit tests also do this. I think Giampaolo is right, what we're
seeing is bad error handling in the FTP t
Bill Janssen added the comment:
>> Depends on what we want. It just suppresses information that's now
>> available. What we'd really like is for the caller to recognize that
>> close() can fail, and should be re-tried if it does. That requires
>> that we s
Bill Janssen added the comment:
I'm seeing this on Python 2.6.4 on Windows XP with the latest MinGW/msys.
--
nosy: +janssen
___
Python tracker
<http://bugs.python.org/i
Bill Janssen added the comment:
Re-opening.
--
keywords: +26backport
priority: high -> normal
resolution: invalid ->
status: closed -> open
___
Python tracker
<http://bugs.python.o
Bill Janssen added the comment:
My bad. Adding --compiler=mingw32 eliminates this error.
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Bill Janssen added the comment:
Shouldn't the import library name end with .lib? I've run up against this
building PyLucene with MinGW. There seems to be code to figure this out
already in CygwinCCompiler, but it's commented out (and arguably incomplete).
--
Bill Janssen added the comment:
Looks like a good idea.
--
___
Python tracker
<http://bugs.python.org/issue8222>
___
___
Python-bugs-list mailing list
Unsub
Bill Janssen added the comment:
So what happens if the original file name is something like "foo~1.txt"?
Couldn't there be a name collision?
--
nosy: +janssen
___
Python tracker
<http://bugs.py
Bill Janssen added the comment:
This looks a lot like bug 1128, too. I think the patch there would also fix
this one.
--
nosy: +janssen
___
Python tracker
<http://bugs.python.org/issue7
Bill Janssen added the comment:
Here's how Microsoft does it: http://support.microsoft.com/kb/142982/en-us
--
___
Python tracker
<http://bugs.python.org/i
New submission from Bill Janssen :
Working with Python 2.6.5, I find I cannot put multiple CABs in the same
installer. This is due to this statement in msilib.CAB.commit():
add_data(db, "Media",
[(1, self.index, None, "#"+self.name, None, None)])
Bill Janssen added the comment:
I'm certainly using the API provided by msilib, but perhaps I'm using it badly.
Which API did you have in mind? I'm using msilib directly, not through
bdist_msi.
This seems like an artificial limitation to put on the Python library; the
st
Bill Janssen added the comment:
Here's another one:
class Directory shows an extra arg, "component", which isn't in the code.
--
nosy: +janssen
___
Python tracker
<http://bu
New submission from Bill Janssen :
I'm trying to create a CAB file containing about 69MB of data, in 4555 files.
msilib fails in CAB.commit():
$ python build-msi-installer.py /c/UpLib/1.7.9 ~/uplib 1.7.9 ./uplib-1.7.9.msi
c:\Documents and Settings\wjanssen\uplib\win32\uplib-1.7.
Bill Janssen added the comment:
Ummm, just in case the packager wanted to.
In my case, I was putting the files which were registered as part of the
installation in one CAB file, and another set of temporary files which were
used by some of the installation scripts, but not part of the
Bill Janssen added the comment:
So, I subclassed msilib.CAB, and re-wrote commit() so that the CAB file is
created in a different process, a la Tools/msi/msilib.py. Still have the same
problem, though. So now I'm thinking it's not a memory problem, but I'm
wondering if th
101 - 200 of 313 matches
Mail list logo
