Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
neil, i just intended to worry that returning a unicode object from ``str()`` would break assumptions about the way that 'type definers' like ``str()``, ``int()``, ``float()`` and so on work, but i quickly realized that e.g. ``int()`` does return a long where appropriate! since the principle works there one may surmise it will also work for ``str()`` in the long run. one point i don't seem to understand right now is why it says in the function definition:: if type(s) is str or type(s) is unicode: ... instead of using ``isinstance()``. Testing for ``type()`` means that instances of derived classes (that may or may not change nothing or almost nothing to the underlying class) when passed to a function that uses ``str()`` will behave in a different way! isn't it more realistic and commonplace to assume that derivatives of a class do fulfill the requirements of the underlying class? -- which may turn out to be wrong! but still... the code as it stands means i have to remember that *in this special case only* (when deriving from ``unicode``), i have to add a ``__str__()`` method myself that simply returns ``self``. then of course, one could change ``unicode.__str__()`` to return ``self``, itself, which should work. but then, why so complicated? i suggest to change said line to:: if isinstance( s, ( str, unicode ) ): ... any objections? _wolf -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Admin access using svn+ssh
Barry Warsaw wrote: >>Not sure what "the right place" would be: [EMAIL PROTECTED] >>I think the email could look any way we want it to look. > > > I think it should be @python.org where is the > firstname.lastname (with some exceptions) scheme that we've agreed on. > I actually /don't/ want all commits to look like they're coming from > [EMAIL PROTECTED] Ok, I have now changed all user names for the python repository to firstname.lastname. That should allow to use them in From: fields of commit email. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Subversion instructions
As some people have been struggling with svn+ssh, I wrote a few instructions at http://www.python.org/dev/svn.html The main issues people have been struggling with are: - you really should use an agent, or else you have to type the private key passphrase three times on checkout - on windows, putty works fine, but you really should use the agent (pageant), or else plink might not find your key. Also, if you use Putty profiles, make sure to add the user name (pythondev) into the profile - we need SSH2 keys; SSH1 is disabled on svn.python.org. Some of you had been using SSH1 keys on sf.net all these years; you will need to generate SSH2 keys. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
Neil Schemenauer <[EMAIL PROTECTED]> writes: > [Please mail followups to [EMAIL PROTECTED] > > The PEP has been rewritten based on a suggestion by Guido to change > str() rather than adding a new built-in function. Based on my > testing, I believe the idea is feasible. It would be helpful if > people could test the patched Python with their own applications and > report any incompatibilities. > I like the fact that currently unicode(x) is guarateed to return a unicode instance, or raises a UnicodeDecodeError. Same for str(x), which is guaranteed to return a (byte) string instance or raise an error. Wouldn't also a new function make the intent clearer? So I think I'm +1 on the text() built-in, and -0 on changing str. Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
Thomas Heller wrote: > Neil Schemenauer <[EMAIL PROTECTED]> writes: > > >>[Please mail followups to [EMAIL PROTECTED] >> >>The PEP has been rewritten based on a suggestion by Guido to change >>str() rather than adding a new built-in function. Based on my >>testing, I believe the idea is feasible. It would be helpful if >>people could test the patched Python with their own applications and >>report any incompatibilities. >> > > > I like the fact that currently unicode(x) is guarateed to return a > unicode instance, or raises a UnicodeDecodeError. Same for str(x), > which is guaranteed to return a (byte) string instance or raise an > error. > > Wouldn't also a new function make the intent clearer? > > So I think I'm +1 on the text() built-in, and -0 on changing str. Same here. A new API would also help make the transition easier from the current mixed data/text type (strings) to data-only (bytes) and text-only (text, renamed from unicode) in Py3.0. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 23 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Admin access using svn+ssh
On 8/22/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > James Y Knight wrote: > > It seems a waste to use SVN's webdav support just for anon access. > > The svnserve method works well for anon access. The only reason to > > use svn webdav IMO is if you want to use that for authenticated > > access. But since you're talking about using svn+ssh for that.. > > It has the advantage that we can easily point people to files > with a web browser; they don't need an svn client. It also allows anonymous svn checkouts for people behind firewalls that only allow HTTP through. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
just tested the proposed implementation on a unicode-naive module basically using import sys import __builtin__ reload( sys ); sys.setdefaultencoding( 'utf-8' ) __builtin__.__dict__[ 'str' ] = new_str_function et voilà, str() calls in the module are rewritten, and print u'düsseldorf' does work as expected(*) (even on systems where i have no access to sitecustomize, like at my python-friendly isp's servers). --- * my expectation is that unicode strings do print out as utf-8, as i can't see any better solution. i suggest to make this option available e.g. via a module in the standard lib to ease transition for people in case the pep doesn't make it. it may be applied where deemed necessary and left ignored otherwise. if nobody thinks the reload hack is too awful and this solution stands testing, i guess i'll post it to the aspn cookbook. after all these countless hours of hunting down ordinal not in range, finally i'm starting to see some light in the issue. _wolf On Tue, 23 Aug 2005 12:39:03 +0200, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Thomas Heller wrote: >> Neil Schemenauer <[EMAIL PROTECTED]> writes: >> >> >>> [Please mail followups to [EMAIL PROTECTED] >>> >>> The PEP has been rewritten based on a suggestion by Guido to change >>> str() rather than adding a new built-in function. Based on my >>> testing, I believe the idea is feasible. It would be helpful if >>> people could test the patched Python with their own applications and >>> report any incompatibilities. >>> >> >> >> I like the fact that currently unicode(x) is guarateed to return a >> unicode instance, or raises a UnicodeDecodeError. Same for str(x), >> which is guaranteed to return a (byte) string instance or raise an >> error. >> >> Wouldn't also a new function make the intent clearer? >> >> So I think I'm +1 on the text() built-in, and -0 on changing str. > > Same here. > > A new API would also help make the transition easier from the > current mixed data/text type (strings) to data-only (bytes) > and text-only (text, renamed from unicode) in Py3.0. > -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
This patch should be reverted or fixed so that the Py2.5 build works again. It contains a disasterous search and replace error that prevents it from compiling. Hence, it couldn't have passed the test suite before being checked in. Also, all of the project and config files need to be updated for the new modules. > -Original Message- > From: [EMAIL PROTECTED] [mailto:python-checkins- > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Sunday, August 21, 2005 2:46 PM > To: [EMAIL PROTECTED] > Subject: [Python-checkins] python/dist/src/Modules _hashopenssl.c, > NONE,2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE,2.1 md5module.c, > 2.35, 2.36 shamodule.c, 2.22, 2.23 > > Update of /cvsroot/python/python/dist/src/Modules > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32064/Modules > > Modified Files: > md5module.c shamodule.c > Added Files: > _hashopenssl.c sha256module.c sha512module.c > Log Message: > [ sf.net patch # 1121611 ] > > A new hashlib module to replace the md5 and sha modules. It adds > support for additional secure hashes such as SHA-256 and SHA-512. The > hashlib module uses OpenSSL for fast platform optimized > implementations of algorithms when available. The old md5 and sha > modules still exist as wrappers around hashlib to preserve backwards > compatibility. ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > This patch should be reverted or fixed so that the Py2.5 build works > again. > > It contains a disasterous search and replace error that prevents it from > compiling. Hence, it couldn't have passed the test suite before being > checked in. It works for me, on OS X. Passes the test suite, even. I presume you're on Windows of some kind? > Also, all of the project and config files need to be updated for the new > modules. Well, yes. But if Greg is on some unix-a-like, he can only update the unix build files (which he has done; it's in setup.py). Cheers, mwh -- If you are anal, and you love to be right all the time, C++ gives you a multitude of mostly untimportant details to fret about so you can feel good about yourself for getting them "right", while missing the big picture entirely -- from Twisted.Quotes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 342 Implementation
"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > Could someone please make an independent check to verify an issue with > the 342 checkin. The test suite passes but when I run IDLE and open a > new window (using Control-N), it crashes and burns. > > The problem does not occur just before the checkin: > cvs up -D "2005-08-01 18:00" > But emerges immediately after: > cvs up -D "2005-08-01 21:00" Is this still happening? I'm not seeing any unusual flakiness, but then I can't run IDLE (OS X, no Tk). It's not exactly a minimal test case :) Cheers, mwh -- A difference which makes no difference is no difference at all. -- William James (I think. Reference anyone?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 342 Implementation
[Raymond Hettinger] > > > Could someone please make an independent check to verify an issue with > > the 342 checkin. The test suite passes but when I run IDLE and open a > > new window (using Control-N), it crashes and burns. > > > > The problem does not occur just before the checkin: > > cvs up -D "2005-08-01 18:00" > > But emerges immediately after: > > cvs up -D "2005-08-01 21:00" > > Is this still happening? I'm not seeing any unusual flakiness, but > then I can't run IDLE (OS X, no Tk). Yes, it is still happening. No one has yet offered an independent confirmation. > It's not exactly a minimal test case :) Right ;-) Once narrowed down, the problem and solution will likely be obvious. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
Neil Schemenauer wrote: > The PEP has been rewritten based on a suggestion by Guido to change > str() rather than adding a new built-in function. Based on my testing, I > believe the idea is feasible. note that this breaks chapter 3 of the tutorial: http://docs.python.org/tut/node5.html#SECTION00513 where str() is first introduced. ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
[Raymond Hettinger] > > This patch should be reverted or fixed so that the Py2.5 build works > > again. > > > > It contains a disasterous search and replace error that prevents it from > > compiling. Hence, it couldn't have passed the test suite before being > > checked in. [Michael Hudson] > It works for me, on OS X. Passes the test suite, even. I presume > you're on Windows of some kind? Here's an excerpt from the check-in note for sha512module.c: RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); Perhaps OS X has some sort of Steve Jobs special constant suffix "ULL" that Mr. Gates and the ANSI C folks have yet to accept ;-) If it works for you, then it probably means that sha512module.c was left out of the build. Maybe sha512module.c wasn't supposed to be checked in? > > Also, all of the project and config files need to be updated for the new > > modules. > > Well, yes. But if Greg is on some unix-a-like, he can only update the > unix build files (which he has done; it's in setup.py). The project files are just text files and can be updated simply and directly. But yes, that is no big deal and I'll just do it for him once the code gets to a compilable state. Aside from the project files, there is still config.c and whatnot. We should put together a checklist of all the things that need to be updated when a new module is added. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
On Tue, Aug 23, 2005 at 10:46:36AM +0200, Wolfgang Lipp wrote: > one point i don't seem to understand right now is why it says in the > function definition:: > > if type(s) is str or type(s) is unicode: > ... > > instead of using ``isinstance()``. I don't think isinstance() would be okay. That test is meant as an optimization to avoid calling __str__ on str and unicode instances. Subclasses should still have their __str__ method called otherwise they cannot override it. > the code as it stands means i have to remember that *in this special > case only* (when deriving from ``unicode``), i have to add a > ``__str__()`` method myself that simply returns ``self``. Ah, I see that unicode.__str__ returns a str instance. > then of course, one could change ``unicode.__str__()`` to return > ``self``, itself, which should work. but then, why so complicated? I think that may be the right fix. Neil ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
> Here's an excerpt from the check-in note for sha512module.c: > > > RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); > RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); > RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); > RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); > RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); > > Perhaps OS X has some sort of Steve Jobs special constant suffix "ULL" > that Mr. Gates and the ANSI C folks have yet to accept ;-) It's valid C99, meaning "this is an unsigned long long". -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote: > > then of course, one could change ``unicode.__str__()`` to return > > ``self``, itself, which should work. but then, why so complicated? > >I think that may be the right fix. No, it isn't. Right now str(u"x") coerces the unicode object to a string, so changing this will be backwards-incompatible with any existing programs. I think the new builtin is actually the right way to go for both 2.x and 3.x Pythons. i.e., text() would be a builtin in 2.x, along with a new bytes() type, and in 3.x text() could replace the basestring, str and unicode types. I also think that the text() constructor should have a signature of 'text(ob,encoding="ascii")'. In the default case, strings can be returned by text() as long as they are pure ASCII (making the code str-stable *and* unicode-safe). In the non-default case, a unicode object should always be returned, making the code unicode-safe but not str-stable. Allowing text() to return 8-bit strings would be an obvious violation of its name: it's for text, not bytes. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
i have to revise my last posting -- exporting the new ``str`` pure-python implementation breaks -- of course! -- as soon as ``isinstance(x,str)`` [sic] is used. right now it breaks because you can't have a function as the second argument of ``isinstance()``, but even if that could be avoided by canny programming, the fact remains that any object derived from e.g. a string literal will still be constructed from the underlying implementation and can't therefore be an instance of the old ``str``. also, ``str.__bases__`` is not extendable (it's a tuple) and not replaceable (it's a built-in), so there seems to be no way to get near a truly working solution except with C-level patches. On Tue, 23 Aug 2005 17:21:57 +0200, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > I don't think isinstance() would be okay. That test is meant as an > optimization to avoid calling __str__ on str and unicode instances. > Subclasses should still have their __str__ method called otherwise > they cannot override it. makes perfect sense, i'll change the line back. _wolf ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > [Raymond Hettinger] >> > This patch should be reverted or fixed so that the Py2.5 build works >> > again. >> > >> > It contains a disasterous search and replace error that prevents it > from >> > compiling. Hence, it couldn't have passed the test suite before > being >> > checked in. > > [Michael Hudson] >> It works for me, on OS X. Passes the test suite, even. I presume >> you're on Windows of some kind? > > > Here's an excerpt from the check-in note for sha512module.c: > > > RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); > > RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); > > RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); > > RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); > > RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); > > Perhaps OS X has some sort of Steve Jobs special constant suffix "ULL" > that Mr. Gates and the ANSI C folks have yet to accept ;-) It's an C99 unsigned long long literal, AFAICT (p70 of the PDF I found lying around somewhere...), so I think it's just Bill who's behind. However, Python doesn't require C99, so it's pretty dodgy code by our standards. Hmm. You have PY_LONG_LONG #define-d, right? Does VC++ 6 (that's what you use, right?) support any kind of long long literal? > If it works for you, then it probably means that sha512module.c was left > out of the build. Nope: [EMAIL PROTECTED] build-debug]$ ./python.exe Python 2.5a0 (#1, Aug 23 2005, 13:24:32) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import _sha512 [44297 refs] > Maybe sha512module.c wasn't supposed to be checked in? I think if you have a sufficiently modern openssl it's unnecessary. > The project files are just text files and can be updated simply and > directly. But yes, that is no big deal and I'll just do it for him once > the code gets to a compilable state. > > Aside from the project files, there is still config.c and whatnot. Does anything need to be done there? Oh, PC/config.c, right? > We should put together a checklist of all the things that need to be > updated when a new module is added. Sounds like it! :) Cheers, mwh -- This makes it possible to pass complex object hierarchies to a C coder who thinks computer science has made no worthwhile advancements since the invention of the pointer. -- Gordon McMillan, 30 Jul 1998 ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules_hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
Gareth McCaughan wrote: > It's valid C99, meaning "this is an unsigned long long". since when does Python require C99 compilers? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicodestrings
Neil Schemenauer wrote:
> The PEP has been rewritten based on a suggestion by Guido to change
> str() rather than adding a new built-in function. Based on my testing, I
> believe the idea is feasible.
Fredrik Lundh replies:
> note that this breaks chapter 3 of the tutorial:
>
> http://docs.python.org/tut/node5.html#SECTION00513
>
> where str() is first introduced.
It's hardly "introduced"... the only bit I found reads:
... When a Unicode string is printed, written to a file, or converted
with str(), conversion takes place using this default encoding.
>>> u"abc"
u'abc'
>>> str(u"abc")
'abc'
>>> u"äöü"
u'\xe4\xf6\xfc'
>>> str(u"äöü")
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-2: ordinal not in range(128)
To convert a Unicode string into an 8-bit string using a specific encoding,
Unicode objects provide an encode() method that takes one argument, the
name of the encoding. Lowercase names for encodings are preferred.
>>> u"äöü".encode('utf-8')
'\xc3\xa4\xc3\xb6\xc3\xbc'
I think that if we just took out the example of str() usage and replaced
it with a sentence or two that DID introduce the (revised) str() function,
it ought to work. In particular, it could mention that you can call str()
on any object, which isn't stated here at all.
-- Michael Chermside
___
Python-Dev mailing list
[email protected]
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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
Michael Hudson <[EMAIL PROTECTED]> writes: > "Raymond Hettinger" <[EMAIL PROTECTED]> writes: > >> [Raymond Hettinger] >>> > This patch should be reverted or fixed so that the Py2.5 build works >>> > again. >>> > >>> > It contains a disasterous search and replace error that prevents it >> from >>> > compiling. Hence, it couldn't have passed the test suite before >> being >>> > checked in. >> >> [Michael Hudson] >>> It works for me, on OS X. Passes the test suite, even. I presume >>> you're on Windows of some kind? >> >> >> Here's an excerpt from the check-in note for sha512module.c: >> >> >> RND(S[0],S[1],S[2],S[3],S[4],S[5],S[6],S[7],0,0x428a2f98d728ae22ULL); >> >> RND(S[7],S[0],S[1],S[2],S[3],S[4],S[5],S[6],1,0x7137449123ef65cdULL); >> >> RND(S[6],S[7],S[0],S[1],S[2],S[3],S[4],S[5],2,0xb5c0fbcfec4d3b2fULL); >> >> RND(S[5],S[6],S[7],S[0],S[1],S[2],S[3],S[4],3,0xe9b5dba58189dbbcULL); >> >> RND(S[4],S[5],S[6],S[7],S[0],S[1],S[2],S[3],4,0x3956c25bf348b538ULL); >> >> Perhaps OS X has some sort of Steve Jobs special constant suffix "ULL" >> that Mr. Gates and the ANSI C folks have yet to accept ;-) > > It's an C99 unsigned long long literal, AFAICT (p70 of the PDF I found > lying around somewhere...), so I think it's just Bill who's behind. > However, Python doesn't require C99, so it's pretty dodgy code by our > standards. > > Hmm. You have PY_LONG_LONG #define-d, right? Does VC++ 6 (that's > what you use, right?) support any kind of long long literal? The suffix seems to be 'ui64'. From vc6 limits.h: #if _INTEGRAL_MAX_BITS >= 64 /* minimum signed 64 bit value */ #define _I64_MIN(-9223372036854775807i64 - 1) /* maximum signed 64 bit value */ #define _I64_MAX 9223372036854775807i64 /* maximum unsigned 64 bit value */ #define _UI64_MAX 0xui64 #endif Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Modules _hashopenssl, sha256, sha512 compile in MinGW, test_hmac.py passes
Hello, I can also report that MinGW can compile the said modules and (after updating config.c, etc.) the resulting code passes as follows: $ python -i ../Lib/test/test_hmac.py test_md5_vectors (__main__.TestVectorsTestCase) ... ok test_sha_vectors (__main__.TestVectorsTestCase) ... ok test_normal (__main__.ConstructorTestCase) ... ok test_withmodule (__main__.ConstructorTestCase) ... ok test_withtext (__main__.ConstructorTestCase) ... ok test_default_is_md5 (__main__.SanityTestCase) ... ok test_exercise_all_methods (__main__.SanityTestCase) ... ok test_attributes (__main__.CopyTestCase) ... ok test_equality (__main__.CopyTestCase) ... ok test_realcopy (__main__.CopyTestCase) ... ok -- Ran 10 tests in 0.050s OK >>> Are these moduels going to be built into the core? Regards Khalid _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules_hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
On Tuesday 2005-08-23 16:51, Fredrik Lundh wrote: > Gareth McCaughan wrote: > > > It's valid C99, meaning "this is an unsigned long long". > > since when does Python require C99 compilers? > > It doesn't, of course, and I hope it won't for a good while. I was just responding to this: | Perhaps OS X has some sort of Steve Jobs special constant suffix "ULL" | that Mr. Gates and the ANSI C folks have yet to accept since in fact Mr Gates and the ANSI C folks (and the gcc folks, and probably plenty of others I can't check so easily) *have* accepted it. -- g ___ Python-Dev mailing list [email protected] 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-checkins]python/dist/src/Modules_hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
[Gareth] > > It's valid C99, meaning "this is an unsigned long long". > since when does Python require C99 compilers? Except from PEP 7: "Use ANSI/ISO standard C (the 1989 version of the standard)." ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules_hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Gareth McCaughan wrote: > >> It's valid C99, meaning "this is an unsigned long long". > > since when does Python require C99 compilers? Well, it doesn't, but Raymond was suggesting the code was GCC specific, or something. Cheers, mwh -- Check out the comments in this source file that start with: # Oh, lord help us. -- Mark Hammond gets to play with the Outlook object model ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
[Michael Hudson] > It's an C99 unsigned long long literal, AFAICT (p70 of the PDF I found > lying around somewhere...), so I think it's just Bill who's behind. > However, Python doesn't require C99, so it's pretty dodgy code by our > standards. More than just dodgy. Except from PEP 7: "Use ANSI/ISO standard C (the 1989 version of the standard)." Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
On Tue, Aug 23, 2005 at 11:43:02AM -0400, Phillip J. Eby wrote: > At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote: > >> then of course, one could change ``unicode.__str__()`` to return > >> ``self``, itself, which should work. but then, why so complicated? > > > >I think that may be the right fix. > > No, it isn't. Right now str(u"x") coerces the unicode object to a > string, so changing this will be backwards-incompatible with any > existing programs. I meant that for the implementation of the PEP, changing unicode.__str__ to return self seems to be the right fix. Whether you believe that str() should be allowed to return unicode instances is a different question. > I think the new builtin is actually the right way to go for both 2.x and > 3.x Pythons. i.e., text() would be a builtin in 2.x, along with a new > bytes() type, and in 3.x text() could replace the basestring, str and > unicode types. Perhaps the critical question is what will the string type in P3k be called? If it will be 'str' then I think the PEP makes sense. If it will be something else, then there should be a corresponding type slot (e.g. __text__). What method does your proposed text() built-in call? > I also think that the text() constructor should have a signature of > 'text(ob,encoding="ascii")'. I think that's a bad idea. We want to get away from ASCII and use Unicode instead. > In the default case, strings can be returned by text() as long as > they are pure ASCII (making the code str-stable *and* > unicode-safe). I think you misunderstand the PEP. Your proposed function is neither Unicode-safe nor str-stable, the worst of both worlds. Passing it a unicode string that contains non-ASCII characters would result in an exception (not Unicode-safe). Passing it a str results in a unicode return value (not str-stable). Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
On Tue, Aug 23, 2005 at 05:45:27PM +0200, Wolfgang Lipp wrote:
> i have to revise my last posting -- exporting the new ``str``
> pure-python implementation breaks -- of course! -- as soon
> as ``isinstance(x,str)`` [sic] is used
Right. I tried to come up with a pure Python version so people
could test their code. This was my latest attempt before giving
up (from memory):
# inside site.py
_old_str_new = str.__new__
def _str_new(self, s):
if type(self) not in (str, unicode):
return _old_str_new(self, s)
if type(s) not in (str, unicode):
return s
r = s.__str__()
if not isinstance(r, (str, unicode)):
raise TypeError('__str__ returned non-string')
return r
str.__new__ = _str_new
It doesn't work though:
TypeError: can't set attributes of built-in/extension type 'str'
Maybe someone else has a clever solution.
Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revised PEP 349: Allow str() to return unicode strings
At 10:54 AM 8/23/2005 -0600, Neil Schemenauer wrote: >On Tue, Aug 23, 2005 at 11:43:02AM -0400, Phillip J. Eby wrote: > > At 09:21 AM 8/23/2005 -0600, Neil Schemenauer wrote: > > >> then of course, one could change ``unicode.__str__()`` to return > > >> ``self``, itself, which should work. but then, why so complicated? > > > > > >I think that may be the right fix. > > > > No, it isn't. Right now str(u"x") coerces the unicode object to a > > string, so changing this will be backwards-incompatible with any > > existing programs. > >I meant that for the implementation of the PEP, changing >unicode.__str__ to return self seems to be the right fix. Whether >you believe that str() should be allowed to return unicode instances >is a different question. > > > I think the new builtin is actually the right way to go for both 2.x and > > 3.x Pythons. i.e., text() would be a builtin in 2.x, along with a new > > bytes() type, and in 3.x text() could replace the basestring, str and > > unicode types. > >Perhaps the critical question is what will the string type in P3k be >called? If it will be 'str' then I think the PEP makes sense. If >it will be something else, then there should be a corresponding type >slot (e.g. __text__). What method does your proposed text() >built-in call? Heck if I know. :) I think the P3k string type should just be called 'text', though, so we can leave the whole unicode/str mess behind. > > I also think that the text() constructor should have a signature of > > 'text(ob,encoding="ascii")'. > >I think that's a bad idea. We want to get away from ASCII and use >Unicode instead. It's not str-stable if it returns unicode for a string input. > > In the default case, strings can be returned by text() as long as > > they are pure ASCII (making the code str-stable *and* > > unicode-safe). > >I think you misunderstand the PEP. Your proposed function is >neither Unicode-safe nor str-stable, the worst of both worlds. >Passing it a unicode string that contains non-ASCII characters would >result in an exception (not Unicode-safe). Passing it a str results >in a unicode return value (not str-stable). I think you misunderstand my proposal. :) I'm proposing rough semantics of: def text(ob, encoding='ascii'): if isinstance(ob,unicode): return ob ob = str(ob) # or ob.__text__, then fallback to __unicode__/__str__ if encoding=='ascii' and isinstance(ob,str): unicode(ob,encoding) # check for purity return ob # return the string if it's pure return unicode(ob, encoding) This is str-stable *and* unicode-safe. ___ Python-Dev mailing list [email protected] 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/dist/src/Doc/tut tut.tex,1.276,1.277
[EMAIL PROTECTED] wrote:
I'm not a native speaker, but...
> @@ -114,7 +114,7 @@
> programs, or to test functions during bottom-up program development.
> It is also a handy desk calculator.
>
> -Python allows writing very compact and readable programs. Programs
> +Python enables programs to written compactly and readably. Programs
> written in Python are typically much shorter than equivalent C or
> \Cpp{} programs, for several reasons:
> \begin{itemize}
...shouldn't it be "programs to be written compactly"?
> @@ -1753,8 +1753,8 @@
>
> \begin{methoddesc}[list]{pop}{\optional{i}}
> Remove the item at the given position in the list, and return it. If
> -no index is specified, \code{a.pop()} returns the last item in the
> -list. The item is also removed from the list. (The square brackets
> +no index is specified, \code{a.pop()} removes and returns the last item
> +in the list. The item is also removed from the list. (The square brackets
> around the \var{i} in the method signature denote that the parameter
> is optional, not that you should type square brackets at that
> position. You will see this notation frequently in the
Thats twice the same the same (removal from list).
> @@ -1985,7 +1987,9 @@
> \section{The \keyword{del} statement \label{del}}
>
> There is a way to remove an item from a list given its index instead
> -of its value: the \keyword{del} statement. This can also be used to
> +of its value: the \keyword{del} statement. Unlike the \method{pop()})
> +method which returns a value, the \keyword{del} keyword is a statement
> +and can also be used to
> remove slices from a list (which we did earlier by assignment of an
> empty list to the slice). For example:
The del keyword is a statement?
> @@ -2133,8 +2137,8 @@
> keys. Tuples can be used as keys if they contain only strings,
> numbers, or tuples; if a tuple contains any mutable object either
> directly or indirectly, it cannot be used as a key. You can't use
> -lists as keys, since lists can be modified in place using their
> -\method{append()} and \method{extend()} methods, as well as slice and
> +lists as keys, since lists can be modified in place using methods like
> +\method{append()} and \method{extend()} or modified with slice and
> indexed assignments.
Is the second "modified" necessary?
> @@ -5595,8 +5603,8 @@
> to round it again can't make it better: it was already as good as it
> gets.
>
> -Another consequence is that since 0.1 is not exactly 1/10, adding 0.1
> -to itself 10 times may not yield exactly 1.0, either:
> +Another consequence is that since 0.1 is not exactly 1/10,
> +summing ten values of 0.1 may not yield exactly 1.0, either:
>
> \begin{verbatim}
> >>> sum = 0.0
Is it clear from context that the "0.1 is not exactly 1/10" refers to
floating point only?
> @@ -5637,7 +5645,7 @@
> you can perform an exact analysis of cases like this yourself. Basic
> familiarity with binary floating-point representation is assumed.
>
> -\dfn{Representation error} refers to that some (most, actually)
> +\dfn{Representation error} refers to fact that some (most, actually)
> decimal fractions cannot be represented exactly as binary (base 2)
> fractions. This is the chief reason why Python (or Perl, C, \Cpp,
> Java, Fortran, and many others) often won't display the exact decimal
"...refers to the fact..."?
Reinhold
--
Mail address is perfectly valid!
___
Python-Dev mailing list
[email protected]
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/dist/src/Doc/tut tut.tex,1.276,1.277
At 07:23 PM 8/23/2005 +0200, Reinhold Birkenfeld wrote:
>[EMAIL PROTECTED] wrote:
>
>I'm not a native speaker, but...
>
> > @@ -114,7 +114,7 @@
> > programs, or to test functions during bottom-up program development.
> > It is also a handy desk calculator.
> >
> > -Python allows writing very compact and readable programs. Programs
> > +Python enables programs to written compactly and readably. Programs
> > written in Python are typically much shorter than equivalent C or
> > \Cpp{} programs, for several reasons:
> > \begin{itemize}
>
>...shouldn't it be "programs to be written compactly"?
It looks to me like the original text here should stand; Python doesn't
"enable programs to be written"; it enables people to write them. That is,
the passive voice should be avoided if possible. ;-)
> > @@ -1985,7 +1987,9 @@
> > \section{The \keyword{del} statement \label{del}}
> >
> > There is a way to remove an item from a list given its index instead
> > -of its value: the \keyword{del} statement. This can also be used to
> > +of its value: the \keyword{del} statement. Unlike the \method{pop()})
> > +method which returns a value, the \keyword{del} keyword is a statement
> > +and can also be used to
> > remove slices from a list (which we did earlier by assignment of an
> > empty list to the slice). For example:
>
>The del keyword is a statement?
The keyword certainly isn't. This section also looks like it should stand
the way it was, or else say that "unlike the pop() method, the del
statement can also be used to remove slices...".
___
Python-Dev mailing list
[email protected]
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-checkins] python/dist/src setup.py, 1.219, 1.220
On Mon, Aug 22, 2005 at 08:46:27AM -0400, Raymond Hettinger wrote: > > A new hashlib module to replace the md5 and sha modules. It adds > > support for additional secure hashes such as SHA-256 and SHA-512. The > > hashlib module uses OpenSSL for fast platform optimized > > implementations of algorithms when available. The old md5 and sha > > modules still exist as wrappers around hashlib to preserve backwards > > compatibility. > > I'm getting compilation errors: > > C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad > suffix on number' > C:\py25\Modules\sha512module.c(146) : error C2146: syntax error : > missing ')' before identifier 'L' > C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad > suffix on number' > C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad > suffix on number' > C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad > suffix on number' > C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad > suffix on number' > C:\py25\Modules\sha512module.c(146) : error C2059: syntax error : 'bad > suffix on number' > C:\py25\Modules\sha512module.c(146) : fatal error C1013: compiler limit > : too many open parentheses > > > Also, there should be updating entries to Misc/NEWS, > PC/VC6/pythoncore.dsp, and PC/config.c. > > > Raymond I don't have a win32 dev environment at the moment so i didn't see that. Sorry. If you remove the 'ULL' suffix from all of the 64bit constants in that file what happens? I added the ULLs to quelch the mass of warnings about constants being to large for the datatype that gcc 3.3 was spewing. -greg ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
> This patch should be reverted or fixed so that the Py2.5 build works > again. > > It contains a disasterous search and replace error that prevents it from > compiling. Hence, it couldn't have passed the test suite before being > checked in. > > Also, all of the project and config files need to be updated for the new > modules. It passes fine on linux. I don't have a windows dev environment. regardless, the quick way to work around the sha512 on windows issue is to comment it out in setup.py and comment out the sha384 and sha512 tests in test_hashlib.py and commit that until the complation issues are worked out. -g > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:python-checkins- > > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > > Sent: Sunday, August 21, 2005 2:46 PM > > To: [EMAIL PROTECTED] > > Subject: [Python-checkins] python/dist/src/Modules _hashopenssl.c, > > NONE,2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE,2.1 > md5module.c, > > 2.35, 2.36 shamodule.c, 2.22, 2.23 > > > > Update of /cvsroot/python/python/dist/src/Modules > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32064/Modules > > > > Modified Files: > > md5module.c shamodule.c > > Added Files: > > _hashopenssl.c sha256module.c sha512module.c > > Log Message: > > [ sf.net patch # 1121611 ] > > > > A new hashlib module to replace the md5 and sha modules. It adds > > support for additional secure hashes such as SHA-256 and SHA-512. The > > hashlib module uses OpenSSL for fast platform optimized > > implementations of algorithms when available. The old md5 and sha > > modules still exist as wrappers around hashlib to preserve backwards > > compatibility. ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src setup.py, 1.219, 1.220
[Gregory P. Smith] > I don't have a win32 dev environment at the moment so i didn't see > that. Sorry. No big deal. But we still have to get the code back to ANSI compliance. Do you have an ANSI-strict option with your compiler? Raymond ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules_hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
On Tue, 2005-08-23 at 11:51, Fredrik Lundh wrote: > Gareth McCaughan wrote: > > > It's valid C99, meaning "this is an unsigned long long". > > since when does Python require C99 compilers? Why, since Python 3.0 of course! -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src setup.py, 1.219, 1.220
Raymond Hettinger wrote: > But we still have to get the code back to ANSI compliance. > Do you have an ANSI-strict option with your compiler? Please don't call this "ANSI compliant". ANSI does many more thinks that writing C standards, and, in the specific case, the code *is* ANSI compliant as it stands - it just doesn't comply to C89. It complies to ISO C 99, which (I believe) is also an U.S. American national (ANSI) standard. gcc does have an option to force c89 compliance, but there is a good chance that Python stops compiling with option: on many systems, essential system headers fail to comply with C89 (in addition, activating that mode also makes many extensions unavailable). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 51 Million calls to _PyUnicodeUCS2_IsLinebreak() (???)
Hi, I'm working on Argon (http://www.third-bit.com/trac/argon) with Greg Wilson this summer We're having a very strange problem with Python's unicode parsing of source files. Basically, our CGI script was running extremely slowly on our production box (a pokey dual-Xeon 3GHz w/ 4GB RAM and 15K SCSI drives). Slow to the tune of 6-10 seconds per request. I eventually tracked this down to imports of our source tree; the actual request was completing in 300ms, the rest of the time was spent in __import__. After doing some gprof profiling, I discovered _PyUnicodeUCS2_IsLinebreak was getting called 51 million times. Our code is 1.2 million characters, so I hardly think it makes sense to call IsLinebreak 50 times for each character; and we're not even importing our entire source tree on every invocation. Our code is a fork of Trac, and originally had these lines at the top: # -*- coding: iso8859-1 -*- This made me suspicious, so I removed all of them. The CGI execution time immediately dropped to ~1 second. gprof revealed that _PyUnicodeUCS2_IsLinebreak is not called at all anymore. Now that our code works fast enough, I don't really care about this, but I thought python-dev might want to know something weird is going on with unicode splitlines. I documented my investigation of this problem; if anyone wants further details, just email me. (I'm not on python-dev) http://www.third-bit.com/trac/argon/ticket/525 Thanks in advance, Keir ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Except from PEP 7: > > "Use ANSI/ISO standard C (the 1989 version of the standard)." Just checked (P&B, Standard C): only one L allowed, not two. But with C99 compilers becoming more common, accidental usages of C99-isms in submitted code will likely become more common, especially when there is not a graceful C89 alternative. While the current policy should be followed while it remains the policy, it may need revision someday. Terry J. Reedy ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
> The project files are just text files and can be updated simply and > directly. But yes, that is no big deal and I'll just do it for him once > the code gets to a compilable state. I just checked in an update removing all of the ULLs. Could you check that it compiles on windows and passes test_hashlib.py now? It does leave gcc 3.x users with a big mess of compiler warnings to deal with but those can be worked around once the build is actually working everywhere. thanks. Greg > Aside from the project files, there is still config.c and whatnot. We > should put together a checklist of all the things that need to be > updated when a new module is added. that'd be helpful. :) ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
Terry Reedy wrote: > Just checked (P&B, Standard C): only one L allowed, not two. But with C99 > compilers becoming more common, accidental usages of C99-isms in submitted > code will likely become more common, especially when there is not a > graceful C89 alternative. While the current policy should be followed > while it remains the policy, it may need revision someday. I think Python switched to C89 in 1999 (shortly before C99 was published, IIRC). So the canonical time for switching to C99 would be in 2009, provided all interesting compilers have implemented it by then, atleast to the degree that Python would typically need. Regards, Martin ___ Python-Dev mailing list [email protected] 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-checkins] python/dist/src/Modules _hashopenssl.c, NONE, 2.1 sha256module.c, NONE, 2.1 sha512module.c, NONE, 2.1 md5module.c, 2.35, 2.36 shamodule.c, 2.22, 2.23
[Gregory P. Smith] > I just checked in an update removing all of the ULLs. Could you check > that it compiles on windows and passes test_hashlib.py now? Okay, all is well. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bare except clauses in PEP 348
The latest version of PEP 348 still proposes that a bare except clause will default to Exception instead of BaseException. Initially, I had thought that might be a good idea but now think it is doomed and needs to be removed from the PEP. A bare except belongs at the end of a try suite, not in the middle. This is obvious when compared to: if a:... elif b: ... elif c: ... else:... # The bare else goes at the end # and serves as a catchall or switch c case a: ... case b: ... default: ... # The bare default goes at the end # and serves as a catchall In contrast, Brett's 8/9 note revealed that the following would be allowable and common if the PEP is accepted in its current form: try: ... except: ... # A bare except in the middle. WTF? except (KeyboardInterrupt, SystemExit): ... The right way is, of course: try: ... except (KeyboardInterrupt, SystemExit): ... except: # Implicit or explicit match to BaseException # that serves as a catchall For those not needing a terminating exception handler, the rest of the PEP appropriately allows and encourages a simple and explicit solution that meets most needs: try: ... except Exception: ... The core issue is that the most obvious meaning of a bare except is "catchall", not "catchmost". When the latter is intended, the simple and explicit form shown in the last example is the way to go. If the former is intended, then either a bare except clause or explicit mention of BaseException will do nicely. However, under the PEP proposal, both new and existing code will suffer from having bare except clauses that look like they catch everything, are intended to catch everything, but, in fact, do not. That kind of optical illusion error must be avoided. There is no getting around our mind's propensity to interpret the bare form as defaulting to the top of the tree rather than the middle as proposed by the PEP. Likewise, there is no getting around the mental confusion caused a bare except clause in the middle of a try-suite rather than at the end. We have to avoid code that looks like it does one thing but actually does something else. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
On 8/23/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The latest version of PEP 348 still proposes that a bare except clause > will default to Exception instead of BaseException. Initially, I had > thought that might be a good idea but now think it is doomed and needs > to be removed from the PEP. If we syntactically enforce that the bare except, if present, must be last, would that remove your objection? I agree that a bare except in the middle is an anomaly, but that doesn't mean we can't keep bare except: as a shorthand for except Exception:. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bare except clauses in PEP 348
[Guido van Rossum] > If we syntactically enforce that the bare except, if present, must be > last, would that remove your objection? I agree that a bare except in > the middle is an anomaly, but that doesn't mean we can't keep bare > except: as a shorthand for except Exception:. Hmm. Prohibiting mid-suite bare excepts is progress and eliminates the case that causes immediate indigestion. As for the rest, I'm not as sure and it would be helpful to get thoughts from others on this one. My sense is that blocking the clause from appearing in the middle is treating the symptom and not the disease. The motivating case for the most of the PEP was that folks were writing bare except clauses and trapping more than they should. Much of the concern was dealt with just by giving a choice between writing Exception and BareException depending on the intended result. That leaves the question of the default value a bare except with Exception being the most useful and BaseException being the most obvious. While I don't doubt that Exception is the more useful, we have already introduced a new builtin and moved two other exceptions to meet this need. Going further and altering the meaning of bare except seems like overkill for a relatively small issue. My remaining concern is about obviousness. How much code has been written or will be written that intends a bare except to mean BaseException instead of Exception. Would such code erroneously pass a code review or inspection. I suspect it would. The code looks like does one thing but actually does something else. This may or may not be a big deal. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
