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 username@python.org where username is the
firstname.lastname (with some exceptions) scheme that we've agreed on.
I actually /don't/
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
people
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
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
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'
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
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
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:
[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
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:
[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
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
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);
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(ux) coerces the unicode object to a string,
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
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
Gareth McCaughan wrote:
It's valid C99, meaning this is an unsigned long long.
since when does Python require C99 compilers?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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:
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
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
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?
/F
It doesn't, of course, and I hope it won't for a good while.
I was just responding to this:
| Perhaps OS
[Gareth]
It's valid C99, meaning this is an unsigned long long.
/F
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.org
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
[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
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,
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
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
[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
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
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
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
[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
___
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! wink
-Barry
signature.asc
Description: This is a digitally signed message
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
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 (PB, Standard C): only one L allowed, not two. But with C99
compilers becoming more common, accidental usages of C99-isms
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
Terry Reedy wrote:
Just checked (PB, 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
[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
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
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.
[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
43 matches
Mail list logo
