[Python-Dev] current 2.5 issues

[Neal Norwitz]

valgrind reports a problem when running test_doctest.  I haven't
spotted a problem with the code, but the report is consistent (hmm, I
thought there were 3 warnings, but now there's only 1):

==19291== Conditional jump or move depends on uninitialised value(s)
==19291==at 0x49D8B5: maybe_call_line_trace (ceval.c:3260)
==19291==by 0x493334: PyEval_EvalFrameEx (ceval.c:857)
==19291==by 0x49C617: PyEval_EvalCodeEx (ceval.c:2832)
==19291==by 0x492E61: PyEval_EvalCode (ceval.c:494)
==19291==by 0x4C50B7: run_mod (pythonrun.c:1232)
==19291==by 0x4C4F89: PyRun_StringFlags (pythonrun.c:1199)
==19291==by 0x4A04F0: exec_statement (ceval.c:4196)
==19291==by 0x4977BC: PyEval_EvalFrameEx (ceval.c:1665)
==19291==by 0x49C617: PyEval_EvalCodeEx (ceval.c:2832)
==19291==by 0x49EABE: fast_function (ceval.c:3661)
==19291==by 0x49E763: call_function (ceval.c:3586)
==19291==by 0x49A3B5: PyEval_EvalFrameEx (ceval.c:2269)

*

Buildbot failures:

openbsd: test_ctypes fails
tru64 alpha: test_signal sometimes hangs
s/390: test_socket_ssl fails probably due to firewall issue in
cygwin: hopeless

debian hppa sometimes hangs when running a forking test (fork1,
wait[34], possibly subprocess).  I am working on a patch to help debug
this situation (already checked in once and reverted).  I can't
reproduce this failure.

*

Some tests fail when run under regrtest.py -R 4:3: .  There are at
least these problems:

* test_logging
* test_optparse
* test_sqlite
* test_threaded_import


test test_logging crashed -- type 'exceptions.KeyError':
logging.StreamHandler instance at 0x184d420

test test_optparse failed -- Traceback (most recent call last):
  File /home/neal/build/python/svn/trunk-clean/Lib/test/test_optparse.py,
line 622, in test_float_default
self.assertHelp(self.parser, expected_help)
  File /home/neal/build/python/svn/trunk-clean/Lib/test/test_optparse.py,
line 202, in assertHelp
actual_help + '\n')
AssertionError: help text failure; expected:

test_sqlite
Traceback (most recent call last):
  File 
/home/neal/build/python/svn/trunk-clean/Lib/sqlite3/test/userfunctions.py,
line 41, in func_raiseexception
5/0
ZeroDivisionError: integer division or modulo by zero

test test_threaded_import crashed -- type 'exceptions.KeyError':
'test.threaded_import_hangers'
___
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] Switch statement

[Josiah Carlson]

Phillip J. Eby [EMAIL PROTECTED] wrote:
 At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
 The non-fast version couldn't actually work if it referenced any names,
 given current Python semantics for arbitrary name binding replacements.
 
 Actually, one could consider case expressions to be computed at function 
 definition time, the way function defaults are.  That would solve the 
 problem of symbolic constants, or indeed any sort of expressions.

Using if/elif/else optimization precludes any non-literal constants, so
we would necessarily have to go with a switch/case for this semantic. It
seems as though it would work well, and wouldn't be fraught with
any of the gotchas that catch users like:
def fcn(..., dflt={}, dflt2=[]):
...


 An alternate possibility would be to have them computed at first use and 
 cached thereafter.
 
 Either way would work, and both would allow multiple versions of the same 
 switch statement to be spun off as closures without losing their constant 
 nature or expressiveness.  It's just a question of which one is easier to 
 explain.  Python already has both types of one-time initialization: 
 function defaults are computed at definition time, and modules are only 
 loaded once, the first time you import them.

I would go with the former rather than the latter, if only for
flexibility.

 - 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] Python 2.4 extensions require VC 7.1?

[Kristján V . Jónsson]

This is, in fact, exactly what the python trunk does right now.  This is done 
in exceptions.c
Kristján 

-Original Message-
From: Scott Dial [mailto:[EMAIL PROTECTED] 
Sent: 17. júní 2006 12:54
To: Python Dev
Cc: Martin v. Löwis; Kristján V. Jónsson
Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1?

I'm nobody but I don't find your argument compelling. I suggest you go
read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx
___
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 2.4 extensions require VC 7.1?

[Kristján V . Jónsson]

The signal() doc is rather vague on the point, since it doesn´t define the 
availible set
of signals.  It doesn´t even say that a signal identifier is an integer.  But 
it says that it should return EINVAL if it cannot satisfy the request.  It 
doesn´t say if the request is invalid, but I don't want to go into 
hairsplitting here.  So I could agree with you there.

But I completely disagree when you insist that microsoft has broken the C 
library.  What
they have done is added parameter validation, and thus simply added code in the 
undefined
domain.
I would also like to point out that, again apart from signal(), you are relying 
on undefined behaviour of fopen and others.  It may well cause a crash on one 
of your other platforms one day, you have no way of knowing.  VS2005 just 
pointed that out to you.

So, it is my suggestion that in stead of going all defensive, and shouting 
breakage, why not simply fix those very dubious CRT usage patterns?  Think of 
it as lint.

Also, consider this:  in the case of file() and strftime() we are passing in 
dynamic strings.  The strings are not within control of python.  Normally these 
are static strings, within the control of the developer which has the function 
reference on hand, knows what he wants and so on.  Yet, here we are passing in 
any old strings.  There is a huge undefined domain there, and we should be very 
concerned about that.  It is a wonder we haven´t seen these functions crash 
before.

I would like to see the question about whether or not to use VS2005 be made 
purely on the merit of what is most practical (and useful) for people, rather 
than some emotional arguments about with loaded terms like breakage, and 
personal feelings towards Microsoft.

(And by the way, why does pythoncore.dll mess with signal() anyway?  shouldn´t 
that be python.exe?  I don´t want a dll that I embed to mess with my signal 
handling) 

Cheers,

Kristján

-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED] 
Sent: 17. júní 2006 13:28
To: Scott Dial
Cc: Python Dev; Kristján V. Jónsson
Subject: Re: [Python-Dev] Python 2.4 extensions require VC 7.1?


Sure, I can *make* the library conform to C 99. I could also write my own C 
library entirely to achieve that effect. The fact remains that VS 2005 violates 
standard C where VS 2003 and earlier did not:
A conforming program will abort, instead of completing successfully.
___
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] unicode imports

[Kristján V . Jónsson]

Ideally, I would like for python to simply work. It seems to me that it is 
mostly a question of time when all modern platforms offer unicode filesystems 
and hence unicode APIs.  IMHO, stuff like the importer should really be written 
in native unicode and revert to ASCII only as a fallback for unsupporting 
platforms.  is WITH_UNICODE ever left undefined these days?

And sure, module names need to be python identifiers (thus ASCII), although I 
wouldn't be surprised if that restriction were lifted in a not too distant 
future :)  After all, we support the utf-8 encoding of source files, but I 
cannot write kristján = 1.  But that's for a future PEP.

Kristján

-Original Message-
From: Nick Coghlan [mailto:[EMAIL PROTECTED] 
Sent: 16. júní 2006 15:30
To: Kristján V. Jónsson
Cc: Python Dev
Subject: Re: [Python-Dev] unicode imports

Kristján V. Jónsson wrote:
 A cursory glance at import.c shows that the import mechanism is fairly 
 complicated, and riddled with char *path thingies, and manual string 
 arithmetic.  Do you have any suggestions on a clean way to unicodify 
 the import mechanism?

Can you install a PEP 302 path hook and importer/loader that can handle path 
entries that are Unicode strings? (I think this would end up being the parallel 
implementation you were talking about, though)

If the code that traverses sys.path and sys.path_hooks is itself 
unicode-unaware (I don't remember if it is or isn't), then you might be able to 
trick it by poking a Unicode-savvy importer directly into the 
path_importer_cache for affected Unicode paths.

One issue is that the package and file names still have to be valid Python 
identifiers, which means ASCII. Unicode would be, at best, permitted only in 
the path entries.

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] unicode imports

[Kristján V . Jónsson]

Okay, for specifics which demonstrate the problem.
I have a directory, C:\tmp\腌
In it, there is a file, doo.py
d = os.listdir(uc:/tmp)[-1]
d
u'\u814c'
 d2 = os.listdir(uc:/tmp/+d)
 d2
[u'doo.py']
 p = uc:/tmp/+d
 p
u'c:/tmp/\u814c'
 sys.path.append(p)
 import doo
Traceback (most recent call last):
  File stdin, line 1, in module
ImportError: No module named doo

 p.encode(mbcs)
'c:/tmp/?'
 p.encode(gb2312)
'c:/tmp/\xeb\xe7'

Running your example test code gives:
Prefixes: C:\PyDev25 C:\PyDev25
Path: ['c:\\tmp', 'c:\\documents and settings\\kristjan\\my documents\\python',
'C:\\PyDev25\\PCbuild8\\python25.zip', 'C:\\PyDev25\\DLLs', 'C:\\PyDev25\\lib',
'C:\\PyDev25\\lib\\plat-win', 'C:\\PyDev25\\lib\\lib-tk', 'C:\\PyDev25\\PCbuild8
', 'C:\\PyDev25', 'C:\\PyDev25\\lib\\site-packages']
Default encoding: ascii
Input encoding: cp850 Output encodings: cp850 cp850

-Original Message-
From: Nick Coghlan [mailto:[EMAIL PROTECTED] 
Sent: 17. júní 2006 04:17
To: Phillip J. Eby
Cc: Kristján V. Jónsson; Python Dev
Subject: Re: [Python-Dev] unicode imports

Phillip J. Eby wrote:
 Actually, you would want to put it in sys.path_hooks, and then 
 instances would be placed in path_importer_cache automatically.  If 
 you are adding it to the path_hooks after the fact, you should simply 
 clear the path_importer_cache.  Simply poking stuff into the 
 path_importer_cache is not a recommended approach.

Oh, I agree - poking it in directly was a desperation measure if the path_hooks 
machinery didn't like Unicode either.

I've since gone and looked, and you may be screwed either way - the standard 
import paths appear to be always put on the system path as encoded 8-bit 
strings, not as Unicode objects.

That said, it also appears that the existing machinery *should* be able to 
handle non-ASCII path items, so long as 'Py_FileSystemDefaultEncoding' is set 
correctly. If it isn't handling it, then there's something else going wrong.

Modules/getpath.c and friends don't encode the results returned by the platform 
APIs, so the strings in

Kristján, can you provide more details on the fault you get when trying to 
import from the path containing the Chinese characters? Specifically:

What is the actual file system path?
What do sys.prefix, sys.exec_prefix and sys.path contain?
What does sys.getdefaultencoding() return?
What do sys.stdin.encoding, sys.stdout.encoding and sys.stderr.encoding say?
What does python -v show?
Does adding the standard lib directories manually to sys.path make any 
difference?
Does setting PYTHONHOME to the appropriate settings make any difference?

Running something like the following would be good:

   import sys
   print Prefixes:, sys.prefix, sys.exec_prefixes
   print Path:, sys.path
   print Default encoding:, sys.getdefaultencoding()
   print Input encoding:, sys.stdin.encoding,
   print Output encodings:, sys.stdout.encoding, sys.stderr.encoding
   try:
   import string # Make python -v do something interesting
   except ImportError:
   print Could not find string module
   sys.path.append(ustdlib directory name)
   try:
   import string # Make python -v do something interesting
   except ImportError:
   print Could not find string module






-- 
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] unicode imports

[Kristján V . Jónsson]

Well, my particular test uses  u'c:/tmp/\u814c'
If that cannot be encoded in mbcs, then mbcs isn't useful.
Note that this is both an issue of python being able to run from an arbitrary 
install position, and also the ability of users to import and run scripts from 
any other arbitrary directory.

Kristján

-Original Message-
From: Neil Hodgson [mailto:[EMAIL PROTECTED] 
Sent: 17. júní 2006 04:53
To: Kristján V. Jónsson
Cc: Python Dev
Subject: Re: [Python-Dev] unicode imports

Kristján V. Jónsson:

 Although python has had full unicode support for filenames for a long 
 time on selected platforms (e.g. Windows), there is one glaring 
 deficiency:  It cannot import from paths containing unicode.  I´ve 
 tried creating folders with chinese characters and adding them to path, to no 
 avail.
 The standard install path in chinese distributions can be with a 
 non-ANSI path, and installing an embedded python application there will break 
 it.

   It should be unusual for a Chinese installation to use an install path that 
can not be represented in MBCS. Try encoding the install directory into MBCS 
before adding it to sys.path.

   Neil
___
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] unicode imports

[Kristján V . Jónsson]

I don't have specific information on the machines.  We didn´t try very hard to 
get things to work with 2.3 since we simply assumed it would work automatically 
when we upgraded to a more mature 2.4.
I could try to get more info, but it would be 2.3 specific.  Have there been 
any changes since then?

Note that it may not go into program files at all.  Someone may want to install 
his modules in a folder named in the honour of his mother.

Also, I really would like to see a general solution that doesn´t assume that 
the path name can somhow be transmuted to an ascii name.  Users are 
unpredictable.  When you have a wide distribution  , you come up against all 
kinds of problems (Currently we have around 500.000 users in china.) 
Also, relying on some locale settings is not acceptable.  My machine here has 
the icelandic locale.  Yet, I need to be able to set up and use a chinese 
install.  Likewise, many machines in china will have an english locale.  A 
default encoding and locale is essentially an evil hack in our increasingly 
global environment.  We have converted more or less our entire code base to 
unicode because keeping track of encoded strings is simply unworkable in a 
large project.

Funny that no other platforms could benefit from a unicode import path.  Does 
that mean that windows will reign supreme?  Please explain.

Cheers,

Kristján

-Original Message-
From: Martin v. Löwis [mailto:[EMAIL PROTECTED] 
Sent: 17. júní 2006 08:42
To: Kristján V. Jónsson
Cc: Python Dev
Subject: Re: [Python-Dev] unicode imports

Kristján V. Jónsson wrote:
 The standard install path in chinese distributions can be with a 
 non-ANSI path, and installing an embedded python application there 
 will break it.

I very much doubt this. On a Chinese system, the Program Files folder likely 
has a non-*ASCII* name, but it will have a fine *ANSI* name, as the ANSI code 
page on that system should be either 936 (simplified
chinese) or 950 (traditional chinese) - unless the system is misconfigured.

Can you please report what the path is, what the precise name of the operating 
system is, and what the system locale and the system code page are?

 A completely parallel implementation on the sys.path[i] level?

You should also take a look at what the 8.3 name of the path is.
I really cannot believe that the path is unaccessible to DOS programs.

 Are there other platforms beside Windows that would profit from this?

No.

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] unicode imports

[Thomas Heller]

It should be noted that I once started to convert the import machinery
to be fully unicode aware.  As far as I can tell, a *lot* has to be changed
to make this work.

I started with refactoring Python/import.c, but nobody responded to the question
whether such a refactoring patch would be accepted or not.

Thomas

___
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] PyString_FromFormat

[Kristján V . Jónsson]

One thing I have 
often lamented having in PyString_FromFormat (and cousins, like PyErr_Format) is 
to be able to integrate PyObject pointers. Adding something like %S and %R 
(for str() and repr() respectively) seems very useful to me. Is there any 
reason why this isn´t there?

Cheers,

Kristjá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] Numerical robustness, IEEE etc.

[Michael Hudson]

Nick Maclaren [EMAIL PROTECTED] writes:

 As I have posted to comp.lang.python, I am not happy with Python's
 numerical robustness - because it basically propagates the 'features'
 of IEEE 754 and (worse) C99. 

That's not really now I would describe the situation today.

 Yes, it's better, but I would like to make it a LOT better.  I
 already have a more robust version of 2.4.2, but there are some
 problems, technical and political.  I should appreciate advice.

I would like to see Tim Peters' opinion on all this.

 1) Should I start off by developing a testing version, to give people
 a chance to scream at me, or write a PEP?

Yes

Or did you want advice on which?  I think a PEP would make a lot of
sense.

 2) Because some people are dearly attached to the current behaviour,
 warts and all, and there is a genuine quandary of whether the 'right'
 behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R-
 finally-specifies (let's ignore C99 and Java as beyond redemption),

Why?  Maybe it's clear to you, but it's not totally clear to me, and
it any case the discussion would be better informed for not being too
dismissive.

 there might well need to be options.  These can obviously be done by
 a command-line option, an environment variable or a float method.
 There are reasons to disfavour the last, but all are possible.  Which
 is the most Pythonesque approach?

I have heard Tim say that there are people who would dearly like to be
able to choose.  Environment variables and command line switches are
not Pythonic.

 3) I am rather puzzled by the source control mechanism.  Are commit
 privileges needed to start a project like this in the main tree?

Yes.  You can also use svk, I believe, but I don't really know
anything about that.

 4) Is there a Python hacking document?  Specifically, if I want to
 add a new method to a built-in type, is there any guide on where to
 start?

Don't think so.  There's some stuff under http://www.python.org/dev/
but nothing that would cover this.

 5) I am NOT offering to write a full floating-point emulator, though
 it would be easy enough and could provide repeatable, robust results.
 Easy does not mean quick :-(  Maybe when I retire.  Incidentally,
 experience from times of yore is that emulated floating-point would
 be fast enough that few, if any, Python users would notice.

Maybe you're right, but I personally doubt this last bit.



Speaking more generally, it would be nice if you gave more
explanations of why the changes you want to make are desirable -- and
for that matter, more details about what they actually are.

I'm interested in making Python's floating point story better, and
have worked on a few things for Python 2.5 -- such as
pickling/marshalling of special values -- but I'm not really a
numerical programmer and don't like to guess what they need.

Cheers,
mwh

-- 
  Python enjoys making tradeoffs that drive *someone* crazy wink.
   -- Tim Peters, comp.lang.python
___
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] When to branch release25-maint?

[Michael Hudson]

Anthony Baxter [EMAIL PROTECTED] writes:

 A question has been asked about branching release25-maint at the time 
 of beta1. I was actually thinking about doing this for 2.5rc1 - once 
 we're in release candidate stage we want to really be careful about 
 checkins. I'm not sure it's worth branching at beta1 - it's a bit 
 more work all round, vs what I suspect will be a small amount of 2.6 
 work landing on the trunk nownownow. Also, I'd prefer people's cycles 
 be spent on bughunting 2.5 rather than worrying about shiny new 
 features for the release that's, what, 18 months away? 
 
 Anyway, thought I'd open this up for discussion...

I agree with you.  If people want to work on new features, they can
create branches for that -- by default, bug fixes should go into 2.5
without further effort.

Cheers,
mwh

-- 
  I wouldn't trust the Anglo-Saxons for much anything else.  Given
  they way English is spelled, who could trust them on _anything_ that
  had to do with writing things down, anyway?
-- Erik Naggum, comp.lang.lisp
___
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] unicode imports

[M.-A. Lemburg]

Thomas Heller wrote:
 It should be noted that I once started to convert the import machinery
 to be fully unicode aware.  As far as I can tell, a *lot* has to be changed
 to make this work.
 
 I started with refactoring Python/import.c, but nobody responded to the 
 question
 whether such a refactoring patch would be accepted or not.

Perhaps someone should start a PEP on this subject ?!
(not me, though :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 19 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] Code coverage reporting.

[Benji York]

Brett Cannon wrote:
 But it does seem accurate; random checking of some modules that got high 
 but not perfect covereage all seem to be instances where dependency 
 injection would be required to get the tests to work since they were 
 based on platform-specific things.

 I don't know if we need it hooked into the buildbots (unless it is dirt 
 cheap to generate the report).

It would be interesting to combine the coverage over several platforms 
and report that.
--
Benji York
___
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] Switch statement

[Phillip J. Eby]

At 12:28 AM 6/19/2006 -0700, Josiah Carlson wrote:

Phillip J. Eby [EMAIL PROTECTED] wrote:
  At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
  The non-fast version couldn't actually work if it referenced any names,
  given current Python semantics for arbitrary name binding replacements.
 
  Actually, one could consider case expressions to be computed at function
  definition time, the way function defaults are.  That would solve the
  problem of symbolic constants, or indeed any sort of expressions.

Using if/elif/else optimization precludes any non-literal constants, so
we would necessarily have to go with a switch/case for this semantic. It
seems as though it would work well, and wouldn't be fraught with
any of the gotchas that catch users like:
 def fcn(..., dflt={}, dflt2=[]):
...


  An alternate possibility would be to have them computed at first use and
  cached thereafter.
 
  Either way would work, and both would allow multiple versions of the same
  switch statement to be spun off as closures without losing their 
 constant
  nature or expressiveness.  It's just a question of which one is easier to
  explain.  Python already has both types of one-time initialization:
  function defaults are computed at definition time, and modules are only
  loaded once, the first time you import them.

I would go with the former rather than the latter, if only for
flexibility.

There's no difference in flexibility.  In either case, the dictionary 
should be kept in a cell in the function's closure, not with the code 
object.  It would simply be a difference in *when* the values were 
computed, and by which code object.  To be done at function definition 
time, the enclosing code block would have to do it, which would be sort of 
weird from a compiler perspective, and there would be an additional problem 
with getting the line number tables correct.  But that's going to be tricky 
no matter which way it's done.

___
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] Code coverage reporting.

[Walter Dörwald]

Benji York wrote:

 Brett Cannon wrote:
 But it does seem accurate; random checking of some modules that got high 
 but not perfect covereage all seem to be instances where dependency 
 injection would be required to get the tests to work since they were 
 based on platform-specific things.
 
 I don't know if we need it hooked into the buildbots (unless it is dirt 
 cheap to generate the report).
 
 It would be interesting to combine the coverage over several platforms 
 and report that.

The code coverage report should include how often a line got executed,
not just if it got executed at all. This makes it possible to se
hotspots in the code.

BTW, if there's interest, I can change the code behind
http://coverage.livinglogic.de so that instead of importing the data
into a database, static HTML files are created, so that we can run the
job more often on one of the Python servers. Currently the job runs once
a month with

   ./python Lib/test/regrtest.py -T -N -R ::
-uurlfetch,largefile,network,decimal

and takes about one hour to run the tests.

The source code is available from
http://styx.livinglogic.de/~walter/python/coverage/PythonCodeCoverage.py

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] unicode imports

[Nick Coghlan]

Kristján V. Jónsson wrote:
 Funny that no other platforms could benefit from a unicode import path.
 Does that mean that windows will reign supreme?  Please explain.

As near as I can tell, other platforms use encoded strings with the normal 
(byte-based) posix file API, so the Python interpreter and the file system 
simply need to agree on the encoding (typically utf-8) in order for both 
filesystem access and importing from non-ASCII paths to work.

On Windows, though, most of the file system interaction code has had to be 
updated to use the wide-character API where possible. import.c is one of the 
few holdouts that relies entirely on the byte-based posix API.

If I had to put money on what's currently happening on your test machine, it's 
that import.c is trying to do u'c:/tmp/\u814c'.encode('mbcs'), getting 
'c:/tmp/?' and proceeding to do nothing useful with that path entry. Checking 
the result of sys.getfilesystemencoding() should be able to confirm that.

So it looks like it ain't really gonna work properly on Windows unless 
import.c is rewritten to use the Unicode-aware platform independent IO 
implementation in posixmodule.c.

Until that happens (hopefully by Python 2.6), I like MvL's suggestion - look 
at the 8.3 DOS name on the command prompt and put that into sys.path. ctypes 
and/or pywin32 should let you get at that information programmatically.

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] Switch statement

[Nick Coghlan]

Phillip J. Eby wrote:
 Either way would work, and both would allow multiple versions of the same
 switch statement to be spun off as closures without losing their 
 constant
 nature or expressiveness.  It's just a question of which one is easier to
 explain.  Python already has both types of one-time initialization:
 function defaults are computed at definition time, and modules are only
 loaded once, the first time you import them.
 I would go with the former rather than the latter, if only for
 flexibility.
 
 There's no difference in flexibility.  In either case, the dictionary 
 should be kept in a cell in the function's closure, not with the code 
 object.  It would simply be a difference in *when* the values were 
 computed, and by which code object.  To be done at function definition 
 time, the enclosing code block would have to do it, which would be sort of 
 weird from a compiler perspective, and there would be an additional problem 
 with getting the line number tables correct.  But that's going to be tricky 
 no matter which way it's done.

Caching on first use would be the easiest to explain I think. Something like:

 if jump_dict is NULL:
 jump_dict = {FIRST_CASE  : JUMP_TARGET_1,
  SECOND_CASE : JUMP_TARGET_2,
  THIRD_CASE  : JUMP_TARGET_3}
 jump_to_case(value, jump_dict)
 ELSE_CLAUSE
 jump_to_end()

'jump_dict' would be held in a cell on the function's closure (since the 
calculated case values might depend on global or closure variables)
'jump_to_case' would be the new opcode, taking two arguments off the stack 
(the jump dictionary and the switch value), executing the matching case (if 
any) and jumping to the end of the switch statement.
If no case is matched, then fall through to the else clause and then jump to 
the end of the statement.

Then the optimisation of the case where all of the case expressions are 
literals would come under the purview of a constant-folding compiler 
automatically when it figures out that the dictionary literal only contains 
constants.

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] Switch statement

[Phillip J. Eby]

At 12:10 AM 6/20/2006 +1000, Nick Coghlan wrote:
Caching on first use would be the easiest to explain I think. Something like:

  if jump_dict is NULL:
  jump_dict = {FIRST_CASE  : JUMP_TARGET_1,
   SECOND_CASE : JUMP_TARGET_2,
   THIRD_CASE  : JUMP_TARGET_3}
  jump_to_case(value, jump_dict)
  ELSE_CLAUSE
  jump_to_end()

Sadly, it's not *quite* that simple, due to the fact that co_lnotab must be 
increase in line numbers as bytecode offsets increase.  It would actually 
look more like:

  LOAD_DEREF jumpdictN
  JUMP_IF_FALSE  initfirstcase

do_switch:
  ...

initfirstcase:
  DUP_TOP
  # compute case value
  LOAD_CONST firstcaseoffset
  ROT_THREE
  STORE_SUBSCR
  JUMP_FORWARD initsecondcase

firstcaseoffset:
  first case goes here
  ...

initsecondcase:
  DUP_TOP
  # compute case value
  LOAD_CONST secondcaseoffset
  ROT_THREE
  STORE_SUBSCR
  JUMP_FORWARD initthirdcase

secondcaseoffset:
  second case goes here
  ...

...

initlastcase:
  DUP_TOP
  # compute case value
  LOAD_CONST lastcaseoffset
  ROT_THREE
  STORE_SUBSCR
  JUMP_ABSOLUTE doswitch

lastcaseoffset:
  last case goes here



The above shenanigans are necessary because the line numbers of the code 
for computing the case expressions have to be interleaved with the line 
numbers for the code for the case suites.

Of course, we could always change how co_lnotab works, which might be a 
good idea anyway.  As our compilation techniques become more sophisticated, 
it starts to get less and less likely that we will always want bytecode and 
source code to be in exactly the same sequence within a given code object.

___
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] Switch statement

[Guido van Rossum]

On 6/18/06, Josiah Carlson [EMAIL PROTECTED] wrote:
 [...] Offering arbitrary expressions whose
 meaning can vary at runtime would kill any potential speedup (the
 ultimate purpose for having a switch statement), [...]

Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that a switch should only exist for speedup.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] unicode imports

[Kristján V . Jónsson]

Wouldn´t it be possible then to emulate the unix way?  Simply encode any 
unicode paths to utf-8, process them as normal, and then decode them just prior 
to the actual windows io call?  It would make sense to just use the utf-8 
encoding all the way for all platforms (since it is easy to work with), and 
then convert to most appropriate encoding for the platform in question right at 
the end, e.g. unicode for windows, mbcs for windows without unicode (win98) 
(which relies on the LC_LOCALE setting) and whatever 8 bit encoding is 
appropriate for the particular unix platform.

Of course, once there, why not do it unicode all the way up to that last point? 
 Unless there are platforms without wchar_t that would make sense.

At any rate, I am trying to find a coding path of least resistance here.  
Regardless of the timeline or acceptance in mainstream python for this feature, 
it is something I will have to patch in for our application.

Cheers,
Kristján

-Original Message-
From: Nick Coghlan [mailto:[EMAIL PROTECTED] 
Sent: 19. júní 2006 13:46
To: Kristján V. Jónsson
Cc: Martin v. Löwis; Python Dev
Subject: Re: [Python-Dev] unicode imports

Kristján V. Jónsson wrote:
 Funny that no other platforms could benefit from a unicode import path.
 Does that mean that windows will reign supreme?  Please explain.

As near as I can tell, other platforms use encoded strings with the normal
(byte-based) posix file API, so the Python interpreter and the file system 
simply need to agree on the encoding (typically utf-8) in order for both 
filesystem access and importing from non-ASCII paths to work.
___
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] unicode imports

[Guido van Rossum]

On 6/16/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote:
 Although python has had full unicode support for filenames for a long time
 on selected platforms (e.g. Windows), there is one glaring deficiency:  It
 cannot import from paths containing unicode.  I´ve tried creating folders
 with chinese characters and adding them to path, to no avail.

I don't know exactly where this discussion is heading at this point,
but I think it's clear that there's a real (though -- yet -- rare)
problem, for which currently only ugly work-arounds exist. I'm not
convinced that it occurs on other platforms than Windows -- everyone
else seems to use UTF-8 for pathnames, while Windows is stuck with
code pages and other crap, and the only reasaonably way to access
Unicode pathnames is via the Windows-specific Unicode API (which is
why import is the last place where this isn't easily solved, as the
import machinery is completely 8-bit-based).

Has it been determined yet whether the DOS 8+3 filename cannot be used
as a workaround?

Perhaps it would be good enough to wait for Py3k? That will have pure
Unicode strings and the import machinery will be completely rewritten
anyway. (And I wouldn't be surprised if that rewrite were to use pure
Python code.) Py3k will be released later than Python 2.6, but most
likely before 2.7.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] PyString_FromFormat

[Guido van Rossum]

On 6/19/06, Kristján V. Jónsson [EMAIL PROTECTED] wrote:
 One thing I have often lamented having in PyString_FromFormat (and cousins,
 like PyErr_Format) is to be able to integrate PyObject pointers.  Adding
 something like %S and %R (for str() and repr() respectively) seems very
 useful to me.  Is there any reason why this isn´t there?

Asking why a particular feature is omitted rarely is a good starting
point. We collectively probably don't remember, or misremember the
discussion if there was any; the most likely reason is simply that
nobody thought it was useful at the time, and nobody who thought it
*was* useful put enough effort in to provide the feature.

If I had to make a guess, %S and %R as you propose have the very real
possibility to fail. PyString_FromFormat() currently only fails if it
runs out of memory. This is especially helpful for PyErr_Format() --
the last thing you want to hapen during formatting of an error message
is to get an error in the formatting. But there are always ways to
handle that if the use case is strong enough.

If you want to gather use cases, you could scour the Python source
code for calls to either API immediately preceded by a call to
PyObject_Str/Repr() to produce a string to be included into the
message. If you find many, you are not alone and you have a good use
case.

Personally, I think it's not worth the trouble. But I wouldn't
necessarily reject a patch (not that I'm in the business of accepting
individual patches any more -- others will weigh in there).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Misleading error message from PyObject_GenericSetAttr

[Guido van Rossum]

On 6/14/06, Alexander Belopolsky [EMAIL PROTECTED] wrote:
 When an extension type Foo defines tp_getattr, but leaves tp_setattr
 NULL, an attempt to set an attribute bar results in an AttributeError
 with the message 'Foo' object has no attribute 'bar'.  This message
 is misleading because the object may have the attribute 'bar' as
 implemented in tp_getattr.  It would be better to change the message
 to 'Foo' object has only read-only attributes (assign to .bar) as in
 the case tp_setattro == tp_setattr == NULL in  PyObject_SetAttr .

I agree. Can you submit a patch to SF please?

 I've also noticed that the exceptions raised from PyObject_SetAttr are
 TypeErrors. Shouldn't PyObject_GenericSetAttr raise a TypeError if
 tp_setattr is null but tp_getattr is not?  This would be consistent
 with the errors from read-only descriptors.

Attempting to obtain complete consistency between TypeError and
AttributeError is hopeless. But if you want to submit a patch to
reduce a particular bit of inconsistency (without increasing it
elsewhere) it might well be accepted.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Bug: xml.dom.pulldom never gives you END_DOCUMENT events with an Expat parser

[Guido van Rossum]

Hm... Perhaps the xml-sig would be a better place to discuss this?

On 6/11/06, Thomas Broyer [EMAIL PROTECTED] wrote:
 Hi,

 First, sorry for posting this here, I closed my SourceForge account a
 few months ago and I can't get it reopened...

 I'm using python 2.2.1 but a diff on SVN showed that there was no
 change at this level, so the following bug should still be there in
 current versions (I'll try with a 2.4 at work tomorrow). On my
 machine, xml.sax.make_parser returns an
 xml.sax.expatreader.ExpatParser instance.

 The problem is: I'm never given END_DOCUMENT events.

 Code to reproduce:

 from xml.dom.pulldom import parseString
 reader = parseString('element attribute=valuetext/element')
 # The following 2 lines will produce, in order:
 # START_DOCUMENT, START_ELEMENT, TEXT, END_ELEMENT
 # Note the lack of the END_DOCUMENT event.
 for event,node in reader:
print event
 # The following line will get an END_DOCUMENT event
 print reader.getEvent()[0]
 # The following line will throw a SAXParseException,
 # because the SAX parser's close method has been
 # called twice
 print reader.getEvent()[0]


 Cause:

 The xml.dom.pulldom.DOMEventStream.getEvent method, when it has no
 more event in its internal stack, calls the SAX parser's close()
 method (which is OK) then immediately returns 'None', ignoring any
 event that could have been generated by the call to the close()
 method. If you call getEvent later, it will send you the remaining
 events until there are no more left, and then will call the SAX
 parser's close() method again, causing a SAXParseException.
 Because expat (an maybe other parsers too) has no way to know when the
 document ends, it generates the endDocument/END_DOCUMENT event only
 when explicitely told that the XML chunk is the final one (i.e. when
 the close() method is called)


 Proposed fix:

 Add a parser_closed attribute to the DOMEventStream class,
 initialized to False. After having called self.parser.close() in the
 xml.dom.pulldom.DOMEventStream.getEvent method, immediately set this
 parser_closed attribute to True and proceed. Finally, at the
 beginning of the while loop, immediately returns None if
 parser_closed is True to prevent a second call to
 self.parser.close().
 With this change, any call to getEvent when there are no event left
 will return None and never throw an exception, which I think is the
 expected behavior.


 Proposed code:

 The closed attribute is initialized in the __init__ method:
 def __init__(self, stream, parser, bufsize):
 self.stream = stream
 self.parser = parser
 self.parser_closed = False
 self.bufsize = bufsize
 if not hasattr(self.parser, 'feed'):
 self.getEvent = self._slurp
 self.reset()

 The getEvent method becomes:
 def getEvent(self):
 # use IncrementalParser interface, so we get the desired
 # pull effect
 if not self.pulldom.firstEvent[1]:
 self.pulldom.lastEvent = self.pulldom.firstEvent
 while not self.pulldom.firstEvent[1]:
 if self.parser_closed:
 return None
 buf = self.stream.read(self.bufsize)
 if buf:
 self.parser.feed(buf)
 else:
 self.parser.close()
 self.parser_closed = True
 rc = self.pulldom.firstEvent[1][0]
 self.pulldom.firstEvent[1] = self.pulldom.firstEvent[1][1]
 return rc

 The same problem seems to exist in the
 xml.dom.pulldom.DOMEventStream._slurp method, when the SAX parser is
 not an IncrementalParser, as the parser's close() method is never
 called. I suggest adding a call to the close() method in there.
 However, as I only have expat as an option, which implements
 IncrementalParser, I can't test it...
 The _slurp method would become:
 def _slurp(self):
  Fallback replacement for getEvent() using the
 standard SAX2 interface, which means we slurp the
 SAX events into memory (no performance gain, but
 we are compatible to all SAX parsers).
 
 self.parser.parse(self.stream)
 self.parser.close()
 self.getEvent = self._emit
 return self._emit()
 The _emit method raises exceptions when there are no events left, so I
 propose changing it to:
 def _emit(self):
  Fallback replacement for getEvent() that emits
 the events that _slurp() read previously.
 
 if not self.pulldom.firstEvent[1]:
 return None
 rc = self.pulldom.firstEvent[1][0]
 self.pulldom.firstEvent[1] = self.pulldom.firstEvent[1][1]
 return rc

 Hope this helps.

 --
 Thomas Broyer
 ___
 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/guido%40python.org



-- 
--Guido van Rossum 

Re: [Python-Dev] setobject code

[Raymond Hettinger]

Alexander Belopolsky wrote:

1. Is there a reason not to have PySet_CheckExact, given that  
PyFrozenSet_CheckExact exists? Similarly, why PyAnySet_Check, but no  
PySet_Check or PyFrozenSet_Check?
  

If you NEED PySet_CheckExact, then say so.  Adding it is trivial.
Each of the six combinations needs to be evaluated on its own
merits.  Do you have use case where it is important to know that
you have a set, that it is not frozen, and that it is not a subtype?


Raymond

___
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] Improve error msgs?

[Raymond Hettinger]

  
  
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?

 So that's definite "perhaps"?

 Anyway, posted patch 1507676.

Sigh. I guess I'll have to commit it to get a second (actually,

third, thanks Armin) opinion...
  
  
If you want an opinion on whether it is useful, then yes, it is
useful.  Honestly I thought that was kind of obvious since better, more
informative error messages are always better as long as the verbosity
is not insane.
  
  
As for looking at the patch, that is just the usual time/priority
problem.  =)
  
  


Also, be sure to pay attention to speed when it comes to exceptions
that are both generated and caught internally -- those need to remain
as fast and lightweight as possible (not spending time inside sprintf()
and the like).  Grep for PyErr_ExceptionMatches to get a feel for which
should treated with care.   Please do not mindlessly go through and
change all the exception messaging.  Instead, devote some thought to
which messages are detrimentally uninformative and are not part of time
critical execution paths.


Raymond


___
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] When to branch release25-maint?

[Raymond Hettinger]

Anthony Baxter wrote:

A question has been asked about branching release25-maint at the time 
of beta1. I was actually thinking about doing this for 2.5rc1 - once 
we're in release candidate stage we want to really be careful about 
checkins. I'm not sure it's worth branching at beta1 - it's a bit 
more work all round, vs what I suspect will be a small amount of 2.6 
work landing on the trunk nownownow. Also, I'd prefer people's cycles 
be spent on bughunting 2.5 rather than worrying about shiny new 
features for the release that's, what, 18 months away? 
  

I recommend holding-off on a 2.6 branch until someone actually
has some non-trivial amount of 2.6 code ready for a commit.
My guess is that we are all focused on 2.5 or are participating
in intoxicating Py3k discussions.


Raymond

___
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] Switch statement

[Phillip J. Eby]

At 09:27 AM 6/19/2006 -0700, Raymond Hettinger wrote:
Guido van Rossum wrote:
Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that a switch should only exist for speedup.


A switch-statement offers only a modest readability improvement over 
if-elif chains.  If a proposal introduces a switch-statement but doesn't 
support fast dispatch, then it loses much of its appeal.

I would phrase that a lot differently.  A switch statement is *very* 
attractive for its readability.  The main problem is that if the most 
expressive way to do something in Python is also very slow -- i.e., people 
use it when they should be using a dictionary of functions -- then it adds 
to the Python is slow meme by attractive nuisance.  :)

Therefore, a switch statement should be made to perform at least as well as 
a dictionary of functions, or having it might actually be a bad thing.

In any case, we *can* make it perform as well as a dictionary of functions, 
and we can do it with or without another opcode.  What really needs to be 
decided on (i.e. by the BDFL) is the final syntax of the statement itself, 
and the semantics of evaluation time for the 'case' expressions, either at 
first execution of the switch statement, or at function definition time.

If explaining the evaluation time is too difficult, however, it might be an 
argument against the optimization.  But, I don't think that either 
first-use evaluation or definition-time evaluation are too hard to explain, 
since Python has both kinds of evaluation already.

___
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] Switch statement

[Guido van Rossum]

On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
  Guido van Rossum wrote:
  On 6/18/06, Josiah Carlson [EMAIL PROTECTED] wrote:

  [...] Offering arbitrary expressions whose
 meaning can vary at runtime would kill any potential speedup (the
 ultimate purpose for having a switch statement), [...]

  Um, is this dogma? Wouldn't a switch statement also be a welcome
 addition to the readability? I haven't had the time to follow this
 thread (still catching up on my Google 50%) but I'm not sure I agree
 with the idea that a switch should only exist for speedup.

  A switch-statement offers only a modest readability improvement over
 if-elif chains.

Probably, which is why it hasn't been added yet. :-)

But there is a definite readability improvement in that you *know*
that it's always the same variable that is being compared and that no
other conditions are snuck into some branches.

 If a proposal introduces a switch-statement but doesn't
 support fast dispatch, then it loses much of its appeal.  Historically, the
 switch-statement discussions centered around fast dispatch without function
 call overhead or loss of direct read/write to local variables (see
 sre_compile.py and sre_parse.py for code would would see a speed benefit but
 almost no improvement in readability).

Well yes duh, of course a switch syntax should be as fast as a
corresponding if/elif dispatch series. (I look upon
dict-of-functions-based dispatch as a tool for a completely different
use case.)

Perhaps I misunderstood Josiah's comment; I thought he was implying
that a switch should be significantly *faster* than if/elif, and was
arguing against features that would jeopardize that speedup. I would
think that it would be fine if some switches could be compiled into
some kind of lookup table while others would just be translated into a
series of if/elifs. As long as the compiler can tell the difference.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Code coverage reporting.

[Brett Cannon]

On 6/19/06, Benji York [EMAIL PROTECTED] wrote:
Brett Cannon wrote: But it does seem accurate; random checking of some modules that got high but not perfect covereage all seem to be instances where dependency injection would be required to get the tests to work since they were
 based on platform-specific things. I don't know if we need it hooked into the buildbots (unless it is dirt cheap to generate the report).It would be interesting to combine the coverage over several platforms
and report that.Ah, do the union of the coverage! Yeah, that would be nice and give the most accurate coverage data in terms of what is actually being tested. But as Titus says in another email, question is how to get that data sent back to be correlated against.
-Brett
___
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] Switch statement

[Raymond Hettinger]

  A switch-statement offers only a modest readability improvement over
 if-elif chains.


 Probably, which is why it hasn't been added yet. :-)

 But there is a definite readability improvement in that you *know*
 that it's always the same variable that is being compared and that no
 other conditions are snuck into some branches.

Hmm, when I saw that arbitrary expressions were being proposed, I took 
that took mean that the variable would have to be repeated in the branches:

   switch x:
  case  x.endswith('wart'):  salicylic_acid()
  case x.endswith('roid'):  preparation_h()
  default:  chicken_soup()




 I would
 think that it would be fine if some switches could be compiled into
 some kind of lookup table while others would just be translated into a
 series of if/elifs. As long as the compiler can tell the difference.

That's a worthy goal; of course, the devil is in the details.  Given:

 switch x:
case 1:  one()
case 2:  two()
case 3:  three()
default:  too_many()

Do we require that x be hashable so that the compiler can use a lookup 
table?


Raymond

___
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] Code coverage reporting.

[Benji York]

Brett Cannon wrote:
 Ah, do the union of the coverage!  Yeah, that would be nice and give the 
 most accurate coverage data in terms of what is actually being tested.  
 But as Titus says in another email, question is how to get that data 
 sent back to be correlated against.

It might be interesting as a BuilBot extension: you already know the 
definitive identity of the thing that you're running (svn path and 
revision), a central server with established communication channel, plus 
all the other BuildBot machinery.
--
Benji York
___
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] Switch statement

[Guido van Rossum]

On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:

   A switch-statement offers only a modest readability improvement over
  if-elif chains.
 
 
  Probably, which is why it hasn't been added yet. :-)
 
  But there is a definite readability improvement in that you *know*
  that it's always the same variable that is being compared and that no
  other conditions are snuck into some branches.

 Hmm, when I saw that arbitrary expressions were being proposed, I took
 that took mean that the variable would have to be repeated in the branches:

switch x:
   case  x.endswith('wart'):  salicylic_acid()
   case x.endswith('roid'):  preparation_h()
   default:  chicken_soup()

That seems insane, since then it would be *just* different syntax for
if/elif. The example looks deceptive: surely the 'switch' expression
should allow an arbitrary expression, so the 'case' wouldn't be able
to refer to the switch part by a name unless there was syntax (or a
convention) for defining a name by which it could be referenced. I
think Perl 6 is defining a very general matching syntax which people
interested in this might want to study, just to see how far one can
stretch the insanity.

  I would
  think that it would be fine if some switches could be compiled into
  some kind of lookup table while others would just be translated into a
  series of if/elifs. As long as the compiler can tell the difference.
 
 That's a worthy goal; of course, the devil is in the details.  Given:

  switch x:
 case 1:  one()
 case 2:  two()
 case 3:  three()
 default:  too_many()

 Do we require that x be hashable so that the compiler can use a lookup
 table?

That's a good question. We could define switch/case in terms of a hash
table created by the compiler, and then raising an exception if x is
unhashable is fair game. Or we could define it in terms of successive
'==' comparisons, and then the compiler would have to create code for
a slow path in case x is unhashable. I don't think I'm in favor of
always taking the default path when x is unhashable; that would cause
some surprises if an object defines __eq__ to be equal to ints (say)
but not __hash__.

Note that we currently don't have a strong test for hashable; it's
basically if hash(x) doesn't raise an exception which means that we
would have to catch this exception (or perhaps only TypeError) in
order to implement the slow path for the successive-comparisons
semantics.

I note that C doesn't require any particular implementation for
switch/case; there's no rule that says the numbers must fit in an
array of pointers or anything like that. So I would be careful before
we define this in terms of hash tables. OTOH the hash table semantics
don't require us to commit to a definition of hashable, which is an
advantage.

How's that for a wishy-washy answer. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Switch statement

[Ka-Ping Yee]

On Mon, 19 Jun 2006, Guido van Rossum wrote:
 Um, is this dogma? Wouldn't a switch statement also be a welcome
 addition to the readability? I haven't had the time to follow this
 thread (still catching up on my Google 50%) but I'm not sure I agree
 with the idea that a switch should only exist for speedup.

I feel quite strongly that readability should be the primary motivator
for just about any new syntax.

Choosing an implementation that runs at a reasonable speed is also
worthwhile consideration, but readability is where it starts, IMHO.


-- ?!ng
___
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] Switch statement

[Raymond Hettinger]

  But there is a definite readability improvement in that you *know*
  that it's always the same variable that is being compared and that no
  other conditions are snuck into some branches.

 Hmm, when I saw that arbitrary expressions were being proposed, I took
 that took mean that the variable would have to be repeated in the 
 branches:

switch x:
   case  x.endswith('wart'):  salicylic_acid()
   case x.endswith('roid'):  preparation_h()
   default:  chicken_soup()


 That seems insane, since then it would be *just* different syntax for
 if/elif. The example looks deceptive: surely the 'switch' expression
 should allow an arbitrary expression, so the 'case' wouldn't be able
 to refer to the switch part by a name unless there was syntax (or a
 convention) for defining a name by which it could be referenced. I
 think Perl 6 is defining a very general matching syntax which people
 interested in this might want to study, just to see how far one can
 stretch the insanity.

I share that view 100%.  Can we conclude that arbitrary expressions are 
fine for the switch value but that the case values must be constants?  
That would neatly dispense with some proposed hypergeneralizations and 
keep the discussion focused.


  Given:

  switch x:
 case 1:  one()
 case 2:  two()
 case 3:  three()
 default:  too_many()

 Do we require that x be hashable so that the compiler can use a lookup
 table?


 That's a good question. We could define switch/case in terms of a hash
 table created by the compiler, and then raising an exception if x is
 unhashable is fair game.


+1

 Or we could define it in terms of successive
 '==' comparisons, and then the compiler would have to create code for
 a slow path in case x is unhashable.

Too perilous.  I would not like to put us in a position of generating 
duplicate code or funky new opcodes for the case suites.  Also, it is 
better for the user to know that __hash__ is going to be called, that 
the default-clause will execute when the key in not found, and that a 
KeyError would be raised if x is unhashable.  This is simple, 
explainable, consistent behavior.  Besides, if we've agreed that the 
case values are required to be constants, then there isn't much in the 
way of use cases for x being unhashable.


 I don't think I'm in favor of
 always taking the default path when x is unhashable; that would cause
 some surprises if an object defines __eq__ to be equal to ints (say)
 but not __hash__.


That would be unpleasant.



 Note that we currently don't have a strong test for hashable; it's
 basically if hash(x) doesn't raise an exception which means that we
 would have to catch this exception (or perhaps only TypeError) in
 order to implement the slow path for the successive-comparisons
 semantics.

 I note that C doesn't require any particular implementation for
 switch/case; there's no rule that says the numbers must fit in an
 array of pointers or anything like that. So I would be careful before
 we define this in terms of hash tables. OTOH the hash table semantics
 don't require us to commit to a definition of hashable, which is an
 advantage.

 How's that for a wishy-washy answer. :-)

Perfect.  Wishy-washy answers reflect an open mind and they contain the 
seeds of complete agreement.

My thought is that we *should* define switching in terms of hash 
tables.  It builds off of existing knowledge and therefore has a near 
zero learning curve.  The implementation is straight-forward and there 
are none of the hidden surprises that we would have with 
fastpath/slowpath approaches which use different underlying magic 
methods and do not guarantee order of execution.

If use cases eventually emerge for an alternative path using successive 
== comparisons, then it can always be considered and added later.  For 
now, YAGNI (neither the functionality, nor the implementation headaches, 
nor the complexity of explaining what it does under all the various cases).



Raymond

___
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] uuid backward compatibility

[Ka-Ping Yee]

On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 As for the comment: It apparently *is* misleading, George mistakenly
 took it as a requirement for future changes, rather than a factual
 statement about the present (even though it uses the tense of simple
 present). Anybody breaking 2.3 compatibility will have to remember
 to remove the comment, which he likely won't.

This sentiment is puzzling to me.  It seems you assume that we can trust
future developers to change the code but we can't trust them to update
the documentation.  So we can't have documentation even if it's factually
true just because someone might forget to update it?  Why is the mere
possibility of incorrect documentation in the future more significant
than actual correct documentation in the present?  Couldn't the same
argument be used to support removing all documentation from all code?

If you see a better way to word the comment to reduce the possibility
of misunderstanding, that's cool with me.  I'd just like people who
get their hands on the module to know that they can use it with 2.3.


-- ?!ng
___
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] Switch statement

[Guido van Rossum]

On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
 [...] Can we conclude that arbitrary expressions are
 fine for the switch value but that the case values must be constants?

That's too strong I believe. If some or all of the cases are arbitrary
expressions the compiler should try to deal. (Although we might have
to add a rule that if more than one case matches there's no guarantee
which branch is taken.)

In particular I expect that named constants are an important use case
(e.g. all of sre_compile.py uses names to compare the op with). The
compiler can't really tell with any degree of certainty that a name
won't ever be rebound (it would take a pretty smart global code
analyzer to prove that).

 That would neatly dispense with some proposed hypergeneralizations and
 keep the discussion focused.


   Given:
 
   switch x:
  case 1:  one()
  case 2:  two()
  case 3:  three()
  default:  too_many()
 
  Do we require that x be hashable so that the compiler can use a lookup
  table?
 
 
  That's a good question. We could define switch/case in terms of a hash
  table created by the compiler, and then raising an exception if x is
  unhashable is fair game.


 +1

  Or we could define it in terms of successive
  '==' comparisons, and then the compiler would have to create code for
  a slow path in case x is unhashable.

 Too perilous.  I would not like to put us in a position of generating
 duplicate code or funky new opcodes for the case suites.  Also, it is
 better for the user to know that __hash__ is going to be called, that
 the default-clause will execute when the key in not found, and that a
 KeyError would be raised if x is unhashable.  This is simple,
 explainable, consistent behavior.  Besides, if we've agreed that the
 case values are required to be constants, then there isn't much in the
 way of use cases for x being unhashable.

Well, the hypothetical use case is one where we have an arbitrary
object of unknown origin or type, and we want to special-case
treatment for a few known values.

I wonder if there should be two default clauses, or some other
syntactic way to indicate whether we expect all x to be hashable?

OTOH maybe doign the simplest thing that could possibly work is the
right thing here, so I'm not going to push back hard. I guess
practicality beats purity and all that.

Actually there are quiet a few zen of Python rules that endorse the
view that requiring x to be hashable is Pythonic, so I'm being swayed
as I write this. ;-)

  I don't think I'm in favor of
  always taking the default path when x is unhashable; that would cause
  some surprises if an object defines __eq__ to be equal to ints (say)
  but not __hash__.


 That would be unpleasant.


 
  Note that we currently don't have a strong test for hashable; it's
  basically if hash(x) doesn't raise an exception which means that we
  would have to catch this exception (or perhaps only TypeError) in
  order to implement the slow path for the successive-comparisons
  semantics.
 
  I note that C doesn't require any particular implementation for
  switch/case; there's no rule that says the numbers must fit in an
  array of pointers or anything like that. So I would be careful before
  we define this in terms of hash tables. OTOH the hash table semantics
  don't require us to commit to a definition of hashable, which is an
  advantage.
 
  How's that for a wishy-washy answer. :-)
 
 Perfect.  Wishy-washy answers reflect an open mind and they contain the
 seeds of complete agreement.

Thanks. Lawyers have different reasons for being wishy-washy but among
geeks there can be clarity in wshy-washiness. :-)

 My thought is that we *should* define switching in terms of hash
 tables.  It builds off of existing knowledge and therefore has a near
 zero learning curve.  The implementation is straight-forward and there
 are none of the hidden surprises that we would have with
 fastpath/slowpath approaches which use different underlying magic
 methods and do not guarantee order of execution.

I'm not so sure about there being no hidden surprises. I betcha that
there are quire a few bits of code that curerntly use the if/elif
style and seem to beg for a switch statement that depend on the
ordering of the tests. A typical example would be to have one of the
earlier tests express an exception to a later test that is a range
test. (Surely we're going to support range tests... sre_compile.py
uses 'in' almost as often as 'is'.)

 If use cases eventually emerge for an alternative path using successive
 == comparisons, then it can always be considered and added later.  For
 now, YAGNI (neither the functionality, nor the implementation headaches,
 nor the complexity of explaining what it does under all the various cases).

I say, let someone give a complete implementation a try, and then try
to modify as much standard library code as possible to use it. Then
report back. That would be a very interesting experiment to do. (And
thanks 

Re: [Python-Dev] uuid backward compatibility

[Guido van Rossum]

On 6/19/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
 On 6/18/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
  As for the comment: It apparently *is* misleading, George mistakenly
  took it as a requirement for future changes, rather than a factual
  statement about the present (even though it uses the tense of simple
  present). Anybody breaking 2.3 compatibility will have to remember
  to remove the comment, which he likely won't.

 This sentiment is puzzling to me.  It seems you assume that we can trust
 future developers to change the code but we can't trust them to update
 the documentation.

It's sad but true that comments often are out of date for several
releases until someone notices them.

 So we can't have documentation even if it's factually
 true just because someone might forget to update it?  Why is the mere
 possibility of incorrect documentation in the future more significant
 than actual correct documentation in the present?  Couldn't the same
 argument be used to support removing all documentation from all code?

I think it has to be weighed in each case. In *this* particular case
the relevance of the comment seems quite minimal and removing it seems
appropriate.

 If you see a better way to word the comment to reduce the possibility
 of misunderstanding, that's cool with me.  I'd just like people who
 get their hands on the module to know that they can use it with 2.3.

Well even if the comment remains, they are going to have to try it
before they can trust the comment (see above). There is lots of code
in the stdlib that is compatible with Python 2.3 (or 1.5.2 for that
matter). How important is it to record that fact? I'd say not at all.

The Python standard library of a particular Python version shouldn't
be seen as an additional way to distribute code that's intended for
other versions. If you want to encourage people to use your module
with older versions, the right path is to have a distribution (can be
very light-weight) on your own website and add it to PyPI (Cheese
Shop). You can put the same version distributed with Python 2.5 there;
this isn't going to be something with maintenance and featuer
evolution, presumably, since it's only needed until they catch up with
2.5 or later.

If you still aren't convinced, how about a comment like this:

# At the time of writing this module was compatible with Python 2.3 and later.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Numerical robustness, IEEE etc.

[John Williams]

On 6/19/06, Michael Hudson [EMAIL PROTECTED] wrote:
 Nick Maclaren [EMAIL PROTECTED] writes:
  2) Because some people are dearly attached to the current behaviour,
  warts and all, and there is a genuine quandary of whether the 'right'
  behaviour is trap-and-diagnose, propagate-NaN or whatever-IEEE-754R-
  finally-specifies (let's ignore C99 and Java as beyond redemption),

 Why?  Maybe it's clear to you, but it's not totally clear to me, and
 it any case the discussion would be better informed for not being too
 dismissive.

I just happened to be reading this, which I found very convincing:

How Java's Floating-Point Hurts Everyone Everywhere
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
___
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 2.4 extensions require VC 7.1?

[Martin v. Löwis]

Kristján V. Jónsson wrote:
 The signal() doc is rather vague on the point, since it doesn´t
 define the availible set of signals.  It doesn´t even say that a
 signal identifier is an integer.  But it says that it should return
 EINVAL if it cannot satisfy the request.

What signal() doc are you looking at? I'm looking at

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf

section 7.14. This is ISO C99 (actually, technical corrigendum 2
of that), and it does not mention EINVAL. (BTW, signal does
not *return* EINVAL, it returns SIG_ERR and sets errno).

signal() isn't vague about the set of available signals. 7.14/3
lists some, then 7.14/4 says

# The complete set of signals, their semantics, and their default
# handling is implementation-defined; all signal numbers shall be
# positive.

 It doesn´t say if the request is invalid

Ah, so you are looking at the Microsoft documentation? As the
implementation isn't compliant to standard C, I would not expect
their documentation to faithfully reproduce standard C.

 but I don't want to go into hairsplitting here.

It's an important point. If Python does not follow some relevant
standard, and therefore breaks, it is Python that must be fixed.
If it breaks on some system which in itself violates some standard,
we have the choice of either working around or ignoring the system.

 But I completely disagree when you insist that microsoft has broken
 the C library.

But they have. A program that is compliant to standard C used to
work with earlier versions of the C library, and stops working with
the current version.

 What they have done is added parameter validation,
 and thus simply added code in the undefined domain.

Except that the set of supported signals is not undefined, it's
implementation-defined. See 3.4.1 for a definition of
implementation-defined behaviour, and 3.4.3 for a definition
of undefined behaviour.

 I would also
 like to point out that, again apart from signal(), you are relying on
 undefined behaviour of fopen and others.

That is true, so we should fix Python here.

 So, it is my suggestion that in stead of going all defensive, and
 shouting breakage, why not simply fix those very dubious CRT usage
 patterns?  Think of it as lint.

Again, for fopen: sure. For signal, this is not possible: We want to
set *all* signal handlers on a system, but we have know way of
determining at compile time what all signal handlers are. Standard C
is deliberately designed to allow applications to do that, and
with msvcr80.dll, we can't.

 Also, consider this:  in the case of file() and strftime() we are
 passing in dynamic strings.  The strings are not within control of
 python.  Normally these are static strings, within the control of the
 developer which has the function reference on hand, knows what he
 wants and so on.  Yet, here we are passing in any old strings.  There
 is a huge undefined domain there, and we should be very concerned
 about that.  It is a wonder we haven´t seen these functions crash
 before.

No, that's not a wonder. It's actually unfortunate that standard
C did not make it an error, but they likely didn't do it because
of existing practice. However, the usual, natural, straight-forward
way of processing the mode string (in a loop with a switch statement)
can't possible cause crashes.

 (And by the way, why does pythoncore.dll mess with signal() anyway?

So we can redirect all signals handlers to Python code if the
user wishes so.

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] Switch statement

[Raymond Hettinger]

 My thought is that we *should* define switching in terms of hash
 tables.  It builds off of existing knowledge and therefore has a near
 zero learning curve.  The implementation is straight-forward and there
 are none of the hidden surprises that we would have with
 fastpath/slowpath approaches which use different underlying magic
 methods and do not guarantee order of execution.


 I'm not so sure about there being no hidden surprises. I betcha that
 there are quire a few bits of code that curerntly use the if/elif
 style and seem to beg for a switch statement that depend on the
 ordering of the tests. A typical example would be to have one of the
 earlier tests express an exception to a later test that is a range
 test. 


That's a tricky issue.  Whenever the cases overlap, I would expect a 
successive comparison approach to jump to the first match while a hash 
table approach would jump to the last match (just like a dictionary 
retains only the latest (key,value) pair when fed successive pairs with 
identical keys and differing values).


 (Surely we're going to support range tests... sre_compile.py
 uses 'in' almost as often as 'is'.)

When the ranges have a short length as they do in sre, I expect that the 
syntax would allow the range to be captured on one line but have 
multiple entries in the hash table which each dispatch to the same 
target code suite:

switch x:
case 0, 2, 4, 6:  handle_even()
case 1, 3, 5, 9:  handle_odd()
default:  handle_fractions()

Unfortunately, that approach is less than ideal for bigger ranges:

   switch x:
   case xrange(0,sys.maxint,2): handle_odd()
   case xrange(1,sys.maxint,2): handle_even()
   default: handle_fractions()

Other types of range checks get us back into the area of arbitrary 
expressions in case values and having to repeat the variable name:

   switch x:
   case x  60:  return too cold
   case 60 = x  80:  return just right
   case 80 = x: return too hot

Choose your poison.  How much range flexibility do you want and how much 
implementation and behavioral complexity are you willing to pay for it.



 If use cases eventually emerge for an alternative path using successive
 == comparisons, then it can always be considered and added later.  For
 now, YAGNI (neither the functionality, nor the implementation headaches,
 nor the complexity of explaining what it does under all the various 
 cases).


 I say, let someone give a complete implementation a try, and then try
 to modify as much standard library code as possible to use it. Then
 report back. That would be a very interesting experiment to do. (And
 thanks for the pointer to sre_compile.py as a use case!)


Hmm, it could be time for the Georg bot to graduate to big game.
Georg, are you up to it?



Raymond

___
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] Switch statement

[Guido van Rossum]

On 6/19/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Guido]
  I'm not so sure about there being no hidden surprises. I betcha that
  there are quire a few bits of code that curerntly use the if/elif
  style and seem to beg for a switch statement that depend on the
  ordering of the tests. A typical example would be to have one of the
  earlier tests express an exception to a later test that is a range
  test.

 That's a tricky issue.  Whenever the cases overlap, I would expect a
 successive comparison approach to jump to the first match while a hash
 table approach would jump to the last match (just like a dictionary
 retains only the latest (key,value) pair when fed successive pairs with
 identical keys and differing values).

But it would be easy enough to define a dict-filling function that
updates only new values. (PyDict_Merge has an option to do this,
although it's not currently exposed to Python.)

  (Surely we're going to support range tests... sre_compile.py
  uses 'in' almost as often as 'is'.)

 When the ranges have a short length as they do in sre, I expect that the
 syntax would allow the range to be captured on one line but have
 multiple entries in the hash table which each dispatch to the same
 target code suite:

 switch x:
 case 0, 2, 4, 6:  handle_even()
 case 1, 3, 5, 9:  handle_odd()
 default:  handle_fractions()

Was it decided yet how to write the cases for a switch that tests for
tuples of values? Requiring parentheses might be sufficient,
essentially making what follows a case *always* take on sequence
syntax.

 Unfortunately, that approach is less than ideal for bigger ranges:

switch x:
case xrange(0,sys.maxint,2): handle_odd()
case xrange(1,sys.maxint,2): handle_even()
default: handle_fractions()

Right. This would be fine syntactically but clearly breaks the dict
implementation...

 Other types of range checks get us back into the area of arbitrary
 expressions in case values and having to repeat the variable name:

switch x:
case x  60:  return too cold
case 60 = x  80:  return just right
case 80 = x: return too hot

 Choose your poison.  How much range flexibility do you want and how much
 implementation and behavioral complexity are you willing to pay for it.

In order to decide, we should look at current usage of long if/elif chains.

  If use cases eventually emerge for an alternative path using successive
  == comparisons, then it can always be considered and added later.  For
  now, YAGNI (neither the functionality, nor the implementation headaches,
  nor the complexity of explaining what it does under all the various
  cases).
 
  I say, let someone give a complete implementation a try, and then try
  to modify as much standard library code as possible to use it. Then
  report back. That would be a very interesting experiment to do. (And
  thanks for the pointer to sre_compile.py as a use case!)

 Hmm, it could be time for the Georg bot to graduate to big game.
 Georg, are you up to it?

Georg is a bot? :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] unicode imports

[Martin v. Löwis]

Kristján V. Jónsson wrote:
 I don't have specific information on the machines.  We didn´t try
 very hard to get things to work with 2.3 since we simply assumed it
 would work automatically when we upgraded to a more mature 2.4. I
 could try to get more info, but it would be 2.3 specific.  Have there
 been any changes since then?

Not in that respect, no.

 Note that it may not go into program files at all.  Someone may want
 to install his modules in a folder named in the honour of his mother.

It's certainly possible to set this up in a way that it won't work,
on any localized version: just use a path name that isn't supported
in the ANSI code page. However, that should rarely happen: the
name of his mother should still be expressable in the ANSI code
page, if the system is setup correctly.

 Also, I really would like to see a general solution that doesn´t
 assume that the path name can somhow be transmuted to an ascii name.

(Please don't say ASCII here. Windows *A APIs are named that way
 because Microsoft Windows has the notion of an ANSI code page,
 which, in turn, is just a code page indirection so some selected
 code page meant to support the characters of the user's locale)

 Users are unpredictable.  When you have a wide distribution  , you
 come up against all kinds of problems (Currently we have around
 500.000 users in china.) Also, relying on some locale settings is not
 acceptable.

Sure, but stating that doesn't really help. Code contributions
would help, but that part of Python has been left out of using
the *W API, because it is particularly messy to fix.

 Funny that no other platforms could benefit from a unicode import
 path.  Does that mean that windows will reign supreme?

That is the case, more or less. Or, more precisely:
- On Linux, Solaris, and most other Unices, file names are bytes
  on the system API, and are expected to be encoded in the user's
  locale. So if your locale does not support a character, you
  can't name a file that way, on Unix. There is a trend towards
  using UTF-8 locales, so that the locale contains all Unicode
  characters.
- On Mac OS X, all file names are UTF-8, always (unless the
  user managed to mess it up), so you can have arbitrary
  Unicode file names

That means that the approach of converting a Unicode sys.path
element to the file system encoding will always do the right
thing on Linux and OS X: the file system encoding will be
the locale's encoding on Linux, and will be UTF-8 on OS X.

It's only Windows which has valid file names that cannot
be represented in the current locale.

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] unicode imports

[Martin v. Löwis]

Kristján V. Jónsson wrote:
 Wouldn´t it be possible then to emulate the unix way?  Simply encode
 any unicode paths to utf-8, process them as normal, and then decode
 them just prior to the actual windows io call?

That won't work. People also put path names from the ANSI code page
onto sys.path and expect that to work - it always worked, and is
a nearly-complete work-around to put directories with funny characters
onto sys.path. sys.path is a list, so we have little control over
what gets put onto it.

 Of course, once there, why not do it unicode all the way up to that
 last point?  Unless there are platforms without wchar_t that would
 make sense.

Again, we can't really control that. Also, most platforms have no
wchar_t API for file IO. We would have to encode each sys.path
element for each stat() call, which would be quite expensive

 At any rate, I am trying to find a coding path of least resistance
 here.  Regardless of the timeline or acceptance in mainstream python
 for this feature, it is something I will have to patch in for our
 application.

The path with least resistance should be usage of 8.3 directory names.
The one to implement in future Python versions should be the rewrite
of import.c, to operate on PyObject* instead of char*, and perform
conversion to the native API only just before calling the native API.

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] uuid backward compatibility

[Martin v. Löwis]

Ka-Ping Yee wrote:
 This sentiment is puzzling to me.  It seems you assume that we can trust
 future developers to change the code but we can't trust them to update
 the documentation.

That's precisely my expectation. Suppose Python 3.0 unifies int and
long, and deprecates the L suffix. Then,

   if not 0 = time_low  132L:

will change to

   if not 0 = time_low  132:

While this will work fine in Python 2.4 and onwards, it will break
2.3. Whoever is making the change won't even think of the necessity
of a documentation change - after all, this is supposed to be a
style change, only. People do make whole-sale style changes to the
entire library from time to time.

 So we can't have documentation even if it's factually
 true just because someone might forget to update it?

Sure, we can, and if you want that to, we should (you are the author,
so your view is quite important), and I'll shut up. I just wanted
to caution about a risk here.

 If you see a better way to word the comment to reduce the possibility
 of misunderstanding, that's cool with me.  I'd just like people who
 get their hands on the module to know that they can use it with 2.3.

I personally didn't find it misleading at all, and see no need to
change it for *that* reason. I see a potential risk in it wrt.
future changes, but perhaps I'm paranoid.

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] uuid backward compatibility

[Martin v. Löwis]

Guido van Rossum wrote:
 # At the time of writing this module was compatible with Python 2.3 and
 later.

:-)

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

[Python-Dev] os.getmtime now returns a float?

[Gregory P. Smith]

os.path.getmtime returns a float on linux (2.5a2/b1 HEAD); in 2.4 it
returned an int.  this change makes sense, its what time.time returns.

should there be a note in Misc/NEWS or whatsnew mentioning this minor
change (or did i miss it)?  It breaks code that unintentionally
depended on it returning an int.

-g

___
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

[Trent Mick]

[Neal Norwitz wrote on June 8th]
 It's June 9 in most parts of the world.  The schedule calls for beta 1
 on June 14.  That means there's less than 4 days until the expected
 code freeze.  Please don't rush to get everything in at the last
 minute.  The buildbots should remain green to keep Anthony happy and
 me sane (or is it the other way around).
 
 If you plan to make a checkin adding a feature (even a simple one),
 you oughta let people know by responding to this message.  Please get
 the bug fixes in ASAP.  Remember to add tests!

[and then Anthony Baxter wrote today]
  Subject: TRUNK FREEZE IMMINENT FOR 2.5 BETA 1 - 00:00 UTC,20-JUNE-2006
 
  The trunk will be FROZEN for 2.5b1 from 00:00UTC on Tuesday, 20th of
  June. That's about 16 hours from now. Please don't checkin while the
  trunk is frozen, unless you're one of the release team (me, Martin,
  Fred, Ronald).


Can I, or will I be able to get these PyExpat fixes?

* [ 1462338 ] upgrade pyexpat to expat 2.0.0
   http://python.org/sf/1462338

* [ 1295808 ] expat symbols should be namespaced in pyexpat
   http://python.org/sf/1295808

The second one is that one I care about (and is well tested in Komodo on 
four platforms). It will be very important to have that one in the 
Python/Mozilla world (which with Mark Hammond's recent work for 
mozilla.org -- making Python a first class language in the browser along 
with JavaScript) because this namespacing is required to avoid crashing 
conflicts with another version of the expat symbols in the mozilla process.

Martin v. L. wanted the namespacing fix to be preceded by the upgrade to 
expat 2.0.0 -- which I have a patch for also.

I haven't checked in yet, because I dropped the ball for a few weeks here.

I'm going to start working on checking it in right now and will probably 
just go for it (because I have a few hours until Anthony's deadline ;)) 
unless I hear some screams.

Honestly I didn't intentionally wait until the pending trunk-freeze 
email came.

Cheers,
Trent

-- 
Trent Mick
[EMAIL PROTECTED]
___
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] Switch statement

[Delaney, Timothy (Tim)]

Guido van Rossum wrote:

 I wonder if there should be two default clauses, or some other
 syntactic way to indicate whether we expect all x to be hashable?

switch expr:
case 1:
statements
case 2:
statements
else:
statements
except KeyError:
statements
finally:
statements

switch expr:
case 1:
statements
case 2:
statements
else:
statements
except KeyError:
statements
finally:
statements

:)

Seriously, I think I'd rather be explicit and just have KeyError
propagate. If someone is expecting occasional unhashable values, they
can just wrap it in try/except.

try:
switch expr:
case 1:
statements
case 2:
statements
else:
statements
except KeyError:
statements
finally:
statements

The first syntax though does have the advantage that it could catch only
KeyErrors raised from the switch statement. That could be easily handled
by a separate SwitchKeyError exception (inheriting from KeyError).

Tim Delaney
___
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)

[Gerhard Häring]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thomas Heller wrote:
 Martin v. Löwis wrote:
 Guido van Rossum wrote:
 4 of the 6 modules in PEP 360 were added to Python in 2.5, so if you want
 to get rid of it, *now* would be the time.
 I'm all for it.

 While I am an enthusiastic supporter of several of those additions, I
 am *not* in favor of the special status granted to software
 contributed by certain developers, since it is a burden for all other
 developers.
 Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the
 status of each of these has been clarified.

 Each maintainer should indicate whether he is happy with a this is
 part of Python approach. If so, the entry should be removed from PEP
 360 (*); if not, the code should be removed from Python before beta 1.
 
 I will be happy to say ctypes is part of Python (although I *fear* it
 is not one of the packages enthusiastically supported by Guido ;-).

The same goes for the sqlite3 module. I see it as part of Python and also
see it as my job synchronize bugfixes with the external version both ways.

I'll also add statements to the source files to ask developers to keep
Python 2.3 compatibility.

 [...]
 I am *very* thankful for the fixes, the code review, the suggestions,
 and the encouragement I got by various python-devers. [...]

Ditto :-)

So, somebody can please adjust the PEPs for the sqlite3 module accordingly.

- -- Gerhard
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFElxytdIO4ozGCH14RAs8PAJ9/+zGGFj3nLyKPNN+B+UmG3gaJeQCfV7Uc
g0PjyvOfXVkA2cohQjJrzeI=
=nM4W
-END PGP 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] Switch statement

[Benji York]

Delaney, Timothy (Tim) wrote:
  Guido van Rossum wrote:
 
 
 I wonder if there should be two default clauses, or some other
 syntactic way to indicate whether we expect all x to be hashable?
 
 
  switch expr:
  case 1:
  statements
  case 2:
  statements
  else:
  statements
  except KeyError:
  statements
  finally:
  statements

Small variation:

switch expr:
 case 1:
 statements
 case 2:
 statements
 else:
 statements
 except:
 statements
--
Benji York
___
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] Documentation enhancement: MS free compiler?

[Martin v. Löwis]

Cameron Laird wrote:
 I'm channeling a correspondent, who tells me that Python documentation
 (Python 2.5 announcement, and so on) mentions compatibility of sources
 with the MS free compiler; that's the default toolchain for Windows.
 
 Apparently we're in conflict with Microsoft on that:  some hyperlinks
 refer to URL: http://msdn.microsoft.com/visualc/vctoolkit2003/ , which
 begins,
   The Visual C++ Toolkit 2003 has been
   replaced by Visual C++ 2005 Express
   Edition.
 The latter is available at no charge, incidentally.

It would be good to know where the hyperlink supposedly is, so we know
who can update it.

In any case, changing the reference to VS 2005 is the wrong thing to
do - VS 2005 is *not* the default tool chain on Windows. So the update
should be that there is no free compiler from MS anymore (or perhaps
it should point to the .NET SDK, provided that has a free compiler).

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

[Python-Dev] XP build failing

[Brett Cannon]

http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0Looks like Tim's XP box is crapping out on a header file included from Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an external svn pull and thus got bit by it?
-Brett
___
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] Documentation enhancement: MS free compiler?

[Paul Moore]

On 6/19/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Cameron Laird wrote:
  I'm channeling a correspondent, who tells me that Python documentation
  (Python 2.5 announcement, and so on) mentions compatibility of sources
  with the MS free compiler; that's the default toolchain for Windows.
 
  Apparently we're in conflict with Microsoft on that:  some hyperlinks
  refer to URL: http://msdn.microsoft.com/visualc/vctoolkit2003/ , which
  begins,
The Visual C++ Toolkit 2003 has been
replaced by Visual C++ 2005 Express
Edition.
  The latter is available at no charge, incidentally.

 It would be good to know where the hyperlink supposedly is, so we know
 who can update it.

There's one in PCBuild/README - I don't know if that's the one
referred to. However, there is no valid replacement link, so I'm not
sure what it should be replaced with (other than a suggestion that the
only way of getting the toolkit compiler is by unofficial means).

 In any case, changing the reference to VS 2005 is the wrong thing to
 do - VS 2005 is *not* the default tool chain on Windows. So the update
 should be that there is no free compiler from MS anymore (or perhaps
 it should point to the .NET SDK, provided that has a free compiler).

As far as I know, there is *no* replacement for the Toolkit compiler
(where replacement implies builds to link with msvcr71.dll, and is an
optimising compiler).

MS withdrew the toolkit compiler right after my patch to document how
to use it was committed :-( I was sufficiently annoyed and demotivated
by this, that I never did anything to fix the documentation,
particularly as I don't have a good suggestion. I'll see if I have
time to look at the README and suggest suitable words.

Paul.
___
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] unicode imports

[Martin v. Löwis]

Thomas Heller wrote:
 It should be noted that I once started to convert the import machinery
 to be fully unicode aware.  As far as I can tell, a *lot* has to be changed
 to make this work.

Is that code available somewhere still? Does it still work?

 I started with refactoring Python/import.c, but nobody responded to the 
 question
 whether such a refactoring patch would be accepted or not.

I would like to see minimal changes only. I don't see why massive
refactoring would be necessary: the structure of the code should
persist - only the data types should change from char* to PyObject*.
Calls like stat() and open() should be generalized to accept
PyObject*, and otherwise keep their interface.

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] os.getmtime now returns a float?

[Martin v. Löwis]

Gregory P. Smith wrote:
 os.path.getmtime returns a float on linux (2.5a2/b1 HEAD); in 2.4 it
 returned an int.  this change makes sense, its what time.time returns.
 
 should there be a note in Misc/NEWS or whatsnew mentioning this minor
 change (or did i miss it)?  It breaks code that unintentionally
 depended on it returning an int.

There is an entry in Misc/NEWS:

- stat_float_times is now True.

The change was originally announced in

http://www.python.org/doc/2.3/whatsnew/node18.html

which says

During testing, it was found that some applications will break if time
stamps are floats. For compatibility, when using the tuple interface of
the stat_result time stamps will be represented as integers. When using
named fields (a feature first introduced in Python 2.2), time stamps are
still represented as integers, unless os.stat_float_times() is invoked
to enable float return values:

 os.stat(/tmp).st_mtime
1034791200
 os.stat_float_times(True)
 os.stat(/tmp).st_mtime
1034791200.6335014

In Python 2.4, the default will change to always returning floats.

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] uuid backward compatibility

[Ka-Ping Yee]

On Mon, 19 Jun 2006, Guido van Rossum wrote:
 If you want to encourage people to use your module
 with older versions, the right path is to have a distribution (can be
 very light-weight) on your own website and add it to PyPI

Okay, i've removed the comment and submitted the package to PyPI.


-- ?!ng
___
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] XP build failing

[Martin v. Löwis]

Brett Cannon wrote:
 http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0
 
 Looks like Tim's XP box is crapping out on a header file included from
 Tcl/Tk.  Did the Tcl/Tk folk just break something and we are doing an
 external svn pull and thus got bit by it?

No, that comes straight out of

http://svn.python.org/projects/external/tcl8.4.12/generic/tclDecls.h

atleast in theory: there is a build process for tcl running if it wasn't
built before. Could just as well also be a hard disk corruption.

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] PyString_FromFormat

[Martin v. Löwis]

Kristján V. Jónsson wrote:
 One thing I have often lamented having in PyString_FromFormat (and
 cousins, like PyErr_Format) is to be able to integrate PyObject
 pointers.  Adding something like %S and %R (for str() and repr()
 respectively) seems very useful to me.  Is there any reason why this
 isn´t there?

Not sure what the specific use case is, but I think I would use
PyString_Format instead, and use everything you can use in a %
operator. If you want to avoid explicit argument tuple building,
you can also write

  static PyObject *fmt = NULL;
  if (!fmt) fmt = PyString_FromString(Foo %s bar %s foobar %d);
  res = PyMethod_Call(fmt, __mod__, (OOi), o1, o2, 42);

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] XP build failing

[Tim Peters]

[Brett]
 Looks like Tim's XP box is crapping out on a header file included from
 Tcl/Tk.  Did the Tcl/Tk folk just break something and we are doing an
 external svn pull and thus got bit by it?

[Martin]
 No, that comes straight out of

 http://svn.python.org/projects/external/tcl8.4.12/generic/tclDecls.h

 atleast in theory: there is a build process for tcl running if it wasn't
 built before. Could just as well also be a hard disk corruption.

It's a Mystery, and I couldn't find anything wrong in tclDecls.h by
eyeball either.  Blowing away  some directories to force a rebuild of
the tcltk directory appears to have cured it.  There's no other
evidence of disk problems here, but after the current test run
finishes I'm taking the box down to run some pre-boot disk
diagnostics.  I probably left the 2.4 buildbot tree in a broken state,
BTW -- if I don't remember to fix that, somebody poke me :-)
___
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] XP build failing

[Tim Peters]

FYI, the tests all pass on my box again.  Going offline line to check the disk.

 ...
 I probably left the 2.4 buildbot tree in a broken state,
 BTW -- if I don't remember to fix that, somebody poke me :-)

I should clarify that that's _my_ 2.4 buildbot tree, only on my
machine.  I didn't break your 2.4 buildbot tree, let alone the 2.4
buidbot tree.  I don't even know what that means :-)
___
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

[Trent Mick]

Trent Mick wrote:
 * [ 1462338 ] upgrade pyexpat to expat 2.0.0
http://python.org/sf/1462338
 
 * [ 1295808 ] expat symbols should be namespaced in pyexpat
http://python.org/sf/1295808

These are in now. I don't see any failures yet, either on the buildbots 
or on the Windows/Linux/Mac OS X boxes I tested on.

Trent



-- 
Trent Mick
[EMAIL PROTECTED]
___
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] ETree: xml vs xmlcore

[Aahz]

Did we make a final decision about whether the canonical location for
ElementTree should be xml or xmlcore?  Also, there's no ElementTree or
xmlcore that I can find at http://docs.python.org/dev/ under global
module index or library reference.
-- 
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] beta1 coming real soon

[Trent Mick]

Trent Mick wrote:
 Trent Mick wrote:
 * [ 1462338 ] upgrade pyexpat to expat 2.0.0
http://python.org/sf/1462338

 * [ 1295808 ] expat symbols should be namespaced in pyexpat
http://python.org/sf/1295808
 
 These are in now. I don't see any failures yet, either on the buildbots 
 or on the Windows/Linux/Mac OS X boxes I tested on.

It looks like this broke the x86 cygwin build:

http://python.org/dev/buildbot/trunk/x86%20cygwin%20trunk/builds/859/step-test/0

 gcc -shared -Wl,--enable-auto-image-base 
 build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.o
  
 build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmlparse.o
  
 build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmlrole.o
  
 build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/expat/xmltok.o
  -L/usr/local/lib -L. -lpython2.5 -o 
 build/lib.cygwin-1.5.19-i686-2.5/pyexpat.dll
 build/temp.cygwin-1.5.19-i686-2.5/home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.o:
  In function `set_error':
 /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:126: 
 undefined reference to `_XML_GetCurrentLineNumber'
 /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:127: 
 undefined reference to `_XML_GetCurrentColumnNumber'
 /home/anthony/Buildbot/trunk.baxter-cygwin/build/Modules/pyexpat.c:131: 
 undefined reference to `_XML_ErrorString'
 ...

I don't have this environment setup right now, though I'll try to check 
in the morning if someone hasn't beaten me to it. (Showing my ignorance 
here and grasping at straws: this wouldn't be because of some extern 
C-name-mangling-with-underscore-prefix thing would it?)

Modules/pyexpat.c:5
#include expat.h
Modules/expat/expat.h:18
#include expat_external.h
Modules/expat/expat_external.h:12
#include pyexpatns.h
Modules/expat/pyexpatns.h:52
#define XML_GetCurrentLineNumberPyExpat_XML_GetCurrentLineNumber

I don't see where the disconnect is.


Trent

-- 
Trent Mick
[EMAIL PROTECTED]
___
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

[Neal Norwitz]

On 6/19/06, Trent Mick [EMAIL PROTECTED] wrote:
 Trent Mick wrote:
  Trent Mick wrote:
  * [ 1462338 ] upgrade pyexpat to expat 2.0.0
 http://python.org/sf/1462338
 
  * [ 1295808 ] expat symbols should be namespaced in pyexpat
 http://python.org/sf/1295808
 
  These are in now. I don't see any failures yet, either on the buildbots
  or on the Windows/Linux/Mac OS X boxes I tested on.

 It looks like this broke the x86 cygwin build:

 http://python.org/dev/buildbot/trunk/x86%20cygwin%20trunk/builds/859/step-test/0

Unfortunately, it's always red, athough this failure is new.

 I don't have this environment setup right now, though I'll try to check
 in the morning if someone hasn't beaten me to it. (Showing my ignorance
 here and grasping at straws: this wouldn't be because of some extern
 C-name-mangling-with-underscore-prefix thing would it?)

I didn't see where pyexpat.c got rebuilt in the compile/test steps.
Which would explain why it can't find new names.  Not sure if that's
the problem or not.  make distclean is supposed to clean that up, hmm
I wonder if distclean was run before this build.  I'm gonna try to
force another build on cygwin.  Anthony might need to do a manual make
distclean.

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] Switch statement

[Josiah Carlson]

Guido van Rossum [EMAIL PROTECTED] wrote:
 Perhaps I misunderstood Josiah's comment; I thought he was implying
 that a switch should be significantly *faster* than if/elif, and was
 arguing against features that would jeopardize that speedup. I would
 think that it would be fine if some switches could be compiled into
 some kind of lookup table while others would just be translated into a
 series of if/elifs. As long as the compiler can tell the difference.

I personally don't find switch/case statements to be significantly (if
at all) easier to read than if/elif/else chains, but that is subjective,
and I note that Ka-Ping finds switch/case to be significantly easier to
read.

Regardless of readability (I know that readability counts), TOOWTDI. If
we allow somewhat arbitrary cases, then any potential speedup may be
thrown away (which would bother those of us who use dispatching), and we
essentially get a different syntax for if/elif/else.  I don't know about
everyone else, but I'm not looking for a different syntax for
if/elif/else, I'm looking for fast dispatch with some reasonable syntax.

In my opinion, the most reasonable syntax is a semantic change for fast
dispatch inside of specifically crafted if/elif chains of the form:
if/elif non_dotted_name == constant_expression:
As stated various ways by various people, you can generate a hash table
during function definition (or otherwise), verify that the value of
non_dotted_name is hashable, and jump to particular offsets.  If you are
careful with your offsets, you can even have parallel if/elif/else tests
that fall through in the case of a 'non-hashable'.

There is a drawback to the non-syntax if/elif/else optimization,
specifically that someone could find that their dispatch mysteriously
got slower when they went from x==1 to including some other comparison
operator in the chain somewhere.  Well, that and the somewhat restricted
set of optimizations, but we seem to be headed into that restricted set
of optimizations anyways.

One benefit to the non-syntax optimization is that it seems like it could
be implemented as a bytecode hack, allowing us to punt on the entire
discussion, and really decide on whether such a decorator should be in
the standard library (assuming someone is willing to write the decorator).

 - 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] ETree: xml vs xmlcore

[Fredrik Lundh]

Aahz wrote:

 Did we make a final decision about whether the canonical location for
 ElementTree should be xml or xmlcore?

the original idea was to use xml to get the latest and greatest from 
either the core or PyXML, xmlcore to use the bundled version.  I see 
no reason to change this just because people have short memory ;-)

(in other words, the modules should be documented as xml.xxx, with a 
note that says that they're also available as xmlcore.xxx.  this applies 
to all modules under xml, not just etree.).

  Also, there's no ElementTree or
 xmlcore that I can find at http://docs.python.org/dev/ under global
 module index or library reference.

the docs are still sitting in the patch tracker.  looks like the just 
post text files; we'll fix the markup approach doesn't work.  oh well, 
there's plenty of time to fix that before 2.5 final.

/F

___
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