Re: [Python-Dev] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?
Guido van Rossum wrote: > The asyncore and asynchat modules are in a difficult position when it > comes to Python 3000. None of the core developers use it or > particularly care about it (AFAIK), and the API has problems because > it wasn't written to deal with bytes vs. unicode. E.g. in > http://bugs.python.org/issue1067, Thomas suggests that these modules > need to be rewritten to use bytes internally and have separate APIs to > handle (unicode) text as desired, similar to the way file I/O was > redesigned. Another alternative would be to make these modules deal > strictly in bytes, but that would probably vastly reduce their > usefulness (though I don't know -- as I said, I don't use them). I guess that would be me, if you'll have me. I think asyncore and asynchat are valuable, and I'm willing to do what needs to be done to ensure that they remain in Py3k. ___ 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
Re: [Python-Dev] Python-Dev Digest, Vol 53, Issue 23
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote: > On Dec 5, 2007 9:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > The asyncore and asynchat modules are in a difficult position when it > > comes to Python 3000. None of the core developers use it or > > particularly care about it (AFAIK), and the API has problems because > > it wasn't written to deal with bytes vs. unicode. E.g. in > > http://bugs.python.org/issue1067, Thomas suggests that these modules > > need to be rewritten to use bytes internally and have separate APIs to > > handle (unicode) text as desired, similar to the way file I/O was > > redesigned. Another alternative would be to make these modules deal > > strictly in bytes, but that would probably vastly reduce their > > usefulness (though I don't know -- as I said, I don't use them). > I can look into it later this month, but for the short term, I'm a > little squeezed for time (work, finishing school, etc.). I am a bit > curious, however, I could have sworn that bytes were to become, > essentially, the 2.x str type (without some methods). If that is the > case, no changes should really be necessary, except for a few small > changes to asynchat with regards to line terminators. > Then again, I haven't really been keeping up in the p3k/pydev lists > for the last 6-8 months, and only the subject line of this posting > caught my eye (because I use asyncore/asynchat, and support users of > asyncore/asynchat that contact me directly). You're exactly right about the (lack of) problems and the correct way to fix them. I've placed a patch in the bug tracker that takes that very approach. http://bugs.python.org/issue1563 ___ 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
[Python-Dev] patching asyncore and asynchat
I've posted a new patch with the documentation for handle_expt and handle_error adjusted, thanks to the feedback from Giampaolo Rodola and James Y Knight. http://bugs.python.org/issue1563 ___ 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
Re: [Python-Dev] patching asyncore and asynchat
> From: "Giampaolo Rodola'" <[EMAIL PROTECTED]> > I remembered right now that there's a patch pending which should be > included in the trunk before solving issues related to py3k and/or > applying other changes: > http://bugs.python.org/issue1736190 > Since it solves a lot of older and newer asyncore/chat issues I guess > you should work on that one instead of using the current asyncore/chat > versions available in the trunk. Those patches can't be applied directly to the py3k branch, where Guido asked me to work, so instead I've ported them and merged them with my patch where appropriate. This merged patch should address both py3k porting and the issues in raised in 1736190 http://bugs.python.org/issue1563 ___ 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
Re: [Python-Dev] Python-Dev Digest, Vol 54, Issue 57
On Tue, 15 Jan 2008 06:57:02 -0500, Kevin Jacobs wrote: > On Jan 15, 2008 6:24 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > > > On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote: > > > It makes sense, but personally I have never heard before of ~/.local. > > > Whereas ~/bin is something I am quite familiar with. > > > > Me too. python-dev is the only place I have heard of ~/.local. I have > > been using Linux (different distributions), Solaris and FreeBSD for quite > > a long time (though I have never used GNOME/KDE/etc.) > > > Never heard of it either, would be completely baffled if caught unawares by > it in the wild. Has anyone consulted with the LSB or a cross-platform > filesystem layout guide to see what the recommended best-practice is? I use ~/local, with a layout analogous to /usr, all the time. It's not a standard, but in my experience it is by far the best solution to installing things in the home directory. It doesn't matter much whether you call it local or .local or .pythonlocal (although that last would limit the utility somewhat, by implying that other things should be installed there). It does matter that it be a _subdirectory_ of ~, and that it be structured like /usr. To those folks who favor creating ~/bin, ~/lib, ~/share, ad nauseum, I point out that non-hidden, non-user-created files in ~ ought to be kept to a minimum. It is, after all, the user's default workspace. ___ 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
[Python-Dev] Py3k and asyncore/asynchat
A while back, I volunteered to update asyncore and asynchat for py3k. I posted a patch, and in response to feedback posted a more complicated patch+modification. Both versions have been languishing at http://bugs.python.org/issue1563 for a couple of months now without any further feedback or action. I need some more experienced member of the community to take some sort of action: reviews and suggestions are welcome, as is advice about which version I should continue on with. Committing the patch would also be acceptable :) ___ 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
Re: [Python-Dev] Py3k and asyncore/asynchat
They applied when posted them, but subsequent patches seem to have broken them. I've now posted updated patches that apply cleanly against revision 60780. On Feb 13, 2008 6:52 PM, Bill Janssen <[EMAIL PROTECTED]> wrote: > 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 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
Re: [Python-Dev] Py3k and asyncore/asynchat
First of all, you're conflating my two possible patches. One patch just addresses the problem of strings and bytes, as GvR asked me to do, and adds an 8-line class called iterator_producer that adapts iterators into producers. The patch doesn't change how the module works at all, and iterator_producer is not invoked anywhere within the code; it's purely for user convenience. I consider this the primary patch and would like to focus attention there if possible. The other patch combines the string and bytes fix with a porting of 1736190 and the other things you complain about, most of which scratch personal itches. If the patches you mention are actually going to be applied, then this patch isn't the way to go, and I'll maybe submit parts of it as separate patches. If they're just going to waste away in the bug tracker, though, this patch should be seriously considered. I'm quite willing to re-construct my string and bytes patch against a version of py3k in which the pre-existing patches are already applied. There needs to be forward progress, though: If nothing at all gets done, asyncore is going to be removed from the standard lib. I don't want to see that happen. On Thu, Feb 14, 2008 at 5:55 AM, Giampaolo Rodola' <[EMAIL PROTECTED]> wrote: > (wrong quoting: obvioulsly I was talking to Daniel) > > > ___ > 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/djarb%40highenergymagic.org > ___ 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
Re: [Python-Dev] UCS2/UCS4 default
On Thu, Jul 3, 2008 at 5:39 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 1. If you are advocating disallowing the use of characters outside the BMP > in a UCS-2 build, enumerate the advantages of doing so (paying particular > attention to any advantages which cannot be obtained simply by using an > appropriate codec that disallows non-BMP characters). Right now, the same python code has different meaning, depending on a compile-time option that most users didn't even set for themselves. Moreover, the errors caused by this semantic difference are not reported. There's just no way to justify that. You can't solve this problem by saying 'programmers should choose a codec that limits them to the BMP when they target 2-byte python,' because the problem specifically arises when code that works correctly in a 4-byte python is placed into a 2-byte python, an operation performed by the users rather than by programmers. Since 2-byte python is apparently a holdover for memory-limited (and presumably CPU-limited as well) systems, it doesn't make sense to impose on it the requirement of correctly dealing with surrogate pairs. Given that, it seems to me that the best solution would be to make 4-byte python the default, and also to make 2-byte python raise an exception when it encounters characters outside the BMP. This way, a mysterious and unreported semantic error becomes an explicit syntactic error. For programmers who want to target a 2-byte format (for win32 compatibility, for example), the correct choice of codec is a superior solution to forcing a 2-byte internal representation on python. ___ 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
Re: [Python-Dev] UCS2/UCS4 default
On Thu, Jul 3, 2008 at 6:42 AM, Mark Hammond <[EMAIL PROTECTED]> wrote: > For people on Windows, win32 isn't a "compatibility" consideration. I > suspect most users of the other platforms MAL mentioned and all others with > their own native unicode implementations would agree. I'm sorry, but you're wrong. Interfacing python to interoperate with the underlying system is compatibility. Surely your own win32 extensions already address this necessity. Regardless, as I said before, nothing justifies silently changing the meaning of a program based on an option that most users don't set for themselves and are not aware of. When such a change would take place, it should be reported explicitly as an error. ___ 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
