Re: [Python-Dev] Switch statement

[M.-A. Lemburg]

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 language.
>> >
>> > However, I've been reading through PEP 275 and it seems that the PEP
>> > calls for a new opcode - SWITCH - to be added to support the new
>> > construct.
>> >
>> > I got a bit lost as to why the SWITCH opcode is necessary for the
>> > implementation of the PEP. The reasoning seems to be
>> > improving performance, but I'm not sure how a new opcode could improve
>> > performance.
>> >
>> > Anybody care to take the time to explain this to me, perhaps within the
>> > context of my patch?
>>
>> Could you upload your patch to SourceForge ? Then I could add
>> it to the PEP.
>>
>> Thomas wrote a patch which implemented the switch statement
>> using an opcode. The reason was probably that switch works
>> a lot like e.g. the for-loop which also opens a new block.
>>
>> Could you explain how your patch works ?
>>
>> BTW, I think this part doesn't belong into the patch:
>>
>> > Index: Lib/distutils/extension.py
>> > ===
>> > --- Lib/distutils/extension.py(revision 46818)
>> > +++ Lib/distutils/extension.py(working copy)
>> > @@ -185,31 +185,31 @@
>> >  continue
>> >
>> >  suffix = os.path.splitext(word)[1]
>> > -switch = word[0:2] ; value = word[2:]
>> > +switch_word = word[0:2] ; value = word[2:]
>>
>> -- 
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Source  (#1, Jun 12 2006)
>> >>> Python/Zope Consulting and Support ...http://www.egenix.com/
>> >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>> >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>> 
>> 2006-07-03: EuroPython 2006, CERN, Switzerland  20 days left
>>
>> ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>>
>>

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 13 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  19 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
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] r46795 - in python/trunk: Doc/lib/libstdtypes.tex Lib/test/string_tests.py Misc/NEWS Objects/stringobject.c Objects/unicodeobject.c

[Tim Peters]

[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 sequence, else e.g. s.endswith(".py") would be ambiguous.

> Are there any other APIs that only support tuples rather than all
> sequences?

Oh, who cares -- it would be a relief to leave _something_ simple <0.7
wink>.  It's a bit of a stretch, but, e.g.,

>>> isinstance(1, [int, str])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: isinstance() arg 2 must be a class, type, or tuple of
classes and types

is restricted to tuple containers; ditto issubclass.  They're similar
in that most expected uses involve small, constant collections.

Given that {start,end}swidth can't support all sequences regardless,
restricting it to tuples is OK by me, and was clearly sufficient for
the uses made of this already in the standard library.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] xrange vs. int.__getslice__

[Vladimir 'Yu' Stepanov]

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 in xrange(1000, 1020): pass
vs.
for i in int[1000:1020]: pass
-

-
for i in xrange(200, 100, -2): pass
vs.
for i in int[200:100:-2]: pass
-
___
Python-Dev mailing list
Python-Dev@python.org
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] r46795 - in python/trunk: Doc/lib/libstdtypes.tex Lib/test/string_tests.py Misc/NEWS Objects/stringobject.c Objects/unicodeobject.c

[Neal Norwitz]

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 sequence and only support tuples?
>
> It can't support any sequence, else e.g. s.endswith(".py") would be ambiguous.

Good point, I was really just thinking of lists though.

> > Are there any other APIs that only support tuples rather than all
> > sequences?
>
> Oh, who cares -- it would be a relief to leave _something_ simple <0.7
> wink>.

:-)

I was thinking about a use case like this:

   supported_suffixes = ['.py', '.pyc', '.pyo']
   if sys.platform[:3] == 'win':
  supported_suffixes.append('.pyw')
   if pathname.endswith(supported_suffixes):
  # ...

I realize you could just throw a tuple(supported_suffixes).  I don't
know that I've ever needed that specific use case.  I don't think it's
too common.  Just thinking about avoiding newbie surprises.

> Given that {start,end}swidth can't support all sequences regardless,
> restricting it to tuples is OK by me, and was clearly sufficient for
> the uses made of this already in the standard library.

I'm ok with this either way.  It's easy enough to add later, but hard
to take away.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crash in dict on gc collect

[Neal Norwitz]

# 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 in PyType_IsSubtype (a=0x0, b=0x663f60) at typeobject.c:816
816 if (!(a->tp_flags & Py_TPFLAGS_HAVE_CLASS))
(gdb) bt
#0  0x00465689 in PyType_IsSubtype (a=0x0, b=0x663f60)
at typeobject.c:816
#1  0x0042bd7a in PyFile_WriteObject (v=0x6615a0, f=0x2a9557a238,
flags=1) at fileobject.c:2159
#2  0x00496ddf in PyEval_EvalFrameEx (f=0x7359a0, throwflag=0)
at ceval.c:1570
#3  0x0049c352 in PyEval_EvalCodeEx (co=0x2a95dec6d0,
globals=0x722420, locals=0x722420, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at ceval.c:2841
#4  0x00492b9c in PyEval_EvalCode (co=0x2a95dec6d0, globals=0x722420,
locals=0x722420) at ceval.c:503
#5  0x004b6821 in PyImport_ExecCodeModuleEx (
name=0x2a95ded434 "cp1140", co=0x2a95dec6d0,
pathname=0x2a95dd6d84 "Lib/encodings/cp1140.py") at import.c:642
#6  0x004b6ff8 in load_source_module (name=0x2a95ded434 "cp1140",
pathname=0x2a95dd6d84 "Lib/encodings/cp1140.py", fp=0x731d10) at
import.c:923


On 6/11/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I wonder if this is similar to Kevin's problem?  I couldn't reproduce
> his problem though.  This happens with both debug and release builds.
> Not sure how to reduce the test case.  pychecker was just iterating
> through the byte codes.  It wasn't doing anything particularly
> interesting.
>
> ./python pychecker/pychecker/checker.py Lib/encodings/cp1140.py
>
> 0x004cfa18 in visit_decref (op=0x661180, data=0x0) at gcmodule.c:270
> 270 if (PyObject_IS_GC(op)) {
> (gdb) bt
> #0  0x004cfa18 in visit_decref (op=0x661180, data=0x0) at 
> gcmodule.c:270
> #1  0x004474ab in dict_traverse (op=0x7cdd90,  visit=0x4cf9e0
> , arg=0x0) at dictobject.c:1819
> #2  0x004cfaf0 in subtract_refs (containers=0x670240) at 
> gcmodule.c:295
> #3  0x004d07fd in collect (generation=0) at gcmodule.c:790
> #4  0x004d0ad1 in collect_generations () at gcmodule.c:897
> #5  0x004d1505 in _PyObject_GC_Malloc (basicsize=56) at 
> gcmodule.c:1332
> #6  0x004d1542 in _PyObject_GC_New (tp=0x64f4a0) at gcmodule.c:1342
> #7  0x0041d992 in PyInstance_NewRaw (klass=0x2a95dffcc0,
> dict=0x800e80) at classobject.c:505
> #8  0x0041dab8 in PyInstance_New (klass=0x2a95dffcc0,
> arg=0x2a95f5f9e0, kw=0x0) at classobject.c:525
> #9  0x0041aa4e in PyObject_Call (func=0x2a95dffcc0,
> arg=0x2a95f5f9e0,  kw=0x0) at abstract.c:1802
> #10 0x0049ecd2 in do_call (func=0x2a95dffcc0,
> pp_stack=0x7fbfffb5b0,  na=3, nk=0) at ceval.c:3785
> #11 0x0049e46f in call_function (pp_stack=0x7fbfffb5b0,
> oparg=3) at ceval.c:3597
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xrange vs. int.__getslice__

[Thomas Wouters]

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 Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] request for review: patch 1446489 (zip64 extensions in zipfile)

[Ronald Oussoren]

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 huge zipfiles.

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 be harmless, I couldn't come  
up with a usecase other then reimplementing the read method outside  
of zipfile. The second incompatibility is that zipfile will try to  
raise an error when the zipfile gets to large, instead of reducing  
the zipfile to garbage as the current revision of zipfile does.

The major changes in the patch are: support for ZIP64 extensions  
which make it possible to handle zipfiles that are larger than 2  
GByte in size and a significant speed-up of zipfile opening when  
dealing with zipfiles that contain a large amount of files. These are  
in one patch because large zipfiles support isn't very useful when  
opening the zipfile takes more than 30 seconds.

Ronald
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xrange vs. int.__getslice__

[Vladimir 'Yu' Stepanov]

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 range functions. My
offer can be considered as replacement to xrange functions. Any
change in a syntactic design of language to spend it is not
necessary.

Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] DRAFT: python-dev summary for 2006-05-01 to 2006-05-15

[Steven Bethard]

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
=

---
Python 2.5 progress
---

Python 2.5 is moving steadily towards its first beta release.  See
`PEP 356`_ for more details and the full schedule.

.. _PEP 356: http://www.python.org/dev/peps/pep-0356/

Contributing threads:

- `2.5 open issues
`__
- `nag, nag -- 2.5 open issues
`__

--
Experimental wiki for editing the Python library reference
--

Fredrik Lundh introduced his `pyref wiki`_ which allows wiki-style
editing of the Python Library Reference.  In addition to providing
useful links, like unique URLs for all keywords, types and special
methods, the project aims to make cleaning up and rewriting parts of
the Python documentation as easy as editing a wiki.  If you'd like to
help out, let `Fredrik`_ know your infogami user name and he can add
you to the group.

.. _pyref wiki: http://pyref.infogami.com/
.. _Fredrik: [EMAIL PROTECTED]

Contributing threads:

- `introducing the experimental pyref wiki
`__
- `introducing the experimental pyref wiki
`__
- `more pyref: continue in finally statements
`__
- `more pyref: a better term for "string conversion"
`__
- `more pyref: comparison precedence
`__
- `context guards, context entry values, context managers, context
contexts `__

---
Assigning a SourceForge group to a tracker item
---

When opening a new patch on the SourceForge tracker, you should set
"Group" to the earliest still-maintained Python version to which it
applies.  Currently, that means if it's a candidate for backporting,
you should set the "Group" to 2.4.

Contributing thread:

- `Assigning "Group" on SF tracker?
`__


=
Summaries
=


PEP 3102: Keyword-only arguments


This fortnight continued discussion from the last on Talin's PEP for
keyword-only arguments.  Mainly the discussion focused on the second
half of his proposal which would allow positional arguments and
keyword-only arguments at the same time with syntax like::

  def compare(a, b, *, key=None):

The arguments for it included:

* It allows function APIs to be more strict initially to allow API
evolution without breaking existing code.
* It provides better documentation for functions that currently would
have to take a \*\*kwargs.

Still, a lot of people felt uncomfortable with the idea that the
writer of a function could force the callee to use keyword arguments
even if the callee found positional arguments to be simpler.

Contributing thread:

- `PEP 3102: Keyword-only arguments
`__

--
Alternative to PEP 355 path object
--

Noam Raphael suggested an alternative to the path object suggested by
`PEP 355`_ which makes paths more like tuples than strings.  The
ensuing discussion considered a variety of options, which would have
allowed code something like::

pth = Path("~/foo/bar/baz.tar.gz"):
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
assert pth.prefix == str(pth.basepath)
assert pth.dir == os.sep.join(pth.dirparts + ('',))
assert pth.name == os.extsep.join(pth.nameparts)

Most of the ideas were also posted to the wiki under
`AlternativePathClass`_ or `AlternativePathDiscussion`_, and a number
of people asked for a PEP, but none was available at the time of this
summary.

.. _PEP 355: http://www.python.org/dev/peps/pep-0355/
.. _AlternativePathClass: http://wiki.python.org/moin/AlternativePathClass
.. _AlternativePathDiscussion:
http://wiki.python.org/moin/AlternativePathDiscussion

Contributing thread:

- `Alternative path suggestion
`__


Mechanics for Python sprints


Tim Peters started a discussion a

[Python-Dev] pychecker warnings in Lib/encodings

[Neal Norwitz]

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 windows only.  But should I be
able to import encodings.mbcs on Linux or is this expected?

>>> import encodings.mbcs
Traceback (most recent call last):
  File "", line 1, in 
  File "Lib/encodings/mbcs.py", line 14, in 
class Codec(codecs.Codec):
  File "Lib/encodings/mbcs.py", line 18, in Codec
encode = codecs.mbcs_encode
AttributeError: 'module' object has no attribute 'mbcs_encode'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Source control tools

[Alexander Schremmer]

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 fixed.)

Maybe you benchmarked a Tailor deficiency here, but Mercurial scales very
well. People use it for work on the Linux kernel etc.
Compared to that, Bazaar-NG seems to reach limits already when working on
it's own code/repository.

Here is a paper comparing different DVCS for the FreeBSD ports tree (one of
the largest CVS repositories that exists ;-)):

http://www.keltia.net/BSDCan/slides.pdf

Kind regards,
Alexander

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crash in dict on gc collect

[Thomas Wouters]

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 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 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 1, ob_type = 0x0,   ob_size = 0, tp_name = 0x53d15a "EncodingMap", tp_basicsize = 80, 
[...]Did someone forget a PyType_Ready() call when EncodingMap was added? (And what other types are missing PyType_Ready() calls? :)-- Thomas Wouters <[EMAIL PROTECTED]
>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crash in dict on gc collect

[Neal Norwitz]

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 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 1, ob_type = 0x0,
>   ob_size = 0, tp_name = 0x53d15a "EncodingMap", tp_basicsize = 80,
> [...]
>
> Did someone forget a PyType_Ready() call when EncodingMap was added? (And
> what other types are missing PyType_Ready() calls? :)

Ya, read your mail, you're behind. I already checked in the fix (and
later the test). :-)
I didn't see any other missing PyType_Ready() calls in
unicodeobject.c.  But I don't know if other types were added at the
NFS sprint.  Hmmm, exceptions and struct?  Heading off to look.

n
___
Python-Dev mailing list
Python-Dev@python.org
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 Benchmarks

[M.-A. Lemburg]

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

Professional Python Services directly from the Source  (#1, Jun 13 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2006-07-03: EuroPython 2006, CERN, Switzerland  19 days left

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 

M.-A. Lemburg wrote:
> Fredrik Lundh wrote:
>> M.-A. Lemburg wrote:
>>
>>> You can download a current snapshot from:
>>>
>>> http://www.egenix.com/files/python/pybench-2.0-2006-06-09.zip
>> believe it or not, but this hangs on my machine, under 2.5 trunk.  and 
>> it hangs hard; nether control-c, break, or the task manager manages to 
>> kill it.
> 
> Weird.
> 
>> if it's any clue, it prints
>>
>>> ---
>>> PYBENCH 2.0
>>> ---
>>> * using Python 2.5a2
>>> * disabled garbage collection
>>> * system check interval set to maximum: 2147483647
>>> * using timer: time.clock
>> and that's it; the process is just sitting there, using exactly 0% CPU.
> 
> This is the output to expect:
> 
> ---
> PYBENCH 2.0
> ---
> * using Python 2.4.2
> * disabled garbage collection
> * system check interval set to maximum: 2147483647
> * using timer: time.time
> 
> Calibrating tests. Please wait...
> 
> Running 10 round(s) of the suite at warp factor 10:
> 
> * Round 1 done in 6.627 seconds.
> * Round 2 done in 7.307 seconds.
> * Round 3 done in 7.180 seconds.
> ...
> 
> Note that the calibration step takes a while.
> 
> Looking at the code, the only place where it could
> hang (because it's relying on a few external tools)
> is when fetching the platform details:
> 
> def get_machine_details():
> 
> import platform
> buildno, builddate = platform.python_build()
> python = platform.python_version()
> if python > '2.0':
> try:
> unichr(10)
> except ValueError:
> # UCS2 build (standard)
> unicode = 'UCS2'
> else:
> # UCS4 build (most recent Linux distros)
> unicode = 'UCS4'
> else:
> unicode = None
> bits, linkage = platform.architecture()
> return {
> 'platform': platform.platform(),
> 'processor': platform.processor(),
> 'executable': sys.executable,
> 'python': platform.python_version(),
> 'compiler': platform.python_compiler(),
> 'buildno': buildno,
> 'builddate': builddate,
> 'unicode': unicode,
> 'bits': bits,
> }
> 
> It does run fine on my WinXP machine, both with the win32
> package installed or not.
> 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pychecker warnings in Lib/encodings

[Walter Dörwald]

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 r46915 and r46917.

> IIUC (and I probably don't), mbcs is on windows only.  But should I be
> able to import encodings.mbcs on Linux or is this expected?
> 
 import encodings.mbcs
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "Lib/encodings/mbcs.py", line 14, in 
> class Codec(codecs.Codec):
>   File "Lib/encodings/mbcs.py", line 18, in Codec
> encode = codecs.mbcs_encode
> AttributeError: 'module' object has no attribute 'mbcs_encode'

mbcs_encode() is compiled conditionally in Modules/_codecsmodule.c with
"#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)".

Should encodings/mbcs.py be made unimportable on non-Windows?

Servus,
   Walter

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Moving PEP 343 to Final

[Nick Coghlan]

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 2.5 alpha 2 
(which is the same as what the PEP currently describes).

Cheers,
Nick.


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)

[Boris Borcic]

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 2.5 compiles
 the following code incorrectly:
>>> No, no, it's an underground move by Jeremy to allow assignment to
>>> variables of enclosing scopes:
>> ...
>>> Credits to Samuele's evil side for the ideas.  His non-evil side doesn't
>>> agree, and neither does mine, of course :-)
>> ...
>>> More seriously, a function with a variable that is only written to as
>>> the target of augmented assignments cannot possibly be something else
>>> than a newcomer's mistake: the augmented assignments will always raise
>>> UnboundLocalError.
>> I am not really a newcomer to python. But lately I find myself regularly 
>> bitten
>> by this compiler behavior that I tend to view as a (design) bug. This started
>> happening after I saw that sets are just as good as lists performance-wise 
>> and I
>> began changing code like this
> 
> I see your attempted use of a closure as a design bug in your code.

 original_post.replace('(design)','(design?)') 

It was no "attempted" use but working code (incorporating a closure) that was 
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.

> Remember that while closures can be quite convenient, there are other
> methods to do precisely the same thing without needing to use nested
> scopes.

Of course there are other methods. I pointed out one relatively straightforward 
workaround that Python offered me in its usually friendly manner. You seem to 
say that I should have considered wholesale restructuration of my code using 
classes as a more appropriate workaround. Hum.

What's unnerving is to be stopped in the course of applying a straightforward 
simplification to working code, by a compiler (!) objection in favor of an 
interpretation that *has no use-cases*.

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.

Are you telling me closures have no use cases ? Of course not. Are you telling 
me closures have use cases to which mine don't belong ? Please point me to the 
part of documentation where I should have learned that will of the Gods.

 >  I find that it would be far easier (for the developers of
> Python)

Could you be more specific ? This thread started with Thomas Wouter announcing 
he assigned a bug because pre-beta 2.5 unwittingly behaved as I would prefer. 
This implies that said behavior can't be _far_ more difficult to implement, 
right ?

Or is what you mean that python developers feel especially bad about the 
typical 
confusion of newcomers when the automatic scoping rules of python fail to 
provide the most helpful error messages ?

So that I shouldn't complain about, well, error dynamics getting special-cased 
for augmented assignments, to feature python with an error message that's 
perfectly to the point... for an audience that the developers of python intend 
to capture by her serendipitous misuse of augmented assignment, right ? An 
audience to which me and my use-cases don't belong, and therefore, should be 
designed out of existence ?

Judging from the rest of your intervention, I guess that's it. Well, I think 
the 
principle of it at least deserves debate. First, please face/state the explicit 
notion that while you speak of the "designers of python", what's the object of 
design here is actually not python itself at all but "how python should be 
learned by spontaneous (trials and) errors". (Proof: or else you have no 
use-cases worthy of the name).

Once you admit the matter belongs to the business of designing a, well, 
spontaneous human learning process; rather than the business of designing a 
programming language for actual use-cases, then maybe we could have a 
constructive discussion between adults.

(To anticipate on it, I must confess a deeply felt aversion for whatever starts 
resembling a constraining curriculum of errors to make and then rectify. Or 
else 
I would be programming in Java).

> and significantly more readable if it were implemented as a
> class.

I'll deny that flatly since first of all the issue isn't limited to closures. 
It 
would apply just as well if it involved globals and top-level functions.

> 
> class solve:
> def __init__(self, problem):
> self.freebits = ...
> ...
> def search(self, data):
> ...
> self.freebits ^= swaps
> ...
> ...
> 
> Not everything needs to (or should) be a closure

Right. Let's thus consider

freebits = ...

def search(data) :
 ...
 freebits ^= s

Re: [Python-Dev] request for review: patch 1446489 (zip64 extensions in zipfile)

[Aahz]

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 be harmless, I couldn't come  
> up with a usecase other then reimplementing the read method outside  
> of zipfile. 

Not knowing anything about this, why not implement file_offset as a
property?
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there."  --Steve Gonedes
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Please stop changing wsgiref on the trunk

[Armin Rigo]

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 actually possible to import a part of an SVN repository into
another while preserving history.  That would be a way to move the
regular development of such packages completely to the Python SVN,
without loss.


A bientot,

Armin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)

[Barry Warsaw]

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 be Barry's fault.
>
> probably-until-the-end-of-time-ly y'rs  - steve

Oh sure, blame the guy who was going to buy both you /and/ Tim kung  
pao chicken in the futile attempt to relieve us all of your new found  
crabbiness.  That's okay, I'll only hold it against you until the end  
of time.

oh-heck-let-the-psf-buy-a-round-for-the-house-ly y'rs,
-Barry

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dropping externally maintained packages (Was:Please stop changing wsgiref on the trunk)

[Fred L. Drake, Jr.]

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.   
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] request for review: patch 1446489 (zip64 extensions in zipfile)

[Ronald Oussoren]

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 scan of the zipfile). This should be harmless, I couldn't come
up with a usecase other then reimplementing the read method outside
of zipfile.


Not knowing anything about this, why not implement file_offset as a
property?


That is possible but would introduce a link from ZipInfo instances to  
Zipfile instances and would therefore introduce a cycle. As Zipfile  
has a __del__ method that's not something I wanted to do.


Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] a note in random.shuffle.__doc__ ...

[Dan Christensen]

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* of numbers it produces, not each individual
> number. 

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 ordering, since the "algorithm" is saving state.  Down below
I show code that calls random.shuffle on a 4 element list using a
"random" number generator of period 13, and it produces all
permutations.

(More generally, there's nothing to stop someone from changing
the random.shuffle code to explicitly store more internal state
to ensure that every permutation eventually gets produced.  I'm
of course not suggesting that this would be a good idea!)

In any case, the (old) text in the docstring:

Note that for even rather small len(x), the total number of
permutations of x is larger than the period of most random
number generators; this implies that "most" permutations of a
long sequence can never be generated.

is at least a bit misleading, especially the "never" part.

Dan



import random

i = 0
period = 13
def myrand():
global i
i = (i+2)%period
return float(i)/period

def countshuffles(L, num):
L = list(L)
S = set([])

for i in range(num):
random.shuffle(L, random=myrand)
S.add(tuple(L))

return len(S)

print countshuffles([1,2,3,4], 40)

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Updating packages from external ?

[M.-A. Lemburg]

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 sub-directory with name
"pybench-2.0".

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 procedure which should be followed for these upgrades,
such as e.g. remove the package directory first, then copy over
the new version ?

Thanks for any help,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 13 2006)
>>> 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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Updating packages from external ?

[Fredrik Lundh]

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 procedure which should be followed for these upgrades,
> such as e.g. remove the package directory first, then copy over
> the new version ?

that's one way to do it.

another way is to use the svn_load_dirs.pl script described here:

 http://svnbook.red-bean.com/en/1.0/ch07s04.html



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)

[Terry Reedy]

"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 transformation amounted to switching from collection mutation to 
object rebinding.  In Python, that is a crucial difference.  That the 
mutation and rebinding were both done with augmented assignments is not 
terribly important except as this masks the difference.  When *you* read 
your code, you know that you will only call the inner function with a 
mutable collection object, so you know that the name will be rebound to the 
same object after mutation, so you can think of the augmented assignment as 
being the same as collection mutation.

But the compiler does not know any such thing about the target of the 
augmented assignment and must therefore treat the statement as an 
assigment.  It was a bug for a2 to do otherwise, even though the bug was 
locally optimal for this particular usage.

Terry Jan Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] beta1 coming real soon

[Walter Dörwald]

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 problems. In particular, it is limited to "DBCS"
> (and SBCS) character sets in the strict sense; general "MBCS"
> character sets are not supported. There are a few of these, most
> notably the ISO-2022 ones, UTF-8, and GB18030 (can't be bothered
> to look up the code page numbers for them right now).

True, but there's no IsMBCSLeadByte().

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 is due
to an incomplete byte sequence or invalid data. But that sounds ugly and
slow to me.

> What I don't know is whether any Windows locale uses a "true"
> MBCS character set as its "ANSI" code page.
> 
> The approach taken in the patch could be extended to GB18030 and
> UTF-8 in principle,

Would that mean that we'd have to determine the active code page and
implement the incomplete byte sequence detection ourselves?

> but can't possibly work for ISO-2022.

So does that mean that IsDBCSLeadByte() returns garbage in this case?

Servus,
   Walter

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] beta1 coming real soon

[Martin v. Löwis]

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 is due
> to an incomplete byte sequence or invalid data. But that sounds ugly and
> slow to me.

That's all true, yes.

>> but can't possibly work for ISO-2022.
> 
> So does that mean that IsDBCSLeadByte() returns garbage in this case?

IsDBCSLeadByteEx is documented to only validate lead bytes for selected
code pages; MSDN versions differ in what these code pages are. The
current online version says

"This function validates leading byte values only in the following code
pages: 932, 936, 949, 950, and 1361."

whereas my January 2006 MSDN (DVD version) says

"IsDBCSLeadByteEx does not validate any lead byte in multi-byte
character set (MBCS) code pages, for example, code pages 52696, 54936,
51949 and 5022x."

Whether or not this is relevant for IsDBCSLeadByte also, I cannot tell:
- maybe they forgot to document the limitation there as well
- maybe you can't use one of the unsupported code pages as CP_ACP,
  so the problem cannot occur
- maybe IsDBCSLeadByte does indeed work correctly in these cases, when
  IsDBCSLeadByteEx doesn't

The latter is difficult to believe, though, as IsDBCSLeadByte is likely
implemented as


BOOL IsDBCSLeadByte(BYTE TestChar)
{
  return IsDBCLeadByteEx(GetACP(), TestChar);
}

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)

[Josiah Carlson]

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 proper and sufficient. Believe whatever you want about
my intentions.


> Josiah Carlson wrote:
> > and significantly more readable if it were implemented as a
> > class.
> 
> I'll deny that flatly since first of all the issue isn't limited to closures. 
> It 
> would apply just as well if it involved globals and top-level functions.
> 
> > 
> > class solve:
> > def __init__(self, problem):
> > self.freebits = ...
> > ...
> > def search(self, data):
> > ...
> > self.freebits ^= swaps
> > ...
> > ...
> > 
> > Not everything needs to (or should) be a closure
> 
> Right. Let's thus consider
> 
> freebits = ...
> 
> def search(data) :
>  ...
>  freebits ^= swaps

You seem to not realize that these different use-cases.  Your new
example involves a global variable that is *shared* among everyone that
knows  about this particular module.  It also is repaired by a simple
insertion of 'global freebits' at the beginning of the search function. 
The closure/class example is merely a method of encapsulating state,
which I find easier to define, describe, and document than the closure
version.

Back in February, there was a discussion about allowing people to
'easily' access and modify variables defined in lexically nested scopes,
but I believed then, as I believe now, that such attempted uses of
closures are foolish when given classes.  Given the *trivial* conversion
of your closure example to a class, and my previous comments on closures
"I find their use rarely, if ever, truely elegant, [...] more like
kicking a puppy for barking: [...] there are usually better ways of
dealing with the problem (don't kick puppies for barking and don't use
closures).", you are not likely to find me agreeing with you about
augmented assignment and/or lexically nested scopes.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Updating packages from external ?

[M.-A. Lemburg]

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 procedure which should be followed for these upgrades,
>> such as e.g. remove the package directory first, then copy over
>> the new version ?
> 
> that's one way to do it.
> 
> another way is to use the svn_load_dirs.pl script described here:
> 
>  http://svnbook.red-bean.com/en/1.0/ch07s04.html

Thanks.

I tried that and also the approach to merge the differences
by hand, but both result in lost version history on the files
in the trunk.

In the end, I simply copied over the distribution onto the
trunk version and did the necessary svn add/remove by
hand. As a result, there's no history leading back to the
external/pybench-2.0/ tree (though I've added a checkin
comment), but it is possible to see and follow the changes
I made to the trunk version.

BTW, just saw the discussion burst about externally managed
packages:

The way I see things with pybench is that development
can and should happen in the trunk, but I reserve the freedom
to use that version as basis for new external releases
which I then merge back into the trunk.

This does sometimes mean incompatible changes or even
removal of things others have added, but then if it
wouldn't the package wouldn't be /externally/
managed :-)

That said, being the maintainer of such a package
becomes harder not easier by contributing it to the
Python core.

Contributors need to be aware of this, but Python core
developers should as well. It's all about working
together rather than fighting each other.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 13 2006)
>>> 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
Python-Dev@python.org
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 Benchmarks

[M.-A. Lemburg]

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 are repeatable within +/- 5%
for each test and under 1% for the whole suite.

Note that this is an incompatible change to pybench. You
will not be able to compare results from runs using pybench 1.x
against results from pybench 2.0 (and pybench will refuse
to display such diffs).

Enjoy,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 13 2006)
>>> 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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python sprint at Google Aug. 21-24

[Jeremy Hylton]

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 will occur just after the Python 2.5 release, assuming the
schedule doesn't slip.  It will be a great opportunity to get started
on Python 2.6 and Python 3000 work.  We hope to get some time for
face-to-face discussion about Python 3000 issues.  (We're expecting to
have a video conference hookup between the two sprints so that
everyone can participate equally.)

Google will provide the basic infrastructure for sprinting--desk
space, network connectivity, and food.  You need to bring your laptop
and your coding skills.  The wiki page has more details about
locations, hotels, &c.  We'll keep it up to date with all the
logistical information about the sprint.

The sprints are sponsored by the Open Source Program Office at Google.
 We'd like to thank Chris DiBona and Leslie Hawthorn for their
enthusiastic support!

Please send any questions about logistics to Neal and me.  I assume we
can discuss the actual technical work on python-dev as usual.

Jeremy & Neal
(co-organizers)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] a note in random.shuffle.__doc__ ...

[Terry Jones]

> "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. The outcome of your algorithm is the whole
>> *sequence* of numbers it produces, not each individual
>> number. 

Dan> I think Terry's point is valid.  While no one call to
Dan> random.shuffle(L) can produce every possible ordering of L (when
Dan> len(L) is large), since random.shuffle shuffle's the data in place,
Dan> repeated calls to random.shuffle(L) could in principle produce every
Dan> possible ordering, since the "algorithm" is saving state.  Down below
Dan> I show code that calls random.shuffle on a 4 element list using a
Dan> "random" number generator of period 13, and it produces all
Dan> permutations.

Maybe I should reiterate what I meant, as it seems the discussion is really
just semantics at this point.

Greg said:

> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> A generator with only N possible internal states can't
Greg> possibly result in more than N different outcomes from
Greg> any algorithm that uses its results.

And I replied:

I don't mean to pick nits, but I do find this a bit too general.

Suppose you have a RNG with a cycle length of 5. There's nothing to
stop an algorithm from taking multiple already returned values and
combining them in some (deterministic) way to generate > 5 outcomes.
(Yes, those outcomes might be more, or less, predictable but that's not
the point). If you expanded what you meant by "internal states" to
include the state of the algorithm (as well as the state of the RNG),
then I'd be more inclined to agree.

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.

It's clear, I think, from the example code that I and Dan posted, that one
can move the boundary between the RNG and the algorithm using it. You can
take a technique (like using lagging as I did, or Dan's method which stores
and composes permutations) out of the RNG and put it in the algorithm.
That's the reason I reacted to Greg's summary - I don't think it's right
when you confine yourself to just the internal states of the generator. As
I said, if you also consider the states of the algorithm, then the argument
is easier to defend. From an information theory point of view, it's simpler
not to draw the distinction between what's in the "RNG" and what's in the
"algorithm" that uses it. I guess we must all agree at that level, which to
me means that the recent discussion is necessarily just semantics.

[Tim's response to my first post wasn't just semantics - I was wrong in
what I said, and he made it clear (to me anyway) why. But at that point
there was no discussion of what any algorithm could produce as an outcome,
algorithm state, determinism, etc.]

And yes, you can also define outcome as you like. I deliberately included
the word 'outcome' in my print statement.  I thought that was definitive :-)

Terry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] a note in random.shuffle.__doc__ ...

[Greg Ewing]

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 ordering,

But how do you decide how many times to shuffle before
dealing the cards? If you pull that number out of your
RNG, then you're back in the same boat. If you get it
from somewhere else, the RNG is no longer the only
thing determining the result.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] a note in random.shuffle.__doc__ ...

[Greg Ewing]

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 normally used.

To be clear: there is an algorithm with a fixed input and
a single output, and a PRNG whose initial state determines
the actions of the algorithm. The only thing which can
change is the initial state of the PRNG.

> It's clear, I think, from the example code that I and Dan posted, that one
> can move the boundary between the RNG and the algorithm using it.

Only if you correspondingly move the boundary of what
constitutes the initial state. It doesn't matter how
much internal state the algorithm has; if it starts
out in the *same* initial state each time, it can't
increase the number of possible results.

While you probably understood this, it's worth
pointing out explicitly, because some people don't,
or neglect to consider it when thinking about this
sort of situation.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] request for review: patch 1446489 (zip64 extensions in zipfile)

[Gregory P. Smith]

> 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 huge zipfiles.
...
> The major changes in the patch are: support for ZIP64 extensions  
> which make it possible to handle zipfiles that are larger than 2  
> GByte in size and a significant speed-up of zipfile opening when  
> dealing with zipfiles that contain a large amount of files.

+1  I've reviewed it and think it sounds useful.  ZIP64 is
supported by many of the popular windows zip file utils.

I'd like to see this one checked in.  Unless I see objections in the
next 24 hours I'll check it in.

-greg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Improve error msgs?

[Georg Brandl]

In abstract.c, there are many error messages like

type_error("object does not support item assignment");

It helps debugging if the object's type was prepended.
Should I go through the code and try to enhance them
where possible?

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com