Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs
On Thu, Oct 4, 2018 at 10:58 AM Steven D'Aprano wrote:
> While keyword arguments have to be identifiers, using **kwargs allows
> arbitrary strings which aren't identifiers:
>
> py> def spam(**kwargs):
> ... print(kwargs)
> ...
> py> spam(**{"something arbitrary": 1, '\n': 2})
> {'something arbitrary': 1, '\n': 2}
>
>
> There is some discussion on Python-Ideas on whether or not that
> behaviour ought to be considered a language feature, an accident of
> implementation, or a bug.
>
>
I would expect this to be costly/annoying for implementations to enforce,
doing it at call time is probably too late to be efficient, it would need
help from dicts themselves or even strings.
A hack that currently works because of this is with dict itself:
>>> d = {'a-1': 1, 'a-2': 2, 'a-3': 3}
>>> d1 = dict(d, **{'a-2': -2, 'a-1': -1})
>>> d1 is d
False
>>> d1
{'a-1': -1, 'a-2': -2, 'a-3': 3}
>>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Challenge: Please break this! [Now with blog post]
Guido van Rossum wrote: On Mon, Feb 23, 2009 at 3:16 PM, Martin v. Löwis mar...@v.loewis.de wrote: Don't I remember the previous restricted module dying a similar death of 1,000 cuts before it was concluded to be unsafe at any height and abandoned? I think you are slightly misremembering. It got cut again and again, but never died. Then, new-style classes hit an artery, and it bled to death. I'm curious how this one fares. FWIW, I am remembering more about how Samuele cracked it. It had to do with getting the supervisor code to call one of its own functions with arguments provided by the sandboxed code. Tav's safelite.py doesn't seem to be directly exploitable that way because (using ctypes hacks) it *removes* some offending special methods. But that door would be at least slightly ajar with Tar's proposed patch to Python, as that doesn't remove the offending attributes (__subclasses__ etc.); it only forbids them in restricted mode. But this once again enables Samuele's hack. (Oh if I only could find the link with the actual attack -- it was quite a bit more devious than attacks linked to so far.) http://mail.python.org/pipermail/python-dev/2003-March/033978.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reviving restricted mode?
Guido van Rossum wrote: I've received some enthusiastic emails from someone who wants to revive restricted mode. He started out with a bunch of patches to the CPython runtime using ctypes, which he attached to an App Engine bug: http://code.google.com/p/googleappengine/issues/detail?id=671 Based on his code (the file secure.py is all you need, included in secure.tar.gz) it seems he believes the only security leaks are __subclasses__, gi_frame and gi_code. (I have since convinced him that if we add restricted guards to these attributes, he doesn't need the functions added to sys.) I don't recall the exploits that Samuele once posted that caused the death of rexec.py -- does anyone recall, or have a pointer to the threads? I don't have much time these days, for sure not until pycon us, to look at the proposed code. A remark though, in many cases people want to use restricted execution to allow trusted and untrusted code to live side by side. In such a scenario the issue is not only how to prevent for example the untrusted code to get hold of open() but also how to deal with the security issues at the boundary when untrusted code calls into trusted code. AFAIK E provides and incorporate a lot of thinking around the concept of guards, a sort of generalized runtime type checking with very strong guarantees, in a language like Java instead type checking and final classes can be used to provide the required safety. Python instead over the years has grown more hooks for object to cheat about their types. In general safely programming such trusted code in python will be delicate and slightly cumbersome. Think for example of thinhs that can be done by objects redefining equality wrt data structures that old sensitive information unless such arguments are blocked. ___ 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] To 3.0.2 or not to 3.0.2?
Victor Stinner wrote: Le Tuesday 17 February 2009 08:52:20 Lennart Regebro, vous avez écrit : On Tue, Feb 17, 2009 at 00:50, Guido van Rossum gu...@python.org wrote: Can you explain the difficulty with porting setuptools in more detail? Oh, it just exposes a bug in distutils. It probably means I'll have to make a test for python version, and if it is 3.0.1, monkey-patch distutils. I haven't really looked into if there is any other possibilities yet, I'm concentrating to make it run for 3.1 trunk first. Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times. ___ 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] PEP 8: Discourage named lambdas?
Terry Reedy wrote: Some people write somename = lambda args: expression instead of the more obvious (to most people) and, dare I say, standard def somename(args): return expression The difference in the result (the only one I know of) is that the code and function objects get the generic name 'lambda' instead of the more informative (in repr() output or tracebacks) 'somename'. I consider this a disadvantage. In the absence of any compensating advantages (other than the trivial saving of 3 chars), I consider the def form to be the proper Python style to the point I think it should be at least recommended for the stdlib in the Programming Recommendations section of PEP 8. There are currently uses of named lambdas at least in urllib2. This to me is a bad example for new Python programmers. What do our style mavens think? I found only an example in my personal recent code: START = !-- *db-payload-start* -- END = !-- *db-payload-end* -- TITLEPATTERN = lambda s: title%s/title % s this three are later used in a very few .find() and .replace() expressions in the same module. I suppose my point is that while I agree it should be discouraged and is really silly to do it for the few chars gain, it can be used to some effect in very rare cases. ___ 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] PEP 8: Discourage named lambdas?
Nick Coghlan wrote: Samuele Pedroni wrote: I found only an example in my personal recent code: START = !-- *db-payload-start* -- END = !-- *db-payload-end* -- TITLEPATTERN = lambda s: title%s/title % s this three are later used in a very few .find() and .replace() expressions in the same module. I suppose my point is that while I agree it should be discouraged and is really silly to do it for the few chars gain, it can be used to some effect in very rare cases. The way that's written currently, I think I could *very* easily miss the fact that TITLEPATTERN is a callable while glancing over the code (and be very confused if I later saw it being called or passed as a callback). confused? maybe, very seems an overstatement ___ 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.99.0: new object spaces, optimizations, configuration ...
= pypy-0.99.0: new object spaces, optimizations, configuration ... = Welcome to the PyPy 0.99.0 release - a major snapshot and milestone of the last 8 months of work and contributions since PyPy-0.9.0 came out in June 2006! Main entry point for getting-started/download and documentation: http://codespeak.net/pypy/dist/pypy/doc/index.html Further below you'll find some notes about PyPy, the 0.99.0 highlights and our aims for PyPy 1.0. have fun, the PyPy team, Samuele Pedroni, Carl Friedrich Bolz, Armin Rigo, Michael Hudson, Maciej Fijalkowski, Anders Chrigstroem, Holger Krekel, Guido Wesdorp and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html What is PyPy? Technically, PyPy is both a Python Interpreter implementation and an advanced Compiler, actually a framework for implementing dynamic languages and generating virtual machines for them. The Framework allows for alternative frontends and for alternative backends, currently C, LLVM and .NET. For our main target C, we can can mix in different Garbage Collectors and threading models, including micro-threads aka Stackless. The inherent complexity that arises from this ambitious approach is mostly kept away from the Python interpreter implementation, our main frontend. Socially, PyPy is a collaborative effort of many individuals working together in a distributed and sprint-driven way since 2003. PyPy would not have gotten as far without the coding, feedback and general support from numerous people. Formally, many of the current developers are involved in executing an EU contract with the goal of exploring and researching new approaches to Language/Compiler development and software engineering. This contract's duration is about to end March 2007 and we are working and preparing the according final review which is scheduled for May 2007. Key 0.99.0 Features = * new object spaces: - Tainting: a 270-line proxy object space tracking and boxing sensitive information within an application. A tainted object is completely barred from crossing an I/O barrier, such as writing to files, databases or sockets. This allows to significantly reduce the effort of e.g. security reviews to the few places where objects are declassified in order to send information across I/O barriers. - Transparent proxies: allow to customize both application and builtin objects from application level code. Works as an addition to the Standard Object Space (and is translatable). For details see http://codespeak.net/pypy/dist/pypy/doc/proxy.html * optimizations: - Experimental new optimized implementations for various built in Python types (strings, dicts, lists) - Optimized builtin lookups to not require any dictionary lookups if the builtin is not shadowed by a name in the global dictionary. - Improved inlining (now also working for higher level backends) and malloc removal. - twice the speed of the 0.9 release, overall 2-3 slower than CPython * High level backends: - It is now possible to translate the PyPy interpreter to run on the .NET platform, which gives a very compliant (but somewhat slow) Python interpreter. - the JavaScript backend has evolved to a point where it can be used to write AJAX web applications with it. This is still an experimental technique, though. For demo applications see: http://play1.codespeak.net:8008/ * new configuration system: There is a new comprehensive configuration system that allows fine-grained configuration of the PyPy standard interpreter and the translation process. * new and improved modules: Since the last release, the signal, mmap, bz2 and fcntl standard library modules have been implemented for PyPy. The socket, _sre and os modules have been greatly improved. In addition we added a the pypymagic module that contains PyPy-specific functionality. * improved file implementation: Our file implementation was ported to RPython and is therefore faster (and not based on libc). * The stability of stackless features was greatly improved. For more details see: http://codespeak.net/pypy/dist/pypy/doc/stackless.html * RPython library: The release contains our emerging RPython library that tries to make programming in RPython more pleasant. It contains an experimental parser generator framework. For more details see: http://codespeak.net/pypy/dist/pypy/doc/rlib.html * improved documentation: - extended documentation about stackless features: http://codespeak.net/pypy/dist/pypy/doc/stackless.html - PyPy video documentation: eight hours of talks, interviews and features: http://codespeak.net/pypy/dist/pypy/doc/video-index.html - technical reports about various aspects
Re: [Python-Dev] Fwd: survey about the use of agile practices
Aahz wrote: On Sun, Dec 24, 2006, Guido van Rossum wrote: Anyone? It was discarded as probable spam by me due to the lack of a valid To: line. Do you have any particular reason for believing that it's real? http://agile.diee.unica.it/uras.html (it's in italian) seems to make this credible. FWIW. ___ 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] Using SCons for cross-compilation
Barry Warsaw wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote: Martin In any case, the patch being contributed uses SCons. If people Martin think this is unmaintainable, this is a reason to reject the Martin patch. Could SCons replace distutils? I'm not so sure. I love SCons, but it has some unpythonic aspects to it, which (IMO) make sense as a standalone build tool, but not so much as a standard library module. I'd probably want to see some of those things improved if we were to use it to replace distutils. in PyPy we explored at some point using SCons instead of abusing distutils for our building needs, it seems to have a library part but a lot of its high-level dependency logic seems to be coded in what is its main invocation script logic in a monolithic way and with a lot of global state. We didn't feel like trying to untangle that or explore more. There does seem to be overlap between the two tools though, and it might make for an interesting sprint/project to find and refactor the commonality. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRVObXHEjvBPtnXfVAQIhQQP/esS6o+7NX/JenJcuEdvb7rWIVxRgzVEh rfZGSOO2mp6b0PgrvXjAnZQHYJFpQO5JXpWJVqLBPxbucbBwvWaA0+tgTrpnBpj9 Cs/vwlMsmk55CwSYjvl7eM0uW9aIuT9QcZxuf4j+T7dzQOL0LL2Id4/876Azcfo0 7A0dtc2oJ+U= =H1w2 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.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] Import semantics
Frank Wierzbicki wrote: On 7/5/06, Guido van Rossum [EMAIL PROTECTED] wrote: Hi Frank, Have you and/or the Jython community made up your mind about this? The thread seems to have disappeared after you posted (or perhaps it continued only on jython-dev, which I don't read?). The thread pretty much stopped there. I think a modification of the import semantics won't really come up again until 2.3 is out, since releases and reviving Jython take priority over backwards incompatible features. For my part I would like to think that a goal for Jython should be: Pure Python code developed first on Jython should run without change on CPython. Which would mean we will eventually need to change the import semantics for importing Python code (though I doubt we will change the semantics for importing Java packages any time soon). Whether that can be done in 2.x, or if this change is so incompatible that we need to think about it in a Jython 3000 way, I don't really know. Changing the behavior of getattr for python modules and leave it as it is for java packages seems a reasonable compromise. Also, I just realized that you're the new Jython maintainer. Is *that* official? It is official, at least in the unofficial way that Jython appears to work: Brian handed the baton to me after (I presume) Samuele Pedroni had handed the baton to Brian. Brian's email is here: http://sourceforge.net/mailarchive/message.php?msg_id=13859029 That said, I still regard Samuele Pedroni as the ultimate authority on Jython and give him pretty much full veto power. He fortunately continues to watch the checkins and prods me when I go in the wrong direction. as things stand this a reasonable way to go about things, I'm the only person with a bit historical prospective, a bit of time to help (less than I would like still), knowing both python semantics well and Java and knowing the Jython code base, also I designed how the new-style classes implemantion work in Jython atm, so I should know how things are supposed to hang together in that respect, also for things that involve the Java glueing aspects of Jython one needs to grow some language design experience and sense, and I'm around since enough time for Jython and on python-dev to have some of that :) regards. ___ 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
Brett Cannon wrote: I don't know how JavaScript is doing it yet. The critical thing for me for this month was trying to come up with a security model. And if you don't think it is going to scale, how do you think it should be done? if I remember correctly, the boundary/granularity of mutual isolation is practically web domains, pages from the same domain can liberally access each other data, javascript state. ___ 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] Reminder: call for proposals Python Language and Libraries Track for Europython 2006
Registration for Europython (3-5 July) at CERN in Geneva is now open, if you feel submitting a talk proposal there's still time until the 31th of May. If you want to talk about a library you developed, or you know well and want to share your knowledge, or about how you are making the best out of Python through inventive/elegant idioms and patterns (or if you are a language guru willing to disseminate your wisdom), you can submit a proposal for the Python Language and Libraries track A track about Python the Language, all batteries included. Talks about the language, language evolution, patterns and idioms, implementations (CPython, IronPython, Jython, PyPy ...) and implementation issues belong to the track. So do talks about the standard library or interesting 3rd-party libraries (and frameworks), unless the gravitational pull of other tracks is stronger. The full call and submission links are at: http://www.europython.org/sections/tracks_and_talks/call-for-proposals Samuele Pedroni, Python Language and Libraries Track Chair ___ 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] Reminder: call for proposals Python Language and Libraries Track for Europython 2006
Python Language and Libraries A track about Python the Language, all batteries included. Talks about the language, language evolution, patterns and idioms, implementations (CPython, IronPython, Jython, PyPy ...) and implementation issues belong to the track. So do talks about the standard library or interesting 3rd-party libraries (and frameworks), unless the gravitational pull of other tracks is stronger. Of course talks to detail new features in the upcoming 2.5 release are more than welcome. Deadline is 31th of May. The full call and submission links are at: http://www.europython.org/sections/tracks_and_talks/call-for-proposals Thanks, Samuele Pedroni ___ 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] Class decorators
Mike Krell wrote: Greg Ewing greg.ewing at canterbury.ac.nz writes: I've just been playing around with metaclasses, and I think I've stumbled across a reason for having class decorators as an alternative to metaclasses for some purposes. There has also been discussion on the IronPython mailing list that class decorators would be a very useful syntax for expressing .NET attributes. http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html the same is true for Jython and Java annotations. ___ 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] Next PyPy Sprint: Tokyo 23/4 - 29/4
Tokyo PyPy Sprint: 23rd - 29th April 2006 The next PyPy sprint is scheduled to take place 23rd- 29th April 2006 (Sunday-Saturday) in Akihabara, Tokyo, Japan. We will together with FSIJ (Free Software Initiative of Japan) aim to promote Python and PyPy. We therefor invite Japanese hackers knowledgeable in Python to join our sprint! We'll give newcomer-friendly introductions. To learn more about the new Python-in-Python implementation look here: http://codespeak.net/pypy For this sprint we are particularly interested in meeting and coding on PyPy together with interested Japanese Python hackers. Please register your interest at [EMAIL PROTECTED] as soon as possible and we will help with any questions regarding getting started, pointing to relevant documentation etc. The PyPy team is curious and interested in the experience of hacking code for embedded devices and would love to discuss and get feedback on optimisation efforts and the current state of PyPy. Goals and topics of the sprint -- Possible suggestions for topics are: - Work on gensqueak (our Squeak backend) or possibly other backends. - Implementing Python 2.5 features in PyPy. - Progress further on an 'rctypes' module aiming at letting us use a ctypes implementation of an extension module from the compiled pypy-c. - Writing ctypes implementations of modules to be used by the above tool. - Experimenting and improving performance of our garbage collectors. - Experiment with PyPy flexibility or other aspects of the implementation. - Possibly experiment with writing modules translatable for use both in PyPy and CPython. - Whatever participants want to do with PyPy or particular areas of PyPy (please send suggestions to the mailing list before to allow us to plan and give feedback) Location Accomodation The sprint will be held at National Institute of AIST (National Institute of Advanced Industrial Science and Technology, http://www.aist.go.jp/index_en.html), Akihahabara (the technical gadget district in Tokyo). Yutaka Niibe is our contact person there, helping with arranging facilities. Niibe is the chairman of FSIJ and they have invited us to sprint in Tokyo and we are very grateful for the help and interest we have recieved so far. The facilities we are sprinting in are located here: http://www.gtrc.aist.go.jp/en/access/index.html#Akihabara The actual address is: Akihabara Dai Bldg , 1-18-13 Sotokanda, Chiyoda-ku, Tokyo 101-0021 Japan Phone: +81-3-5298-4729 Hotel areas - we are recommended to book hotels in Ueno and Asakusa (old town), from those areas there are only two metro stops to Akihabara. Please note that hotelrooms in Tokyo are often very small. http://www.wh-rsv.com/english/akihabara/index.html (nearest hotel to sprint location) http://www.greenhotel.co.jp/ochanomizu_e.html http://www.ohgai.co.jp/index-e.html (Ueno) http://www.toyoko-inn.com/e_hotel/00012/index.html (Asakusa) http://www.hotelnewkanda.com/ (second nearest, but no english page) Here is a url for booking hotels with not too unreasonable rates (see map): http://japan-hotelguide.com/hotels/Japan/Tokyo/index.htm For more general tourist information about travelling to Japan and Tokyo - please see: http://www.jnto.go.jp/eng/ http://www.japantravelinfo.com/ (really useful information regarding airfares, hotels, currency, phones etc etc) Comments on the weather: In end April it is ca 20 degrees Celsius. Exact times --- The public PyPy sprint is held Sunday 23rd - Saturday 29th April 2006. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. Sometimes people cannot stay for the whole sprint - you are welcome even if you can only stay for a day or a few days. Sunday: Starting at 10:00. This day is focused on getting to know PyPy enought to start to participate. We will hold a PyPy tutorial and an architectural overview. Planning meeting for the work to be done during the week and grouping of developers (pairs or groups mixing new participants with core developers). Dinner in the evening (Yutaka will arrange a place for us to go to). Monday-Tuesday: Starting at 10:00 with status meetings. Possible regrouping depending on the interest and progress of the various teams. Wednesday: Breakday (coding is allowed although we recommend taking a break). Thursday-Saturday: Starting at 10:00 with status meetings. Possible regrouping depending on the interest and progress of the various teams. Ending on Saturday with a Closure session - summing of the work and planning work to be done until the next sprint. Network, Food, currency We will have access to WiFi at AIST - please make sure you have wlan capabilities.
Re: [Python-Dev] GeneratorExit inheriting from Exception
Barry Warsaw wrote: On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote: Should GeneratorExit inherit from Exception or BaseException? Actually, this prompts me to write about an issue I have with PEP 352. I actually don't think it's necessary (yes, I know it's already in the tree). What I would much rather is is for StandardError to be renamed Error, for Exception to remain the base class of the exception hierarchy, and for KeyboardInterrupt to be moved to inherit directly from Exception. GeneratorExit, SystemExit, and StopIteration would continue to inherit from Exception. The reasoning is this: anything that can be raised is an Exception. Not all Exceptions are Errors. Anything that signals an error condition is an Error, and anything that signals a warning condition is a Warning. Thus the basic hierarchy /ought/ to be: Exception +- KeyboardInterrupt +- GeneratorExit +- SystemExit +- StopIteration +- Error | +- ImportError | +- (etc.) | +- Warning +- UserWarning +- (etc.) Use defined errors should inherit from Error, not Exception. With this, except Exception would be a synonym for bare except, while except Error would be the standard idiom for letting non-error exceptions pass through. I don't know whether this is possible for Python 2.5, well, one thing to consider is all the class MyException(Exception): in current code. but I think it should be what we strive for for Py3K, and I do not think BaseException is at all necessary. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.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] Threading idea -- exposing a global thread lock
Raymond Hettinger wrote: [Samuele Pedroni] there's no sys.checkinterval in Jython. Implementing this would need the introduction of some kind of GIL implementation in Jython, the JVM has no primitive for global critical sections. Wouldn't Java implement this directly by suspending and resuming the other threads (being careful to avoid access to monitored resources and to pair the suspend/resume operations in a try/finally or with-statement to prevent deadlocks)? suspending a thread is a deprecated operation because it can cause deadlocks. ___ 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] Making builtins more efficient
Phillip J. Eby wrote: At 02:47 PM 3/13/2006 -0500, Jim Jewett wrote: Paul Moore wrote: Is there any practical way of detecting and flagging constructs like the above (remotely shadowing a builtin in another module)? Phillip J. Eby wrote: the patch ended up being backed out ... too strict of a check to be accepted for Python 2.4. http://svn.python.org/view/python/trunk/Objects/moduleobject.c It was revision 33054, backed out in 33084. The patch warned about any shadowing of builtins, which probably is too strict. I'm curious: what actually happened? What things were causing warnings? http://mail.python.org/pipermail/python-dev/2003-July/036879.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.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] Threading idea -- exposing a global thread lock
Raymond Hettinger wrote: it doesn't translate reasonably to Jython or IronPython, it's really tricky to implement, FWIW, someone on the newsgroup suggested implementing this via a slight modification to sys.checkinterval(). The idea was that a None argument would translate to stop-checking and the active thread would do a few steps atomically and then restore the original value. The new with-statement makes that a piece of cake. there's no sys.checkinterval in Jython. Implementing this would need the introduction of some kind of GIL implementation in Jython, the JVM has no primitive for global critical sections. A GIL is something users of Jython don't want. Even with that is way too easy to have non-Jython threads around that could manipulates Java objects you are seamlessy dealing with. That is of course true for CPython and C extension initiated threads too, but is probably harder to be oblivious of such things in CPython context. ___ 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] PEP for Better Control of Nested Lexical Scopes
Almann T. Goo wrote: As far as I remember, Guido wasn't particularly opposed to the idea, but the discussion fizzled out after having failed to reach a consensus on an obviously right way to go about it. My apologies for bringing this debated topic again to the front-lines--that said, I think there has been good, constructive things said again and sometimes it doesn't hurt to kick up an old topic. After pouring through some of the list archive threads and reading through this thread, it seems clear to me that the community doesn't seem all that keen on fixing issue--which was my goal to ferret out. For me this is one of those things where the Pythonic thing to do is not so clear--and that mysterious, enigmatic definition of what it means to be Pythonic can be quite individual so I definitely don't want to waste my time arguing what that means. The most compelling argument for not doing anything about it is that the use cases are probably not that many--that in itself makes me less apt to push much harder--especially since my pragmatic side agrees with a lot of what has been said to this regard. IMO, Having properly nested scopes in Python in a sense made having closures a natural idiom to the language and part of its user interface. By not allowing the name re-binding it almost seems like that user interface has a rough edge that is almost too easy to get cut on. This in-elegance seems very un-Pythonic to me. If you are looking for rough edges about nested scopes in Python this is probably worse: x = [] for i in range(10): ... x.append(lambda : i) ... [y() for y in x] [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] although experienced people can live with it. The fact is that importing nested scope from the like of Scheme it was not considered that in Scheme for example, looping constructs introduce new scopes. So this work more as expected there. There were long threads about this at some point too. Idioms and features mostly never port straightforwardly from language to language. For example Python has nothing with the explicit context introduction and grouping of a Scheme 'let', so is arguable that nested scope code, especially with rebindings, would be less clear, readable than in Scheme (tastes in parenthesis kept aside). Anyhow, good discussion. Cheers, Almann -- Almann T. Goo [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/pedronis%40strakt.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] PEP for Better Control of Nested Lexical Scopes
Greg Ewing wrote: Jeremy Hylton wrote: The names of naming statements are quite hard to get right, I fear. My vote goes for 'outer'. And if this gets accepted, remove 'global' in 3.0. In 3.0 we could remove 'global' even without 'outer', and make module global scopes read-only, not rebindable after the top-level code has run (i.e. more like function body scopes). The only free-for-all namespaces would be class and instance ones. I can think of some gains from this. .3 wink ___ 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] Draft proposal: Implicit self in Python 3.0
Ralf W. Grosse-Kunstleve wrote: --- Fredrik Lundh [EMAIL PROTECTED] wrote: Please try the code below to see the performance impact. oh, please. do you seriously think that if you don't have to type self yourself, Python will suddenly be able to turn all instance variables into local function variables without any performance overhead ? Yes, exactly, since you can make the local namespace vs. instance attribute distinction in C. Cheers, Ralf that indeed proves why this discussion for whatever value it has, belongs to comp.lang.python. This is not a place to clarify people how Python currently works, or to have discussions made of guesses and half-formed speculations. ___ 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] Draft proposal: Implicit self in Python 3.0
Ian Bicking wrote: Tim Peters wrote: [Thomas Wouters] My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ, the minds of many, many people, not just Python developers) but that it isn't easily findable and it isn't easily accessible in a single location. I thought PEP's where supposed to be that, and if I have a particular idea for new syntax or new semantics, PEPs would be the place I'd look, not the FAQ or a Wiki. Luckily, in his benevolent infinite wisdom, I expect Guido reserved PEP number 13 for exactly this purpose: for a meta-PEP to record the unlucky PEP ideas that are so unlikely to get accepted that it's not worth anyone's time to write an actual PEP for them. I like the title: Don't Bother: PEPs Rejected Before Being Written No, I'm not kidding. At least I don't think I am. +1. I think it's rather patronizing to send things back to python-list when you know people are wasting their time discussing them because they will never be accepted. Well, the problem is that most of these proposers think that their proposal deserve attention, is valuable no matter what, but python-dev is not the place to defuse/clarify that in a gentle way for the proposer. Of course some people do exactly that here out of kindness etc., I personally don't think it's a good approach. python-list is a better place to get clarifications about the way Python is, will stay. Half-baked, not well thought out ideas, as huge threads in the past going nowhere have proven, are not healthy to python-dev s/n ratio. Even with such a valuable PEP in place, I expect some people to need clarification discussions and python-list will still be the right place to have them. People on python-list have useful things to do too, they don't just read to waste their time. I would prefer PEP form over a wiki page, as I'd rather this be truly authoritative, and only Guido can really completely reject an idea. Justifying the rejections can be done by anyone though; maybe each idea could link to a wiki page on the topic. I think it's also important to be clear on what's being rejected. Often these rejected ideas address a real issue, and if you think about the issue from another angle you might be able to solve that without falling into the trap that the oft-rejected proposal fell into. But it's easy to confuse that the issue or use case is being explicitly ignored, rather than the particulars. For instance, Thomas said changing all statements into expressions (e.g. logix): python isn't (going to be) a functional language -- and that's what shouldn't be in the PEP. All statements aren't going to be expressions; the editorialization that Python isn't going to be a functional language is both rather inaccurate, misses the real reason for statements, and needlessly alienates people who like functional programming (and they have been *needlessly* alienated by discussions about lambda and filter). So... maybe Guido or python-dev should write/vet the justifications too. When you are putting up walls and specifically discouraging community participation on certain issues, it should be done in a sensitive way. ___ 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] Draft proposal: Implicit self in Python 3.0
Ian Bicking wrote: I just don't want people to feel discouraged when they try to contribute to the Python community and a PEP 13 could help direct people towards areas where their contributions are more likely to be useful. but people have a lot of options, probably more effective, ranging from writing great applications in Python, great libraries ... plus implementation work before they are left with the hard option that is language design to contribute to the community. Also I think it is unfair to use python-list to clarify things that python-dev is not willing to clarify itself. notice that the intersection is not empty yet. Also PEP 1 contains PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list@python.org and/or python-dev@python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include: setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, setting up a wiki page, etc. PEP authors should use their discretion here. in the past it often happened that water testing, honing for a PEP happend on python-list before any long discussion went on on python-dev. Basically I think that throwing half-cooked ideas at python-dev, especially for people with no track-record of language design contributions to Python, is just a recipe for frustration. ___ 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] some interesting readings
because I was reminded of them recently, because they may be useful landmarks in the prospective of future discussions, because expanding one's understanding of the problem/solution space of language design is quite a good thing if one is interested in such things... 1) Gilad Bracha. Pluggable Type Systems . OOPSLA04 Workshop on Revival of Dynamic Languages ( http://pico.vub.ac.be/%7Ewdmeuter/RDL04/papers/Bracha.pdf ) As a talk: Pluggable Types, originally given at Aarhus University in March 2003, and repeated since at Berne and elsewhere. ( http://bracha.org/pluggable-types.pdf ) 2) http://homepages.cwi.nl/~ralf/OOHaskell/ state of the art experiment on trying to reconcile object orientation, type inference and as much as possible expressiveness PS: I think 1 is much more relevant than 2 for Python as we know it. happy reading. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Michael Chermside wrote: The F-bot writes: in reality, some things are carefully thought out and craftily im- plemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. +1 QOTF. Seriously... I've seen this behavior also, but I haven't ever thought about it as clearly as Fredrik does here. When we go to answer questions we ought to pause briefly first and decide which of these categories applies to a given piece of behavior. I think users will be understanding if we're honest about what are the accidents -- every language or software package has some, and just because it's an accident does NOT mean we should fix it. it's indeed a matter of trade-offs. Converting NameErrors into commands doesn't look like a good trade off in terms of expectations management and understandable behavior. Ka-Ping Yee ExitHatch still seem a reasonable improvement. Fernando Perez considerations about Python vs. commands and prefixing and extra-linguistic extensions seem also on spot. It's not a matter of defending the status quo, more about what kind of price is reasonable for DWIM. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a quit that actually quits
Michael Hudson wrote: [EMAIL PROTECTED] writes: Fredrik a quit/exit command that actually quits, instead of printing a Fredrik you didn't say please! message. I like Fredrik's idea more and more. The thing that bothers me about it is that the standard way you tell python to do something is call a function -- to me, a special case for exiting the interpreter seems out of proportion. also worth remarking is that is quite a FAQ at least for Jython, how to convince python to accept bare words (plus args) as function calls. So this magic is confusing and in the wrong direction from that point of view, given that we don't plan to support that at all. In other news, clever hacks with tb_next and so on also seem excessive. Why not have the equivalent of if input.rstrip() == 'exit': sys.exit() in the implementation of the interactive interpreter? Cheers, mwh ___ 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] status of development documentation
Tim Peters wrote: [Neal] Hmmm, I thought others were running the tests on Windows too. There was one report on Nov 22 about running Purify on Windows 2k (subject: ast status, memory leaks, etc). He had problems with a stack overflow in test_compile. He was going to disable the test and re-run. I never heard back though. Based on that info, I would guess that test_builtin was working on Win 2k on Nov 22. I wouldn't assume that. My nobody was wrt the universe of Python developers, not users; folks like Trent and MarkH and you and me. Without normal baseline test experience, users don't understand what they're seeing, and so their reports can be highly misleading. You can trust that while I don't understand what I'm seeing here either, at least I told the absolute truth about it and didn't hold back critical details ;-) That said, I was hoping to do some Python work over Thanksgiving week, but was mortally discouraged on the Nov 19-20 weekend by all the test failures I saw. So I'm pretty sure (but not certain) that test_builtin was failing then. (A parenthentical question: is there a reason you don't pass -uall to regrtest.py?) It's calling make test. I thought about calling regrtest.py instead and doing as you suggest. Is there a benefit to running make test? You're asking a Windows guy about make: bad career move ;-) I know it runs with and without -O. I guess it's only machine time, I could run make test and regrtest.py -uall. -uall is helpful in finding bugs. One thing in particular here is that test_compiler runs only a tiny subset of its full test unless an appropriate -u flag is given. On WinXP Pro SP2 today, passing -uall, and after fixing all the MS compiler warnings that have crept in: 251 tests OK. 12 tests failed: test_builtin test_coding test_compiler test_pep263 test_univnewlines test_urllib test_urllib2 test_urllibnet test_userlist test_wave test_whichdb test_zipfile 1 skip unexpected on win32: test_xml_etree_c Ouch! I'm might be to blame for at least some of those. :-( I'm sure it's not as bad as it looks. For example, test_coding and (the -uall) test_compiler fail for exactly the same reason. For another, when a test fails on Windows, it sometimes leaves a @test file or directory behind, which causes a cascade of bogus failures later. For example, test_userlist, test_wave, test_whichdb, and test_zipfile all pass when run alone here. Others probably do too. ... Do you know if the tests were broken before the AST merge (about Oct 22 I think)? I don't know. I'm getting more evidence that most (if not all) of the failures are due to compile-time parsing screwups, so the AST merge is a prime suspect. Is it possible that generated parse tables (whatever) are out-of-date on a Windows box? There are no makefiles here, and the Windows build has always relied on Unix-heads to check in correct generated parser files. The code up to the first failure is short: bom = '\xef\xbb\xbf' compile(bom + 'print 1\n', '', 'exec') Curiously, that sequence doesn't blow up under the released Windows Python 2.4.2, so somebody broke something here since then ... There were a bunch of changes to Parser/tokenizer.c to handle error conditions. Those go back to Oct 1. I don't *think* those would cause these, but I'm not sure. Sorry, I don't know any more. I guess you might have to binary search by date to try and find the problem. That's just silly ;-) What I need is someone who understands what this code is _supposed_ to do, so we can fix it; finding the checkin that caused it isn't nearly as interesting. Windows has an excellent debug-build debugger and I can easily step through the code. But I have no idea why compiling a string starting with '\xef\xbb\xbf' should _not_ be a syntax error -- it looks like a syntax error to me. And when I step thru the code, it looks like a syntax error to the parser too. It peels off the first character (\xef), and says syntax error at that point: Py_CompileStringFlags - PyParser_ASTFromString - PyParser_ParseStringFlagsFilename - parsetok - PyTokenizer_Get That sets `a` to point at the start of the string, `b` to point at the second character, and returns type==51. Then `len` is set to 1, `str` is malloc'ed to hold 2 bytes, and `str` is filled in with \xef\x00 (the first byte of the input, as a NUL-terminated C string). PyParser_AddToken then calls classify(), which falls off the end of its last loop and returns -1: syntax error. So how it gets there is really quite straightfoward. The problem for me is that I have no idea why it _should_ do something other than that, let alone what that may be. PEP263: To aid with platforms such as Windows, which add Unicode BOM marks to the beginning of Unicode files, the UTF-8 signature '\xef\xbb\xbf' will be interpreted as 'utf-8' encoding
[Python-Dev] Next PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006
Palma de Mallorca PyPy Sprint: 23rd - 29th January 2006 The next PyPy sprint is scheduled to take place January 2006 in Palma De Mallorca, Balearic Isles, Spain. We'll give newcomer-friendly introductions and the focus will mainly be on current JIT work, garbage collection, alternative threading models, logic programming and on improving the interface with external functions. To learn more about the new Python-in-Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint -- In Gothenburg we have made some first forays into the interesting topics of Just-in-Time compilation. In Mallorca we will continue that and have the following ideas: - Further work/experimentation toward Just-In-Time Compiler generation, which was initiated with the Abstract Interpreter started in Gothenburg. - Integrating our garbage collection toolkit with the backends and the code generation. - Heading into the direction of adding logic programming to PyPy. - Optimization work: our threading implementation is still incredibly slow, we need to work on that. Furthermore there are still quite some slow places in the interpreter that could be improved. - getting the socket module to a more complete state (it is already improved but still far from complete) - generally improving the way we interface with external functions. - whatever participants want to do with PyPy (please send suggestions to the mailing list before to allow us to plan and give feedback) Location Accomodation The sprint will be held at the Palma University (UIB - Universitat de les Illes Balears), in their GNU/Linux lab (http://mnm.uib.es/phpwiki/AulaLinux). We are hosted by the Computer Science department and Ricardo Galli is our contact person there, helping with arranging facilities. The University is located 7 km away from the central Palma. Busses to the University departs from Plaza de España (which is a very central location in Palma). Take bus 19 to the UIB campus. A ticket for one urban trip costs 1 euro. You can also buy a card that is valid for 10 trips and costs 7.51 euros. Information about bus timetables and routes can be found on: http://www.a-palma.es A map over the UIB campus are can be found on: http://www.uib.es/imagenes/planoCampus.html The actual address is: 3r pis de l'Anselm Turmeda which can be found on the UIB Campus map. At Plaza de España there is a hostel (Hostal Residencia Terminus) which has been recommended to us. It's cheap (ca 50 euros/double room with bathroom). Some more links to accomodations (flats, student homes and hotels): http://www.lodging-in-spain.com/hotel/town/Islas_Baleares,Mallorca,Palma_de_Mallorca,1/ http://www.uib.es/fuguib/residencia/english/index.html http://www.homelidays.com/EN-Holidays-Rental/110_Search/SearchList.asp?DESTINATION=Palma%20de%20MallorcaADR_PAYS=ESADR_ LOCALISATION=ES%20ISLASBALEARES%20MALLORCA If you want to find a given street, you can search here: http://www.callejeando.com/Pueblos/pueblo7_1.htm To get to Palma De Mallorca almost all low fare airlines and travel agencies have cheap tickets to get there. Information about Mallorca and Palma (maps, tourist information, local transports, recommended air lines, ferries and much more) can be found on: http://www.palmademallorca.es/portalPalma/home.jsp Comments on the weather: In January it is cold and wet on Mallorca Average temperature: 8,4 degrees Celsius Lowest temperature: 2 degrees Celsius Highest temperature: 14,5 degrees Celsius Average humidity rate: 77,6 % So more time for coding and less time for sunbathing and beaches ;-) Exact times --- The public PyPy sprint is held Monday 23rd - Sunday 29th January 2006. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. In the middle of the sprint there usually is a break day and it's usually ok to take half-days off if you feel like it. For this particular break day, Thursday, we are invited to the studio of Ginés Quiñonero, a local artist and painter. Ginés have also been the person helping us getting connections to UIB and providing much appreciated help regarding accommodation and other logistical information. For those of you interested - here is his website where there also are paintings showing his studio: http://www.hermetex4.com/damnans/ For those interested in playing collectable card games, this will also be an opportunity to get aquainted with V:TES which will be demoed by Ginés and Beatrice and Sten Düring. For more information on this cardgame - see: http://www.white-wolf.com/vtes/index.php. (The Mallorca
Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison
Noam Raphael wrote: Three weeks ago, I read this and thought, well, you have two options for a default comparison, one based on identity and one on value, both are useful sometimes and Guido prefers identity, and it's OK. But today I understood that I still think otherwise. well, this still belongs to comp.lang.python. In two sentences: sometimes you wish to compare objects according to identity, and sometimes you wish to compare objects according to values. Identity-based comparison is done by the is operator; Value-based comparison should be done by the == operator. Let's take the car example, and expand it a bit. Let's say wheels have attributes - say, diameter and manufacturer. Let's say those can't change (which is reasonable), to make wheels hashable. There are two ways to compare wheels: by value and by identity. Two wheels may have the same value, that is, they have the same diameter and were created by the same manufacturer. Two wheels may have the same identity, that is, they are actually the same wheel. We may want to compare wheels based on value, for example to make sure that all the car's wheels fit together nicely: assert car.wheel1 == car.wheel2 == car.wheel3 == car.wheel4. We may want to compare wheels based on identity, for example to make sure that we actually bought four wheels in order to assemble the car: assert car.wheel1 is not car.wheel2 and car.wheel3 is not car.wheel1 and car.wheel3 is not car.wheel2... We may want to associate values with wheels based on their values. For example, it's reasonable to suppose that the price of every wheel of the same model is the same. In that case, we'll write: price[wheel] = 25. We may want to associate values with wheels based on their identities. For example, we may want to note that a specific wheel is broken. For this, I'll first define a general class (I defined it before in one of the discussions, that's because I believe it's useful): class Ref(object): def __init__(self, obj): self._obj = obj def __call__(self): return self._obj def __eq__(self, other): return isinstance(other, ref) and self._obj is other._obj def __hash__(self): return id(self._obj) ^ 0xBEEF Now again, how will we say that a specific wheel is broken? Like this: broken[Ref(wheel)] = True Note that the Ref class also allows us to group wheels of the same kind in a set, regardless of their __hash__ method. I think that most objects, especially most user-defined objects, have a *value*. I don't have an exact definition, but a hint is that two objects that were created in the same way have the same value. Sometimes we wish to compare objects based on their identity - in those cases we use the is operator. Sometimes we wish to compare objects based on their value - and that's what the == operator is for. Sometimes we wish to use the value of objects as a dictionary key or as a set member, and that's easy. Sometimes we wish to use the identity of objects as a dictionary key or as a set member - and I claim that we should do that by using the Ref class, whose *value* is the object's *identity*, or by using a dict/set subclass, and not by misusing the __hash__ and __eq__ methods. I think that whenever value-based comparison is meaningful, the __eq__ and __hash__ should be value-based. Treating objects by identity should be done explicitly, by the one who uses the objects, by using the is operator or the Ref class. It should not be the job of the object to decide which method (value or identity) is more useful - it should allow the user to use both methods, by defining __eq__ and __hash__ based on value. Please give me examples which prove me wrong. I currently think that the only objects for whom value-based comparison is not meaningful, are objects which represent entities which are outside of the process, or in other words, entities which are not computational. This includes files, sockets, possibly user-interface objects, loggers, etc. I think that objects that represent purely data, have a value that they can be compared according to. Even wheels that don't have any attributes are simply equal to other wheels, and not equal to other objects. Since user-defined classes can interact with the environment only through other objects or functions, it is reasonable to suggest that they should get a value-based equality operator. Many times the value is defined by the __dict__ and __slots__ members, so it seems to me a reasonable default. I would greatly appreciate repliers that find a tiny bit of reason in what I said (even if they don't agree), and not deny it all as a complete load of rubbish. not if you think python-dev is a forum for such discussions on OO thinking vs other paradigms. Thanks, Noam ___ Python-Dev mailing list Python-Dev@python.org
Re: [Python-Dev] Why should the default hash(x) == id(x)?
Noam Raphael wrote: On 11/5/05, Martin v. Löwis [EMAIL PROTECTED] wrote: More generally, I claim that the current behaviour is better than *any* alternative. To refute this claim, you would have to come up with an alternative first. The alternative is to drop the __hash__ method of user-defined classes (as Guido already decided to do), and to make the default __eq__ method compare the two objects' __dict__ and slot members. no, whether object has an __hash__ and what is the default hashing are different issues. Also all this discussion should have started and lived on comp.lang.python and this is a good point as any to rectify this. See the thread about default equality operator - Josiah Carlson posted there a metaclass implementing this equality operator. Noam ___ 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/pedronis%40strakt.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] a different kind of reduce...
Reinhold Birkenfeld wrote: Raymond Hettinger wrote: [Martin Blais] I'm always--literally every time-- looking for a more functional form, something that would be like this: # apply dirname() 3 times on its results, initializing with p ... = repapply(dirname, 3, p) [Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! not really, those right now work with any callable, class C: ... def __call__(self, x): ... return 2*x ... map(C(), [1,2,3]) [2, 4, 6] that's why attaching functionaliy as methods is not always the best solution. regards. ___ 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] [Jython-dev] Re: AST branch is in?
Frank Wierzbicki wrote: On 10/20/05, *Neal Norwitz* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The Grammar is (was at one point at least) shared between Jython and would allow more tools to be able to share infrastructure. The idea is to eventually be able to have [JP]ython output the same AST to tools. Hello Python-dev, My name is Frank Wierzbicki and I'm working on the Jython project. Does anyone on this list know more about the history of this Grammar sharing between the two projects? I've heard about some Grammar sharing between Jython and Python, and I've noticed that (most of) the jython code in /org/python/parser/ast is commented Autogenerated AST node. I would definitely like to look at (eventually) coordinating with this effort. I've cross-posted to the Jython-dev list in case someone there has some insight. as far as I understand now Python trunk contains some generated AST representation C code created through the asdl_c.py script from an updated Python.asdl, these files live in http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Parser/ a parallel asdl_java.py existed in Python CVS sandbox (where the AST effort started) and was updated the last time the Jython own AST classes were generated with at the time version of Python.asdl (this was done by me if I remember correctly at some point in Jython 2.2 evolution, I think when the PyDev guys wanted a more up-to-date Jython parser to reuse): http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/nondist/sandbox/ast/asdl_java.py?content-type=text%2Fplainrev=1.7 basically the new Python.asdl needs to be used, the asdl_java.py maybe updated and our compiler changed as necessary. regards. ___ 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] AST branch is in?
Guido van Rossum wrote: On 10/25/05, Frank Wierzbicki [EMAIL PROTECTED] wrote: My name is Frank Wierzbicki and I'm working on the Jython project. Does anyone on this list know more about the history of this Grammar sharing between the two projects? I've heard about some Grammar sharing between Jython and Python, and I've noticed that (most of) the jython code in /org/python/parser/ast is commented Autogenerated AST node. I would definitely like to look at (eventually) coordinating with this effort. I've cross-posted to the Jython-dev list in case someone there has some insight. Your best bet is to track down Jim Hugunin and see if he remembers. He's jimhug at microsoft.com or jim at hugunin.net. no. this is all after Jim, its indeed a derived effort from the CPython own AST effort, just that we started using it quite a while ago. This is all after Jim was not involved with Jython anymore, Finn Bock started this. ___ 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] Deprecating builtin id (and moving it to sys())
Jeremy Hylton wrote: I'd like to see the builtin id() removed so that I can use it as a local variable name without clashing with the builtin name. I certainly use the id() function, but not as often as I have a local variable I'd like to name id. The sys module seems like a natural place to put id(), since it is exposing something about the implementation of Python rather than something about the language; the language offers the is operator to check ids. it is worth to remember that id() functionality is not cheap for Python impls using moving GCs. Identity mappings would be less taxing. Jeremy ___ 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/pedronis%40strakt.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] __traceback__ and reference cycles
Tim Peters wrote: I can't think of a Python feature with a higher aggregate braincell_burned / benefit ratio than __del__ methods. If P3K retains them-- or maybe even before --we should consider taking the Java dodge on this one. That is, decree that henceforth a __del__ method will get invoked by magic at most once on any given object O, no matter how often O is resurrected. Jython __del__ support is already layered on Java finalize, so that's what one gets. ___ 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] Next PyPy sprint: Heidelberg (Germany), 22nd-29th of August
PyPy Sprint in Heidelberg 22nd - 29th August 2005 == The next PyPy sprint will take place at the Heidelberg University in Germany from 22nd August to 29th August (both days included). Its main focus is translation of the whole PyPy interpreter to a low level language and reaching 2.4.1 Python compliancy. To learn more about the new PyPy Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint -- One of the main goals of the sprint is going to be a 0.7 release of PyPy. The 0.7 is meant to be the first self-contained PyPy version but still alpha with some C-extension modules missing and not meant for production use. Therefore the topics of the sprint will be: - translation efforts: it's not completely clear now what related task will be left at that time - work on 2.4.1 compliancy: there are some failing compliancy tests on which we plan to work - rewriting c-extension modules/integrating existing rewrites - all kinds of small release issues - possibly some more LLVM efforts Location Accomodation The sprint will be held in a conference room of the Institute of Physics, University of Heidelberg. We have WLAN connection there and small kitchen to make tea and coffee. `See here`_ how to get there from the Heidelberg main station. There is a huge number of hotels_ in Heidelberg, all of which are unfortunately rather expensive. It should be no problem to reach the sprint venue from anywhere in Heidelberg. As an alternative you could also take a `hotel in Mannheim`_ which you can reach in 15 min from Heidelberg with the train. .. _`See here`: http://www.physi.uni-heidelberg.de/physi/front/anfahrt.en.php .. _hotels: http://www.cvb-heidelberg.de/index_eng.html .. _`hotel in Mannheim`: http://www.hotels.de/en/mannheim.htm Exact times --- The Pypy sprint is held Monday 22nd August - Monday 29th August 2005. Hours will be from 09:00 until people have had enough. It's a good idea to arrive a day before the sprint starts. Network, Food - The Heidelberg Altstadt can be reached in approximately 10 min from the sprint venue. There you will find all kinds of restaurants and fast food places. You will probably need a wireless network card to access the network although we could set up a WLAN to cable bridge if necessary. Registration etc.pp. Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Heidelberg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/heidelberg-people.txt .. _`Heidelberg people`: http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/heidelberg-people.html .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint -- Samuele Pedroni the PyPy team ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Language track at Europython, still possibilities to submit talks
I'm the track chair of the Python Language track at Europython (27-29 June, Göteborg, Sweden) . The general deadlline for talk submission has been extended until the 7th of May. There are still open slots for the language track. So if someone with (core) language interests is or may be interested in partecipating, there's still the possibility to submit talks about idioms, patterns, recent new additions to language (for example new 2.4 features), or other language related topics. http://www.europython.org/sections/tracks_and_talks/propose_a_talk/#language http://www.europython.org/sections/tracks_and_talks/propose_a_talk/ http://www.europython.org Regards, Samuele Pedroni, Python Language Track chair. ___ 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] Re: anonymous blocks
Jim Fulton wrote: Duncan Booth wrote: Jim Fulton [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Guido van Rossum wrote: I've written a PEP about this topic. It's PEP 340: Anonymous Block Statements (http://python.org/peps/pep-0340.html). Some observations: 1. It looks to me like a bare return or a return with an EXPR3 that happensto evaluate to None inside a block simply exits the block, rather than exiting a surrounding function. Did I miss something, or is this a bug? No, the return sets a flag and raises StopIteration which should make the iterator also raise StopIteration at which point the real return happens. Only if exc is not None The only return in the pseudocode is inside if exc is not None. Is there another return that's not shown? ;) I agree that we leave the block, but it doesn't look like we leave the surrounding scope. that we are having this discussion at all seems a signal that the semantics are likely too subtle. ___ 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] defmacro (was: Anonymous blocks)
Robert Brewer wrote: Shane Hathaway wrote: Robert Brewer wrote: So currently, all subclasses just override __set__, which leads to a *lot* of duplication of code. If I could write the base class' __set__ to call macros like this: def __set__(self, unit, value): self.begin() if self.coerce: value = self.coerce(unit, value) oldvalue = unit._properties[self.key] if oldvalue != value: self.pre() unit._properties[self.key] = value self.post() self.end() defmacro begin: pass defmacro pre: pass defmacro post: pass defmacro end: pass Here is a way to write that using anonymous blocks: def __set__(self, unit, value): with self.setting(unit, value): if self.coerce: value = self.coerce(unit, value) oldvalue = unit._properties[self.key] if oldvalue != value: with self.changing(oldvalue, value): unit._properties[self.key] = value def setting(self, unit, value): # begin code goes here yield None # end code goes here def changing(self, oldvalue, newvalue): # pre code goes here yield None # post code goes here ... Which do you prefer? I like fewer methods. ;-) I still prefer more methods, because my actual use-cases are more complicated. Your solution would work for the specific case I gave, but try factoring in: * A subclass which needs to share locals between begin and post, instead of pre and post. or * A set of 10 subclasses which need the same begin() but different end() code. Yielding seems both too restrictive and too inside-out to be readable, IMO. it seems what you are asking for are functions that are evaluated in namespace of the caller: - this seems fragile, the only safe wat to implement 'begin' etc is to exactly know what goes on in __set__ and what names are used there - if you throw in deferred evaluation for exprs or suites passed in as arguments and even without considering that, it seems pretty horrid implementation-wise Notice that even in Common Lisp you cannot really do this, you could define a macro that produce a definition for __set__ and takes fragments corresponding to begin ... etc ___ 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] Re: Re: anonymous blocks
Fredrik Lundh wrote: Regardless, I believe that solving generator finalization (calling all enclosing finally blocks in the generator) is a worthwhile problem to solve. Whether that be by PEP 325, 288, 325+288, etc., that should be discussed. Whether people use it as a pseudo-block, or decide that blocks are further worthwhile, I suppose we could wait and see. Agreed. I agree, in fact I think that solving that issue is very important before/if ever introducing a generalized block statement because otherwise things that would naturally be expressible with for and generators will use the block construct which allow more variety and so possibly less immediate clarity just because generators are not good at resource handling. ___ 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] Security capabilities in Python
Ka-Ping Yee wrote: On Sat, 9 Apr 2005, Jp Calderone wrote: Does using the gc module to bypass this security count? If so: [EMAIL PROTECTED]:~$ python -i facet.py import gc c = readonly_facet.__getattr__.func_closure[1] r = gc.get_referents(c)[0] r.n = 'hax0r3d' readonly_facet.value() 'hax0r3d' You can't get func_closure in restricted mode. (Or at least, i can't, using the Python included with Mac OS 10.3.8.) restrict() readonly_facet.__getattr__.func_closure Traceback (most recent call last): File stdin, line 1, in ? RuntimeError: restricted attribute Even though this particular example doesn't work in restricted mode, it's true that the gc module violates capability discipline, and you would have to forbid its import. In any real use case, you would have to restrict imports anyway to prevent access to sys.modules or loading of arbitrary binaries. For a version that restricts imports, see: http://zesty.ca/python/facet.py Let me know if you figure out how to defeat that. you should probably search the list and look at my old attacks against restricted execution, there's reason why is not much supported anymore. One can still try to use it but needs to be extremely careful or use C defined proxies... etc. (This is a fun exercise, but with a potential purpose -- it would be nice to have a coherent story on this for Python 3000, or maybe even Python 2.x.) -- ?!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/pedronis%40strakt.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] Pickling instances of nested classes
Walter Dörwald wrote: Samuele Pedroni wrote: [...] And having the full name of the class available would certainly help in debugging. that's probably the only plus point but the names would be confusing wrt modules vs. classes. You'd propably need a different separator in repr. XIST does this: from ll.xist.ns import html html.a.Attrs.href attribute class ll.xist.ns.html:a.Attrs.href at 0x8319284 My point was that enabling reduce hooks at the metaclass level has propably other interesting applications, is far less complicated than your proposal to implement, it does not further complicate the notion of what happens at class creation time, and indeed avoids the implementation costs (for all python impls) of your proposal and still allows fairly generic solutions to the problem at hand because the solution can be formulated at the metaclass level. Pickling classes like objects (i.e. by using the pickling methods in their (meta-)classes) solves only the second part of the problem: Finding the nested classes in the module on unpickling. The other problem is to add additional info to the inner class, which gets pickled and makes it findable on unpickling. If pickle.py is patched along these lines [*] (strawman impl, not much tested but test_pickle.py still passes, needs further work to support __reduce_ex__ and cPickle would need similar changes) then this example works: class HierarchMeta(type): metaclass such that inner classes know their outer class, with pickling support def __new__(cls, name, bases, dic): sub = [x for x in dic.values() if isinstance(x,HierarchMeta)] I did something similar to this in XIST, but the problem with this approach is that in: class Foo(Elm): pass class Bar(Elm): Baz = Foo the class Foo will get its _outer_ set to Bar although it shouldn't. this should approximate that behavior better: [not tested] import sys def __new__(cls, name, bases, dic): sub = [x for x in dic.values() if isinstance(x,HierarchMeta)] newtype = type.__new__(cls, name, bases, dic) for x in sub: if not hasattr(x, '_outer_') and getattr(sys.modules.get(x.__module__), x.__name__, None) is not x: x._outer_ = newtype return newtype . we don't set _outer_ if a way to pickle the class is already there ___ 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] Pickling instances of nested classes
Walter Dörwald wrote:
Samuele Pedroni wrote:
Walter Dörwald wrote:
[User cases for pickling instances of nested classes]
So is this change wanted? useful? implementable with reasonable
effort? Or
just not worth it?
notice that in this cases often metaclasses are involved or could
easely be, so if pickling would honor __reduce__ or __reduce_ex__ on
metaclasses (which right now it doesn't treating their instances as
normal classes) one could roll her own solution without the burden for
the language of implementing pickling of nested classes in general, so
I think that would make more sense, to add support to honor
__reduce__/__reduce_ex__ for metaclasses.
Sorry, I don't understand: In most cases it can be possible to
work around the nested classes problem by implementing custom pickling
functionality (getstate/setstate/reduce/reduce_ex). But it is probably
impossible to implement this once and for all in a common base class,
because there's no way to find the real name of the nested class (or any
other handle that makes it possible to retrieve the class from the
module on unpickling).
And having the full name of the class available would certainly help in
debugging.
that's probably the only plus point but the names would be confusing wrt
modules vs. classes.
My point was that enabling reduce hooks at the metaclass level has
propably other interesting applications, is far less complicated than
your proposal to implement, it does not further complicate the notion of
what happens at class creation time, and indeed avoids the
implementation costs (for all python impls) of your proposal and still
allows fairly generic solutions to the problem at hand because the
solution can be formulated at the metaclass level.
If pickle.py is patched along these lines [*] (strawman impl, not much
tested but test_pickle.py still passes, needs further work to support
__reduce_ex__ and cPickle would need similar changes) then this example
works:
class HierarchMeta(type):
metaclass such that inner classes know their outer class, with
pickling support
def __new__(cls, name, bases, dic):
sub = [x for x in dic.values() if isinstance(x,HierarchMeta)]
newtype = type.__new__(cls, name, bases, dic)
for x in sub:
x._outer_ = newtype
return newtype
def __reduce__(cls):
if hasattr(cls, '_outer_'):
return getattr, (cls._outer_, cls.__name__)
else:
return cls.__name__
# uses the HierarchMeta metaclass
class Elm:
__metaclass__ = HierarchMeta
def __init__(self, **stuff):
self.__dict__.update(stuff)
def __repr__(self):
return %s %s % (self.__class__.__name__, self.__dict__)
# example
class X(Elm):
class Y(Elm):
pass
class Z(Elm):
pass
import pickle
x = X(a=1)
y = X.Y(b=2)
z = X.Z(c=3)
xs = pickle.dumps(x)
ys = pickle.dumps(y)
zs = pickle.dumps(z)
print pickle.loads(xs)
print pickle.loads(ys)
print pickle.loads(zs)
pedronis$ python2.4 example.py
X {'a': 1}
Y {'b': 2}
Z {'c': 3}
[*]:
--- pickle.py.orig Wed Mar 30 20:37:14 2005
+++ pickle.py Thu Mar 31 21:09:41 2005
@@ -298,12 +298,19 @@
issc = issubclass(t, TypeType)
except TypeError: # t is not a class (old Boost; see SF #502085)
issc = 0
+reduce = None
if issc:
-self.save_global(obj)
-return
+for x in t.__mro__:
+if x is not object and '__reduce__' in x.__dict__:
+reduce = x.__dict__['__reduce__']
+break
+else:
+self.save_global(obj)
+return
# Check copy_reg.dispatch_table
-reduce = dispatch_table.get(t)
+if not reduce:
+reduce = dispatch_table.get(t)
if reduce:
rv = reduce(obj)
else:
___
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] Pickling instances of nested classes
Walter Dörwald wrote: For XML: 1) Those classes are the element types and the nested classes are the attributes. 2) Being able to define those attributes as separate classes makes it possible to implement custom functionality (e.g. for validation or for handling certain attribute types like URLs, colors etc.) and 3) Those classes get instantiated when an XML tree is created or parsed. A framework that does this (and my main motivation for writing this :)) is XIST (see http://www.livinglogic.de/Python/xist/). For the ORM case: Each top level class defines a table and the nested classes are the fields, i.e. something like this: class person(Table): class firstname(Varchar): The person's first name null = False class lastname(Varchar): The person's last name null = False class password(Varchar): Login password def validate(self, value): if not any(c.islower() for c in value) and \ not any(c.isupper() for c in value) and \ not any(c.isdigit() for c in value): raise InvalidField(password requires a mix of upper and lower case letters and digits) Instances of these classes are the records read from the database. A framework that does something similar to this (although AFAIK fields are not nested classes is SQLObject (http://sqlobject.org/) So is this change wanted? useful? implementable with reasonable effort? Or just not worth it? notice that in this cases often metaclasses are involved or could easely be, so if pickling would honor __reduce__ or __reduce_ex__ on metaclasses (which right now it doesn't treating their instances as normal classes) one could roll her own solution without the burden for the language of implementing pickling of nested classes in general, so I think that would make more sense, to add support to honor __reduce__/__reduce_ex__ for metaclasses. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
Josiah Carlson wrote: Greg Ewing [EMAIL PROTECTED] wrote: Josiah Carlson wrote: Since PEP 310 was already mentioned, can we just say that the discussion can be boiled down to different ways of spelling __enter__/__exit__ from PEP 310? It's not quite the same thing. PEP 310 suggests a mechanism with a fixed control flow -- do something on entry, do the code block, do something on exit. A general block-passing mechanism would give complete control to the function as to when and how to call the block. I would like to ask a question. Does Python want or need Ruby code blocks? I ask because that is what is being offered to cure what ails us. Don't get me wrong, I'm sure code blocks can solve quite a few problems (and is used as such in Ruby), but I'm not convinced that it is the solution for Python. Any manual on Ruby will invariably discuss code blocks as one of the most powerful features Ruby has to offer. Sounds great. Sounds like a great big sledgehammer that can be used to do a bunch of things...so what is currently being proposed as a use for them, and what can't they do (that would be really nice)? They are being offered, right now, as a setup and finalization mechanism. Essentially a way of allowing people to wrap their own blocks of code in custom try/finally code, or whatever their minds can think up. Ok, __enter__/__exit__ offers that. What else? If you were to pass your generator as a code block, then you could finalize a generator [1], and even raise exceptions in your code block, but it still wouldn't allow one to pass exceptions into a currently running generator (a long standing problem such that if we could, then we would get generator finalization for free [2]). What else? Let's dig back into the python-dev archives... http://mail.python.org/pipermail/python-dev/2003-February/032739.html Guido: - synchronized-like, where the block should connect to its environment - property-like, where the block should introduce a new scope, and the caller should be able to inspect or control that scope's namespace The synchronized-like thing is the custom try/finally, aka __enter__/__exit__ as specified in PEP 310. The property-like thing was perhaps to be an easier way to generate properties, which fairly quickly fell to the wayside in discussion, seemingly because people didn't see a need to add thunks for this. Later XML DOM parsing came into the discussion, and was quickly dismissed as being not possible due to the Python parser's limited lookahead. Someone else mentioned that thunks could be used to generate a switch statement, but no elaboration was done, and no PEP was actually written (switch has also had its own PEP, and even talk of a peephole optimization for certain if/elif/else blocks to be made into dictionary lookups...) So where has all this reading gotten me? To the point that I believe previous discussion had concluded that Ruby-style code blocks have little use in Python. *shrug* well, I think some people desire a more streamlined way of writing code like: def f(...) ... def g(...) ... x = h(...,f,g) [property, setting up callbacks etc are cases of this] were f,g etc definitions would appear inline and the whole has a statement flavor; because this is Python a form that does not involve a lot parantheses would be nice. Of course if the functions then are allowed to change the surrounding bindings this could be used for resource release issues etc. Notice that decorators basically support a special case of this. But yes, apart for the issue of rebinding (and if one wants non-local returns), this is stricly about sugar. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
Brian Sabbey wrote:
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a
substitute of lambda for cases like:
f(lambda: ..., ...)
where the function is the first argument, and then there are further
arguments.
I do not see why you say suite-based thunks cannot be used in the case
in which the function takes more than one argument. Using the syntax I
described earlier, they work in just that way:
def pickled_file(thunk, name):
...
new_data = thunk(pickle.load(f))
...
with greetings from pickled_file('greetings.pickle'):
...
value greetings
One can make an analogy with self. Both the thunk and self can be
passed automatically as the first argument, and further arguments can
follow. In this way, functions that already take a thunk as a first
argument (such as sort) can be re-used without modification.
Of course now one has a problem with things that take functions as last
arguments, wich if I rembember correctly is the natural position in
Ruby. Unless the syntax involve placeholders (likely icky) one is going
to have this kind of limitations. My point is that a suite-based syntax
can only be a half substitute for lambda and anyway requiring a suite
seems overkill and unnatural for the just 1 expression case, for example
predicates. IOW a suite-based syntax is not a lambda killer in itself, I
would not try to stress that point.
Apart this one very hard problem, it would be nice to be able to define
and pass more thunks simultaneously. In particular a more concise
syntax for
def setx(self, v): self._x = v
def getx(self): return self._x
x = property(getx,setx)
was considered in the past discussions about the topic a worthy goal.
Here I can make another analogy with self. Just as python does not give
syntactic support for multiple dispatch because (I assume) it would
require major syntax changes
multiple dispatch has nothing to do with syntax, in fact usual call
syntax is sufficient, and people do use multiple dispatch sometimes,
and decorators now can be even used to sugar up the definition side
of it.
for something that would be rarely used, I
do not think
well that's up to discussion to discover
it is worth it to give syntactic support for multiple
thunks. If only a fraction epsilon of functions take a single thunk,
then I would guess that epsilon**2 take two thunks, and it is not
worth creating syntax for such a small number of cases, especially if
that syntax compromises what would otherwise be a much cleaner syntax
for the single thunk case.
well, but this is stated without even trying to come up with a syntax
for that case. Notice that the first time around Guido himself would
have preferred if achievable a multithunk syntax, he obviously can have
changed his mind. But, yes, syntax vs expressivity is the key issue here.
___
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] RE: code blocks using 'for' loops and generators
Jim Jewett wrote: It may be time to PEP (or re-PEP), if only to clarify what people are actually asking for. Brian Sabbey's example from message http://mail.python.org/pipermail/python-dev/2005-March/052202.html *seems* reasonably clear, but I don't see how it relates in any way to for loops or generators, except as one (but not the only) use case. def add(thunk1, thunk2, other): print thunk1(1,2) + thunk2(3,4) + other with x,y from add(100): value x*y also a,b: # yikes?? value a*b # this is thunk2 To make my own understanding explicit: (1) Calls for Ruby blocks or thunks are basically calls for placeholders in a function. These placeholders will be filled with code from someplace else, but will execute in the function's own local namespace. (2) A function as a parameter isn't good enough, because the passed-in function can't see bindings in the surrounding larger function. (It still sees the lexical scope it which it was defined.) (3) A function as a parameter isn't good enough, because the passed-in function can't modify bindings in the surrounding larger function. (4) A thunk could be used today be creating a string (rather than a pre-compiled function) and substituting in the thunk's string (rather than the code to which it would compile) before execution, though this would be ugly. (5) A thunk *might* be do-able with exec or eval if a function's locals were still a dictionary. notice that while closures with the current semantics of def cannot rebind, the internal mechanism for closures is perfectly capable of supporting rebinding. So thunks could be function objects. (6) This has nothing whatsoever to do with for loops or generators, except as a common use case. In particular, thunks may be used to lock/unlock or unwind-protect some resource. Generators are not the only place this is needed, but they have made the what do you mean, __del__ might never get called? problem even worse, and Ruby often solves these with a Ruby Block. (7) A __leave__ or __exit__ special method really turns into another name for __del__. It might still be useful if it came with semantics of I explicitly don't care what order cycles are broken; call me as soon as my object is garbage and who cares if it gets resurrected. There have been recipes (from Tim?) for emulating this by using a proxy to the resource, so that no __del__ cycles can form. -jJ ___ 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/pedronis%40strakt.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] Adding any() and all()
Peter Astrand wrote: On Fri, 11 Mar 2005, Paul Moore wrote: Not sure this is pertinent but anyway: any and all are often used as variable names. all especially often and then almost always as a list of something. It would not be good to add all to the list of words to watch out for. Also, all is usually thought of as a list of Using any and all as variables hides the builtins, but doesn't disallow their use elsewhere. Personally, though, I wouldn't use any or all as variable names, so that's a style issue. Even though you can use them as variables (and shadow the builtins), you will still get warnings from pychecker. The code will also be harder to read: When you see all in the middle of some code, you don't know if it's referring to the builtin or a variable. Personally, I think Python has too many builtins already. to extend the naming pool, FWIW CL calls similar things EVERY and SOME. ___ 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] PEP 309 enhancements
Nick Coghlan wrote: The initial suggestion was to provide a __get__ method on partial objects, which forces the insertion of the reference to self at the beginning of the argument list instead of at the end: def __get__(self, obj, type=None): if obj is None: return self return partial(self.fn, obj, *self.args, **self.kw) just a note: I don't see why this is not also a possible definition: return partial(self.fn, *(self.args+(obj,)), **self.kw) it may be impractical, but it would implement the direct mechanics of partial should behave like a function. ___ 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
