On Mon, Aug 31, 2009 at 7:49 AM, Robert Brewer wrote:
> CherryPy 3.2 is now in beta, and mod_wsgi is nearly ready as well. Both
> support Python 3. :)
Excellent news! I just saw that PyYAML also suports 3.1. Slowly but
surely, 3.1 is gaining traction...
--
--Guido van Rossum (home page: http://w
Chris Withers wrote:
> Guido van Rossum wrote:
> > Being adults about it also means when to give up. Chris, please stop
> > arguing about this.
>
> Sure. Even if people had agreed to this change, it wouldn't end up in
a
> python release I could use for this project.
>
> > There are plenty of tech
Guido van Rossum wrote:
Being adults about it also means when to give up. Chris, please stop
arguing about this.
Sure. Even if people had agreed to this change, it wouldn't end up in a
python release I could use for this project.
There are plenty of techniques you can use to get
what you w
2009/8/27 Barry Warsaw :
> On Aug 27, 2009, at 9:08 AM, exar...@twistedmatrix.com wrote:
>
>> This is what I meant when I said what I said about correct code. If you're
>> happy to have encoding errors and corrupt data, then I guess you're happy to
>> have a function like setdefaultencoding.
>
>
On Aug 27, 2009, at 9:08 AM, exar...@twistedmatrix.com wrote:
This is what I meant when I said what I said about correct code. If
you're happy to have encoding errors and corrupt data, then I guess
you're happy to have a function like setdefaultencoding.
Whatever happened to "we're all adu
On 26 Aug, 11:51 pm, ch...@simplistix.co.uk wrote:
exar...@twistedmatrix.com wrote:
The ability to change the default encoding is a misfeature. There's
essentially no way to write correct Python code in the presence of
this feature.
How so? If every single piece of text in your project is en
Chris Withers writes:
> > How can you be certain that any string is UTF-8 when doing any
> > reasonable IO?
>
> Careful checking, and a knowledge for people working on the app's
> development that anything else will result in severe pain, both physical
> and mental ;-)
If you're *that* c
Chris Withers wrote:
> M.-A. Lemburg wrote:
>> Let's look at this from another angle: sys.setdefaultencoding()
>> is only made available for use in site.py.
>
> ...see this:
>
> http://mail.python.org/pipermail/python-dev/2009-August/091391.html
>
> I would like to use sitecustomize.py for all
> if hasattr(sys, "setdefaultencoding"):
> +sys._setdefaultencoding = sys.setdefaultencoding
> del sys.setdefaultencoding
Ah, so you didn't want to rename the function. I agree that this
would not break backwards compatibility.
I guess the basic objection remains: making it
>> One specific problem is dictionaries will stop working correctly if you
>> set the default encoding to anything but ASCII.
>
> ...except they haven't.
In your application. Can you please agree that this a semantical problem
that is completely unacceptable for language design?
> Indeed, but t
Martin v. Löwis wrote:
- If people were somehow relying on sys not having an attribute called
_setdefaultencoding, or were relying on stuffing an attribute into sys
called _setdefaultencoding then... well... that seems pretty unlikely ;-)
If people were using the reload trickery, that would bre
Chris Withers wrote:
> Martin v. Löwis wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
>>> Crazy idea: how about mutating it into sys._setdefaultencoding rather
>>> than deleting it?
>>
>> Please d
Martin v. Löwis wrote:
The ability to change the default encoding is a misfeature. There's
essentially no way to write correct Python code in the presence of
this feature.
How so? If every single piece of text in your project is encoded in a
superset of ascii (such as utf-8), why would this be
Martin v. Löwis wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
Crazy idea: how about mutating it into sys._setdefaultencoding rather
than deleting it?
Please don't post crazy ideas unless you really me
>> In retrospect, it should have been called sys._setdefaultencoding().
>> That sends an extra signal that it's not meant for general use.
>
> Crazy idea: how about mutating it into sys._setdefaultencoding rather
> than deleting it?
Please don't post crazy ideas unless you really mean them.
This
>> The ability to change the default encoding is a misfeature. There's
>> essentially no way to write correct Python code in the presence of
>> this feature.
>
> How so? If every single piece of text in your project is encoded in a
> superset of ascii (such as utf-8), why would this be a problem?
Guido van Rossum wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
Crazy idea: how about mutating it into sys._setdefaultencoding rather
than deleting it?
Chris
--
Simplistix - Content Management, Batc
M.-A. Lemburg wrote:
Let's look at this from another angle: sys.setdefaultencoding()
is only made available for use in site.py.
...see this:
http://mail.python.org/pipermail/python-dev/2009-August/091391.html
I would like to use sitecustomize.py for all the very good reasons given
in this t
exar...@twistedmatrix.com wrote:
The ability to change the default encoding is a misfeature. There's
essentially no way to write correct Python code in the presence of this
feature.
How so? If every single piece of text in your project is encoded in a
superset of ascii (such as utf-8), why w
On 2009-08-25 13:29 PM, Guido van Rossum wrote:
On Tue, Aug 25, 2009 at 11:10 AM, Robert Kern wrote:
On 2009-08-25 12:37 PM, Guido van Rossum wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
Consideri
On Tue, Aug 25, 2009 at 11:10 AM, Robert Kern wrote:
> On 2009-08-25 12:37 PM, Guido van Rossum wrote:
>>
>> In retrospect, it should have been called sys._setdefaultencoding().
>> That sends an extra signal that it's not meant for general use.
>
> Considering all of the sys._getframe() hacks out t
On 2009-08-25 12:37 PM, Guido van Rossum wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
Considering all of the sys._getframe() hacks out there, I suspect that this
would encourage more abuse of the fun
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http:
Chris Withers wrote:
> Hi All,
>
> Would anyone object if I removed the deletion of of
> sys.setdefaultencoding in site.py?
>
> I'm guessing "yes!" so thought I'd state my reasons now:
>
> This deletion appears to be pretty flimsy; reload(sys) and you have it
> back. Which is lucky, because I ne
On 04:08 pm, ch...@simplistix.co.uk wrote:
Hi All,
Would anyone object if I removed the deletion of of
sys.setdefaultencoding in site.py?
I'm guessing "yes!" so thought I'd state my reasons now:
This deletion appears to be pretty flimsy; reload(sys) and you have it
back. Which is lucky, bec
Hi All,
Would anyone object if I removed the deletion of of
sys.setdefaultencoding in site.py?
I'm guessing "yes!" so thought I'd state my reasons now:
This deletion appears to be pretty flimsy; reload(sys) and you have it
back. Which is lucky, because I need it after it's been deleted...
26 matches
Mail list logo
