Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Noam Raphael wrote:
> 2006/6/17, "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> Noam Raphael wrote:
>>> I meant the extra code for writing a special class to handle scalars,
>>> if I decide that the "x[()]" syntax is too ugly or too hard to type,
>>> so I write a special class which will allow the syntax "x.value".
>> What I cannot understand is why you use a zero-dimensional array to
>> represent a scalar. Scalars are directly supported in Python:
>>
>> x = 5
>
> I need a zero-dimensional array as a single cell - an object that
> holds a value that can change over time. It works just like a cell in
> a spreadsheet: For example, say that if you change the value of cell
> A1 to 0.18, cell A2 changes to 5. When using the library I design, you
> would write "sheet1[0, 0] = 0.18", and, magically, "sheet1[0, 1]" will
> become 5. But in my library, everything is meaningful and doesn't have
> to be two-dimensional. So, if in the spreadsheet example, A1 meant the
> income tax rate, you would write "income_tax[] = 0.18", and,
> magically, "profit['Jerusalem', 2005]" will become 5.
Try to think more about how users will use your API. You haven't
specified where those names (sheet1, income_tax, and profit) are coming
from. What do you expect users of your library to do to bring those
names into their namespace?
Let me take a wild guess so you can see what I'm asking:
import spreadsheetlib
sheet1 = spreadsheetlib.sheet('sheet1')
income_tax = spreadsheetlib.cell('income_tax')
profit = spreadsheetlib.cell('profit')
So far, that's a mess! What are you really going to do? Will it be
better? This could be a much greater concern than optimizing away
parentheses.
A possible way to solve the namespace problem is to make all names an
attribute of some object.
from spreadsheetlib import sp
sp.sheet1[0, 0] = 0.18
assert sp.sheet1[0, 1] == 5
sp.income_tax = 0.18
assert sp.profit['Jerusalem', 2005] == 5
That would be a pretty usable API, IMHO, and you'd be able to write it
now without any changes to Python.
Shane
___
Python-Dev mailing list
[email protected]
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
On Sun, 18 Jun 2006, George Yoshida wrote: > uuid.py says in its docstring: > This module works with Python 2.3 or higher. > > And my question is: > Do we plan to make it 2.3 compatible in future releases? > > If so, uuid needs to be listed in PEP 291. > Otherwise, the comment is misleading. The comment isn't misleading, because the module actually does work with Python 2.3. It would only become misleading if it were later changed to break compatibility with Python 2.3 without updating the comment. I intentionally avoided breaking compatibility with Python 2.3 so that there would be just one current version of uuid.py, both in the svn repository and available for use with existing installations of Python, since Python 2.3 is so widely deployed right now. Anyway, it looks like someone has added this module to the list of backward-compatible modules in PEP 291. Regarding whether we want it to be on that list (i.e. whether or not this backward-compatibility should be retained as Python moves forward), i'm happy to have it either way. -- ?!ng ___ Python-Dev mailing list [email protected] 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 wrote: > Anyway, it looks like someone has added this module to the list of > backward-compatible modules in PEP 291. Regarding whether we want > it to be on that list (i.e. whether or not this backward-compatibility > should be retained as Python moves forward), i'm happy to have it > either way. In that case, I think we shouldn't require 2.3 compatibility. There is no reason to deliberately break it either, of course. 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. Regards, Martin ___ Python-Dev mailing list [email protected] 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?
Georg Brandl wrote:
> Georg Brandl wrote:
>> 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...
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding winerror module (Beta 1 schedule ?)
Anthony Baxter wrote: >> I'd also like to get the new winerror module in before >> beta1 is released - documentation will follow next week: > > Hm. A new python module should be OK - but I was under the impression > that then large piles of the standard library would be updated to use > this new module. I'm less happy (much less) about this happening for > 2.5. I don't think that a lot of code currently uses the Windows error codes. If code does use the Windows error codes, then they usually hard-code the values in the module, so replacing those values with ones from winerror wouldn't cause breakage. winerror only contains mappings from error codes to error names and vice-versa. I agree, that it's a bit late in the 2.5 release process to add a new module. Perhaps it should wait until 2.6. Note that the module was motivated by a change Martin implemented which now causes several os module APIs to return Windows error codes rather than POSIX ones (r45925). This was later reverted by Martin (r45964). The Windows error codes are now available through the .winerror attribute. The winerror module is intended to be able to use symbolic names for code using .winerror (much like the errno serves this purpose for .errno). >> Is it OK to first check in a pure Python version and then >> replace this with a C implementation having the same interface >> later on in the beta cycle ? > > How big is it likely to be? How much of a pain will it be to make it > work with various versions of Windows? Not much: the C module will contain the same values as the Python file (which are extracted from the standard Windows WinError.h file). The only difference is that the C module will use a static C array to store the values, which results in less heap memory being used. Both modules are (will be) generated from the WinError.h file (see the SF patch). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 18 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding winerror module (Beta 1 schedule ?)
M.-A. Lemburg wrote: > The winerror module is intended to be able to use symbolic > names for code using .winerror (much like the errno > serves this purpose for .errno). couldn't this be implemented as an extra table in errno instead ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
The implementations of PEP 328 (explicit relative imports) and PEP 338 (executing modules as scripts) currently have a fight over the __name__ attribute of a module. The -m switch sets __name__ to '__main__', even though it knows the module's real name. This is so that "if __name__ == '__main__':" blocks get executed properly in the main module. Relative imports, however, use __name__ to figure out the parent package, which obviously won't work if the -m switch has clobbered it. I think this is a solvable problem, but with beta 1 going out in a couple of days, I don't know if it's too late in the 2.5 cycle to fix it. If Anthony's willing to class this as a bug fix, it should be possible to get it sorted out by beta 2. I think fixing it will actually be easier than trying to write documentation explaining why it doesn't work right ;) The 'bug fix' solution would be: 1. Change main.c and PySys_SetPath so that '' is NOT prepended to sys.path when the -m switch is used 2. Change runpy.run_module to add a __pkg_name__ attribute if the module being executed is inside a package 3. Change import.c to check for __pkg_name__ if (and only if) __name__ == '__main__' and use __pkg_name__ if it is found. If we don't fix it, I'd like to document somewhere that you can't currently rely on relative imports if you want to be able to execute your module with the '-m' switch. However, the question I have then is. . . where? It's pretty esoteric, so I don't really want to put it in the tutorial, but I can't think of any other real documentation we have that covers how to launch the interpreter or the "if __name__ == '__main__':" trick. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding winerror module (Beta 1 schedule ?)
On 6/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Anthony Baxter wrote: > >> I'd also like to get the new winerror module in before > >> beta1 is released - documentation will follow next week: > > > > Hm. A new python module should be OK - but I was under the impression > > that then large piles of the standard library would be updated to use > > this new module. I'm less happy (much less) about this happening for > > 2.5. > > I don't think that a lot of code currently uses the Windows > error codes. If code does use the Windows error codes, then > they usually hard-code the values in the module, so replacing > those values with ones from winerror wouldn't cause breakage. > winerror only contains mappings from error codes to error > names and vice-versa. > > I agree, that it's a bit late in the 2.5 release process > to add a new module. Perhaps it should wait until 2.6. That's a big part of the reason I'd like to wait. I think Martin had something about it he didn't like. If the API isn't right, it's hard to change. If we wait for 2.6, we can have more confidence the API will be good and we won't have to rush anything. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
2006/6/18, Shane Hathaway <[EMAIL PROTECTED]>: > Try to think more about how users will use your API. You haven't > specified where those names (sheet1, income_tax, and profit) are coming > from. What do you expect users of your library to do to bring those > names into their namespace? > That's a good question. I'm going to do some bytecode hacks! Something like this: from spreadsheetlib import SourceCube, CalculatedCube income_tax = SourceCube([]) income_tax[] = 0.18 years = set([2003, 2004, 2005]) profit = SourceCube([years]) profit[2003] = 1000; profit[2004] = 2000; profit[2005] = 2500 real_profit = CalculatedCube([years], lambda year: profit[year] / (1+ income_tax[])) print real_profit[2004] (1694.9152542372883) It may be what Talin meant about a "higher level language", but I don't really change the language - I only inspect the function to see on what other changeable objects it depends. Those changeable objects implement some sort of change notification protocol, and it allows the system to automatically recalculate the result when one of the values it depends on changes. (Actually, I intend to change the function to depend directly on the changeable object instead of look it up every time in the global namespace, but I don't think that it changes the explanation.) Note that requiring that all changeable objects will be attributes of some other object won't remove the need for bytecode hacking: the only way is to explicitly specify a list of all the objects that the function depends on, and then give a function that gets these as arguments. This will really be inconvenient. But thanks for the suggestion! Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
On 6/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Talin wrote: > > The motivation, as I understand it, is one of mathematical consistency. > > Noam told me in private email that this is *not* the motivation. > Instead, he wants mutable values. This, in turn, he wants so he > can catch modifications. That cannot be the only motivation. He can have mutable values today without any new syntax. (Either he can use x[()] or he can use attribute assignment.) But more to the point, this discussion is pointless, since I won't accept the syntax change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > The implementations of PEP 328 (explicit relative imports) and PEP 338 > (executing modules as scripts) currently have a fight over the __name__ > attribute of a module. > > The -m switch sets __name__ to '__main__', even though it knows the module's > real name. This is so that "if __name__ == '__main__':" blocks get executed > properly in the main module. > > Relative imports, however, use __name__ to figure out the parent package, > which obviously won't work if the -m switch has clobbered it. > > I think this is a solvable problem, but with beta 1 going out in a couple of > days, I don't know if it's too late in the 2.5 cycle to fix it. > > If Anthony's willing to class this as a bug fix, it should be possible to get > it sorted out by beta 2. I think fixing it will actually be easier than trying > to write documentation explaining why it doesn't work right ;) > > The 'bug fix' solution would be: > >1. Change main.c and PySys_SetPath so that '' is NOT prepended to sys.path > when the -m switch is used >2. Change runpy.run_module to add a __pkg_name__ attribute if the module > being executed is inside a package >3. Change import.c to check for __pkg_name__ if (and only if) __name__ == > '__main__' and use __pkg_name__ if it is found. That's pretty heavy-handed for a pretty esoteric use case. (Except #1, which I think should be done regardless as otherwise we'd get a messed-up sys.path.) I'd like to understand the use case better. Why can't a "script" module inside a package use absolute imports to reference other parts of the package? > If we don't fix it, I'd like to document somewhere that you can't currently > rely on relative imports if you want to be able to execute your module with > the '-m' switch. > > However, the question I have then is. . . where? It's pretty esoteric, so I > don't really want to put it in the tutorial, but I can't think of any other > real documentation we have that covers how to launch the interpreter or the > "if __name__ == '__main__':" trick. With the docs for -m, obviously. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An obscene computed goto bytecode hack for "switch" :)
On 6/17/06, Armin Rigo <[EMAIL PROTECTED]> wrote: > The reason is that the details of the stack behavior of END_FINALLY are > messy in CPython. The finally blocks are the only place where the depth > of the stack is not known in advance: depending on how the finally block > is entered, there will be between one and three objects pushed (a single > None, or an int and another object, or an exception type, instance and > traceback). FWIW, I see this as an unintended accident and would gratefully accept fixes to the bytecode that made this behavior more regular. I'm not in favor of abusing this to generate a computed goto, and I don't see a need for that -- if we decide to add that (either as syntax or as an automatic optimization) I see no problem adding a new bytecode. Python's bytecode is not sacred or frozen like Java's. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding winerror module (Beta 1 schedule ?)
Neal Norwitz wrote: > On 6/18/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> Anthony Baxter wrote: >> >> I'd also like to get the new winerror module in before >> >> beta1 is released - documentation will follow next week: >> > >> > Hm. A new python module should be OK - but I was under the impression >> > that then large piles of the standard library would be updated to use >> > this new module. I'm less happy (much less) about this happening for >> > 2.5. >> >> I don't think that a lot of code currently uses the Windows >> error codes. If code does use the Windows error codes, then >> they usually hard-code the values in the module, so replacing >> those values with ones from winerror wouldn't cause breakage. >> winerror only contains mappings from error codes to error >> names and vice-versa. >> >> I agree, that it's a bit late in the 2.5 release process >> to add a new module. Perhaps it should wait until 2.6. > > That's a big part of the reason I'd like to wait. I think Martin had > something about it he didn't like. If the API isn't right, it's hard > to change. If we wait for 2.6, we can have more confidence the API > will be good and we won't have to rush anything. Ok, let's wait for Python 2.6... -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 18 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 [email protected] 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
On 6/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:> Ka-Ping Yee wrote:> > Anyway, it looks like someone has added this module to the list of > > backward-compatible modules in PEP 291. Regarding whether we want> > it to be on that list (i.e. whether or not this backward-compatibility> > should be retained as Python moves forward), i'm happy to have it > > either way.> > In that case, I think we shouldn't require 2.3 compatibility. There> is no reason to deliberately break it either, of course.> I agree with Martin. We can try to avoid the issue (and usually people should to make backporting fixes easier), but adding that hinderance can be a real pain, especially as we get farther and farther away from 2.3 .> 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.> I think it is better to add a comment in the external release that it is backwards compatible somewhere, but leave it out of the core. -Brett ___ Python-Dev mailing list [email protected] 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?
On 6/18/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote:> Georg Brandl wrote:>> 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. =)-Brett
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An obscene computed goto bytecode hack for "switch" :)
At 11:23 AM 6/18/2006 -0700, Guido van Rossum wrote: >I'm not in favor of abusing this to generate a computed goto, and I >don't see a need for that -- if we decide to add that (either as >syntax or as an automatic optimization) I see no problem adding a new >bytecode. Me either -- I suggest simply adding a JUMP_TOP -- but I wanted to point out that people wouldn't need to add a new opcode in order to experiment with possible "switch" syntaxes. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote: >On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > The 'bug fix' solution would be: > > > >1. Change main.c and PySys_SetPath so that '' is NOT prepended to > sys.path > > when the -m switch is used > >2. Change runpy.run_module to add a __pkg_name__ attribute if the module > > being executed is inside a package > >3. Change import.c to check for __pkg_name__ if (and only if) > __name__ == > > '__main__' and use __pkg_name__ if it is found. > >That's pretty heavy-handed for a pretty esoteric use case. (Except #1, >which I think should be done regardless as otherwise we'd get a >messed-up sys.path.) Since the -m module is being run as a script, shouldn't it put the module's directory as the first entry on sys.path? I don't think we should change the fact that *some* directory is always inserted at the beginning of sys.path -- and all the precedents at the moment say "script directory", if you consider -c and the interactive interpreter to be scripts in the current directory. :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
2006/6/18, Guido van Rossum <[EMAIL PROTECTED]>: > But more to the point, this discussion is pointless, since I won't > accept the syntax change. OK, too bad! But don't say I haven't warned you, when you will all use my fabulous package and get tired from typing all those extra parentheses! :) Noam ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
On 6/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote: > >On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > The 'bug fix' solution would be: > > > > > >1. Change main.c and PySys_SetPath so that '' is NOT prepended to > > sys.path > > > when the -m switch is used > > >2. Change runpy.run_module to add a __pkg_name__ attribute if the > > > module > > > being executed is inside a package > > >3. Change import.c to check for __pkg_name__ if (and only if) > > __name__ == > > > '__main__' and use __pkg_name__ if it is found. > > > >That's pretty heavy-handed for a pretty esoteric use case. (Except #1, > >which I think should be done regardless as otherwise we'd get a > >messed-up sys.path.) > > Since the -m module is being run as a script, shouldn't it put the module's > directory as the first entry on sys.path? Yes for a top-level module. No if it's executing a module inside a package; it's really evil to have a package directory on sys.path. > I don't think we should change > the fact that *some* directory is always inserted at the beginning of > sys.path -- and all the precedents at the moment say "script directory", if > you consider -c and the interactive interpreter to be scripts in the > current directory. :) You have a point about sys.path[0] being special. It could be the current directory instead of the package directory. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
On 6/18/06, Noam Raphael <[EMAIL PROTECTED]> wrote: > 2006/6/18, Guido van Rossum <[EMAIL PROTECTED]>: > > But more to the point, this discussion is pointless, since I won't > > accept the syntax change. > > OK, too bad! > > But don't say I haven't warned you, when you will all use my fabulous > package and get tired from typing all those extra parentheses! :) The bet is on. :) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
At 02:03 PM 6/18/2006 -0700, Guido van Rossum wrote: >On 6/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote: > > >On 6/18/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > > The 'bug fix' solution would be: > > > > > > > >1. Change main.c and PySys_SetPath so that '' is NOT prepended to > > > sys.path > > > > when the -m switch is used > > > >2. Change runpy.run_module to add a __pkg_name__ attribute if > the module > > > > being executed is inside a package > > > >3. Change import.c to check for __pkg_name__ if (and only if) > > > __name__ == > > > > '__main__' and use __pkg_name__ if it is found. > > > > > >That's pretty heavy-handed for a pretty esoteric use case. (Except #1, > > >which I think should be done regardless as otherwise we'd get a > > >messed-up sys.path.) > > > > Since the -m module is being run as a script, shouldn't it put the module's > > directory as the first entry on sys.path? > >Yes for a top-level module. No if it's executing a module inside a >package; it's really evil to have a package directory on sys.path. > > > I don't think we should change > > the fact that *some* directory is always inserted at the beginning of > > sys.path -- and all the precedents at the moment say "script directory", if > > you consider -c and the interactive interpreter to be scripts in the > > current directory. :) > >You have a point about sys.path[0] being special. It could be the >current directory instead of the package directory. Mightn't that be a security risk, in that it introduces an import hole for secure scripts run with -m? Not that I know of any such scripts existing as yet... If it's not the package directory, perhaps it could be a copy of whatever sys.path entry the package was found under - that wouldn't do anything but make "nearby" imports faster. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
On 6/18/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > >You have a point about sys.path[0] being special. It could be the > >current directory instead of the package directory. > > Mightn't that be a security risk, in that it introduces an import hole for > secure scripts run with -m? Not that I know of any such scripts existing > as yet... That sounds like an invented use case if I ever heard of one. YAGNI, please! > If it's not the package directory, perhaps it could be a copy of whatever > sys.path entry the package was found under - that wouldn't do anything but > make "nearby" imports faster. But it could theoretically affect search order for other modules. I still see nothing wrong with "". After all that's also the default if you run a script using python http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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
On Sat, Jun 10, 2006 at 05:53:14PM -0500, [EMAIL PROTECTED] wrote:
>
> Thomas> As the subject of this e-mail says, the attached patch adds a
> Thomas> "switch" statement to the Python language.
>
> Thanks for the contribution. I patched my sandbox and it built just fine.
> I'm going out of town for a couple weeks, so I'll point out what everyone
> else is thinking then duck out of the way:
>
> * Aside from the modified Grammar file there is no documentation.
> * There are no test cases.
> * Can you submit a patch on SourceForge?
>
You're right, of course. I'll sort the documentation and test cases out
as soon as I get a chance.
> You mentioned:
>
> Thomas> I got a bit lost as to why the SWITCH opcode is necessary for
> Thomas> the implementation of the PEP. The reasoning seems to be
> Thomas> improving performance, but I'm not sure how a new opcode could
> Thomas> improve performance.
>
> Your implementation is straightforward, but uses a series of DUP_TOP and
> COMPARE_OP instructions to compare each alternative expression to the
> initial expression. In many other languages the expression associated with
> the case would be restricted to be a constant expression so that at compile
> time a jump table or dictionary lookup could be used to jump straight to the
> desired case.
>
I see. But restricting the switch to constants in the name of
performance may not make sense in a language like Python. Maybe this is
something for the PEP to discuss, but it seems such an implementation
would be confusing and sometimes it may not be possible to use a switch
case in place of if/elif/else statements at all.
Consider the following:
#!/usr/bin/python
FAUX_CONST_A = 'a'
FAUX_CONST_B = 'b'
some_value = 'a'
switch some_value:
case FAUX_CONST_A:
print 'got a'
case FAUX_CONST_B:
print 'got b'
else:
print ':('
# EOF
Although, conceptually, FAUX_CONST_A and FAUX_CONST_B are constants, a
'constants only' implementation would likely give a syntax error (see
expr_constant in Python/compile.c).
IMHO, this will lead to one of two things:
a) unnecessarily duplication of constant values for the purpose of using
them as case values
b) reverting back to if/elif/else
I do get the distinction, I'm just wondering if the usefulness of the semantics
(or lack thereof) are going to negate any potential performance
enhancements: if a switch statement is never used because it's only
useful in a narrow set of circumstances, then maybe we're looking to
improve performance in the wrong place?
Just thinking about it, maybe there could be two different code paths
for switch statements: one when all the case values are constants (the
'fast' one) and one where one or more are expressions. This would mean a
slightly longer compile time for switch statements while ensuring that
runtime execution is the maximum possible without placing any major
restrictions on what can be used as a case value.
Cheers,
Tom
--
Tom Lee
http://www.vector-seven.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault in collections.defaultdict
On 6/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: Kevin Jacobs <[EMAIL PROTECTED]> wrote:> Try this at home:> import collections> d=collections.defaultdict(int)> d.iterkeys().next() # Seg fault > d.iteritems().next() # Seg fault> d.itervalues().next() # Fine and dandyThis all worked fine for me in rev 46739 and 46849 (Kubuntu 6.06, gcc 4.0.3).> Python version:> Python 2.5a2 (trunk:46822M, Jun 10 2006, 13:14:15)> [GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] on linux2Either something got broken and then fixed again between the two revs I tried,there's a problem specific to GCC 4.0.2, or there's a problem with whateverlocal modifications you have in your working copy :)Looks like pilot error on this one. I'm working on a 64 bit system and did not do a distclean after my svn update. Tim updated dictobject's mask from an int to Py_ssize_t in rev 46594 ( http://svn.python.org/view?rev=46594&view=rev), which changed the memory layout of dictionaries. I can only assume that collectionsmodule.c was not recompiled to reflect this change and the dict iterator was using a garbled mask. Resolution: Always run distclean when updating from the trunk.Sorry for the noise,-Kevin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Bug: xml.dom.pulldom never gives you END_DOCUMENT events with an Expat parser
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('text')
# 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
[email protected]
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)
[Guido] > 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. [Martin] > 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 very much identify with Phillip's gripe, but I gotta admit Guido has the compelling argument here. Personally, I have noticed very few "rogue" changes to optparse.py over the years, and have quietly grumbled and backported most of them over to Optik for eventual re-merge to optparse. (One or two got dropped because I had already fixed the problem differently in Optik.) I think this is just the price that must be paid for maintaining two copies of something. It's nice that Optik has an existence of its own (every time I break compatibility with Python 2.0, someone comes along with a patch to restore it), but I think it's better that the burden of keeping track of what is effectively a closely-tracked fork should be on the person who knows the code best (me), not on a horde of Python developers who may occasionally stumble across a style issue or shallowf bug and just fix it. In retrospect, I'm *really* glad that I didn't release textwrap separately, and just stuffed it in the stdlib. And while I have been thinking about Optik 2.0 for a couple of years now, I think that I have just decided that there will be no Optik 2.0: there will only be optparse2. (Unless I can figure out a backwards-compatible way of making the changes I've been thinking about all these years, in which case there will only be optparse. Unlikely.) Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Reality is for people who can't handle science fiction. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On Tue, Jun 13, 2006 at 10:27:17AM +0200, Alexander Schremmer wrote: > Maybe you benchmarked a Tailor deficiency here, but Mercurial scales very > well. People use it for work on the Linux kernel etc. > Compared to that, Bazaar-NG seems to reach limits already when working on > it's own code/repository. We happen to have switched to mercurial a month ago for all of our code and are happy with it. It scales well, as opposed to darcs. It is very similar to git. Mercurial is used for OpenSolaris if I recall correctly. -- Nicolas Chauvat logilab.fr - services en informatique avancée et gestion de connaissances ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation enhancement: "MS free compiler"?
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 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. We need to update things, I believe. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Misleading error message from PyObject_GenericSetAttr
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'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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Code coverage reporting.
Folks, I've just run a code coverage report for the python2.4 branch: http://vallista.idyll.org/~t/temp/python2.4-svn/ This report uses my figleaf code, http://darcs.idyll.org/~t/projects/figleaf-latest.tar.gz I'm interested in feedback on a few things -- * what more would you want to see in this report? * is there anything obviously wrong about the report? In other words... comments solicited ;). By the by, I'm also planning to integrate this into buildbot on some projects. I'll post the scripts when I get there, and I'd be happy to help Python itself set it up, of course. cheers, --titus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] About dynamic module loading
I saw in this list, or some of its relatives, an old discussion between David Abrams, the developer of boost.python, and the devteam of python about loading modules with RTLD_GLOBAL. Many useful comments and a lot of insight, but didn't find a solution to the question posed by David. I don't like to put a sys.dlopenflags something around my imports of c++ modules, nor to change 300 c++ files with template instantiations just to be able to export some functionality to python. All I need is to use RTLD_GLOBAL in a user transparent way for loading the extensions, so, if there already is a way of doing so, please tell me (have into account that I read the complete discussion thread of that time, if I miss the solution, let'me know). If not, here's a modified version of the dynload_shlib.c file in:http://dignor.sign.googlepages.com/dynloadpatchforpython2.4.1 that checks the existence of foo.so.global for module foo.so in the same dir and if so, loads it using RTLD_GLOBAL. An ugly hack, I know, but it works for me. Maybe there are other users with this problem and they can use this. Best Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Numerical robustness, IEEE etc.
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. 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. 1) Should I start off by developing a testing version, to give people a chance to scream at me, or write a PEP? Because I am no Python development expert, the former would help to educate me into its conventions, technical and political. 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), 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? 3) I am rather puzzled by the source control mechanism. Are commit privileges needed to start a project like this in the main tree? Note that I am thinking of starting a test subtree only. 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? 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. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Source control tools
On Thu, Jun 15, 2006 at 10:33:49PM +0200, Alexander Schremmer wrote: > On Thu, 15 Jun 2006 19:00:09 +0200, Jan Claeys wrote: > > > Op di, 13-06-2006 te 10:27 +0200, schreef Alexander Schremmer: > >> Bazaar-NG seems to reach limits already when working on > >> it's own code/repository. > > > > Canonical uses bzr to develop launchpad.net, which is a "little bit" > > larger dan bzr itself, I suspect...? > > I don't think so, without having seen the Launchpad code. I assume that > Launchpad has less comitters (closed source!) and therefore less change > sets and less parallel branches. Actually, Launchpad's got twice as many lines of source (as measured by sloccount), nearly 10 times as many versioned files, and about twice as many revisions as bzr. We typically have 10-20 parallel branches going through our review process at any one time (branches are generally reviewed before they land on the trunk), and probably many others being worked on at any given time. > Once I pulled the bzr changesets (1-3 months ago) and it needed 3 hours on > a 900 MHz machine with a high-speed (> 50 MBit) internet connection (and it > was CPU bound). Note that bzr has gained a lot of speed since then, though. That would have been when it was in "weave" format? The current "knit" format doesn't suffer the CPU problems in my experience. It's still very slow over a network because it does a very large number of round trips. There's work to greatly reduce that problem, by pipelining and by reducing the number of HTTP requests (by issuing one request with a range header with many ranges, rather than one request per range!). There are also plans to write a smart server. There's a big focus on performance improvements on the bzr list at the moment, and they seem to be making rapid progress. -Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FishEye on Python CVS Repository
Hi Martin, The FishEye'd Python Subversion repository is now available here: http://fisheye3.cenqua.com/browse/python A big sorry for the delay in actioning this, lost in the email pile :( Cheers, Pete. On 18/04/2006, at 5:16 AM, Martin v. Löwis wrote: > Peter Moore wrote: >> I'm responsible for setting up free FishEye hosting for community >> projects. As a long time python user I of course added Python up >> front. You can see it here: >> >> http://fisheye.cenqua.com/viewrep/python/ > > Can you please move that to the subversion repository > (http://svn.python.org/projects/python), or, failing that, > remove that entry? The CVS repository is no longer used. > > Regards, > Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Allow Empty Subscript List Without Parentheses
Talin <[EMAIL PROTECTED]> wrote: > > Ok, so in order to clear up the confusion here, I am going to take a > moment to try and explain Noam's proposal in clearer language. > > Now, as to the specifics of Noam's problem: Apparently what he is trying > to do is what many other people have done, which is to use Python as a > base for some other high-level language, building on top of Python > syntax and using the various operator overloads to define the semantics > of the language. No, that's too restrictive. Back in the 1970s, Genstat (a statistical language) and perhaps others introduced the concept of an array type with an indefinite number of dimensions. This is a requirement for implementing such things as continengy tables, analysis of variance etc., and was and is traditionally handled by some ghastly code. It always was easy to handle in LISP and, as far as this goes, Python is a descendent of LISP rather than of Algol, CPL or Fortran. Now, I thought of how conventional "3rd GL" languages (Algol 68, Fortran, C etc.) could be extended to support those - it is very simple, and is precisely what Noam is proposing. An index becomes a single-dimensional vector of integers, and all is hunky-dory. When you look at it, you realise that you DO want to allow zero-length index vectors, to avoid having to write separate code for the scalar case. So it is not just a matter of mapping another language, but that of meeting a specific requirement, that is largely language-independent. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] About dynamic module loading
On Thu, Jun 15, 2006, dsign wrote: > > If not, here's a modified version of the dynload_shlib.c file in: > > http://dignor.sign.googlepages.com/dynloadpatchforpython2.4.1 > > that checks the existence of foo.so.global for module foo.so in the > same dir and if so, loads it using RTLD_GLOBAL. An ugly hack, I know, > but it works for me. Maybe there are other users with this problem and > they can use this. Because of the upcoming beta for 2.5, you are not likely to get much attention right now. Please make a SourceForge patch so that we can track this later. -- 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 [email protected] 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
Thomas Lee <[EMAIL PROTECTED]> wrote: > I see. But restricting the switch to constants in the name of > performance may not make sense in a language like Python. Maybe this is > something for the PEP to discuss, but it seems such an implementation > would be confusing and sometimes it may not be possible to use a switch > case in place of if/elif/else statements at all. The PEP already discussed it. Offering arbitrary expressions whose meaning can vary at runtime would kill any potential speedup (the ultimate purpose for having a switch statement), leaving us with if/elif/else that, paradoxically, ran faster in general than the equivalent switch statement. [snip] > a) unnecessarily duplication of constant values for the purpose of using > them as case values The vast majority of use-cases in C/C++ uses single character or small integer constants. This hasn't slowed down the switch/case use in C/C++, and I haven't even seen an over-abundance of const or macro definitions of constants in C/C++ switch/case statements. > I do get the distinction, I'm just wondering if the usefulness of the > semantics > (or lack thereof) are going to negate any potential performance > enhancements: if a switch statement is never used because it's only > useful in a narrow set of circumstances, then maybe we're looking to > improve performance in the wrong place? Please re-read the PEP, more specifically the 'Problem' section: "A nice example of this is the state machine implemented in pickle.py which is used to serialize Python objects. Other prominent cases include XML SAX parsers and Internet protocol handlers." > Just thinking about it, maybe there could be two different code paths > for switch statements: one when all the case values are constants (the > 'fast' one) and one where one or more are expressions. This would mean a > slightly longer compile time for switch statements while ensuring that > runtime execution is the maximum possible without placing any major > restrictions on what can be used as a case value. The non-fast version couldn't actually work if it referenced any names, given current Python semantics for arbitrary name binding replacements. - Josiah ___ Python-Dev mailing list [email protected] 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.
[skipping answering the numeric-specific questions since I am no math expert =) ]On 6/15/06, Nick Maclaren <[EMAIL PROTECTED] > wrote: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. Yes, it's better, but I would like tomake 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.1) Should I start off by developing a testing version, to give peoplea chance to scream at me, or write a PEP? Because I am no Pythondevelopment expert, the former would help to educate me into its conventions, technical and political.I would do both. It is a lot easier to get something accepted when you have working code. But a PEP to vent possible arguments against the change along with any backwards-compatibility issues will be needed for something as major as changing how math works. 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),there might well need to be options. These can obviously be done bya command-line option, an environment variable or a float method. There are reasons to disfavour the last, but all are possible. Whichis the most Pythonesque approach?3) I am rather puzzled by the source control mechanism. Are commitprivileges needed to start a project like this in the main tree? Note that I am thinking of starting a test subtree only.To work directly in Python's repository, yes, checkin privileges are needed. In order to get these, though, you usually either need to have been involved in python-dev for a while and be known to the group or have someone everyone trusts to watch over you as you do your work in a branch. 4) Is there a Python hacking document? Specifically, if I want toadd a new method to a built-in type, is there any guide on where to start?The C API docs are at http://docs.python.org/ and there are some docs at http://www.python.org/dev/ in terms of intro to how development for Python tends to take place. -Brett5) 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. ___ Python-Dev mailing list [email protected] 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.
On 6/15/06, Titus Brown <[EMAIL PROTECTED]> wrote: Folks,I've just run a code coverage report for the python2.4 branch:http://vallista.idyll.org/~t/temp/python2.4-svn/This report uses my figleaf code, http://darcs.idyll.org/~t/projects/figleaf-latest.tar.gzVery nice, Titus! I'm interested in feedback on a few things -- * what more would you want to see in this report? * is there anything obviously wrong about the report?In other words... comments solicited ;). Making the comments in the code stand out less (i.e., not black) might be handy since my eye still gets drawn to the comments a lot.It would also be nice to be able to sort on different things, such as filename. 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. By the by, I'm also planning to integrate this into buildbot on someprojects. I'll post the scripts when I get there, and I'd be happy to help Python itself set it up, of course.I don't know if we need it hooked into the buildbots (unless it is dirt cheap to generate the report). But hooking it up to the script in Misc/build.sh that Neal has running to report reference leaks and fundamental test failures would be wonderful. -Brett ___ Python-Dev mailing list [email protected] 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.
You should be aware of PEP 754 and address it. http://www.python.org/dev/peps/pep-0754/ Also note that Python conforms to C89, not C99. Any solution should work on all Python platforms. Some of those platforms are here: http://www.python.org/dev/buildbot/all/ n -- On 6/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > [skipping answering the numeric-specific questions since I am no math expert > =) ] > > > On 6/15/06, Nick Maclaren <[EMAIL PROTECTED] > wrote: > > 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. 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. > > > > 1) Should I start off by developing a testing version, to give people > > a chance to scream at me, or write a PEP? Because I am no Python > > development expert, the former would help to educate me into its > > conventions, technical and political. > > > I would do both. It is a lot easier to get something accepted when you have > working code. But a PEP to vent possible arguments against the change along > with any backwards-compatibility issues will be needed for something as > major as changing how math works. > > > 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), > > 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? > > > > 3) I am rather puzzled by the source control mechanism. Are commit > > privileges needed to start a project like this in the main tree? > > Note that I am thinking of starting a test subtree only. > > > To work directly in Python's repository, yes, checkin privileges are needed. > In order to get these, though, you usually either need to have been > involved in python-dev for a while and be known to the group or have someone > everyone trusts to watch over you as you do your work in a branch. > > > 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? > > > The C API docs are at http://docs.python.org/ and there are some docs at > http://www.python.org/dev/ in terms of intro to how development for Python > tends to take place. > > -Brett > > > > 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. > > > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com > > > ___ Python-Dev mailing list [email protected] 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)
On 6/12/06, Greg Ward <[EMAIL PROTECTED]> wrote: > [Guido] > > 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. > > [Martin] > > 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 very much identify with Phillip's gripe, but I gotta admit Guido has > the compelling argument here. Personally, I have noticed very few > "rogue" changes to optparse.py over the years, and have quietly grumbled > and backported most of them over to Optik for eventual re-merge to > optparse. (One or two got dropped because I had already fixed the > problem differently in Optik.) Also note it sucks for users. For example, I recently closed an optparse bug without even looking at it, since it has to go into the optik tracker afaik (I think it was a doc issue). Did the person bother to go through the effort to submit the bug a second time? I don't know, but we know many people don't submit bugs the first time. The process adds work to users too. n ___ Python-Dev mailing list [email protected] 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
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. 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 338 vs PEP 328 - a limitation of the -m switch
Guido van Rossum wrote: >> If it's not the package directory, perhaps it could be a copy of whatever >> sys.path entry the package was found under - that wouldn't do anything but >> make "nearby" imports faster. > > But it could theoretically affect search order for other modules. I > still see nothing wrong with "". After all that's also the default if > you run a script using python http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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 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. There's something odd going on with __future__.py, though. The module level code all shows up as not executed, but the bodies of the two _Feature methods both show up as being run. I'm curious as to how a function body can be executed without executing the function definition first :) As far as making the comments/docstrings less obvious goes, grey is usually a good option for that. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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.
Nick Maclaren wrote: > 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. Python 2.4's decimal module is, in essence, a floating point emulator based on the General Decimal Arithmetic specification. If you want floating point mathematics that doesn't have insane platform dependent behaviour, the decimal module is the recommended approach. By the time Python 2.6 rolls around, we will hopefully have an optimized version implemented in C (that's being worked on already). That said, I'm not clear on exactly what changes you'd like to make to the binary floating point type, so I don't know if I think they're a good idea or not :) Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] When to branch release25-maint?
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... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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.
"Nick Maclaren" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > experience from times of yore is that emulated floating-point would > be fast enough that few, if any, Python users would notice. Perhaps you should enquire on the Python numerical and scientific computing lists to see how many feel differently. I don't see how someone crunching numbers hours per day could not notice a slowdown. tjr ___ Python-Dev mailing list [email protected] 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?
On 6/18/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: A question has been asked about branching release25-maint at the timeof beta1. I was actually thinking about doing this for 2.5rc1 - oncewe're in release candidate stage we want to really be careful aboutcheckins. 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.6work landing on the trunk nownownow. Also, I'd prefer people's cyclesbe spent on bughunting 2.5 rather than worrying about shiny newfeatures for the release that's, what, 18 months away? Anyway, thought I'd open this up for discussion...Sounds reasonable to me. Betas could still have more semantic changes for bug fixes than a release candidate might allow and thus make the branch too early a step at b1. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] setobject code
On 6/16/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > I would like to share a couple of observations that I made as I > studied the latest setobject implementation. ... > 2. Type of several data members in dict-object and dict-entry structs > were recently changed to Py_ssize_t . Whatever considerations > prompted the change, they should probably apply to the similar > members of set-object and set-entry structs as well. Thanks for pointing that out. Fixed in 47018. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] current 2.5 issues
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 -- : 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 -- : 'test.threaded_import_hangers' ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
