Re: [Python-Dev] PyObject_CallFunction and 'N' format char
On 6/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Gustavo Carneiro wrote: > > However, PyObject_CallFunction does _not_ > > consume such an object reference, contrary to what I believed for > > years. > > Why do you say that? It certainly does. Yes it does. I could almost swear it didn't last night when I was debugging this, but today it works as expected. I guess I was just sleepy... :P Sorry. ___ 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] pypy-0.9.0: stackless, new extension compiler
The PyPy development team has been busy working and we've now packaged our latest improvements, completed work and new experiments as version 0.9.0, our fourth public release. The highlights of this fourth release of PyPy are: **implementation of "stackless" features** We now support the larger part of the interface of the original Stackless Python -- see http://www.stackless.com for more. A significant part of this is the pickling and unpickling of a running tasklet. These features, especially the pickling, can be considered to be a "technology preview" -- they work, but for example the error handling is a little patchy in places. **ext-compiler** The "extension compiler" is a new way of writing a C extension for CPython and PyPy at the same time. For more information, see its documentation: http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html **rctypes** Most useful in combination with the ext-compiler is the fact that our translation framework can translate code that uses the standard-in-Python-2.5 ctypes module. See its documentation for more: http://codespeak.net/pypy/dist/pypy/doc/rctypes.html **framework GCs** PyPy's interpreter can now be compiled to use a garbage collector written in RPython. This added control over PyPy's execution makes the implementation of new and interesting features possible, apart from being a significant achievement in its own right. **__del__/weakref/__subclasses__** The PyPy interpreter's compatibility with CPython continues improves: now we support __del__ methods, the __subclasses__ method on types and weak references. We now pass around 95% of CPython's core tests. **logic space preview** This release contains the first version of the logic object space, which will add logical variables to Python. See its docs for more: http://codespeak.net/pypy/dist/pypy/doc/howto-logicobjspace-0.9.html **high level backends preview** This release contains the first versions of new backends targeting high level languages such as Squeak and .NET/CLI and updated versions of the JavaScript and Common Lisp backends. They can't compile the PyPy interpreter yet, but they're getting there... **bugfixes, better performance** As you would expect, performance continues to improve and bugs continue to be fixed. The performance of the translated PyPy interpreter is 2.5-3x times faster than 0.8 (on richards and pystone), and is now stable enough to be able to run CPython's test suite to the end. **testing refinements** py.test, our testing tool, now has preliminary support for doctests. We now run all our tests every night, and you can see the summary at: http://snake.cs.uni-duesseldorf.de/pypytest/summary.html What is PyPy (about)? PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, memory and threading models are to become aspects of the translation process - as opposed to encoding low level details into the language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. PyPy is partially funded as a research project under the European Union's IST programme. Where to start? - Getting started:http://codespeak.net/pypy/dist/pypy/doc/getting-started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.9 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals - The Just-in-Time compiler and other performance improvements will be one of the main topics of the next few months' work, along with finishing the logic object space. Project Details --- PyPy has been developed during approximately 20 coding sprints across Europe and the US. It continues to be a very dynamically and incrementally evolving project with many of these one-week workshops to follow. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback
Re: [Python-Dev] Simple Switch statement
Sorry, no go. You can say "supports key use cases found in real code"
as often as you like, but limiting it only to literals drops many use
cases on the floor, and is unacceptable for me. There are no other
places in Python where only literals are allowed. In your eagerness to
rule out surprises, you're creating the biggest surprise of all: the
restriction to literals is certainly a surprise!
If you want to provide a solution for the constantification issue,
let's discuss that first and then come back here.
--Guido
On 6/24/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From what I can see, almost everyone wants a switch statement, though perhaps
> for different reasons.
>
> The main points of contention are 1) a non-ambiguous syntax for assigning
> multiple cases to a single block of code, 2) how to compile variables as
> constants in a case statement, and 3) handling overlapping cases.
>
> Here's a simple approach that will provide most of the benefit without trying
> to
> overdo it:
>
> switch f(x): # any expression is allowable here but raises an
> exception if the result is not hashable
> case 1: g() # matches when f(x)==1
> case 2,3 : h()# matches when f(x) in (2,3)
> case 1: i() # won't ever match because the first case 1 wins
> case (4,5), 6: j()# matches when f(x) in ((4,5), 6)
> case "bingo": k() # matches when f(x) in ("bingo",)
> default: l()# matches if nothing else does
>
> Though implemented as a hash table, this would execute as if written:
>
> fx = f(x)
> hash(fx)
> if fx in (1,):
> g()
> elif fx in (2,3):
> h()
> elif fx in (1,):
> i()
> elif fx in ((4,5), 6):
> j()
> elif fx in ("bingo",):
> k()
> else:
> l()
[...]
--
--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
On 6/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > [...] a syntactic nit that Eric Sumner pointed out. Since > it involves iteration over x to populate the jump table rather than doing a > containment test on x, using 'case in x' is misleading. It would be better > written as 'case *x'. > > Then: >'case 1:' ==> a switch value of 1 will jump to this case >'case 1, 2:' ==> a switch value of 1 or 2 will jump to this case >'case *x' ==> any switch value in x will jump to this case >'case *x, *y' ==> any switch value in x or y will jump to this case I'm +0 on this idea, or something similar (maybe my original 'case in' syntax with 'in' replaced by '*'. I'm going to have to sleep on Nick's 'once' proposal (which deserves a separate thread). -- --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] [Python-checkins] Things to remember when adding *packages* to stdlib
Neal Norwitz wrote: > I believe this change is all that's necessary on the Unix side to > install wsgiref. Can someone please update the Windows build files to > ensure wsgiref is installed in b2? Don't forget to update the NEWS > entry too. It's installed in b1 already. The msi generator picks up all .py files in Lib automatically, except for those that have been explicitly excluded (the plat-* ones). > Maybe someone could come up with a heuristic to add to Misc/build.sh > which we could test in there. I think "make install INSTALL=true|grep true" should print the names of all .py files in Lib, except for the ones in plat-*. 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] basearray
Dear all, Some of you might be aware that a project has been granted to me for this year's Google's Summer of Code, which aims at preparing a base multidimensional array type for Python. While I had a late start at it, I would like to go through with the project. The focus is on preparing a minimal type, that basically only defines how memory is alllocated for the array, and which can be used by other, more sophisticated types. Later during the project, the type may be enhanced, depending on how using it in practice (also part of the project) works out. Wiki page about the project: http://scipy.org/BaseArray SVN repository: http://svn.scipy.org/svn/PEP/ In order to make this a potential success, I definately need feedback from all you out there interested in pushing such a base type towards Python core. So any comments and opinions are welcome! I will keep you informed on my progress and ask about things that may need concensus (although I'm not sure which lists will be the most interested in this). Please note that I am still in the phase of completing the minimal type, so the svn repository does not contain a working example, yet. Regards, Karol Langner -- written by Karol Langner nie cze 25 19:18:45 CEST 2006 ___ 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] Simple Switch statement
> Sorry, no go. You can say "supports key use cases found in real code" > as often as you like, Those were not empty words. I provided two non-trivial worked-out examples taken from sre_constants.py and opcode.py. Nick provided a third example from decimal.py. In all three cases, the proposal was applied effortlessly resulting in improved readability and speed. I hope you hold other proposals to the same standard. > If you want to provide a solution for the constantification issue, > let's discuss that first and then come back here. No thanks. That is its own can of worms. The obvious solutions (like const declarations, macros, or a syntax to force compile-time expression evaluation) are unlikely to sit well because they run afoul Python's deeply ingrained dynamism. The switch-case construct in C uses constant cases but depends on macros to make the constants symbolic. Is that where we want to go with Python? If so, that is most likely a Py3k discussion. In contrast, the proposed simple switch statement is something we could have right away. I will likely write-up a PEP and get a sample implementation so we can discuss something concrete at EuroPython. 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] Alternatives to switch?
Talin wrote: > In fact, I'd like to point out something that hasn't been brought up, > which is that in many cases having a closure rebind the switch cases > defeats the purpose of the thing. For example: > > def outer(): >def inner(x): > switch(x): > case 1: ... > case 2: ... > case 3: ... > >return inner > > If the switch cases are bound at the time that 'inner' is defined, it > means that the hash table will be rebuilt each time 'outer' is called. not if all cases are literals, as in your example. and how common is this, really? are you sure you're not arguing against a construct that is more efficient in many existing use cases, based on a single, mostly hypothetical use case ? (after all, if you don't want Python to waste time optimizing things for you, you don't have to use a construct that does that...) ___ 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 wrote:
>> I don't see this as much of a problem, really: we can simply restrict
>> the optimization to well-known data types ("homogenous" switches using
>> integers or strings should cover 99.9% of all practical cases), and then
>> add an opcode that checks uses a separate dispatch object to check if
>> fast dispatch is possible, and place that before an ordinary if/elif
>> sequence.
>
> What about switches on types? Things like XML-RPC and JSON want to be able
> to have a fast switch on an object's type and fall back to slower tests
> only for non-common cases.
good point (and nice example).
> for t in obtype.__mro__:
> switch t:
> case int: ...; break
> case str: ...; break
> else:
> continue
> else:
> # not a recognized type
but I wonder how confusing the "break inside switch terminates the outer
loop" pattern would be to a C programmer...
___
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] Simple Switch statement
At 11:13 AM 6/25/2006 -0700, Raymond Hettinger wrote: >No thanks. That is its own can of worms. The obvious solutions (like const >declarations, macros, or a syntax to force compile-time expression >evaluation) >are unlikely to sit well because they run afoul Python's deeply ingrained >dynamism. I think perhaps you haven't been paying close attention to Fredrik's proposal. The "static" operator simply lifts expression evaluation to function definition time, so that this: def x(y): print y * static(123+456) becomes equivalent to this: foo = 123+456 def x(y): print y * foo This simple transformation doesn't "run afoul" of anything that I'm aware of, any more than the "with:" statement does. Meanwhile, you seem to be arguing that forcing the use of literals at compilation time is somehow more dynamic than allowing them to be computed at runtime! I don't get it. Are you perhaps thinking that it's necessary to know the values at compilation time in order to compile the switch statement? If so, note that the dictionary entries can be loaded by the code where the function is defined, and accessed as a free variable within the function body. This is the same way that other "static" expressions would be implemented. (On an unrelated note, I think that maybe rather than making "static" look like a function call, we should use a form that looks more like a generator expression, conditional, or yield expression, i.e. (static 123+456) instead of static(123+456), as this emphasizes its nature as an element of language syntax rather than making it look like a function call.) ___ 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] doc for new restricted execution design for Python
On 6/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: Brett Cannon wrote:> Yep. That API will be used directly in the changes to pymalloc and> PyMem_*() macros (or at least the basic idea). It is not *only* for> extension modules but for the core as well. >> Existing extension modules and existing C code in the Python interpreter> have no idea of any PyXXX_ calls, so I don't understand how new API> functions help here.>> > The calls get added to pymalloc and PyMem_*() under the hood, so that> existing extension modules use the memory check automatically without a> change. The calls are just there in case some one has some random need > to do their own malloc but still want to participate in the cap. Plus> it helped me think everything through by giving everything I would need> to change internally an API.This confused me a bit, too. It might help if you annotated each of the new API's with who the expected callers were: - trusted interpreter - untrusted interpreter - embedding application - extension moduleThere are only two "different" possible callers for the whole API: a trusted interpreter or embedded application that launches an untrusted interpreter, and then there is *everyone* (this removes the distinction of trusted and untrusted interpreter and just views them as an interpreter). The former use the setting API to set the limits of the untrusted interpreter being created, while everyone else uses the API to make sure an untrusted interpreter does not overstep its bounds. The checks are done regardless of the type of interpreter, it just varies on whether the checks are NOOPs or not. Since the memory cap seems to be causing the confusion, let me try it again. You are in a trusted interpreter or embedded app and you want an untrusted interpreter with a memory cap. You create the interpreter and call the PyXXX_SetMemoryCap() function on the untrusted interpreter to set that cap. Now, within the core interpreter code (untrusted or not) for where the interpreter allocates and deallocates memory there are calls to PyXXX_MemoryAllow() and PyXXX_MemoryFree(). If this is the trusted interpreter running, they are basically NOOPs. If it is an untrusted interpreter, then the actual checks are done to make sure the restriction is not broken. And if an extension module has some reason to use the memory cap checks as well, it can. Same with an embedded application.There is no grand distinction in terms of "this is for use in the core only while these are only for extension modules". It is just whether a function is used to set a restriction before an untrusted interpreter is used, or to check to make sure that a restriction is not violated. -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] doc for new restricted execution design for Python
On 6/24/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:> Brett Cannon wrote:>> Yep. That API will be used directly in the changes to pymalloc and>> PyMem_*() macros (or at least the basic idea). It is not *only* for >> extension modules but for the core as well. Existing extension modules and existing C code in the Python>> interpreter>> have no idea of any PyXXX_ calls, so I don't understand how >> new API>> functions help here.>> The calls get added to pymalloc and PyMem_*() under the hood, so that>> existing extension modules use the memory check automatically >> without a>> change. The calls are just there in case some one has some random>> need>> to do their own malloc but still want to participate in the cap.>> Plus>> it helped me think everything through by giving everything I would >> need>> to change internally an API.>> This confused me a bit, too. It might help if you annotated each of> the new> API's with who the expected callers were:>>- trusted interpreter >- untrusted interpreter>- embedding application>- extension moduleThreading is definitely going to be an issue with multipleinterpreters (restricted or otherwise)... for example, the PyGILState API probably wouldn't work anymore.PyGILState won't work because there are multiple interpreters period, or because of the introduced distinction of untrusted and trusted interpreters? In other words, is this some new possible breakage, or is this an issue with threads that has always existed with multiple interpreters? -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] Import semantics
Sorry for the untrimmed conversation, but I've cc'ed jython-dev, my comments are at the bottom. On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 6/12/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote: > > Fabio Zadrozny wrote: > > > Python and Jython import semantics differ on how sub-packages should be > > > accessed after importing some module: > > > > > > Jython 2.1 on java1.5.0 (JIT: null) > > > Type "copyright", "credits" or "license" for more information. > > > >>> import xml > > > >>> xml.dom > > > > > > > > > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on > > > win32 > > > Type "help", "copyright", "credits" or "license" for more information. > > > >>> import xml > > > >>> xml.dom > > > Traceback (most recent call last): > > > File "", line 1, in ? > > > AttributeError: 'module' object has no attribute 'dom' > > > >>> from xml.dom import pulldom > > > >>> xml.dom > > > > > > > > > Note that in Jython importing a module makes all subpackages beneath it > > > available, whereas in python, only the tokens available in __init__.py > > > are accessible, but if you do load the module later even if not getting > > > it directly into the namespace, it gets accessible too -- this seems > > > more like something unexpected to me -- I would expect it to be > > > available only if I did some "import xml.dom" at some point. > > > > > > My problem is that in Pydev, in static analysis, I would only get the > > > tokens available for actually imported modules, but that's not true for > > > Jython, and I'm not sure if the current behaviour in Python was expected. > > > > > > So... which would be the right semantics for this? > > > > the difference in Jython is deliberate. I think the reason was to mimic > > more the Java style for this, in java fully qualified names always work. > > In jython importing the top level packages is enough to get a similar > > effect. > > > > This is unlikely to change for backward compatibility reasons, at least > > from my POV. > > IMO it should do this only if the imported module is really a Java > package. If it's a Python package it should stick to python semantics > if possible. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) This is a tough one since the BDFL and Samuele disagree here. Perhaps we should document the Java import behavior as permanent, but document the Python imports in Jython as being deprecated but available until some future release? I believe we would keep it at least through Jython 2.3. -Frank ___ 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] Simple Switch statement
>>No thanks. That is its own can of worms. The obvious solutions (like const >>declarations, macros, or a syntax to force compile-time expression >>evaluation) >>are unlikely to sit well because they run afoul Python's deeply ingrained >>dynamism. >> >> > >I think perhaps you haven't been paying close attention to Fredrik's >proposal. > Yes, I have been. That is one of the three options I listed above. Each has its own issues. The static() keyword works like Forth's brackets for forcing compile-time evaluation. The issue for us is that unlike other Python expressions, there are inconvenient limitiations on what can be expressed inside: five = 5 eight = [8] def f(x, six=6): seven = 7 a = static(five + 4)# this is legal b = static(six + 4) # this is illegal c = static(seven + 4) # this is illegal d = static(eight + [4]) # this is illegal That will be a perpetual maintenance trap and conundrum for newbies. Besides, the issue of constantification is orthogonal to the discussion at hand. If compile-time expression evaluation ever gets approved, it is no problem to extend my switch statement proposal to accomodate it. IOW, my simplified version does not preclude future buildouts for your constantification magic. > The "static" operator simply lifts expression evaluation to >function definition time, so that this: > > def x(y): > print y * static(123+456) > >becomes equivalent to this: > > foo = 123+456 > def x(y): > print y * foo > > FWIW, this is a crummy example. Py2.5 already makes a better version of this transformation. > >> def f(y): print y * (123+456) > >> from dis import dis > >> dis(f) 2 0 LOAD_FAST0 (y) 3 LOAD_CONST 3 (579) 6 BINARY_MULTIPLY 7 PRINT_ITEM 8 PRINT_NEWLINE 9 LOAD_CONST 0 (None) 12 RETURN_VALUE >Meanwhile, you seem to be arguing that forcing the use of literals at >compilation time is somehow more dynamic than allowing them to be computed >at runtime! I don't get it. > You may be reading to much into it. The essential idea that is that limiting case values to constants is a simplifying assumption that makes it easy to explain and easy to compile. I wasn't truly happy with it until I started trying it on real code examples and found that it fit effortlessly and that the code was much improved. Also, there was some appeal in knowing that if some constantification proposal gets accepted, then those would become allowable values also. 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] Numerical robustness, IEEE etc.
[EMAIL PROTECTED] wrote:
>
> I'm not asking you to describe SC22WG14 or post detailed technical summaries
> of the long and painful road. I'd like you to post things directly relevant
> to Python with footnotes to necessary references. It is then incumbent on
> those that wish to respond to your post to familiarize themselves with the
> relevant background material. However, it is really darn hard to do that
> when we don't know what you're trying to fix in Python. The examples you
> show below are a good start in that direction.
Er, no. Given your response, it has merely started off a hare. The
issues you raise are merely ones of DETAIL, and I was and am trying
to tackle the PRINCIPLE (a.k.a. design).
I originally stated my objective, and asked for information so that I
could investigate in depth and produce (in some order) a sandbox and
a PEP. That is still my plan.
This example was NOT of problems with the existing implementation,
but was to show how even the most basic numeric code that attempts to
handle errors cannot avoid tripping over the issues. I shall respond
to your points, but shall try to refrain from following up.
> 1) The string representation of NaN is not standardized across platforms
Try what I actually used:
x = 1.0e300
x = (x*x)/(x*x)
I converted that to float('NaN') to avoid confusing people. There
are actually many issues around the representation of NaNs, including
whether signalling NaNs should be separated from quiet NaNs and whether
they should be allowed to have values. See IEEE 754, IEEE 754R and
C99 for more details (but not clarification).
> 2) on a sane platform, int(float('NaN')) should raise an ValueError
> exception for the int() portion.
Well, I agree with you, but Java and many of the C99 people don't.
> 3) float('NaN') == float('NaN') should be false, assuming NaN is not a
> signaling NaN, by default
Why? Why should it not raise ValueError? See table 4 in IEEE 754.
I could go into this one in much more depth, but let's not, at least
not now.
> So the open question is how to both define the semantics of Python floating
> point operations and to implement them in a way that verifiably works on the
> vast majority of platforms without turning the code into a maze of
> platform-specific defines, kludges, or maintenance problems waiting to
> happen.
Well, in a sense, but the second is really a non-question - i.e. it
answers itself almost trivially once the first is settled. ALL of your
above points fall into that category. The first question to answer is
what the fundamental model should be, and I need to investigate in
more depth before commenting on that - which should tell you roughly
what I know and what I don't about the decimal model.
The best way to get a really ghastly specification is to decide on
the details before agreeing on the intent. Committees being what they
are, that is a recipe for something that nobody else will ever get
their heads around.
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
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] Simple Switch statement
On Sat, 24 Jun 2006, Raymond Hettinger wrote: > The main points of contention are 1) a non-ambiguous syntax for assigning > multiple cases to a single block of code, 2) how to compile variables as > constants in a case statement, and 3) handling overlapping cases. > > Here's a simple approach that will provide most of the benefit without > trying to overdo it: [...] > The result of f(x) should be hashable or an exception is raised. > Cases values must be ints, strings, or tuples of ints or strings. > No expressions are allowed in cases. I like this proposal. It eliminates all of the surprises that have been hiding in the other switch proposals so far, except for throwing an exception when the switch expression isn't hashable. But i can easily live with that restriction, since the cases are all literals that must be hashable, so if the switch expression comes out to some other type then it probably really is an error that should be caught. I agree with the general feeling that it would be nice to have a bit more flexibility, but so far i haven't thought of any way to get more flexibility without more surprises, so until a better idea comes along i'm happy with this one. -- ?!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] doc for new restricted execution design for Python
On Jun 25, 2006, at 1:08 PM, Brett Cannon wrote:On 6/24/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:> Brett Cannon wrote:>> Yep. That API will be used directly in the changes to pymalloc and>> PyMem_*() macros (or at least the basic idea). It is not *only* for >> extension modules but for the core as well. Existing extension modules and existing C code in the Python>> interpreter>> have no idea of any PyXXX_ calls, so I don't understand how >> new API>> functions help here.>> The calls get added to pymalloc and PyMem_*() under the hood, so that>> existing extension modules use the memory check automatically >> without a>> change. The calls are just there in case some one has some random>> need>> to do their own malloc but still want to participate in the cap.>> Plus>> it helped me think everything through by giving everything I would >> need>> to change internally an API.>> This confused me a bit, too. It might help if you annotated each of> the new> API's with who the expected callers were:>>- trusted interpreter >- untrusted interpreter>- embedding application>- extension moduleThreading is definitely going to be an issue with multipleinterpreters (restricted or otherwise)... for example, the PyGILState API probably wouldn't work anymore.PyGILState won't work because there are multiple interpreters period, or because of the introduced distinction of untrusted and trusted interpreters? In other words, is this some new possible breakage, or is this an issue with threads that has always existed with multiple interpreters? It's an issue that's always existed with multiple interpreters, but multiple interpreters aren't really commonly used or tested at the moment so it's not very surprising.It would be kinda nice to have an interpreter-per-thread with no GIL like some of the other languages have, but the C API depends on too much global state for that...-bob___ 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] Simple Switch statement
On Sat, 24 Jun 2006, Phillip J. Eby wrote: > At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote: > >Cases values must be ints, strings, or tuples of ints or strings. > > -1. There is no reason to restrict the types in this fashion. Even if you > were trying to ensure marshallability, you could still include unicode and > longs. When he said "ints" i assumed that included longs. The distinction is so nearly gone by now (from the Python programmer's point of view). I don't see any particular problem with allowing all basestrings rather than just 8-bit strings. -- ?!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] Simple Switch statement
Raymond Hettinger wrote: >>>No thanks. That is its own can of worms. The obvious solutions (like const >>>declarations, macros, or a syntax to force compile-time expression >>>evaluation) >>>are unlikely to sit well because they run afoul Python's deeply ingrained >>>dynamism. >>> >>> >> >>I think perhaps you haven't been paying close attention to Fredrik's >>proposal. >> > Yes, I have been. That is one of the three options I listed above. > Each has its own issues. > > The static() keyword works like Forth's brackets for forcing > compile-time evaluation. The issue for us is that unlike other Python > expressions, there are inconvenient limitiations on what can be > expressed inside: > >five = 5 >eight = [8] >def f(x, six=6): > seven = 7 > a = static(five + 4)# this is legal > b = static(six + 4) # this is illegal > c = static(seven + 4) # this is illegal > d = static(eight + [4]) # this is illegal Why would the last line be illegal? > > That will be a perpetual maintenance trap and conundrum for newbies. In contrary to other "newbie traps" such as mutable default arguments, if this would give a clear exception message like "function-local name cannot be used in static expression", I can't imagine it would be a bigger problem than e.g. "why is my floating point result incorrect". Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple Switch statement
On Sun, 25 Jun 2006, Guido van Rossum wrote: > In your eagerness to > rule out surprises, you're creating the biggest surprise of all: the > restriction to literals is certainly a surprise! I disagree. Perhaps what we mean by "surprise" is different. In Raymond's design, there is a simple rule for what's allowed in a case. The whole statement can be described in very few words: Each case is a literal integer, string, or tuple of integers or strings. Execution jumps to the first case that matches the value of the switch expression (or to 'default' if no match). That's it. The simpler the rule, the less surprising it is. It would take a lot more words to explain the behaviour of something like Nick's 'once'-based proposal. Here's an attempt: Each case consists of an arbitrary expression, but the expression may not refer to any local variables or arguments of the immediately surrounding function definition. The value of each case is computed when the surrounding function definition is compiled. If any two cases have the same value, an exception is thrown at compile time. At runtime, execution jumps to the case whose previously fixed value matches the value of the switch expression (or to 'default' if no match). Not only is that longer to describe, it's also more difficult for a beginning programmer to understand, since it requires knowing when different parts of a program are compiled (and what happens if the same part is compiled more than once). -- ?!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
[Python-Dev] Temporary Constantification
It seems to me that the main reason to provide constantification (in a switch statement or anywhere else) is to be able to optimize execution by caching the result locally for later use. The problem comes from trying to determine exactly when and how a value gets calculated, as most values in Python are subject to change. If, however, there was a mechanism by which a cache could be invalidated when its value changes, the only remaining difference between cached and non-cached values becomes their execution speed and memory usage (and possibly impact on the execution speed of other code). Thus, I propose a 'cached' keyword much like the static and const proposed keywords. In general, a cached value can be used (rather than re-evaluating the expression) if: - The expression has no side effects, - The result of all operations is deterministic, and - None of the expression parameters have changed since the cached value was generated The first two can be determined at compile-time without too much difficulty (except possibly function calls, I'll get to those in a minute). The hard issue here is knowing when parameters have changed. These fall into two different categories: literals and name lookups. Immutable literals don't cause a problem, and mutable literals always have a side-effect of generating a new object. There are two ways to determine if name lookups have changed: 1) Cache all the parameters, and check them against the current values, or 2) Be notified whenever one of the parameters changes. The first option requires a bunch of name lookups whenever the cached value is considered, which is exactly the problem that caching is supposed to fix. To implement the second, each name in each namespace needs a list of caches that depend on the name, and all name binding operations need to check the list and mark all dependent caches invalid. This is a small performance penalty whenever any name is rebound, and a large penalty whenever a watched name is rebound. Function calls can safely be considered volatile, but this would invalidate many of the uses for caching. Instead, each function has an immutable property of being either volatile or deterministic. Each deterministic function call maintains its own cache which is invalidated if the name to which the associated function (or any of its parameters) is rebound. Thus, if a function is rebound to something volatile, it does not force continual re-evaluation of other sub-expressions. Functions should be assumed to be volatile unless specified otherwise (probably via a decorator). I'm not particularly familiar with the internals of Python, so I'm not able to actually assess the feasability or performance implications of this proposal, but I think it basically covers the problem. -- Eric Sumner ___ 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] Temporary Constantification
On Sun, Jun 25, 2006, Eric Sumner wrote: > > In general, a cached value can be used (rather than re-evaluating the > expression) if: > - The expression has no side effects, > - The result of all operations is deterministic, and > - None of the expression parameters have changed since the cached > value was generated > > The first two can be determined at compile-time without too much > difficulty (except possibly function calls, I'll get to those in a > minute). Except for properties. So you'd have to allow only bare names, no attributes. You'd also have to restrict values to immutable ones. -- 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] Temporary Constantification
On 6/25/06, Eric Sumner <[EMAIL PROTECTED]> wrote: > It seems to me that the main reason to provide constantification (in a > switch statement or anywhere else) is to be able to optimize execution > by caching the result locally for later use. The problem comes from > trying to determine exactly when and how a value gets calculated, as > most values in Python are subject to change. Actually, most values tend *not* to change -- it's just hard for the compiler to prove this to so that it can use that fact. For example, in practice, builtins don't change. Imported objects (modules, and things you import from modules like constants, functions and classes) don't change. Defined functions and classes don't change. Manifest constants don't change. (*In practice*, you should add in all cases.) > If, however, there was a mechanism by which a cache could be > invalidated when its value changes, the only remaining difference > between cached and non-cached values becomes their execution speed and > memory usage (and possibly impact on the execution speed of other > code). Thus, I propose a 'cached' keyword much like the static and > const proposed keywords. In all (or nearly all) the use cases that were considered so far, the problem is more that the programmer knows that a certain expression isn't going to change, but the compiler doesn't. The problem is more that we'd like to be told (preferably at compile time -- but runtime is better than not at all) if we assume that something is a constant where in fact it is subject to change. > In general, a cached value can be used (rather than re-evaluating the > expression) if: > - The expression has no side effects, > - The result of all operations is deterministic, and > - None of the expression parameters have changed since the cached > value was generated > > The first two can be determined at compile-time without too much > difficulty (except possibly function calls, I'll get to those in a > minute). The hard issue here is knowing when parameters have changed. > These fall into two different categories: literals and name lookups. > Immutable literals don't cause a problem, and mutable literals always > have a side-effect of generating a new object. There are two ways to > determine if name lookups have changed: > 1) Cache all the parameters, and check them against the current values, or > 2) Be notified whenever one of the parameters changes. > > The first option requires a bunch of name lookups whenever the cached > value is considered, which is exactly the problem that caching is > supposed to fix. To implement the second, each name in each namespace > needs a list of caches that depend on the name, and all name binding > operations need to check the list and mark all dependent caches > invalid. This is a small performance penalty whenever any name is > rebound, and a large penalty whenever a watched name is rebound. > > Function calls can safely be considered volatile, but this would > invalidate many of the uses for caching. Instead, each function has > an immutable property of being either volatile or deterministic. Each > deterministic function call maintains its own cache which is > invalidated if the name to which the associated function (or any of > its parameters) is rebound. Thus, if a function is rebound to > something volatile, it does not force continual re-evaluation of other > sub-expressions. Functions should be assumed to be volatile unless > specified otherwise (probably via a decorator). > > I'm not particularly familiar with the internals of Python, so I'm not > able to actually assess the feasability or performance implications of > this proposal, but I think it basically covers the problem. Unfortunately, a mechanism that would let you register a callback for when a particular variable or attribute used in a cached expression is used, is pretty hard to implement without affecting the performance of code that doesn't use it. I'm afraid this is not a very likely path towards a solution. -- --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
Guido van Rossum wrote: > I'm currently leaning > towards making static expressions outside a function illegal and limit > switches outside a function to compile-time-constant expressions. I'm not sure I like the idea of having things that are illegal outside a function, because it can be a nuisance for code refactoring. I'd be happy if case worked at the top level, but wasn't any faster than if-elses. That wouldn't be so bad -- top-level code is already slower due to global variable accesses. Also I don't care what happens if you change the case values of a top-level case. It's undefined behaviour anyway. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Simple Switch statement
On 6/25/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Sun, 25 Jun 2006, Guido van Rossum wrote: > > In your eagerness to > > rule out surprises, you're creating the biggest surprise of all: the > > restriction to literals is certainly a surprise! > > I disagree. Perhaps what we mean by "surprise" is different. Apparently. I would find it very surprising if a language as dynamic as Python didn't allow expressions for cases. User learning a language generalize from examples. They see that expressions can be used whenever constants can be used. When they find that one particular context doesn't allow an expression, they will surely be surprised. I'm utterly unconvinced by Raymond's arguments for his proposal. Disallowing names goes against half a century of programming wisdom. Here's an argument for allowing names (this argument has been used successfully for using names instead of string literals in many APIs): if there is a spelling error in the string literal, the case will silently be ignored, and who knows when the bug is detected. If there is a spelling error in a NAME, however, the error will be caught as soon as it is evaluated. > In Raymond's design, there is a simple rule for what's allowed in a case. > The whole statement can be described in very few words: > > Each case is a literal integer, string, or tuple of integers > or strings. Execution jumps to the first case that matches the > value of the switch expression (or to 'default' if no match). > > That's it. The simpler the rule, the less surprising it is. It would > take a lot more words to explain the behaviour of something like Nick's > 'once'-based proposal. Here's an attempt: > > Each case consists of an arbitrary expression, but the expression > may not refer to any local variables or arguments of the immediately > surrounding function definition. The value of each case is computed > when the surrounding function definition is compiled. If any two > cases have the same value, an exception is thrown at compile time. > At runtime, execution jumps to the case whose previously fixed value > matches the value of the switch expression (or to 'default' if no > match). > > Not only is that longer to describe, it's also more difficult for a > beginning programmer to understand, since it requires knowing when > different parts of a program are compiled (and what happens if the > same part is compiled more than once). But beginning programmers don't read descriptions like that. They generalize from examples. It's the experts who need to have the complete unambiguous rules so they can know where the boundaries of safe code are. Beginners tend not to get near the boundaries at all. The experts can handle the unvarhished truth. (Hey, they can handle metaclasses. :-) Here's how I envision beginners learning about the switch statement (after they're utterly familiar with if/elif). We show them a few examples, some involving literals, some involving manifest constants (either defined locally at the module level, or imported). We give them *one* simple rule: "the cases must be run-time constants" (an intentionally vague term). Then let them loose. I expect that the results will be total satisfaction. I expect that the same approach should work for users who are beginning Python programmers but who are experienced in other languages (say, Java). The most likely problem a newbie will run into if they forget about the "cases must be constants" rule is trying to use a locally computed value as a case expression. This will most likely involve a local variable, and the proposed switch semantics specifically disallow these. So it'll be a compile time error -- better than most rookie mistakes! Yes, it's possible that someone has a global variable that really varies between function invocations, and they might use it in a switch. This will fail (give the wrong answer) silently (without an immediate error). But I think it's pretty unlikely that someone will try this -- they must not have been paying attention in two different classes: first when it was explained that variable globals are usually a bad idea; second when it was explained that switch cases must be (run-time) constants. Note that the entire class of well-known problems (which surprise almost every ne Python programmer at least once) that are due to one-time evaluation of mutable initializers (both parameter defaults and class variables) is ruled out here, by the requirement that switch cases be hashable, which in practice means immutable. Now, I'm not convinced that we need a switch statement. There are lots of considerations, and I sympathize with those folks who argue that Python doesn't need it. But I'd rather have no switch statement than Raymond's castrated proposal. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail
Re: [Python-Dev] Switch statement
On 6/25/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I'm currently leaning > > towards making static expressions outside a function illegal and limit > > switches outside a function to compile-time-constant expressions. > > I'm not sure I like the idea of having things that > are illegal outside a function, because it can be a > nuisance for code refactoring. > > I'd be happy if case worked at the top level, but > wasn't any faster than if-elses. That wouldn't be > so bad -- top-level code is already slower due to > global variable accesses. > > Also I don't care what happens if you change the > case values of a top-level case. It's undefined > behaviour anyway. Fair enough. I wasn't leaning very strongly anyway. :-) -- --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] Simple Switch statementZ
On Mon, 26 Jun 2006, Georg Brandl wrote: > Raymond Hettinger wrote: > >five = 5 > >eight = [8] > >def f(x, six=6): > > seven = 7 > > a = static(five + 4)# this is legal > > b = static(six + 4) # this is illegal > > c = static(seven + 4) # this is illegal > > d = static(eight + [4]) # this is illegal > > Why would the last line be illegal? I believe Raymond is assuming it would be illegal because it's mutable. I don't think much has been said about whether static() should be allowed to yield a mutable value, but if we did allow that, it might open up an avenue to much confusion. (I join the chorus of voices that dislike the name 'static' for this feature.) Whether or not 'eight + [4]' is allowed in 'static', it certainly wouldn't be allowed after 'switch' or 'case' since it's unhashable. -- ?!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] Temporary Constantification
On 6/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Unfortunately, a mechanism that would let you register a callback for > when a particular variable or attribute used in a cached expression is > used, is pretty hard to implement without affecting the performance of > code that doesn't use it. I'm afraid this is not a very likely path > towards a solution. I could make a strong argument that it is actually impossible to implement without affecting the performance of other code; the only issue is whether or not the impact is acceptable. I may be wrong, but I think that this particular scheme minimizes the impact: - There is a bit more data to store in every namespace - There is no change to dereferencing names; no test is required, no callback is generated - Binding to a name that currently has no binding simply requires allocating the extra memory and clearing it. - Binding to a name that is bound and does have callbacks is slow, but those are supposed to be constant *in practice* anyway. - Binding to a name that is already bound, but has no callbacks requires a test on a single variable against a constant. Without knowing more about the internals of Python (such as how long a check of a single variable takes relative to binding a new value to a name), I can't properly evaluate how much of a problem this would be. -- Eric Sumner ___ 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] Simple Switch statementZ
On 6/25/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Mon, 26 Jun 2006, Georg Brandl wrote: > > Raymond Hettinger wrote: > > >five = 5 > > >eight = [8] > > >def f(x, six=6): > > > seven = 7 > > > a = static(five + 4)# this is legal > > > b = static(six + 4) # this is illegal > > > c = static(seven + 4) # this is illegal > > > d = static(eight + [4]) # this is illegal > > > > Why would the last line be illegal? > > I believe Raymond is assuming it would be illegal because it's mutable. > I don't think much has been said about whether static() should be > allowed to yield a mutable value, but if we did allow that, it might > open up an avenue to much confusion. (I join the chorus of voices that > dislike the name 'static' for this feature.) What do you think of Nick C's 'once'? > Whether or not 'eight + [4]' is allowed in 'static', it certainly > wouldn't be allowed after 'switch' or 'case' since it's unhashable. Right. But there are all sorts of objects that are compared by object identity (e.g. classes, modules, even functions) which may contain mutable components but are nevertheless "constant" for the purpose of switch or optimization. Let's not confuse this concept of constness with immutability. -- --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] Temporary Constantification
On 6/25/06, Eric Sumner <[EMAIL PROTECTED]> wrote: > On 6/25/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Unfortunately, a mechanism that would let you register a callback for > > when a particular variable or attribute used in a cached expression is > > used, is pretty hard to implement without affecting the performance of > > code that doesn't use it. I'm afraid this is not a very likely path > > towards a solution. > > I could make a strong argument that it is actually impossible to > implement without affecting the performance of other code; the only > issue is whether or not the impact is acceptable. I may be wrong, but > I think that this particular scheme minimizes the impact: > - There is a bit more data to store in every namespace > - There is no change to dereferencing names; no test is required, no > callback is generated > - Binding to a name that currently has no binding simply requires > allocating the extra memory and clearing it. > - Binding to a name that is bound and does have callbacks is slow, > but those are supposed to be constant *in practice* anyway. > - Binding to a name that is already bound, but has no callbacks > requires a test on a single variable against a constant. > > Without knowing more about the internals of Python (such as how long a > check of a single variable takes relative to binding a new value to a > name), I can't properly evaluate how much of a problem this would be. Your proposal would require a change to the dict type to set a callback to be called when a particular key is modified (not a generic callback when any key is modified). That seems pretty tricky to do with no impact, given how highly dicts are optimized. Also, allowing attribute references is a whole new can of worms, since attributes aren't necessarily implemented as standard namespaces implemented by dictionaries. Aahz already pointed this out. -- --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] Simple Switch statementZ
On Sun, 25 Jun 2006, Guido van Rossum wrote: > What do you think of Nick C's 'once'? It's a bit closer to the right meaning... but what about: def f(x): def g(y): return y + once x return g Does "once" mean not really once here, but "once for each new function object that's created for g"? > Right. But there are all sorts of objects that are compared by object > identity (e.g. classes, modules, even functions) which may contain > mutable components but are nevertheless "constant" for the purpose of > switch or optimization. Let's not confuse this concept of constness > with immutability. That's a good point. We need a concept like "stable for equality" separate from "constant", since "constant" and "immutable" will mislead those who are used to the meanings of these words in other languages. -- ?!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
[Python-Dev] 2.5b1 Windows install
Has anyone else tried doing an admin install with "compile .py files" checked? It's causing my install to blow up, but I'd prefer to assume it's some weird Windows config/bug unless other people also have it, in which case I'll file an SF report. -- 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] Simple Switch statement
At 01:37 PM 6/25/2006 -0700, Raymond Hettinger wrote: >>>No thanks. That is its own can of worms. The obvious solutions (like const >>>declarations, macros, or a syntax to force compile-time expression >>>evaluation) >>>are unlikely to sit well because they run afoul Python's deeply ingrained >>>dynamism. >>> >> >>I think perhaps you haven't been paying close attention to Fredrik's >>proposal. >Yes, I have been. That is one of the three options I listed above. >Each has its own issues. > >The static() keyword works like Forth's brackets for forcing compile-time >evaluation. No, it doesn't; this is why I suggested that you haven't been paying close attention. The evaluation is at function definition time, not compile time. >The issue for us is that unlike other Python expressions, there are >inconvenient limitiations on what can be expressed inside: > > five = 5 > eight = [8] > def f(x, six=6): > seven = 7 > a = static(five + 4)# this is legal > b = static(six + 4) # this is illegal > c = static(seven + 4) # this is illegal > d = static(eight + [4]) # this is illegal The last one is perfectly legal, and the middle two make no sense. ___ 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] ImportWarning flood
Martin v. Löwis wrote: > Actually, your application *was* pretty close to being broken a few > weeks ago, when Guido wanted to drop the requirement that a package > must contain an __init__ file. BTW, when that was being discussed, did anyone consider allowing a directory to be given a .py suffix as an alternative way to mark it as a package? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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] Simple Switch statementZ
On 6/25/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote: > On Sun, 25 Jun 2006, Guido van Rossum wrote: > > What do you think of Nick C's 'once'? > > It's a bit closer to the right meaning... but what about: > > def f(x): > def g(y): > return y + once x > return g > > Does "once" mean not really once here, but "once for each new function > object that's created for g"? He specifically wants the latter semantics because it solves the problem of binding the value of a loop control variable in an outer scope: def f(n): return [(lambda: once i) for i in range(n)] should return n functions returning the values 0 through n-1. Without the once it returns n identical functions all returning n-1; this is due to outer-scope references referencing variables, not values. (In Scheme this is solved by making the for loop create a new variable for each iteration, but that's not Pythonic.) > > Right. But there are all sorts of objects that are compared by object > > identity (e.g. classes, modules, even functions) which may contain > > mutable components but are nevertheless "constant" for the purpose of > > switch or optimization. Let's not confuse this concept of constness > > with immutability. > > That's a good point. We need a concept like "stable for equality" > separate from "constant", since "constant" and "immutable" will mislead > those who are used to the meanings of these words in other languages. Anyone familiar with const in C++ will have a good grasp of the infinite shades of gray it can express. :-) -- --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] ImportWarning flood
On 6/24/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > >Actually, your application *was* pretty close to being broken a few > >weeks ago, when Guido wanted to drop the requirement that a package > >must contain an __init__ file. In that case, "import math" would have > >imported the directory, and given you an empty package. > > But this change was *not* made, and afaict it is not going to be made. Correct. We'll stick with the warning. (At least until Py3k but most likely also in Py3k.) -- --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
On 6/23/06, Edward C. Jones <[EMAIL PROTECTED]> wrote: > Python is a beautiful simple language with a rich standard library. > Python has done fine without a switch statement up to now. Guido left it > out of the original language for some reason (my guess is simplicity). > Why is it needed now? What would be added next: do while or goto? The > urge to add syntax should be resisted unless there is a high payoff > (such as yield). > > There are much better ways for the developers to spend their time and > energy (refactoring os comes to mind). > > Please keep Python simple. > > -1 on the switch statement. I agree. IMHO switch is a useless statement which can cause many problems in any language. It misleads programmers to dispatch in the wrong way. If you have switch with < 5 cases, an if-elif chain fits just fine. If the switch is larger use a dictionary that maps values to functions. In C, many times a switch block starts small (40 lines) but grows as the number of values to dispatch on increases. Soon it becomes a 500 line monstrosity that is impossible to refactor because variables from the enclosing space is used frivolously. I don't get the speed argument either. Who cares that if-elif-chains are O(n) and switch O(1)? If n > 10 you are doing something wrong anyway. I don't think I have ever seen in any language a switch construct that, barring speed concerns, wouldn't be better written using any other dispatch mechanism than switch. -- mvh Björn ___ 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] ImportWarning flood
On Sunday 25 June 2006 20:48, Greg Ewing wrote: > BTW, when that was being discussed, did anyone consider > allowing a directory to be given a .py suffix as an > alternative way to mark it as a package? I'd certainly be a lot happier with that than with the current behavior. Silly little warnings about perfectly good data-only directories are just silly. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ImportWarning flood
On 6/25/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > On Sunday 25 June 2006 20:48, Greg Ewing wrote: > > BTW, when that was being discussed, did anyone consider > > allowing a directory to be given a .py suffix as an > > alternative way to mark it as a package? > :-) > I'd certainly be a lot happier with that than with the current behavior. > Silly little warnings about perfectly good data-only directories are just > silly. And silly whining about warnings for silly name conflicts are just as silly. :-) -- --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] ImportWarning flood
On Jun 24, 2006, at 1:29 PM, Ralf W. Grosse-Kunstleve wrote: > --- Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >> I think it is safe to say that Twisted is more widely used than >> anything >> Google has yet released. Twisted also has a reasonably plausible >> technical reason to dislike this change. Google has a bunch of >> engineers >> who, apparently, cannot remember to create an empty __init__.py >> file in >> some directories sometimes. > > Simply adding a note to the ImportError message would solve this > problem "just > in time": > import mypackage.foo > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named mypackage.foo > Note that subdirectories are searched for imports only if they > contain an > __init__.py file: http://www.python.org/doc/essays/packages.html > I also dislike the warning solution. Making the ImportError message more verbose seems like a much nicer solution. James ___ 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] Alternatives to switch?
Talin wrote: > def outer(): >def inner(x): > switch(x): > case 1: ... > case 2: ... > case 3: ... > >return inner > > If the switch cases are bound at the time that 'inner' is defined, it > means that the hash table will be rebuilt each time 'outer' is called. I was just thinking the same thing... > But the compiler has no idea which of these two cases is true. Actually I think it does, by looking at the scopes of names referred to in the case expressions. Suppose there were a rule that case expressions are evaluated as early as possible, and in the outermost possible scope that contains all the names that they reference. Then, in fred = 1 mary = 2 def f(): ... def g(): ... switch x: case fred: ... case mary: the case expressions would be evaluated at the module scope, somewhere between the binding of mary and the definition of f(). The distinction between module and function scopes could then go away. A case expression could reference a local if it wanted, at the cost of the case expression being evaulated for every call to the function. A case at the module level would just be an instance of that. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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] ImportWarning flood
--- Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 6/25/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > > On Sunday 25 June 2006 20:48, Greg Ewing wrote: > > > BTW, when that was being discussed, did anyone consider > > > allowing a directory to be given a .py suffix as an > > > alternative way to mark it as a package? > > :-) > > I'd certainly be a lot happier with that than with the current behavior. > > Silly little warnings about perfectly good data-only directories are just > > silly. > > And silly whining about warnings for silly name conflicts are just as silly. > :-) I cannot smile here. I anticipate real damage in terms of $$$. To see what lead me to the subject of this thread, please take a quick look here, which is the result of running (most) of our unit tests: http://cci.lbl.gov/~rwgk/tmp/py25b1_ImortWarning_flood I can work around it, sure. Everybody can work around it, of course. But consider that one hour of a professional person is at least $100 with benefits etc. included. (If that sounds high, I know people charging much more than that; also consider that the going rate for a car mechanic in the bay area is $90, as you probably know.) Now say you have 1000 groups of developers having to work around the warning (I bet you have more). There will be discussions, alternatives will be tried and discarded, etc. Say that eats about 10 man hours per group before the issue is settled, which again is a very conservative estimate I believe. That makes a total of $100 in damages, at least. Is that warning really worth a millon dollar? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] Simple Switch statement
Raymond Hettinger wrote: > The static() keyword works like Forth's brackets for forcing > compile-time evaluation. The issue for us is that unlike other Python > expressions, there are inconvenient limitiations on what can be > expressed inside: > >five = 5 >eight = [8] >def f(x, six=6): > seven = 7 > a = static(five + 4)# this is legal > b = static(six + 4) # this is illegal > c = static(seven + 4) # this is illegal > d = static(eight + [4]) # this is illegal bzzt. try again. ___ 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] Simple Switch statement
Guido van Rossum wrote: > Here's an argument for allowing names (this argument has been used > successfully for using names instead of string literals in many APIs): > if there is a spelling error in the string literal, the case will > silently be ignored, and who knows when the bug is detected. If there > is a spelling error in a NAME, however, the error will be caught as > soon as it is evaluated. which is the rationale for using names in SRE, of course. and adding a proper switch statement will make this approach a bit robust; if all cases are marked as static (or made static by default), all case expressions will be evaluated up front. ___ 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] 2.5b1 Windows install
Aahz wrote: > Has anyone else tried doing an admin install with "compile .py files" > checked? It's causing my install to blow up, but I'd prefer to assume > it's some weird Windows config/bug unless other people also have it, in > which case I'll file an SF report. It works fine for me. One way for it to fail is if you uncompilable modules in the target directory. Currently, it invokes [TARGETDIR]python.exe -Wi [TARGETDIR]Lib\compileall.py -f -x bad_coding|badsyntax|site-packages [TARGETDIR]Lib where TARGETDIR is, well, the target directory of the installation. You could try to run this after you installed Python without pyc compilation, to see whether it succeeds. 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] ImportWarning flood
Ralf W. Grosse-Kunstleve wrote: > I can work around it, sure. Everybody can work around it, of course. But > consider that one hour of a professional person is at least $100 with benefits > etc. included. (If that sounds high, I know people charging much more than > that; also consider that the going rate for a car mechanic in the bay area is > $90, as you probably know.) Now say you have 1000 groups of developers having > to work around the warning (I bet you have more). There will be discussions, > alternatives will be tried and discarded, etc. Say that eats about 10 man > hours > per group before the issue is settled, which again is a very conservative > estimate I believe. That makes a total of $100 in damages, at least. Is > that warning really worth a millon dollar? So spend some of the money to come up with an alternate solution for 2.5b2. With a potential damage of a million dollars, it shouldn't be too difficult to provide a patch by tomorrow, right? This is open source, folks. Business arguments don't matter much to many of us. I don't get any money for my contributions to Python, and I'm not whining about all the lost consultant fees I could have collected while contributing to Python instead. What matters are actual contributions: bug reports, patches, PEPs, etc. In the specific case, make sure that your alternative solution not only makes you happy, but also solves the original problem as good or better than the current solution (read some email archives to find out what the original problem was). 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
