[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
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
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 th
[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
Python-Dev@python.org
http://mail.python.o
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
> 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
"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
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
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 SCS
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
[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-D
> 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
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 algo
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 comp
[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 wri
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
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
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 f
[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 AN
"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
[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
Python-Dev@python.or
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:
| Per
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_norm
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
>>>
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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
"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
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 ca
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
> 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[
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 b
[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
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#SECTION
[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:
> > cv
"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 che
"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
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 fo
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
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
> > acce
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
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,
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
> p
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
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
44 matches
Mail list logo
