Michael Walter wrote:
Maybe switch became a keyword with the patch..
Ah, right. Good catch :-)
Regards,
Michael
On 6/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Thomas Lee wrote:
Hi all,
As the subject of this e-mail says, the attached patch adds a switch
statement to the Python
[georg.brandl]
Author: georg.brandl
Date: Fri Jun 9 20:45:48 2006
New Revision: 46795
Log:
RFE #1491485: str/unicode.endswith()/startswith() now accept a
tuple as first argument.
[Neal Norwitz]
What's the reason to not support any sequence and only support tuples?
It can't support any
You were bothered yet with function xrange ? :) I suggest to replace it.
-
for i in xrange(100): pass
vs.
for i in int[:100]: pass
-
-
for i
On 6/13/06, Tim Peters [EMAIL PROTECTED] wrote:
[georg.brandl]
Author: georg.brandl
Date: Fri Jun 9 20:45:48 2006
New Revision: 46795
Log:
RFE #1491485: str/unicode.endswith()/startswith() now accept a
tuple as first argument.
[Neal Norwitz]
What's the reason to not support any
# This crashes, but i need to print type(encoding_table) at end of cp1140.py
import imp, sys
path = sys.path
enc = imp.find_module('encodings')
imp.load_module('encodings', *enc)
path.append(enc[1])
cp1140 = imp.find_module('cp1140')
imp.load_module('cp1140', *cp1140)
###
0x00465689
On 6/13/06, Vladimir 'Yu' Stepanov [EMAIL PROTECTED] wrote:
You were bothered yet with function xrange ? :) I suggest to replace it.http://www.python.org/dev/peps/pep-0204/ (If you must really discuss this, which would probably be futile and senseless, please do it on python-3000 only.)
-- Thomas
Hi,
As I mentioned earlier I'd like to get patch 1446489 (support for
zip64 extensions in the zipfile module) in python 2.5. The patch
should be perfectly safe, it comes with unittests and a documentation
update. I'm also using this version of zipfile in (closed-source)
projects to handle
Thomas Wouters wrote:
http://www.python.org/dev/peps/pep-0204/
(If you must really discuss this, which would probably be futile and
senseless, please do it on python-3000 only.)
Certainly looks very similar. PEP-204 demands change in a parser
and considers a new design as replacement to
Ok, here's the frist half or May. I'd almost feel like I was catching
up if there wasn't going to be another summary waiting for me in two
days. ;-)
As always, please look it over and let me know if you have any
corrections/comments.
Thanks!
=
Announcements
=
All are missing parameters. I'm not sure of the proper signature, so
I didn't fix these:
Lib/encodings/punycode.py:217: No global (errors) found
Lib/encodings/utf_8_sig.py:33: No global (errors) found
Lib/encodings/uu_codec.py:109: No global (errors) found
IIUC (and I probably don't), mbcs is
On Mon, 12 Jun 2006 23:31:14 +0200, Thomas Wouters wrote:
I did partial imports into Mercurial and Bazaar-NG, but I got interrupted
and couldn't draw any conclusions -- although from looking at the
implementation, I don't think they'd scale very well at the moment (but that
could probably be
On 6/13/06, Neal Norwitz [EMAIL PROTECTED] wrote:
# This crashes, but i need to print type(encoding_table) at end of cp1140.pyHere's a shorter version:import codecsdecmap = u.join(unichr(i) for i in xrange(256))
print type(codecs.charmap_build(decmap))The source fo the crash is the EncodingMap
On 6/13/06, Thomas Wouters [EMAIL PROTECTED] wrote:
The source fo the crash is the EncodingMap type (defined in
unicodeobject.c); it has an invalid type:
Breakpoint 2, PyUnicode_BuildEncodingMap (string=0x2b97d44dbf40)
at Objects/unicodeobject.c:3213
(gdb) print EncodingMapType
$1 =
Fredrik,
could you check whether the get_machine_details() function
is causing the hand on your machine ?
Does anyone else observe this as well ?
I'm about to check in version 2.0 of pybench, but would like
to get this resolved first, if possible.
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Neal Norwitz wrote:
All are missing parameters. I'm not sure of the proper signature, so
I didn't fix these:
Lib/encodings/punycode.py:217: No global (errors) found
Lib/encodings/utf_8_sig.py:33: No global (errors) found
Lib/encodings/uu_codec.py:109: No global (errors) found
Fixed in
Steven's summary reminded me that PEP 343 was still sitting at 'Accepted' with
a couple of open issues still listed (ignore what PEP 0 claims for the moment ;)
Unless there are any objections, I'll move it to Final later this week,
marking the open issues as resolved in favour of what was in
Josiah Carlson wrote:
Boris Borcic [EMAIL PROTECTED] wrote:
Hello,
Armin Rigo wrote:
Hi,
On Wed, Jun 07, 2006 at 02:07:48AM +0200, Thomas Wouters wrote:
I just submitted http://python.org/sf/1501934 and assigned it to Neal so it
doesn't get forgotten before 2.5 goes out ;) It seems Python
On Tue, Jun 13, 2006, Ronald Oussoren wrote:
There are two backward incompatbile changes, both minor. First of all
ZipInfo will lose the file_offset attribute because calculating it
when opening a zipfile is very expensive (it basically requires a
full scan of the zipfile). This should
Hi Phillip,
On Mon, Jun 12, 2006 at 12:29:48PM -0400, Phillip J. Eby wrote:
This idea would address the needs of external maintainers (having a single
release history) while still allowing Python developers to modify the code
(if the external package is in Python's SVN repository).
It's
On Jun 12, 2006, at 8:42 PM, Steve Holden wrote:
Phillip J. Eby wrote:
[...]
So, to summarize, it's all actually Tim's fault, but only in a
parallel
universe where nobody believes in unit testing. ;-)
I'm sorry to contradict you, but every issue of significance is
already
known to
On Monday 12 June 2006 20:42, Steve Holden wrote:
Phillip J. Eby wrote:
I'm sorry to contradict you, but every issue of significance is already
known to be Barry's fault.
And don't forget, all the issues of no significance as well. Barry's been
busy! :-)
-Fred
--
Fred L. Drake, Jr.
On 13-jun-2006, at 15:08, Aahz wrote:
On Tue, Jun 13, 2006, Ronald Oussoren wrote:
There are two backward incompatbile changes, both minor. First of all
ZipInfo will lose the file_offset attribute because calculating it
when opening a zipfile is very expensive (it basically requires a
full
Greg Ewing [EMAIL PROTECTED] writes:
Terry Jones wrote:
The code below uses a RNG with period 5, is deterministic, and has one
initial state. It produces 20 different outcomes.
You misunderstand what's meant by outcome in this
context. The outcome of your algorithm is the whole
*sequence*
I just tried to upgrade Tools/pybench/ to my latest version,
so I imported pybench-2.0 into the externals/ tree and then
tried copying over the new version into the Tools/pybench/
trunk.
Unfortunately the final copy didn't actually replace the files in
Tools/pybench/ but instead created a
Boris Borcic [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
being transformed to profit from simplifications I expected sets to allow.
There, itemwise augmented assigments in loops very naturally transform to
wholesale augmented assignments without loops. Except for this wart.
Your
Martin v. Löwis wrote:
Walter Dörwald wrote:
The best way to throughly test the patch is of course to check it in. ;)
Is it too risky? ;)
At least I'd like to get a second review of the patch.
I've reviewed it, and am likely to check it in.
Great!
I notice that the
patch still has
Walter Dörwald wrote:
And passing MB_ERR_INVALID_CHARS in a call to MultiByteToWideChar()
doesn't help either, because AFAICT there's no information about the
error location. What could work would be to try MultiByteToWideChar()
with various string lengths to try to determine whether the error
Boris Borcic [EMAIL PROTECTED] wrote:
NB : That the compiler's interpretation has no use-cases is my crucial point,
it's the reason why I dared suggest a design bug - as you seem to take at
heart.
I think that Python's compiler with respect to augmented assignment and
nested scopes is
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
Here's the command I used:
svn copy svn+pythonssh://[EMAIL PROTECTED]/external/pybench-2.0 \
svn+pythonssh://[EMAIL PROTECTED]/python/trunk/Tools/pybench
Am I missing some final slash in the copy command or is there
a different
FYI: I've just checked in pybench 2.0 under Tools/pybench/.
Please give it a go and let me know whether the new
calibration strategy and default timers result in
better repeatability of the benchmark results.
I've tested the release extensively on Windows and Linux
and found that the test times
We'd like to invite you to attend a Python development sprint at
Google the week of Aug. 21. We will be hosting sprints on two
coasts--at Google HQ in Mountain View CA and at our New York City
office. You can find more information here:
http://wiki.python.org/moin/GoogleSprint
The sprint
Dan == Dan Christensen [EMAIL PROTECTED] writes:
Dan Greg Ewing [EMAIL PROTECTED] writes:
Terry Jones wrote:
The code below uses a RNG with period 5, is deterministic, and has one
initial state. It produces 20 different outcomes.
You misunderstand what's meant by outcome in this
context.
Dan Christensen wrote:
I think Terry's point is valid. While no one call to
random.shuffle(L) can produce every possible ordering of L (when
len(L) is large), since random.shuffle shuffle's the data in place,
repeated calls to random.shuffle(L) could in principle produce every
possible
Terry Jones wrote:
I was not meaning to say that anyone was wrong, just that I found Greg's
characterization a bit too general, or not as well defined as it might have
been.
I meant it in the context being discussed, which was a
shuffling algorithm being used the way shuffling algorithms
are
As I mentioned earlier I'd like to get patch 1446489 (support for
zip64 extensions in the zipfile module) in python 2.5. The patch
should be perfectly safe, it comes with unittests and a documentation
update. I'm also using this version of zipfile in (closed-source)
projects to handle
35 matches
Mail list logo
