I've added in some code that Chris Stawarz contributed to allow the
use of non-blocking sockets, with the program thread allowed to do
other things during the handshake while waiting for the peer to
respond.
http://pypi.python.org/pypi/ssl
If this is OK with everyone, I'd like to now port this ba
> > One thing to watch out for: ssl.SSLError can't
> > inherit from socket.error, as it does in 2.6+,
>
> Why not?
Mainly because I don't see how to get my hands on the C version of
socket.error. Patches gratefully accepted, though.
Bill
___
Python-De
> For anyone who wants to write the patch, you can obviously either
> expose the variable the exception is stored in globally,
Remember that this is an add-on module, so re-compiling the socket
module code to expose the variable globally would be a rather big
change. Or so it seemed to me when I
> > you can
> > import the socket module and just get socket.error directly off of the
> > module itself.
>
> This is feasible.
In fact, so feasible I've done it. :-).
http://pypi.python.org/pypi/ssl/1.9/
Bill
___
Python-Dev mailing list
Python-Dev@py
I'd love to know what's "different" about Python 2.4 on Windows that
isn't different in 2.3 and 2.5.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/op
Application programmers... Web programmers...
I can't resist chiming in that I'm running a 4000-line Python
application on my iPhone that is both a full-blown application, and a
Web server, because it uses the phone's browser as its application
GUI. (By the way, thanks to whoever pushed through
I've updated the PyPI SSL package to 1.10, to fix a fairly serious bug
in sendall() I found while updating the trunk code.
http://pypi.python.org/pypi/ssl/
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
> Simply, it's sometimes desired to know the encoding for purposes that
> don't require immediate decoding. A function would be quite handy
> in these cases.
In os.path? os.path.encoding(location)?
Bill
___
Python-Dev mailing list
Python-Dev@python.o
> Hi there,
> since ssl module is still in development I thought it would have been
> better asking such question here instead of on comp.lang.python.
> I'm interested in using the ssl module with asyncore but since there's
> no real documentation about it yet I've been not able to write
> somethin
> I downloaded this one:
> http://pypi.python.org/pypi/ssl/1.12
Yes, that's the one.
> ...which seems to contain the same test-suite used in the current
Not quite.
> Python 2.6 distribution available here:
> http://svn.python.org/snapshots/
> I looked into test/test_ssl.py but I didn't find any
Which branch is this?
Bill
> Seeing more in deep, I saw that Bill replaced in r58164, in this
> BasicTest, a lot of previous code (I think that from r57464) that
> actually tested it *locally*.
___
Python-Dev mailing list
Python-Dev@python.org
http://m
> I tried to write a simple asyncore-based server code, then I used a
> simple client to establish a connection with it.
> Once the client is connected server raises the following exception:
I think this is a bug. Thanks!
The issue is that the internal call to do_handshake() doesn't handle
non-b
> It does raise the same exception.
Hmmm, not in my version.
> Are there plans for fixing this?
Yes, it's fixed in my CVS, and I'll upload a new version to PyPI when
I get a chance.
> Using that kind of workaround is not acceptable in any case (select
> module shouldn't even get imported when u
> IMO, it's not reasonable since the application could use something
> different than select.select(), like select.poll() or something else
> again.
As I said before, you can do away with select or poll altogether if
you write a state machine for your asyncore dispatcher. Asyncore will
tell you w
> No, the SSL code should NOT be allowed to block anything in any case,
> even though the handshake is still not completed, in which case just
> retry it at a later time.
That's why there's "do_handshake_on_connect" in the first place. I'm
just talking about what the SSL module should do if you d
An interesting question has come up in the development of the SSL module.
The function ssl.wrap_socket() takes a flag, do_handshake_on_connect,
which tells it whether to do the SSL handshake before returning an
SSLSocket object to the caller. If the socket being wrapped is
non-blocking, the code
> Rather than temporarily
> making it blocking by whatever means, some indication needs
> to be returned that the operation would block, and a way
> provided for the calling code to re-try later.
>
> If that can't reasonably be done, then passing a non-blocking
> socket here should be an error.
I
Thanks, Audun. If you look at the code, you'll see that both a
connect method and a do_handshake method already exist, and work
pretty much as you describe. The issue is what to do when the user
doesn't use them -- specifies do_handshake_on_connect=True.
> Another way of doing it could be to exp
I shifted to Leopard a couple of weeks ago. Seems to build and test
fine, but I disable all the various poorly documented/maintained Mac
modules, so my configure looks like this:
./configure --disable-universalsdk --disable-framework --disable-toolbox-glue
I believe OSA is "toolbox glue", so I'l
> Good to know there are users.
And I use Medusa, which is built on top of asyncore.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
> I see a few tests leaking; in particular test_ssl (1522 refs leaned
> per run!)
I'm looking at this, but I haven't found anything in the last week...
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
> The test_ssl tests are only leaking with the -unetwork option. On my
> Ubuntu box they are leaking 1536 references per turn. For heaven's sake
> I can't remember how I found the leaking code lines the last time.
> Py_DUMP_REFS dumps too many information.
I found the leak the last time by narrowi
The latest version of the PyPI SSL module is 1.13, and it seems pretty
stable. I'd appreciate it if one of you who've compiled it in the past
would do so again, and send me Windows binary dists to post to the PyPI
site.
http://pypi.python.org/pypi/ssl/
Thanks!
Bill
_
> I think there ought to be a much more agressive standard for 3.0 backports:,
> "does the proposed backport make 2.6 more attractive?"
> Remember, for large code bases, upgrading is a PITA (I think Google is still
> running tons of code on 2.2, 2.3, and 2.4). There
> needs to be a good incent
> My main gripe is with code contributions to Py3k and 2.6; Py3k is
> mostly done by a handful of people, and almost nobody is working much
> on 2.6.
There's a great Duke Ellington quote: ``Without a deadline, baby, I
wouldn't do nothing.''
The SSL code in 2.6 is out-of-date (buggy) compared to t
> > 3.x fixes, because there's no schedule for 2.6.
>
> Eh? PEP 3000 has a schedule that includes 2.6:
OK, no schedule that I knew about :-). I'll get back to work on it.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Oleg Broytmann writes:
> On Wed, Jan 16, 2008 at 06:31:42AM +0900, Stephen J. Turnbull wrote:
> > I think both for UI reasons (given above) and for API reasons (given
> > by others) there should be a separate ~/SOMETHING/{bin,etc,lib,share}
> > hierarchy for user-specific packaged contents. I like
> Bill Janssen wrote:
> > Good point, but I prefer ~/Library/Python to either of these.
>
> ~/Library/ is a Mac OS X thing. I haven't seen it on other Unix systems.
> I *could* add yet another environment variable PYTHONUSERHOME to set the
> base path but I prefer not.
> >> ~/Library/ is a Mac OS X thing.
>
> Bill> Sure, but it's clearly where this should be on an OS X system, by
> Bill> default.
>
> I think only for stuff that is a Mac-ish GUI app type of thing and/or that
> plays with Mac's distinct APIs (Carbon, Cocoa, whatever). Would you
> i
It's a big patch, but I'll try applying it to the current py3k branch
-- does it apply? -- and try a few things with it. I'm concerned
about how well it behaves with things like Medusa (which probably
needs its own py3k update).
Bill
___
Python-Dev mail
If you
> > > want my opinion on other async-related features, feel free to email me
> > > directly (use the gmail address you see here, then it ends up in my
> > > inbox, not the overflowing python folder).
> >
> > How's your solution? Could you pos
> I've read through ssl.py but I didn't notice anything useful.
> It seems that ssl.SSLSocket class does not provide any method/facility
> to switch back to a plain text socket state.
I suggest using socket.dup(sslsock) to simply create a non-encrypted
copy of the socket, and switch to using that
> But shouldn't there be a way to invoke SSL_shutdown? You need to get
> the close_notify alert message sent, IIUC.
Perhaps that would be nice, but switching to plain-text use of the
socket can be coordinated outside the SSL protocol. I had an accessor
for SSL_shutdown, in an earlier version, but
> IIUC, RFC 4217 mandates that a TLS shutdown is exchanged (although they
> apparently didn't read the TLS spec when they wrote the RFC, as the
I'm pretty dubious about section 5 there. I don't think reverting to
a plaintext state, once you've been in TLS, happens in real life to
real connections
> > I suggest using socket.dup(sslsock) to simply create a non-encrypted
> > copy of the socket, and switch to using that copy. There's no way to
> > "unwrap" an SSLSocket.
>
> It does not seem to work:
>
> File "C:\python26\lib\ssl.py", line 115, in read
>return self._sslobj.read(len)
> ss
It's on my list.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> - Alpha Tru64: test_smtplib.py is flaky, and _ssl.c is not compiled
> correctly. Neil is hunting this, I think.
Last time we looked at the _ssl problem, the machine had an
out-of-date installation of OpenSSL. Don't know if that ever got
rectified; I just crossed that buildbot off my list :-).
> I personally have not used _ssl but on quick inspection I don't see any
> of the crypto algorithms implemented, AES, ECDSA, etc. What if we want
> to encrypt or sign content using OpenSSL?
I suggested adding a class which gives you access to those. I think
it's a good idea, and that serious us
> Bill Janssen wrote:
> [snip]
>
> Do you have an opinion on the initial proposal of applink.c? The
> proposal does neither seem harmful nor problematic but I also don't see
> how it is going to help the op.
>
> Christian
I know nothing about it -- it's a Windo
> Why not also make unicode() the default type constructor and only
> keep str() as alias to simplify porting (perhaps with a warning) ?
>
> The term "string" is just too overloaded with all kinds of
> misinterpretations. The term "string" just refers to a string of
> bytes - a variable length arr
Now I apparently need an email reader that understands reStructuredText :-).
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
I don't think this is bike-shedding.
The debate about "AMD64" vs. "amd64" vs. "x86_64" reminded me that
I've been bit more and more frequently by bits of platform-specific
knowledge scattered around the standard library. The latest is the
code in distutils.unixccompiler that tries to figure out w
I've set up a Parallels virtual machine on my Mac, and have succeeded
in getting Windows XP running in it! And I've installed MinGW, as
well. Now I'd like to learn how to build the SSL module from source
on Windows for Python 2.5.2. Is there any documentation on the
process of building an extens
> Having recently sunk a lot of time into the Windows build process, I'd
> recommend going with Visual C++ Express 2008 rather than MinGW, as this is
> the official compiler for 2.6/3.0. (You can download a free copy.)
Thanks for the advice, but it's sort of Greek to me. Is there a
step-by-ste
Nice and simple, thanks, Martin!
Works OK after I upgraded to MinGW 5.1.3 (5.0.0 is what I had, and the
gcc build didn't work there with that).
I think I've got it!
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
7;, 'java', 'riscos'.
This implies that there's a registry somewhere?
Bill
> Great idea! Sounds like a PEP (informational, probably) would be good idea.
>
> On Tue, Mar 18, 2008 at 4:59 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > I don't thi
> although the word "trove" means nothing to me
http://www.askoxford.com/concise_oed/trove?view=uk
"a store of valuable or delightful things"
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsu
> There
> have been other tests that have also been flaky like test_asynchat,
> test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
> test_xmlrpc_net and some of the tests that use networking.
Some of the *other* tests that use networking, I think you mean.
Sounds like networking tests in g
> On Fri, Mar 28, 2008 at 3:31 AM, <[EMAIL PROTECTED]> wrote:
> >
> > Neal> Anything that connects to a remote host is definitely flaky.
> >
> > Would it maybe help to set up a dedicated host (or virtual host) to serve
> > as
> > the sole target of all network tests?
>
> It would help, but
There's some really convoluted code in socket._fileobject.__init__()
here. When initializing a _fileobject, if the 'bufsize' parameter is
explicitly given as zero, that's turned into an _rbufsize of 1, which,
combined with the 'min' change, will produce the read-one-byte
behavior. The code for se
> IMHO, more research has to be done into this area before a
> "standard" module can be added to the Python's stdlib... and
> who knows, perhaps we're lucky and by the time everyone is
> using UTF-8 anyway :-)
I walked over to our computational linguistics group and asked. This
is often combined
The 2002 paper "A language and character set determination method
based on N-gram statistics" by Izumi Suzuki and Yoshiki Mikami and
Ario Ohsato and Yoshihide Chubachi seems to me a pretty good way to go
about this. They're looking at "LSE"s, language-script-encoding
triples; a "script" is a way o
> > When a web browser POSTs data, there is no standard way of communicating
> > which encoding it's using.
>
> That's just not true. Web browser should and do use the encoding of the
> web page that originally contained the form.
Since the site that receives the POST doesn't necessarily have acc
> Unless you're using a very broad scope, I don't think that
> you'd need more than a few hundred LSEs for a typical
> application - nothing you'd want to put in the Python stdlib,
> though.
I tend to agree with this (and I'm generally in favor of putting
everything in the standard library!). For
> Yup, but DrProject (the target application) also serves as a relay and
> archive for email. We have no control over the agent used for
> composition, and AFAIK there's no standard way to include encoding
> information.
Greg,
Internet-compliant email actually has well-specified mechanisms fo
[EMAIL PROTECTED] writes:
> > When a web browser POSTs data, there is no standard way of communicating
> > which encoding it's using.
>
> That's just not true. Web browser should and do use the encoding of the
> web page that originally contained the form.
I wonder if the discussion is confusing
> Windows and Mac OS X have dedicated directories for application specific
> libraries. That is ~/Library on Mac and Application Data on Windows.
In fact, I had to write code for this, and had to read the specs for each.
Here's the code (I've substituted Python for UpLib):
if sys.platform == 'dar
> > /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local?
>
> Because unlike a home directory, users don't frequently perform
> directory listings or tab completion of /usr/. For a frequently used
> personal directory one wants the minimum of noise.
Glad someone around here kn
I just made another attempt to use ctypes to wrap a library, and am
facing the same problem I had the last time: the documentation doesn't
really work. I'm wondering if we have any projects underway to
re-write it?
Bill
___
Python-Dev mailing list
Pyth
> On win32 it will usually (but not always) provide a file name in a directory
> writeable only by the current user.
OS X 10.5 also does this.
>>> import tempfile
>>> tempfile.mktemp()
'/var/folders/Ru/RuapMUan2RWWJ++1YwBnRU++0T6/-Tmp-/tmpjjkKha'
>>> os.system("ls -dl /var/folders/Ru/RuapMUan2RWW
> I would be okay with changing the requirements in Py3k so that you are
> required to keep the socket object open at least as long as you plan
> on using the derived stream(s), but this will require some careful
> redesign, especially in the light of SSL support. (Read ssl.py and
> _ssl.c to under
See http://bugs.python.org/issue1348.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> On 2008-05-09 15:29, [EMAIL PROTECTED] wrote:
> > mal> Is there a tool available that can convert 2.x code automagically
> > mal> to the .format() method syntax ?
> >
> > mal> Just did a quick grep of our code base and it has some 2000 lines
> > mal> of code that would need to be
Thomas, I think this is related to issue 1348.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> Hmm, perhaps the ctypes documentation could use a more prominent warning
> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
> and that it may require the use of GCC rather than the vendor compiler
> on others (Solaris).
>
> At the moment, I suspect some projects may be
> If you can run a pure Python module
> that does not depend on any C extension, then that platform has the
> support needed to run Python.
This is certainly a point of view. One that many end-users wouldn't
understand :-).
Bill
___
Python-Dev mailing
> On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >> If you can run a pure Python module
> >> that does not depend on any C extension, then that platform has the
> >> support needed to run Python.
> >
> > This is cer
Steve Holden wrote:
> The more libraries that use ctypes to call into native functionality,
> the more important it becomes to have ctypes run, even if only to
> implement platform-specific functionality on the given platforms. I
> would like "being able to call a wide range of native libraries"
> Bill Janssen schrieb:
> >> Hmm, perhaps the ctypes documentation could use a more prominent warning
> >> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
> >> and that it may require the use of GCC rather than the vendor compiler
> >
> > Does that mean that we need access to the Sun compiler or that the Sun
> > compiler has bugs which prevent ctypes from compiling?
> >
> I don't think anyone's mentioned Solaris in this context, but there are
> claims that libffi "doesn't build" for AIX and HP-UX.
I think there was also an i
Thomas Heller schrieb:
> A.M. Kuchling schrieb:
> > On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> >> Myself I would rather spend my energy to make ctypes more portable, within
> >> my
> >> skills and the platforms I have access to.
> >
> > Someone could run Solaris x86 inside a
> So maybe Python just doesn't run on Solaris with the Sun C compiler.
> Certainly doesn't build out of the box.
Hmmm, when I look at http://www.sun.com/software/solaris/freeware/, I
see that Python is listed as "included with Solaris 10" as
"Sun-supported software". But the version installed on
> The "csvn" subversion bindings use "ctypesgen" to grovel header files:
> http://code.google.com/p/ctypesgen/
Thanks for the pointer. Looks nice. I've used ctypeslib before, but
it takes a bit of infrastructure building (gcc-xml) before it works.
Bill
__
> That's all fine, but then I'm missing the OpenSSL license and
> attribution notice somewhere in the installer, the README of the
> installation or elsewhere.
Good point. We need this for both the ssl module and the hashlib
module.
Bill
___
Python-Dev
> I'm beginning to wonder whether I'm the only one who cares about
> the Python 2.x branch not getting cluttered up with artifacts caused
> by a broken forward merge strategy.
I share your concern. Seems to me that perhaps (not sure, but
perhaps) the rush to back-port from 3.x, and the concern ab
> >>> I'm not against this, but so far I've not been able to come up with a
> >>> good set of methods to endow the String ABC with.
> >>
> >> If we stay minimalistic we could consider that the three basic operations
> >> that
> >> define a string are:
> >> - testing for substring containment
> >>
> I think I agree with Raymond on the basic principle that simple ABC's
> are easier to use than simple ones.
I don't think he was saying that. He was saying that simple ABC's are
easier to implement to.
It's not at all clear to me that simple ABC's are good in and of
themselves. I think a Stri
This is a common problem. Binding to '127.0.0.1' will bind to *only*
that address; binding to "" will bind to *all* addresses the machine
is known by. If the client uses a different way of getting the
address than the literal '127.0.0.1' (like a call to getfqdn(), which
has pretty indeterminate r
> Is anyone else finding it increasingly odd that subprocess, signal,
> socket/ssl, and syncore are in the same chapter? I'm tempted to move
> socket, ssl, asyncore+asynchat into a 'networking' chapter, and then
> also move SocketServer from the 'Internet Protocols' chapter into this
> new chapter
> On Fri, Jun 20, 2008 at 08:55:13AM -0700, Bill Janssen wrote:
> > > Is anyone else finding it increasingly odd that subprocess, signal,
> > > socket/ssl, and syncore are in the same chapter? I'm tempted to move
> > > socket, ssl, asyncore+asynchat in
> > What follows from that? To me, the natural conclusion is "people who
> > witness performance problems just need to despair, or accept them, as
> > they can't do anything about it", however, I don't think this is the
> > conclusion that you had in mind.
> >
>
> I can say with complete certainty
> I notice that there is some work being done on urllib / urllib2 for
> python 2.6/3.0. One thing I've always missed in urllib/urllib2 is the
> facility to encode POST data as multipart/form-data. I think it would
> also be useful to be able to stream a POST request to the remote
> server rather
All sounds reasonable to me.
Bill
> On Fri, Jun 27, 2008 at 11:40 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >> I notice that there is some work being done on urllib / urllib2 for
> >> python 2.6/3.0. One thing I've always missed in urllib/urllib2 is the
>
> I hope this the correct place to report this...
Hi, Roger.
Please file a bug report at http://bugs.python.org/, and assign it to
me. Please attach a patch for the change you made to the unit test
suite to send >16K.
Thanks!
Bill
___
Python-Dev mail
> Surely it's desirable under all circumstances that
>
>len(u) == sum(1 for c in u)
>
> and that
>
>[c for c in u] == [c[i] for i in range(*len(u))]
>
> How would that play under Jeroen's proposed change?
Yes, but I think the argument is about what "c" is -- a character or a
codepoint.
> Basically, urllib.quote and unquote seem not to have been updated since
> Python 2.5, and because of this they implicitly perform Latin-1 encoding and
> decoding (with respect to percent-encoded characters). I think they should
> default to UTF-8 for a number of reasons, including that's what oth
> Ah there may be some confusion here. We're only dealing with str->str
> transformations (which in Python 3 means Unicode strings). You can't put a
> bytes in or get a bytes out of either of these functions. I suggested a
> "quote_raw" and "unquote_raw" function which would let you do this.
Ah, w
>> Clearly the unquote is str->bytes, You can't pass a Unicode string
>> back
>> as the result of unquote *without* passing in an encoding specifier,
>> because the character set is application-specific.
> So for unquote you're suggesting that it always return a bytes object
> UNLESS an encoding
> test_ssl ... constantly failing on both the trunk and py3k.
I'll take a closer look at this. It's the new test added in lately.
Seems to be working on non-Windows platforms, so I'm guessing it's
some Windows oddity, which I'm not very good at diagnosing. Worst
comes to worst, we can take out t
> > test_ssl ... constantly failing on both the trunk and py3k.
>
> I'll take a closer look at this. It's the new test added in lately.
> Seems to be working on non-Windows platforms, so I'm guessing it's
> some Windows oddity, which I'm not very good at diagnosing. Worst
> comes to worst, we ca
> The Windows buildbots are not very happy, though. test_ssl ...
> constantly failing on both the trunk and py3k.
I've checked in patches for test_ssl on both branches. Let's see how
the Windows buildbots do.
Bill
___
Python-Dev mailing list
Python-Dev
These requests always have a higher probability of being addressed if
you summarize the issue in the request.
Bill
> Can anyone look at the patch for Issue2944?
>
> I hope the issue can be fixed before the release of python 2.6.
___
Python-Dev mailin
Why is it you're trying to use "git"?
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> For unquote, I think it will break a lot and surprise everyone. I
> think that while this may be "purely" the best option, it's pretty
> silly.
I don't mind being silly to do the right thing. Happens to me a lot :-).
Bill
___
Python-Dev mailing list
> On Wed, Jul 30, 2008 at 8:09 AM, André Malo <[EMAIL PROTECTED]> wrote:
> > I'm actually in favour of encoding bytes only back and forth. A useful
> > extension would be *another* function which wraps quote/unquote and encod=
> es
> > and decodes characters.
>
> I'd reverse this. By all means, ad
> Actually (as I pointed out before) the existing functions are not
> string-in/string-out. They are something-in and bytes-out.
Sorry, this is wrong. "quote" is clearly bytes-in and string-out.
"unquote" is clearly string-in and bytes-out.
The whole point of "quote" is to take an arbitrary seq
> It looks like all other APIs in the Py3k version of
> urllib treat URLs as text.
The URL is text, a string of ASCII characters. We're just talking
about urllib.quote() and urllib.unquote(), which are there to support
the text-ization of binary values, and the de-text-ization.
> I think that wo
> > unquote() -- takes string, produces bytes or string
> >
> > If optional "encoding" parameter is specified, decodes bytes with
> > that encoding and returns string. Otherwise, returns bytes.
>
> The default of returning bytes will break almost all uses. Most code
> will uses the unquo
> I think this is as close as consensus as we can get on this issue. Can
> whoever wrote the patch adjust the patch to this outcome? (I think the
> only change is to remove the encoding arguments and make separate
> functions for bytes.)
This is 2.7/3.1 only, right? I'm looking at the bales of co
> Guido says:
>
> > Actually, we'd need to look at the various other APIs in Py3k before we can
> > decide whether these should be considered taking or returning bytes or text.
> > It looks like all other APIs in the Py3k version of urllib treat URLs as
> > text.
>
>
> Yes, as I said in the bug
301 - 400 of 537 matches
Mail list logo
