Mailman 3 July 2005 - Python-Dev

getch() in msvcrt does not accept extended characters.
by Darryl Dixon July 5, 2005

July 5, 2005

Hi, I'm sorry, I don't seem to have done a very good job at explaining the situation. I'll try again: 'getch()' is a low-level function provided on Windows to capture a single character of input from a user, /without echoing it to the screen/. As far as I can tell there's no other way of doing this with Python on Windows. The Python interface to this function is in the C code in msvcrtmodule.c, which has a (very thin) wrapper around the raw OS system call. Microsoft provide a way of accepting both normal ASCII codes, and extended characters via this system call. Currently, the Python wrapper in msvcrtmodule.c only supports the semantics of getting the bare ASCII codes, and not the extended characters. I would strongly suggest that it should support both. So, I guess in answer to the questions raised below; 1) I can't do it in Python code without getch() (hence the original email) 2) I would argue that in fact getch() is 'broken' in its current Python implementation, as it doesn't support what the OS implies /should/ be supported (and, indeed, if I input an extended character in response to a 'getch()' call, all I get back currently is an empty string). Hope this helps, D Fredrik wrote: >Darryl Dixon wrote: > >> Microsoft support capturing extended characters via _getch, but it requires making a >> second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 >> or 0xE0). > >so why not do that in your python code? > >> The relevant chunk of code in Python that would probably need to be >> changed to support this appears to be in msvcrtmodule.c: > >if you change msvcrt, you'll break all the programs that uses getch() in >the prescribed way... > ></F> -- Darryl Dixon <esrever_otua(a)pythonhacker.is-a-geek.net>

3 3

Re: [Python-Dev] Terminology for PEP 343
by Nick Coghlan July 5, 2005

July 5, 2005

Raymond Hettinger wrote: >>""" >>With Statements and Suite Management > > > > This is nicely done :-) > > Nit: Replace "e.g." with "such as". > > BTW, do you support changing __exit__ to __leave__? I think it provides > a small but useful gain in usability. I was initially -0 on the idea, and I've moved to a solid -1 after spending more time thinking about it. The only real pro I can see for 'leave' is that it is more common than 'exit' in conversational English, particularly when using the past tense. However, I've come to see significant pros for staying with 'exit': 1. 'Exit' is more precise than 'leave'. 'exit' has just the one real meaning - to go out of something. It has a couple of variants on the theme, and can be used as both a verb and a noun, but the basic meaning stays the same. However, the same cannot be said for 'leave'. In addition to its usage as a synonym for 'exit', it can be used in the sense of not taking something ('leave it behind'), not doing something ('leave the lights on') or handing over responsibility ('leave it to me'). When used as a noun, it refers to permission ('you have my leave') and absences ('annual leave'). 'Exit' covers just what we mean, while 'leave' covers that and a hell of a lot more, leading me to favour 'exit' as the more precise term. 2. Enter/exit and arrive/leave are the natural terminology pairings in English. The first pair are more specific, implying the existence of an 'inside' and an 'outside', while the latter pair are significantly less fussy (e.g. consider arriving at and leaving a picnic in the park, versus trying to enter and exit that same picnic). It is just a quirk of the language that the more general term 'leave' is substituted for many uses of 'exit' (particularly when the past tense is involved). I suspect the single syllable of 'left' tends to win out over the three syllable verbal gymnastics of 'exited' (try saying the two words out loud - I found the difference to be surprising, and significantly more marked than the difference between 'enter' and 'arrive'). In our case, code is written and read far more often than it is spoken, again leading me to favour the use of 'exit', this time as the more natural counterpart to 'enter'. 3. The common starting letter gives a nice visual pairing for enter/exit. This is not the case for enter/leave, again leading to a preference for the use of 'exit'. Using 'leave' instead of 'exit' is an interesting idea, but I think these are good reasons to stick with the PEP 343 terminology. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

1 0

python-dev Summary for 2005-06-16 through 2005-06-30 [draft]
by Steven Bethard July 4, 2005

July 4, 2005

Here's our draft of the summary for the second half of June. As usual, please let me, Tony or Tim know if you have any comments or corrections. -- Steven Bethard ===================== Summary Announcements ===================== ------------------ OSCON Registration ------------------ Though if you haven't yet registered, you've already missed the early registration period (which ended June 20), you should still consider taking a look at the O'Reilly Open Source Convention (OSCON). Guido assures us that "the Python program is really good!" Contributing Thread: - `Please spread the word about OSCON early reg deadline <http://mail.python.org/pipermail/python-dev/2005-June/054259.html>`__ ========= Summaries ========= ------------ PEP Clean Up ------------ Raymond Hettinger decided to go through the `list of PEPs`_ and do some spring cleaning (late for the Northern Hemisphere, but early down south). * Rejection of `PEP 303`_ ("Extend divmod() for Multiple Divisors") was proposed on the grounds that it has been open for two and half years and hasn't generated discussion or support, is unpersuasive, and unnecessary. No-one spoke up for it (and some against), so it is now rejected. * Rejection of `PEP 254`_ ("Making Classes Look More Like Types") was proposed on the grounds that it is only an empty stub and is unlikely to ever get filled-out. No-one spoke up either way, and it is now rejected. * Rejection of `PEP 265`_ ("Sorting Dictionaries by Value") was proposed on the grounds that as of Python 2.4 its use case is easily solved with a one-line sorted() solution. Several people agreed, and no-one disagreed, so the PEP is now rejcted. * Rejection of `PEP 276`_ ("Simple iterator for ints") was proposed on the grounds that the principal use case was largely met by enumerate() and that the proposed syntax was problematic. Guido agreed, so the PEP was rejected. * Rejection of `PEP 281`_ ("Loop Counter Iteration with range and xrange") was proposed on the grounds that it too was solved by the enumerate() built-in. Guido agreed again, and this PEP too was rejected. * Rejection of `PEP 294`_ ("Type Names in the types Module") was proposed on the grounds that a centralized repository of type names was a mistake and that neither the "types" nor "new" modules should be carried forward to Python 3.0. No-one disagreed, and the PEP was rejected. * Rejection of `PEP 313`_ ("Adding Roman Numeral Literals to Python" - yes, this is a real PEP!) was proposed, and the PEP was rejected. * Rejection of `PEP 336`_ ("Make None Callable") was proposed on the grounds that no support has grown beyond the original poster, and that it fails the tests of obviousness, necessity, clarity, and explicitness. Many people, including Guido, agreed, and the PEP was rejected. * Raymond suggested updating `PEP 284`_ ("Integer for-loops"), but several people spoke up against it, including Guido, so the PEP was rejected. * Raymond asked whether `PEP 330`_ ("Python Bytecode Verification") had any known uses. Guido said that he believes that a verification tool has some value, but if someone wants to add it to Tools/scripts, no PEP is required, so the PEP was rejected. * A.M. Kuchling volunteered to take over `PEP 206`_ ("Python Advanced Library", or the "Batteries Included" PEP) and rewrite it to describe a set of third-party packages to complement the standard library. This was approved, and so he's now the maintainer. * Raymond suggested accepting `PEP 312`_ ("Simple Implicit Lambda"), which resulted in the most discussion of any of the PEP recommendations. However, Guido hates the unary colon syntax, and it was decided that the PEP needs to go back to the drawing board and find a more Pythonic syntax (perhaps an alternative unary operator). The PEP is now deferred. * Raymond asked whether `PEP 237`_ ("Unifying Long Integers and Integers") was now complete and could be marked as final. Guido noted that it was complete for 2.x, but that phase C will be implemented in Python 3.0, as the PEP states. He indicated that he would be fine with marking `PEP 237`_ as final and moving this phase to `PEP 3000`_; at the time of writing, this hadn't been done yet. .. _list of PEPs: http://wwww.python.org/peps .. _PEP 303: http://www.python.org/peps/pep-0303.html .. _PEP 265: http://www.python.org/peps/pep-0265.html .. _PEP 254: http://www.python.org/peps/pep-0254.html .. _PEP 276: http://www.python.org/peps/pep-0276.html .. _PEP 281: http://www.python.org/peps/pep-0281.html .. _PEP 294: http://www.python.org/peps/pep-0294.html .. _PEP 313: http://www.python.org/peps/pep-0313.html .. _PEP 336: http://www.python.org/peps/pep-0336.html .. _PEP 284: http://www.python.org/peps/pep-0284.html .. _PEP 330: http://www.python.org/peps/pep-0330.html .. _PEP 206: http://www.python.org/peps/pep-0206.html .. _PEP 312: http://www.python.org/peps/pep-0312.html .. _PEP 237: http://www.python.org/peps/pep-0237.html .. _PEP 3000: http://www.python.org/peps/pep-3000.html Contributing Threads: - `Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors <http://mail.python.org/pipermail/python-dev/2005-June/054283.html>`__ - `Propose to close PEP 254 -- Making Classes Look More Like Types <http://mail.python.org/pipermail/python-dev/2005-June/054357.html>`__ - `Propose to reject PEP 265 -- Sorting Dictionaries by Value <http://mail.python.org/pipermail/python-dev/2005-June/054262.html>`__ - `Propose to reject PEP 276 -- Simple iterator for ints <http://mail.python.org/pipermail/python-dev/2005-June/054276.html>`__ - `Propose to reject PEP 281 -- Loop Counter Iteration with range and xrange <http://mail.python.org/pipermail/python-dev/2005-June/054263.html>`__ - `Propose to reject PEP 294 -- Type Names in the types Module <http://mail.python.org/pipermail/python-dev/2005-June/054353.html>`__ - `Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python <http://mail.python.org/pipermail/python-dev/2005-June/054278.html>`__ - `Propose to reject PEP 336 -- Make None Callable <http://mail.python.org/pipermail/python-dev/2005-June/054280.html>`__ - `Propose updating PEP 284 -- Integer for-loops <http://mail.python.org/pipermail/python-dev/2005-June/054316.html>`__ - `Question about PEP 330 -- Python Bytecode Verification <http://mail.python.org/pipermail/python-dev/2005-June/054354.html>`__ - `Request to rewrite PEP 206 <http://mail.python.org/pipermail/python-dev/2005-June/054287.html>`__ - `Recommend accepting PEP 312 -- Simple Implicit Lambda <http://mail.python.org/pipermail/python-dev/2005-June/054303.html>`__ - `Is PEP 237 final -- Unifying Long Integers and Integers <http://mail.python.org/pipermail/python-dev/2005-June/054305.html>`__ [TAM] ------------------------------------------- PEP 342: Coroutines via Enhanced Generators ------------------------------------------- Raymond Hettinger withdrew `PEP 288`_, suggesting that the exception-handling parts were now covered in `PEP 343`_ and that the generator-attributes part was never very popular. Though he seemed to think `PEP 342`_ could replace the generator-attributes part, he was concerned that `PEP 342`_ was proposing too extensive a set of changes, as it modified the basic for-loop and continue statement semantics, and created a split between new- and old-style iterators. Phillip J. Eby took over `PEP 342`_, made some changes to address these issues, added some motivating examples, and provided a `prototype patch`_ implementing the proposal. `PEP 342`_ no longer modifies for-loop or continue statements or introduces a new iterator protocol, instead choosing to modify the generator-iterator type by adding the methods: - send(value) which acts like the previously proposed single-argument form of next(). (Introducing a new method instead of overloading next() minimizes overhead for simple next() calls.) Calling send(value) before the generator has advanced to the first yield-expression raises a TypeError. - throw() which injects exceptions at the point of the generator's last yield-expression. - close() which injects a GeneratorExit exception into the generator to make sure that it terminates. PEP 342 also attempts to ensure that this close() method will be called when a generator-iterator is garbage-collected. Additionally, Phillip's patch addressed some garbage collection issues, having generators set their gi_frame to None when they finish, and modifying gcmodule.c to check for tp_del methods on instance objects (instead of just on heap types) so that the close() methods of generators would be properly invoked. .. _PEP 288: http://www.python.org/peps/pep-0288.html .. _PEP 342: http://www.python.org/peps/pep-0342.html .. _PEP 343: http://www.python.org/peps/pep-0343.html .. _prototype patch: http://python.org/sf/1223381 Contributing Threads: - `Withdrawn PEP 288 and thoughts on PEP 342 <http://mail.python.org/pipermail/python-dev/2005-June/054261.html>`__ - `Implementing PEP 342 (was Re: Withdrawn PEP 288 and thoughts on PEP 342) <http://mail.python.org/pipermail/python-dev/2005-June/054309.html>`__ - `gcmodule issue w/adding __del__ to generator objects <http://mail.python.org/pipermail/python-dev/2005-June/054334.html>`__ - `Generator enhancements patch available <http://mail.python.org/pipermail/python-dev/2005-June/054337.html>`__ [SJB] -------------------------------------------------- Adding Jason Ordenorff's path module to the stdlib -------------------------------------------------- Reinhold Birkenfeld suggested that Jason Ordenorff's `path module`_ should be in the standard library as it has a large user base, frequently c.l.py praises, is a superior interface to OS paths than the existing os.path module, and could more easily be made to properly support unicode paths. Phillip J. Eby reviewed the module and made a list of suggested changes, primarily changing so that there is only one way to do things and clearing up naming confusion between the module and the existing os.path module, but was generally in favour of inclusion. The suggestion was to call the object either "path" or "Path" and put it either in the os module or os.path module, although Guido vetoed os.path.path and Tony Meyer begged for more differentiation between the path class and path module than a single character's case. Early enthusiasm suggested that a PEP wasn't needed to include the module, as there was general agreement about the inclusion and all but minor details. Guido disagreed, however, asking whether there was a need for a completely different mechanism for doing the same things that os.path already does, and inevitable disgreements about details (e.g. time in seconds, or a datetime object?) reinforced the need for a PEP. Discussion was still continuing at the end of the summary period; a PEP seems the likely outcome. .. _path module: http://www.jorendorff.com/articles/python/path/ Contributing Thread: - `Adding the 'path' module (was Re: Some RFE for review) <http://mail.python.org/pipermail/python-dev/2005-June/054439.html>`__ [TAM] ------------------------------- PEP 304 searches for a champion ------------------------------- Skip Montanaro wrote `PEP 304`_ ("Controlling Generation of Bytecode Files") a couple of years ago, and has mostly sat idle other than minor updates. Skip has no personal use for the PEP, and can't offer championing for it than continuing to respond to people's inputs. He asked whether anyone would be willing to take up championship of the PEP, or if it could be rejected. There were a couple of people interested in the idea, but no-one has yet volunteered to take the PEP from Skip. .. _PEP 304: http://www.python.org/peps/pep-0304.html Contributing Threads: - `PEP 304 - is anyone really interested? <http://mail.python.org/pipermail/python-dev/2005-June/054419.html>`__ - `PEP 304 "Controlling Generation of Bytecode Files" - patch updated <http://mail.python.org/pipermail/python-dev/2005-June/054264.html>`__ [TAM] ------------------------- Merging float and Decimal ------------------------- Fredrik Johansson suggested that Python floats and decimal.Decimal objects should be merged together much in the way that Python ints and longs have been. The idea would be that a binary or decimal represenation could be selected at runtime using a context object like decimal.Context. This would allow code like:: >>> from __future__ import new_float_behaviour >>> 1.1 1.1 >>> import sys >>> sys.float_context.binary = True >>> 1.1 1.1000000000000001 One issue would be the extent to which various context settings could be respected for both binary and decimal floating-point numbers. Since binary floating-point numbers would be represented using C floats, they would not have direct access to the traps and flags that decimal.Decimal floats do because these signals are not available in C. This issue could possibly be addressed by maintaining platform-dependent code for accessing traps and flags. People seemed generally to agree with the proposal, with Raymond Hettinger suggesting a roadmap: first move decimal.Decimal objects to C code, next introduce decimal literals, and then perhaps use decimal floating-point numbers as the default in Python 3.0. Contributing Thread: - `Decimal floats as default (was: discussion about PEP239 and 240) <http://mail.python.org/pipermail/python-dev/2005-June/054409.html>`__ [SJB] ------------------------------------------------ API differences between builtin set and sets.Set ------------------------------------------------ Barry Warsaw noted that builtin set objects (unlike sets.Set objects) do not have .union_update() methods as aliases for their .update() methods. He also pointed out that the documentation for builtin set objects does not cover the .update() method, and wrongly indicates that the set methods only accept sequences, not iterables. Raymond Hettinger indicated that the API change was intentional, but that he would fix the documentation if someone assigned him an appropriate patch. Contributing Thread: - `Inconsistent API for sets.Set and build-in set <http://mail.python.org/pipermail/python-dev/2005-June/054518.html>`__ [SJB] ---------------------------------- Using the alternate form of iter() ---------------------------------- In the dowhile threads, Jp Calderone pointed out a useful case for the alternate form of iter() which takes a no-argument function to call repeatedly, and a sentinel value to look for:: for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): f2.write(chunk) This started a brief discussion on how this very useful idiom could be made easier to read. I suggested that it would be nice if iter() had a signature like unittest.TestCase.assertRaises which accepts ``*args`` and ``**kwargs`` to be passed to the function when it is called. This would have to be a Python 3.0 change because it's backwards incompatible, but would look something like:: for chunk in iter('', f1.read, CHUNK_SIZE): f2.write(chunk) Benji York, Michael Hudson and James Y Knight suggested that functional.partial (which will be available in Python 2.5) is a more general solution because it does not require argument reordering and it can also be used in the occasional cases that require multiple callables:: for chunk in iter(partial(f1.read, CHUNK_SIZE), ''): f2.write(chunk) Contributing Thread: - `iter alternate form and *args and **kwargs <http://mail.python.org/pipermail/python-dev/2005-June/054256.html>`__ [SJB] -------------------------------------- Adding lightweight cooperative threads -------------------------------------- Adam Olsen outlined various problems with the current state of Python threading (they are expensive, unpredictable, uninterupptible, fail silently, and have finely grained atomicity), and proposed adding lightweight cooperative threads to Python (including a new operator for threaded calls, and new statement for creating threads). The proposal received no support, however, with Adam pointed towards `Stackless Python`_ and greenlets from `the Py lib`_ as similar solutions that do not require modification of the language. `PEP 342`_ was also touted as a solution - the PEP includes a short (<50 lines) cooperative threading example. .. _Stackless Python: http://www.stackless.com/ .. _the Py lib: http://codespeak.net/py .. _PEP 342: http://www.python.org/peps/pep-0342.html Contributing Thread: - `Adding Python-Native Threads <http://mail.python.org/pipermail/python-dev/2005-June/054430.html>`__ [TAM] ------------------------------ Syntax for ignoring exceptions ------------------------------ Dmitry Dvoinikov proposed a shorthand for ignoring exceptions:: ignore TypeError: do stuff [else: do other stuff] which would replace:: try: do stuff except TypeError: pass [else: do other stuff] Most people seemed to think that generally the except and/or else clauses would be non-trivial, so the savings of two lines were not really worth the complications to the language. Contributing Thread: - `Explicitly declaring expected exceptions for a block <http://mail.python.org/pipermail/python-dev/2005-June/054387.html>`__ [SJB] ---------------------------------- Proposed new serialization format. ---------------------------------- Simon Wittber proposed a pre-PEP for `RFE 46738`_, to provide a safe, documented class for serialization of simple python types; however, many people commented that they felt that there were already sufficient serialization formats. Simon felt that they were all slow, bloated or unsafe, but wasn't able to convince anyone that there was a need for a new format. .. _RFE 46738: http://python.org/sf/467384 Contributing Thread: - `PEP for RFE 46738 (first draft) <http://mail.python.org/pipermail/python-dev/2005-June/054313.html>`__ [TAM] --------------------------------------- Behavior of subprocess.call(stdin=PIPE) --------------------------------------- In a followup to a `sourceforge patch`_, Stuart Bishop asked that subprocess.call() close the input stream if it receives the keyword argument stdin=PIPE. Since subprocess.call() creates a process and waits for it to complete before returning, the stdin pipe is never available to the caller and thus can never be written to while the process is running. Stuart suggested that if subprocess.call() closed the input stream when stdin=PIPE, subprocesses that incorrectly read from stdin would break out with an error immediately instead of hanging. While people seemed to agree that the current behavior of subprocess.call(stdin=PIPE) was mildly undesirable, there was disagreement as to the solution. Michael Chermside suggested that subprocess.call(stdin=PIPE) should raise an exception, while Peter Åstrand felt that keeping the subprocess.call() wrapper around subprocess.Popen() as simple as possible spoke against complicating it with error checking code. .. _sourceforge patch: http://www.python.org/sf/1220113 Contributing Thread: - `subprocess.call() and stdin <http://mail.python.org/pipermail/python-dev/2005-June/054405.html>`__ [SJB] =============== Skipped Threads =============== - `getch() in msvcrt does not accept extended characters. <http://mail.python.org/pipermail/python-dev/2005-June/054506.html>`__ - `Terminology for PEP 343 <http://mail.python.org/pipermail/python-dev/2005-June/054525.html>`__ - `List copy and clear (was Re: Inconsistent API for sets.Set and build-in set) <http://mail.python.org/pipermail/python-dev/2005-June/054522.html>`__ - `Multiple expression eval in compound if statement? <http://mail.python.org/pipermail/python-dev/2005-June/054164.html>`__ - `refcounting vs PyModule_AddObject <http://mail.python.org/pipermail/python-dev/2005-June/054232.html>`__ - `Some RFE for review <http://mail.python.org/pipermail/python-dev/2005-June/054438.html>`__ - `Please spread the word about OSCON early reg deadline <http://mail.python.org/pipermail/python-dev/2005-June/054259.html>`__ - `New python developer <http://mail.python.org/pipermail/python-dev/2005-June/054509.html>`__ - `Possible C API problem? <http://mail.python.org/pipermail/python-dev/2005-June/054471.html>`__ - `PyPI: no space left on device <http://mail.python.org/pipermail/python-dev/2005-June/054331.html>`__ - `PySWT -- Python binding of SWT using GCJ + SIP <http://mail.python.org/pipermail/python-dev/2005-June/054502.html>`__ - `Subclassing in 'C' <http://mail.python.org/pipermail/python-dev/2005-June/054434.html>`__ - `is type a usable feature? <http://mail.python.org/pipermail/python-dev/2005-June/054422.html>`__ - `misplaced PEP <http://mail.python.org/pipermail/python-dev/2005-June/054377.html>`__ - `using pyhon from the MSYS shell <http://mail.python.org/pipermail/python-dev/2005-June/054505.html>`__ - `[Python-checkins] python/dist/src/Lib Cookie.py, 1.17, 1.18 <http://mail.python.org/pipermail/python-dev/2005-June/054447.html>`__ - `[Python-checkins] python/dist/src/Tools/bgen/bgen bgenGenerator.py, 1.17, 1.18 bgenObjectDefinition.py, 1.29, 1.30 bgenType.py, 1.15, 1.16 bgenVariable.py, 1.6, 1.7 scantools.py, 1.37, 1.38 <http://mail.python.org/pipermail/python-dev/2005-June/054444.html>`__ - `floatobject.c 2.136 <http://mail.python.org/pipermail/python-dev/2005-June/054513.html>`__

2 1

Re: [Python-Dev] Terminology for PEP 343
by Delaney, Timothy (Tim) July 4, 2005

July 4, 2005

Phillip J. Eby wrote: > Expand your mind. :) "Resource" can include whatever objects you > want it > to -- or no objects at all. A resource can be conceptual - like for > example the user's attention, or the contents of a status bar or log > message, or the timing/profiling of an activity. I think maybe you're Well, HR considers me to be a resource ... ;) Personally, I'm very happy with considering anything a with statement manages as a resource. Tim Delaney

1 0

Money module
by Facundo Batista July 4, 2005

July 4, 2005

People: The Money two-days sprint in EuroPython 2005 has finished. We advanced a lot. The pre-PEP is almost done, and the corresponding test cases are all written. We need to finish the structure procesing for currency general information, and bring general functions to the module, but most of the decision-taking part is done. So, it's not a chaos any more, it's in a very coherent state, but yet it's not everything written in stone. So, if you want to influence somehow in the Money module, this is the moment to get in and participate. The project is in SourceForge (http://sourceforge.net/projects/pymoney), and there we have a mailing list (just to not bloat this one). Thank you. . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

3 4

floatobject.c 2.136
by Raymond Hettinger July 4, 2005

July 4, 2005

I'm getting a compiler warning from your checkin: C:\py25\Objects\floatobject.c(1430) : warning C4244: 'initializing' : conversion from 'double ' to 'float ', possible loss of data

4 4

Re: [Python-Dev] reducing self.x=x; self.y=y; self.z=z boilerplate code
by Ralf W. Grosse-Kunstleve July 2, 2005

July 2, 2005

Aahz wrote: > This is off-topic for python-dev. Please take it to comp.lang.python. > (It's not immediately obvious that this is off-topic, I know, but please > take my word for it.) Done: http://mail.python.org/pipermail/python-list/2005-July/288292.html Sorry for creating so much noise here. Cheers, Ralf

1 0

reducing self.x=x; self.y=y; self.z=z boilerplate code
by Ralf W. Grosse-Kunstleve July 2, 2005

July 2, 2005

Josiah Carlson wrote: > Now, don't get me wrong, definining __slots__ can be a pain in the > tookus, but with a proper metaclass, that metaclass can define the > __slots__ attribute based on the argument list for __init__(). > > There you go. Where? The meta-class idea sounds interesting. Could you work it out? > A syntax change is wholly unnecessary. I wonder why everybody gets so agitated about a syntax enhancement proposal. I am not proposing a syntax change! I know enhancing the syntax is work, but shouldn't a syntax leading to less code clutter be the higher value? IMO a long-term gain counts for much more than avoiding a one-time investment implementing a useful feature. Take, for example, the syntax enhancement supporting "import foo as bar". I could just as easily write: import foo bar = foo del foo "A syntax change is wholly unnecessary." Why was it important enough anyway? It was a good enhancement because it is clearly more expressive and reduces clutter. In my experience the self.x=x; self.y=y etc. problem arises much more often than the problem solved by "import foo as bar". IMO a *built-in* solution is much more important in practice. Why does everybody have to reinvent the adopt_init_args/initialize wheel, or have to sheepishly type self.x=x...? I am not wedded to the .x idea, but counter-proposals should be at least approximately as powerful as what I propose. > class grouping: > def __init__(self, _x, _y, _z): > initialize(self, locals()) The "_x" alternative looks interesting but is problematic: it doesn't have a special meaning so far, but it is also not a syntax error. You are also not getting rid of the odd (from a learner's viewpoint) requirement to stick in "locals()". Remember where Python comes from: it goes back to a teaching language, enabling non-geeks to write programs. "initialize(self, locals())" doesn't fit that bill, especially if you have to import initialize first. In contrast def __init__(self, .x, .y, .z): ^^^^^^^^ almost looks like ^^^^^^ self.x and should therefore be easy to learn and remember. I'd also be happy with def __init__(self, self.x, self.y, self.z): which wouldn't be too different from unpacking tuples (and is currently a syntax error). However, remember, elegance = power/length. .x above has the same power as self.x, but is shorter, therefore more elegant. :) Hoping-that-this-leads-to-some-consensus-for-a-*built-in*-solution-ly yours, Ralf

5 4

reducing self.x=x; self.y=y; self.z=z boilerplate code
by Ralf W. Grosse-Kunstleve July 1, 2005

July 1, 2005

Hi, I often find myself writing: class grouping: def __init__(self, x, y, z): self.x = x self.y = y self.z = z I hate it, and every time I show this to a Python newcomer I get that skeptic look. How about this for a change? class grouping: def __init__(self, .x, .y, .z): pass This is supposed to work the same way as: def __init__(self, x, y, z): self.x = x del x self.y = y del y self.z = z del z Currently the .x syntax leads to: def __init__(self, .x, .y, .z): ^ SyntaxError: invalid syntax I.e. it seems to me that there shouldn't be any backward compatibility issues. I'll write a PEP if I hear a few voices of support. (Otherwise I'll stick to my "adopt_init_args" workaround: http://phenix-online.org/cctbx_sources/libtbx/libtbx/introspection.py which does a similar job but doesn't look as elegant and is also quite inefficient). Cheers, Ralf

7 6

Re: [Python-Dev] reducing self.x=x; self.y=y; self.z=z boilerplate code
by Ralf W. Grosse-Kunstleve July 1, 2005

July 1, 2005

Jp Calderone wrote: > If you use vars(self).update(locals()), it even looks halfway > pleasant ;) I'm not sure what python-dev's current opinion of > vars(obj) is though (I'm hoping someone'll tell me). http://docs.python.org/lib/built-in-funcs.html#l2h-76 is pretty clear: vars([object]) Without arguments, return a dictionary corresponding to the current local symbol table. With a module, class or class instance object as argument (or anything else that has a __dict__ attribute), returns a dictionary corresponding to the object's symbol table. The returned dictionary should not be modified: the effects on the corresponding symbol table are undefined. > Of course, both of these fall over for __slots__'ful classes. It'd be > nice if there were a general way to deal with attributes of an > instance, regardless of the implementation details of its memory > layout. I agree. Ideally I'd like this class grouping: __slots__ = True def __init__(self, .x, .y, .z): pass to be equivalent to: class grouping: __slots__ = ["x", "y", "z"] def __init__(self, x, y, z): self.x = x del x self.y = y del y self.z = z del z Cheers, Ralf

1 0